Skip to content
ReleasesGitHub

Changelog — New Feature

Subscribe with RSS

All areas
New Feature
Clear all

GitHub Actions now selects among multiple AWS STS Credential Providers

The Aembit GitHub Action can now choose which AWS Security Token Service (STS) Federation Credential Provider to use when an Access Policy holds more than one.

An Access Policy can hold more than one AWS STS Federation Credential Provider, each with its own Access Key ID selector. Until now, a GitHub Actions workflow needed a self-hosted runner running Aembit Edge to reach more than one IAM role from a single Access Policy. The alternative was a direct call to the Edge API.

Key capabilities:

Minimum version required:

  • Aembit GitHub Action 1.3.0
  • Edge SDK 1.34.0

For how Aembit matches a selector to a Credential Provider, see Using multiple AWS STS Credential Providers.

Tags:

MCP Identity Gateway 1.34.5794 release

Aembit has released MCP Identity Gateway version 1.34.5794.

For the latest available versions of these components, see the Edge Components Supported Versions page.

Key Updates:

  • MCP Tool Access Control enforcement: The Gateway now enforces MCP Tool Access Control, a Content Security Provider you add to an Access Policy. The Tool Visibility control decides which MCP tools an AI agent discovers, and the Tool Invocation control decides which MCP tools an AI agent can call.
  • Glob patterns for MCP tool names: An entry in either control takes an exact MCP tool name or a glob pattern, and matching is case-sensitive. A pattern matches the name the MCP server publishes, not the prefixed name an AI agent displays. See MCP Tool Access Control tool name reference.
  • Tool filtering decisions in your events: MCP workload events record which control decided an MCP tool’s fate, which rules matched, which MCP tools a listing removed, and how many it returned, under application.mcp.contentSecurity.

A security update also shipped in this build.

Tags:

Aembit Edge SDKs for TypeScript and Python now available

The Aembit Edge SDKs are language libraries that wrap the Aembit Edge API. Your application authenticates a workload and retrieves credentials through a few method calls, so you write no HTTP requests and manage no token lifecycles. The SDK runs inside your application process, so there’s nothing extra to deploy or operate alongside it.

Use an SDK when you can change the application’s source and you want credential retrieval to be explicit in your code. It suits environments where running a proxy next to the workload isn’t practical, such as serverless functions, ephemeral CI containers, and platforms where you don’t control the runtime.

What’s new:

  • TypeScript and Python libraries: Install the SDK from its language package registry and call it from your application. The SDK repository carries the installation steps, the developer reference, and runnable examples.
  • Workload attestation, token lifecycle, and credential retrieval: The SDK collects identity evidence from the environment it runs in, caches the resulting access token in memory, refreshes that token before it expires, and requests the credential your application needs.
  • Seven supported Trust Providers: Attest with AWS Metadata Service, AWS Role, Azure Instance Metadata Service, GCP Identity Token, GitHub, GitLab, or OIDC ID Token. For per-language coverage, see Edge SDK Trust Providers.
  • Integration guides for four platforms: Follow a worked setup for AWS EC2, AWS Lambda, GCP Cloud Run, or Vercel OIDC.

The console-side configuration matches every other Aembit access path. You configure a Trust Provider to verify the workload’s identity and a Credential Provider to supply the credential. An Access Policy then authorizes a specific Client Workload to reach a specific Server Workload.

To retrieve your first credential, see the Edge SDK quickstart. For the full overview, see Aembit Edge SDKs.

Tags:

Aembit CLI now available as a glibc-linked Linux binary

Aembit CLI 1.34.5772 adds a second Linux amd64 archive, aembit_agent_cli_linux_amd64_glibc_<version>.tar.gz, that links dynamically against glibc 2.28 or newer. The default archive still links statically against musl, runs on amd64 and arm64 with no dependency on the host C library, and remains the recommended download.

