Skip to content
ReleasesGitHub

Changelog — New Feature

Subscribe with RSS

All areas
New Feature
Clear all

MCP Identity Gateway 1.35.6086 release

Aembit has released MCP Identity Gateway version 1.35.6086, which relays change notifications to MCP clients and checks tool results against their output schemas.

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

Key Updates:

  • Change notifications: An MCP client using the 2026-07-28 revision of the MCP specification can send subscriptions/listen to learn when the tools, resources, or prompts it can reach change. MCP Identity Gateway relays these notifications from MCP servers using the 2026-07-28 revision. It also sends one when the client’s assigned Server Workloads or MCP Tool Access Control rules change, and when it reconnects to an MCP server. See Change notifications.
  • Tool output validation: When a tool publishes an output schema, MCP Identity Gateway checks the tool’s completed results against it. The MCP client gets error -32004 in place of a result that doesn’t match. For the results MCP Identity Gateway doesn’t check, see Tool output validation.
  • Subscription refresh interval: AEMBIT_MCP_GATEWAY_TIMEOUT accepts the subscriptions_workload_refresh_interval timeout name, which sets how often MCP Identity Gateway checks for assignment and rule changes. The default is 30 seconds.

Access token, credential, and error handling improvements and a security update also shipped in this build.

Tags:

MCP user session management now available

Each Identity Provider in the Aembit Tenant UI now has a Sessions tab that lists the MCP user sessions of the people who signed in through it. Filter the list, revoke one session, or revoke every session for a user or an MCP client at once. When you delete an Identity Provider that has active sessions, Aembit prompts you to revoke them.

Sessions exist when the Client-to-Gateway Access Policy uses an OIDC ID Token Credential Provider with Enable Refresh Token Support turned on. To get started, see Manage MCP user sessions. For what revoking a session does, see MCP user sessions.

Tags:

Agent Proxy now injects credentials for MCP Server Workloads

Agent Proxy 1.34.6014 injects credentials for Server Workloads whose Application Protocol is MCP. Agent Proxy handles this traffic as HTTP and injects the credential the same way it does for HTTP Server Workloads. Earlier versions passed MCP traffic through without injecting a credential.

Agent Proxy doesn’t read the MCP messages in this traffic, so these features of the MCP Identity Gateway don’t apply to it:

Tags:

MCP Identity Gateway 1.34.6034 release

Aembit has released MCP Identity Gateway version 1.34.6034, which serves the 2026-07-28 revision of the MCP specification.

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

Key Updates:

  • 2026-07-28 MCP specification support: MCP Identity Gateway serves MCP clients using the 2026-07-28 revision and earlier revisions. A client’s revision and a server’s revision don’t have to match, because MCP Identity Gateway negotiates each connection. The 2026-07-28 revision removes sessions, so MCP Identity Gateway doesn’t create a session for clients using that revision. See Proxied MCP methods.
  • Prompts, resources, and tasks across all assigned MCP servers: MCP Identity Gateway lists prompts and resources from every assigned MCP server. It sends each prompt or resource read to the MCP server that owns it. It routes task requests to the MCP server that created the task. It advertises the capabilities its assigned MCP servers support. It prefixes prompt and resource names with the Server Workload they came from, and returns each resource URI exactly as the MCP server reported it.
  • More timeout names: AEMBIT_MCP_GATEWAY_TIMEOUT accepts seven more timeout names, which tune the prompts/list fanout, the fan-out cap, upstream calls, upstream session caching, and Multi Round-Trip Request backoff.

Access token validation and error reporting improvements and a security update also shipped in this build.

Tags:

MCP Enterprise Managed Access Token Credential Provider now available

The MCP Enterprise Managed Access Token Credential Provider is now available in the Aembit Tenant UI. It obtains each user’s MCP server access token through your corporate identity provider, so users reach MCP servers behind the MCP Identity Gateway without a per-user consent prompt.

Aembit Cloud makes two token requests on the user’s behalf. The first asks your identity provider for an identity assertion that vouches for the user to one MCP server. The second presents that assertion to the MCP server’s authorization server in exchange for an access token, which the MCP Identity Gateway injects into the request.

To get started, prepare your identity provider for enterprise-managed access, then configure the Credential Provider. For how the exchange works, see About the MCP Enterprise Managed Access Token Credential Provider.

Tags:

Aembit Secrets Operator now delivers X.509-SVID certificates

Aembit Secrets Operator 1.34.358 and Aembit Secrets Operator Helm chart 1.34.358 are now available.

Secrets Operator now delivers X.509-SVID certificates to your Kubernetes workloads. When an AembitSecretRefreshSchedule sets credentialType: X509Svid, Secrets Operator generates a private key inside the cluster and obtains a signed certificate from Aembit. It writes both to a kubernetes.io/tls Secret that your workload uses for mutual TLS. See Deliver X.509-SVID certificates with Secrets Operator.

  • New X509Svid credential type: The Secret holds tls.crt with the signed certificate chain and tls.key with the private key. Secrets Operator sends Aembit only a certificate signing request, so the private key never leaves the cluster.
  • Automatic renewal: Secrets Operator refreshes the certificate before it expires.
  • TLS Secret type: X509Svid writes a kubernetes.io/tls Secret, while every other credential type writes a generic Secret, so switching a schedule to or from X509Svid deletes and recreates the target Secret. See Credential types and Secret data keys.
Tags:

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 for TypeScript 1.34.0
  • Edge SDK for Python 1.35.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 TypeScript SDK from npm and call it from your application. The Python SDK installs from PyPI starting with version 1.35.0. 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 and caches the resulting access token in memory. It refreshes that token before it expires and requests the credential your application needs.
  • Eight supported Trust Providers: Attest with AWS Metadata Service, AWS Role, Azure Instance Metadata Service, GCP Identity Token, GitHub, GitLab, OIDC ID Token, or Terraform Cloud. 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:
Copyright © 2026. All rights reserved.Privacy PolicyTerms of ServiceTrust CenterMetadata collectionContact Aembit