Skip to content
ReleasesGitHub

Changelog — Credential Provider

Subscribe with RSS

Credential Provider
All changes
Clear all

Access Policy builder search and Credential Provider value checks

The Select Existing tab in the Access Policy builder now searches and pages through all the entities you can access. Lists of more than 100 Client Workloads, Server Workloads, Trust Providers, Credential Providers, or Access Conditions no longer hide entries past the first page.

Credential Provider fields that take a Literal or Dynamic value now check the value against its type. Aembit rejects a save, including one through the API or Terraform, when a Literal value contains a ${...} expression or a Dynamic value contains no valid ${...} expression. In the Aembit Tenant UI, entering a ${...} expression in a field switches it to Dynamic. See Dynamic claims.

Tags:

Edge components release with Ubuntu 26.04 support

Aembit has released new versions of the following components and packages:

  • Agent Proxy 1.34.6014
  • Aembit CLI 1.34.6014
  • AWS Lambda Extension 1.34.185
  • Helm Chart 1.34.571
  • AWS ECS Terraform 1.34.4

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

Key Updates:

  • Agent Proxy installs on Ubuntu 26.04 LTS: The Linux installer now completes on Ubuntu 26.04 LTS hosts. See Supported versions.
  • Private Network Access credential retrieval: Agent Proxy retrieves and injects credentials for Access Policies whose Credential Provider uses Private Network Access. Agent Proxy 1.34.5755 could fail credential retrieval for these Access Policies.

A dependency security fix also shipped in this build. See Edge components dependency security updates.

Tags:

Dynamic claims now support SAML assertions

Dynamic claims can now read values from a SAML 2.0 response, so a Credential Provider can issue a credential bound to each SAML user’s own identity.

Aembit receives SAML responses when users sign in through the MCP Authorization Server or the MCP Identity Gateway. A SAMLv2 Response Trust Provider validates each response, and three expressions read values from its assertion:

  • ${saml.response.subject.nameId} returns the Subject NameID that identifies the user.
  • ${saml.response.issuer} returns the identity provider that issued the assertion.
  • ${saml.response.attributes['<name>']} returns a named attribute, such as a user’s groups.

If a SAML expression can’t resolve to a value, Aembit denies the request and issues no credential. The Credential Provider form in the Aembit Tenant UI shows the SAML syntax with examples. See SAML assertion claims.

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:

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:

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 event correlation and platform fixes

This update brings event correlation to MCP Identity Gateway workload events, along with fixes across Credential Provider, Access Policy, and Client Workload workflows.

This update includes:

  • MCP Identity Gateway 1.32.5098

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

Key Updates:

  • Workload event correlation: MCP Identity Gateway workload events now carry the client and server workload identity (name and id), so you can tie an event to a specific workload in the Cloud UI without mapping it by hand.
  • Azure OAuth Credential Provider verification: Resolved an issue that caused Azure OAuth Credential Provider verification to fail after a recent build, so these providers verify successfully again.
  • Access Condition URL validation: The Endpoint and Token Endpoint URL fields for Access Condition integrations now show the correct “Invalid Value” message instead of a “Required” message.
  • Concurrent policy edits: Deleting an Access Policy at the same time as a patch request no longer produces errors, preserving data integrity during high-volume policy updates.
  • CIMD authorization flow: Fixed an issue where an OIDC session expiring mid-flow could clear the Client Workload cookie and interrupt authorization.
  • Form validation focus: Saving a form with an invalid URL field now scrolls that field into view across entity editors, and External ID tooltips no longer get cut off in long list views.

Session IDs are now bound to the authenticated user in this build, closing a privilege-escalation gap. See the Security entry. Client ID Metadata Document (CIMD) identification also reached general availability in this update. See the announcement.

Tags:

MCP User-Based Access Token callback URL format

MCP User-Based Access Token Credential Providers now generate their read-only callback URL in the form https://<tenantId>.id.<region>.aembit.io/mcp-auth/userauth/<cp-id>/callback.