If the default build has worked for you, keep using it. The glibc build is for organizations whose policy requires glibc, and for working around rare bugs in the default build. For example, the default build reports failed to lookup address information on some hosts where dig and curl resolve the same name, because musl rejects a DNS resolver response that glibc tolerates. See DNS lookup fails with failed to lookup address information for that case. The glibc build is amd64 only, and it doesn’t run on Alpine Linux or in distroless images. See Choose a Linux build for the full comparison.

Tags:

Google Cloud Identity-Aware Proxy (IAP) JWT Trust Provider now available

Aembit now offers a Google Cloud Identity-Aware Proxy (IAP) JWT Trust Provider. It validates the signed x-goog-iap-jwt-assertion token that IAP forwards to your workloads on Google Kubernetes Engine (GKE), Cloud Run, and App Engine after IAP authenticates a user.

Use this Trust Provider instead of the OIDC ID Token Trust Provider when IAP authenticates users in front of your workloads. IAP issues signed JWTs, but they aren’t standard OpenID Connect (OIDC) ID tokens. Google publishes the IAP signing keys at a static JWKS endpoint with no discovery document, and the audience identifies a Google Cloud resource rather than an OIDC client ID.

Aembit resolves Google’s signing key at validation time rather than from a preconfigured key set. It reads the key ID from the token, then retrieves the matching public key from Google’s IAP key endpoint. Aembit caches that key in memory, so your workload only forwards the token.

What’s new:

  • GCP IAP JWT Trust Provider type: Supply the IAP audience that identifies the Google Cloud resource IAP protects. Aembit pins the issuer and resolves the signing keys, so you don’t upload a key or enter a discovery URL.
  • Match rules on IAP token claims: Authorize on aud, iss, sub, and email, or on any additional claim IAP signs using custom_claim. The aud attribute supports wildcards, so one rule can cover more than one backend service in the same project.
  • Terraform support: Manage the Trust Provider through the Aembit Terraform provider with the aembit_trust_provider resource.

This Trust Provider validates the user identity that IAP asserts. To validate the identity of a workload running in Google Cloud, use the GCP Identity Token Trust Provider instead.

For the audience formats, match rule attributes, and configuration steps, see Google Cloud Identity-Aware Proxy (IAP) JWT Trust Provider.

Tags:

Content Security now available

Aembit now offers Content Security, an Access Policy component that inspects content and enforces the verdict an inspection service returns. Content Security inspects Model Context Protocol (MCP) traffic that flows through the Aembit MCP Identity Gateway.

In the Access Policy Builder, Content Security is an optional component positioned between Access Conditions and Credential Providers. It adds inspection to the request path without changing how the policy’s other components authorize access.

What’s new:

  • Content Security Access Policy component: Add Content Security to a policy to inspect the MCP traffic that policy governs. Inspection applies only to the policies you add it to.
  • CrowdStrike AIDR integration: CrowdStrike AI Detection and Response (AIDR) inspects tool listings, tool call inputs, and tool call outputs, and returns an allow, block, or transform verdict that Aembit enforces. AIDR requires an active CrowdStrike AIDR for Agents subscription.
  • Inspection decisions in your events: Access Authorization Events record the Content Security component a policy identified, and MCP Workload Events record the decision AIDR returned, including CrowdStrike’s request ID for correlating an event with the CrowdStrike console.

CrowdStrike AIDR Content Security is separate from the CrowdStrike Access Condition, which evaluates endpoint posture. Configuring one doesn’t enable the other.

To add the component to a policy, see Add CrowdStrike AIDR to a policy.

Tags:

AWS Application Load Balancer JWT Trust Provider now available

Aembit now offers an AWS Application Load Balancer JWT Trust Provider. It validates the signed x-amzn-oidc-data token that an AWS Application Load Balancer (ALB) forwards to your workloads after the ALB authenticates a user session with OpenID Connect (OIDC).

Use this Trust Provider instead of the OIDC ID Token Trust Provider when your workloads sit behind an ALB that authenticates users. ALB tokens require the AWS Application Load Balancer JWT Trust Provider.

Aembit resolves the signing key at validation time rather than from a preconfigured key set. It reads the AWS region and key ID from the token, validates the region before it contacts AWS, then retrieves and caches the matching regional public key. Aembit rotates those keys for you, so your workload only forwards the token.

What’s new:

  • AWS Application Load Balancer JWT Trust Provider type: Select the type and add your match rules. The type has no configuration fields of its own, so you don’t set a region or upload a signing key.
  • Match rules on ALB token claims: Authorize on aud, iss, sub, and email, or on any additional claim your identity provider forwards through the ALB using custom_claim. You can add more than one custom_claim rule to a single Trust Provider.
  • Terraform support: Manage the Trust Provider through the Aembit Terraform Provider with the aembit_trust_provider resource.

This Trust Provider works with Aembit Edge. Agent Controller support isn’t available yet.

For the match rule attributes, configuration steps, and troubleshooting, see AWS Application Load Balancer JWT Trust Provider.

Tags:

OpenAI WIF Credential Provider now available

Aembit now offers an OpenAI Workload Identity Federation (WIF) Credential Provider. Your workloads can call the OpenAI API with short-lived tokens that Aembit obtains on their behalf instead of long-lived API keys.

Aembit acts as a trusted OIDC issuer. You register Aembit as a Workload Identity Provider in OpenAI. Then, whenever an Access Policy grants a workload access, Aembit exchanges its issued assertion for a short-lived OpenAI access token.

What’s new:

  • OpenAI WIF Credential Provider type: Configure the Identity Provider ID, service account, and optional audience that Aembit presents when it exchanges tokens with OpenAI.
  • Built-in connection verification: Use Verify to confirm the trust between Aembit and your OpenAI federation setup before you put the Credential Provider into an Access Policy.
  • Terraform support: Manage the OpenAI WIF Credential Provider through the Aembit Terraform Provider.

For setup instructions, see Configure an OpenAI WIF Credential Provider.

Tags:

MCP Identity Gateway sessions can persist across restarts

A self-hosted MCP Identity Gateway can now keep its MCP sessions in Valkey instead of in process memory. Persisted sessions survive a service restart or an upgrade, and more than one Gateway instance can share them.

Set AEMBIT_VALKEY_URL on the install command to enable it. The Gateway keeps sessions in memory when you leave that variable unset, which remains the default. An in-memory store ends every open session on restart. AEMBIT_MCP_SESSION_IDLE_TTL_SECS sets how long an unused session lives, and it defaults to 12 hours for both store types.

Sessions hold MCP protocol state, not authentication state. The Gateway still validates every request’s token and evaluates Access Policies per request, so persistence doesn’t extend anyone’s access.

This change requires no configuration if you use the Aembit-managed service or want the in-memory default. It ships in MCP Identity Gateway 1.32.5098, alongside the session ID binding in this build; see the session IDs bound to the authenticated user entry. For configuration and operational detail, see Session persistence.

Tags:

Client ID Metadata Document (CIMD) identification now available

Aembit can now identify MCP client workloads with a Client ID Metadata Document (CIMD). A CIMD is a JSON document the client hosts at a public HTTPS URL, and the URL itself serves as the client’s identity. When the client presents the URL-formatted client_id, Aembit fetches the document and validates the client’s metadata, so the client can authenticate without Dynamic Client Registration.

CIMD has reached general availability, and Aembit enables it by default. To identify a Client Workload by its CIMD URL, see CIMD Client ID.

Tags:

Resource Set deletion now available

You can now delete a custom Resource Set: Resource Sets are organizational containers that group Access Policy components together, enabling you to manage configurations across different environments, regions, or use cases.Learn more when you no longer need it. Deletion is a cascading, all-or-nothing operation: Aembit removes the Resource Set and every entity it contains in a single action that either completes fully or rolls back.