What this means for you:

  • Existing Credential Providers - Providers created before this change keep their original callback URL, which takes the form https://<tenantId>.mcp.<region>.aembit.io/userauth/<cp-id>/callback. Updating a provider doesn’t regenerate its callback URL. Both formats remain valid, so you don’t need to take any action or re-register anything with your MCP server vendor.
  • New Credential Providers - Aembit assigns the callback URL when you save the Credential Provider. Save the provider first, then copy the read-only value and register it with the MCP server vendor.

Always copy the exact value shown in the Credential Provider rather than constructing the URL yourself.

For details, see Configure MCP User-Based Access Token Credential Provider.

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:

Edge components release with reliability and CLI enhancements

Aembit has released new versions of the following components and packages:

  • Helm Chart
  • Terraform ECS module
  • VM Agent Proxy package
  • VM Agent Controller package
  • Agent CLI
  • AWS Lambda Extension
  • AWS Lambda Layer
  • Agent Proxy

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

Key Updates:

  • X.509-SVID retrieval through Aembit CLI: The aembit credentials get command now accepts --client-tls-private-key to retrieve a SPIFFE-compliant X.509-SVID certificate from the existing X.509-SVID Credential Provider. You supply a PEM-encoded private key; Aembit CLI generates the certificate signing request locally and returns the signed chain in CLIENT_CERT_CHAIN, and the private key never leaves the local machine.
  • Configurable gRPC keep-alives: Two optional environment variables, AEMBIT_TENANT_GRPC_PING_INTERVAL_SECS and AEMBIT_TENANT_GRPC_PING_TIMEOUT_SECS, let Agent Proxy send keep-alives on its connection to your Tenant so it detects a dead connection and reconnects faster. They’re off by default and useful for networks, such as a Secure Web Gateway, that stall idle connections.
  • CA certificate configuration for the Cloud connection: AGENT_TRUST_PATH again lets you supply a custom CA certificate for the Agent Proxy’s connection to the Aembit Cloud, which is useful when an inspecting proxy terminates TLS on outbound traffic.
  • Configurable HTTP idle timeout on Windows: The Windows installer now exposes AEMBIT_HTTP_IDLE_TIMEOUT_SECS, letting you tune the idle timeout for HTTP/1.1 connections handled by the Agent Proxy.
  • Caching enhancements: Improvements to credential caching across the Agent Proxy and Aembit CLI.
  • Improved upstream proxy diagnostics: When the Agent Proxy can’t reach a configured upstream HTTP proxy, logs now include the full error source chain instead of a generic connection error, making a misconfigured upstream proxy easier to diagnose.
  • General improvements: Stability, robustness, and dependency updates across edge components, including improved hardware-identification handling during process identification on Linux virtual machines.
Tags:

Aembit CLI now retrieves X.509-SVID certificates

Aembit CLI now retrieves SPIFFE-compliant X.509-SVID certificates directly from the X.509-SVID Credential Provider.

Aembit has released new versions of the following components and packages:

  • Aembit CLI

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

Key Updates:

  • X.509-SVID retrieval through Aembit CLI: The aembit credentials get command now accepts --client-tls-private-key to retrieve a SPIFFE-compliant X.509-SVID certificate from the existing X.509-SVID Credential Provider. You supply a PEM-encoded private key. Aembit CLI generates the Certificate Signing Request (CSR) locally, submits it through the credential retrieval flow, and returns the signed certificate chain in CLIENT_CERT_CHAIN. The private key never leaves the local machine.
Tags:

End-to-end mTLS between Client and Server Workloads with SPIFFE X.509-SVID certificates

Introducing end-to-end mutual TLS (mTLS) between Client Workloads and Server Workloads using SPIFFE-compliant X.509-SVID certificates.

Aembit has released new versions of the following components and packages:

  • Agent Proxy
  • Cloud (Tenant UI + API)
  • EdgeAPI
  • Terraform Provider
  • Helm Chart
  • Terraform ECS module
  • AWS Lambda Extension
  • AWS Lambda Layer

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