What’s new:

  • Cascading deletion: Deleting a Resource Set also deletes everything it contains, including Access Policies, Client and Server Workloads, Trust Providers, Credential Providers, Access Conditions, and Standalone CAs, leaving no orphaned data behind.
  • Safeguards against accidental loss: Deletion requires Write access to the Resource Set or an administrator role, and Aembit asks you to confirm the action in a dialog that lists what it removes. You can’t delete the Default Resource Set.
  • Audit coverage: Aembit records an audit entry for each deleted entity, plus one for the Resource Set deletion itself, so the operation stays traceable through Audit Logs and Log Streams.
  • Terraform lifecycle management: Manage the same lifecycle as code with the aembit_resource_set resource. Destroying an aembit_resource_set performs the identical cascading delete, and the resource_set_id argument assigns or filters entities by Resource Set.

For the full workflow and its effects, see Delete a Resource Set. For managing Resource Sets as code, see Scaling Aembit with Terraform.

Tags:

Claude API WIF Credential Provider now available

Aembit now offers a Claude Workload Identity Federation (WIF) Credential Provider. Your workloads can call the Claude API with short-lived tokens that Aembit obtains on their behalf instead of long-lived API keys.

Aembit acts as a trusted OIDC issuer. You register Aembit as a federation issuer in Claude Console. Then, whenever an Access Policy grants a workload access, Aembit exchanges its issued assertion for a short-lived Claude access token.

What’s new:

  • Claude WIF Credential Provider type: Configure the federation rule, organization, service account, and optional workspace from your Claude Console, plus the requested scope and token lifetime.
  • Built-in connection verification: Use Verify to confirm the trust between Aembit and your Claude federation rule before you put the Credential Provider into an Access Policy.
  • Terraform support: Manage the Claude WIF Credential Provider through the Aembit Terraform Provider.

For setup instructions, see Configure a Claude WIF Credential Provider.

Tags:

Aembit Secrets Operator now supports more credential types

Aembit Secrets Operator 1.32.322 is now available.

Secrets Operator now retrieves any credential type your Access Policy issues—not just HashiCorp Vault tokens. A new credentialType field on the AembitSecretRefreshSchedule resource selects which Credential Provider type Aembit uses, and the managed Kubernetes Secret mirrors the Aembit Edge API credentials response for that provider.

  • New credentialType field: Choose OAuthToken (the default), ApiKey, UsernamePassword, AwsStsFederation, or GoogleWorkloadIdentityFederation. Each type writes its own Secret data keys—for example, UsernamePassword produces username and password, and AwsStsFederation produces awsAccessKeyId, awsSecretAccessKey, and awsSessionToken. See Credential types and Secret data keys.
  • Backward compatible: Schedules that omit credentialType keep writing a single token key, so existing HashiCorp Vault and cert-manager configurations need no change.
  • Clearer mismatch errors: When credentialType doesn’t match the configured Credential Provider, the schedule reports Aembit Edge API returned a credentials response with no populated fields instead of writing a blank Secret.
  • AWS credential redaction: Secrets Operator redacts the AWS access key, secret access key, and session token values from its debug logs.
Tags:

Aembit Secrets Operator now available

Aembit Secrets Operator 1.31.298 is now available.

Secrets Operator is a Kubernetes operator that authenticates to the Aembit platform and synchronizes credentials into Kubernetes Secrets. Applications consume managed secrets the same way they consume any other Kubernetes Secret.

Key capabilities in this release:

  • Kubernetes Service Account authentication: Authenticate using the operator’s in-cluster ServiceAccount token, validated against the cluster’s OIDC endpoint. No per-cluster signing key required. Verified on Amazon EKS and K3s. See Set up Secrets Operator for configuration.
  • OIDC symmetric key authentication: Alternatively, authenticate using OIDC tokens with symmetric key signing (HS256) for custom claims and non-Kubernetes identity scenarios.
  • Proactive credential renewal: Credentials refresh at 80% of their TTL, or sooner when you configure a shorter refreshInterval, ensuring applications always have a valid credential.
  • Multi-namespace install: You can now use the same Helm release name across multiple namespaces on the same cluster without resource name conflicts.
Tags:

Oracle Database now generally available

Oracle Database protocol support is now available for production use.