Key Updates:

  • Agent Proxy outbound mTLS with X.509-SVID: Agent Proxy can now establish outbound mTLS connections to Server Workloads using SPIFFE-compliant X.509-SVID certificates, with no application code changes required.
  • mTLS Authentication method for Server Workloads: A new authentication method, mTLS Authentication with the x509 Certificate scheme, lets Server Workloads validate the client certificate that Agent Proxy presents during the mTLS handshake.
  • X.509-SVID Credential Provider: A new Credential Provider type that issues SPIFFE-compliant X.509 certificates. This release’s Agent Proxy update is what consumes them for outbound mTLS to Server Workloads.

Agent Proxy can now establish outbound mTLS connections to Server Workloads using SPIFFE-compliant X.509-SVID certificates, enabling certificate-based workload-to-workload authentication without application code changes.

What’s new:

  • In-memory private key: Agent Proxy generates an ECDSA key pair in memory for each X.509-SVID certificate. The private key is never written to disk and is never transmitted to Aembit Cloud.
  • Automatic rotation at 80% of certificate lifetime: Agent Proxy refreshes the certificate well before expiration, generating a new key pair on each refresh. In-progress mTLS connections continue using the prior certificate until they close.
  • mTLS Authentication for Server Workloads: A new Server Workload authentication method (mTLS Authentication with the x509 Certificate scheme) lets the Server Workload side validate the X.509-SVID certificate that Agent Proxy presents during the handshake.

For the end-to-end workflow and procedure, see Enable mTLS on a Server Workload. For the authentication-method catalog, see Authentication methods and schemes.

Aembit is introducing a new X.509-SVID Credential Provider type that issues SPIFFE-compliant X.509 certificates to Client Workloads, signed by an Aembit Standalone CA.

What’s new:

  • SPIFFE-compliant identity in the URI Subject Alternative Name (SAN): Every issued certificate embeds the workload’s SPIFFE ID as a URI SAN, so SPIFFE-aware Server Workloads can authenticate the Client Workload during the TLS handshake.
  • Literal or dynamic Subject and SPIFFE ID: Configure either field with a fixed value or with template expressions that resolve at issuance time using workload attestation attributes.
  • Configurable Extended Key Usage: Default to id-kp-clientAuth for outbound mTLS, or add id-kp-serverAuth to use the same certificate as a server credential.
  • Configurable certificate lifetime: Set the lifetime in minutes (default 15). Agent Proxy automatically refreshes the certificate before expiration (typically at 80% of the configured lifetime).

For setup instructions, see Create an X.509-SVID Credential Provider. For concepts and the end-to-end issuance flow, see About the X.509-SVID Credential Provider.

Tags:

Dynamic claims now support custom environment variables

Custom environment variables on Agent Proxy and Aembit CLI can now feed into OIDC and JWT-SVID dynamic claims, gated by an explicit allowlist.

What’s new:

  • AEMBIT_ENV_VAR_ALLOWLIST: A new environment variable that defines which custom variables Agent Proxy and Aembit CLI may capture for use in dynamic claims. By default, Agent Proxy and Aembit CLI capture no custom variables.
  • Always-available Kubernetes variables: K8S_POD_NAME, K8S_NAMESPACE, and KUBERNETES_PROVIDER_ID are now usable in dynamic claims regardless of the allowlist.

For setup instructions, see Configure custom environment variables for Agent Proxy. For the dynamic claims expression syntax, see OIDC and JWT-SVID dynamic claims.

Tags:

OAuth 2.0 Authorization Code now uses centralized callback URL

The OAuth 2.0 Authorization Code Credential Provider now uses a centralized callback URL and supports an optional Final Redirect URL that supports custom or embedded integration scenarios.

What’s new:

  • Centralized Callback URL - OAuth 2.0 Authorization Code Credential Providers now use a single, centralized callback URL shared across Credential Providers on your Aembit stack. If you previously registered a per-tenant callback URL with a third-party provider, you don’t need to take any action.
  • Final Redirect URL - A new optional field that redirects users to a specified URL after completing the OAuth authorization flow, instead of returning to the Aembit Credential Provider page. Contact Aembit support to enable this feature.

For details, see OAuth 2.0 Authorization Code Credential Provider.

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 Identity Gateway enters beta with MCP Server and component copying

Aembit now offers an MCP Identity Gateway (Beta) that sits between AI agents and MCP servers, enforcing Access Policies, performing secure token exchange, and providing visibility into MCP activity. Deployed on a Linux VM, the Gateway ensures AI agents never hold direct credentials for enterprise systems.

Key capabilities:

  • Proxies MCP traffic with identity-aware policy enforcement
  • Performs secure token exchange using OAuth 2.0 and API key credentials
  • Provides per-user credential management and centralized MCP routing
  • Logs agent identity, user identity, and policy decisions for auditability
  • Fail-closed behavior—denies access by default unless explicitly allowed

For setup instructions and architecture details, see MCP Identity Gateway.

Aembit now provides an MCP Server that enables AI agents and users to query Aembit event logs using structured commands. Built on the Model Context Protocol specification, the MCP Server enables agentic observability and auditability for organizations using Aembit.

Key capabilities:

  • Query audit logs, authorization events, and workload events
  • Integrations with MCP Inspector, Claude Code, GitHub Copilot, and Visual Studio
  • Resource-set-based access scoping for least-privilege access
  • Read-only access—no create, update, or delete operations
  • Full audit trail of all MCP Server queries

For setup and connection guides, see Aembit MCP Server.

Aembit has added a new MCP User-Based Access Token Credential Provider type. This type enables per-user OAuth credentials for MCP servers using the OAuth 2.0 Authorization Code flow. The MCP Identity Gateway manages user-specific tokens when connecting to downstream MCP servers.

Key capabilities:

  • OAuth 2.0 Authorization Code flow with Proof Key for Code Exchange (PKCE) support
  • MCP Server URL discovery with auto-population of OAuth endpoints
  • Per-user credential scoping
  • Token introspection and lifetime management

For configuration details, see MCP User-Based Access Token Credential Provider.

Aembit now supports component copying between Resource Sets. You can replicate Access Policy components—including Client Workloads, Server Workloads, Trust Providers, Credential Providers, and Access Conditions—from one Resource Set to another. You can also copy entire Access Policies with all related components at once.

Key capabilities:

  • Copy individual components or entire Access Policies between Resource Sets
  • Each copy receives a unique identifier while the original remains unchanged
  • Supports environment promotion, regional deployments, and safe experimentation

For details, see About component copying and Copy components.

Tags:

Edge components release with S3 streaming and Secrets Manager improvements

Aembit has released new versions of the following components and packages:

  • Helm Chart
  • Terraform ECS module
  • Agent Proxy

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

Key Updates:

  • Improved AWS S3 upload streaming signature support
  • AWS Secrets Manager Private Network Access username/password credential support (requires Agent Proxy 1.28)

Aembit has improved Agent Proxy’s AWS S3 upload support with enhanced streaming signature handling. Agent Proxy 1.28 addresses limitations from the 1.27 release related to streaming signed payloads.

Key capabilities:

  • Improved handling of aws-chunked content encoding for streaming uploads
  • Better compatibility with AWS SDK streaming operations
  • Enhanced request signing for chunked transfer encoding

For complete documentation, see How Aembit uses AWS SigV4 and SigV4a.

The AWS Secrets Manager Credential Provider with Private Network Access now supports username/password credentials. This extends the PNA capability introduced in Agent Proxy 1.27 to include secrets stored as username/password pairs.

Requirements:

  • Agent Proxy 1.28 or later

For configuration details, see AWS Secrets Manager Credential Provider.

  • VM Agent Proxy package
  • AWS Lambda Extension
  • AWS Lambda Layer
  • Agent Proxy

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

Key Updates:

  • Added private network access support for HTTP Basic Auth Credential Providers using AWS Secrets Manager.
  • Added process name and process username as Client Workload Identifiers.
  • Extended AWS S3 support to include all SigV4 headers, enabling required signing type specification.
Tags:
Copyright © 2026. All rights reserved.Privacy PolicyTerms of ServiceTrust CenterMetadata collectionContact Aembit