What’s new:

  • Oracle Database GA: Support for Oracle 19c and 21c is now available for production use. Aembit injects username/password credentials into Oracle TNS connections at authentication time, eliminating static database passwords without modifying your application code.
  • TLS connections: Oracle database connections can now use TLS via the TCP/IP with TLS (TCPS) protocol. You can enable TLS independently on the client-to-proxy and proxy-to-database sides by checking the TLS checkbox on the Port and Forward to Port fields in the Server Workload configuration.
  • Improved Oracle error handling: Agent Proxy now returns clearer ORA-* error messages when Oracle authentication fails, making it easier to diagnose credential injection and configuration issues.
  • Prometheus observability: Oracle credential injection events now appear in the aembit_agent_proxy_credential_injections_total metric with application_protocol="oracleDatabase", so you can monitor Oracle credential operations alongside other supported protocols.

For setup instructions, see Create an Oracle Database Server Workload. For a technical overview, see About Oracle Databases.

Tags:

Refresh token support for MCP authorization flows

OIDC ID Token and Aembit Access Token Credential Providers now support refresh tokens for MCP Authorization Server flows. This feature applies exclusively to MCP Authorization Server use cases.

What’s new:

  • An Enable Refresh Token Support option on OIDC ID Token and Aembit Access Token Credential Providers.
  • An Absolute Token Lifetime setting that controls how long refresh tokens remain valid for exchanging for new access tokens after initial issuance.
  • Refresh tokens are single-use. Each exchange returns a new refresh token.

When enabled, the MCP Authorization Server returns refresh tokens alongside access tokens during OAuth token requests. MCP clients can exchange a refresh token for a new access token and a new refresh token, maintaining an active session without completing a new authorization flow. This setting doesn’t affect other credential flows, such as Agent Proxy.

To use this feature, edit your Credential Provider, toggle Enable Refresh Token Support to on, and set the Absolute Token Lifetime.

For details, see Token refresh, OIDC ID Token, and Aembit Access Token.

Tags:

MCP Authorization Server now supports unauthenticated flows

Aembit’s MCP Authorization Server now supports OAuth flows that don’t require end-user authentication. This enables use cases like ChatGPT apps and other MCP integrations where user sign-in isn’t needed or desired.

What’s new:

  • An Enforce SSO option on Client Workloads with the Redirect URI identifier type. Enforce SSO is on by default, preserving the current behavior of requiring user authentication.
  • When Enforce SSO is on, a multi-select dropdown lets you choose which SSO identity providers appear on the MCP authentication page. By default, the dropdown selects all configured identity providers.
  • When Enforce SSO is off, the MCP Authorization Server issues access tokens without redirecting users to an identity provider. The flow needs no Trust Provider, but a Credential Provider is still required.
  • Access Policies still apply as an authorization control. You can turn off policies or entities to block token issuance.

To use this feature, edit your Client Workload, select the Redirect URI client identifier, and configure Enforce SSO under MCP Authorization Configuration.

For details, see Authentication support and MCP Authorization Server architecture.

Tags:

MCP Identity Gateway now supports MCP resources

Aembit has released MCP Identity Gateway version 1.29.4419.

Key Updates:

  • MCP resource support for the Identity Gateway

The MCP Identity Gateway now proxies MCP resource requests alongside tool requests. MCP servers that expose resources, such as files, database schemas, or application data, are now accessible through the Gateway. The same identity-aware access policies, credential isolation, and audit logging that govern tool invocations apply.

What’s new:

  • resources/list discovers available resources across all assigned MCP servers. The Gateway fans out the request and aggregates results from all connected servers.
  • resources/read retrieves a specific resource by URI from the appropriate MCP server.

No action required. Resource support is available automatically after upgrading to MCP Identity Gateway 1.29.4419. Your existing access policies, Trust Providers, and Credential Providers apply to resource requests with no configuration changes.

For details, see MCP resource support.

Tags:
Copyright © 2026. All rights reserved.Privacy PolicyTerms of ServiceTrust CenterMetadata collectionContact Aembit