Skip to content

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.

Aembit Cloud configuration updates

Aembit Cloud corrects configuration workflows across Content Security, Client Workloads, Trust Providers, and authorization event reporting.

Key Updates:

  • Content Security tool lists: Switching between Allow and Block in a Content Security Provider keeps the tool list you configured, and Remove Tools clears the whole list in a separate step that asks you to confirm.
  • Redirect URI fields: A Redirect URI field on a Client Workload accepts a pasted value in every position, inserts a long pasted value rather than overwriting the text around it, and shows one validation message at a time. Copying the full contents of a field leaves the browser responsive.
  • Trust Provider secrets in custom Resource Sets: Terraform reads the state of a Trust Provider secret when that Trust Provider belongs to a custom Resource Set.
  • Authorization event timespan filters: The date filters on Access Authorization Events offer a maximum timespan of 24 hours, the window over which the Aembit Tenant UI makes authorization events available.

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.

Developer Guide combines the API, CLI, and SDK documentation

The Developer Guide is now the single home for every way you integrate with Aembit from code, commands, or infrastructure. It replaces the separate API Guide and CLI Guide, which each covered one surface and left you to work out which one fit your workload. The new Edge SDK section lands inside it rather than beside it.

The guide opens by separating the two decisions an integration involves. First, choose how your workload gets a credential at runtime, through Agent Proxy, the Edge SDK, the Aembit CLI, or the Edge API. Second, choose how you manage the Aembit configuration behind that path, in the Aembit Tenant UI, through the Cloud API, or as Terraform code.

What’s new:

  • One guide for every developer surface: Aembit SDKs, Aembit APIs, Aembit CLI, Agent Proxy, and the local development and testing pages all sit under /dev-guide/.
  • A comparison of every credential path: The overview compares Agent Proxy, the Edge SDK, the Aembit CLI, and the Edge API side by side, so you can pick one before you read its section.
  • Shared local development and testing pages: One page covers local development and one covers testing and debugging across every integration path.

Every URL under the old /api-guide/ and /cli-guide/ paths redirects to its new location, so existing bookmarks and links keep working.

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.

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.

Edge components dependency security updates

Agent Proxy 1.34.5755 and Aembit CLI 1.34.5772 fix two published Rust advisories in bundled third-party libraries: RUSTSEC-2026-0190 in anyhow and RUSTSEC-2026-0204 in crossbeam-epoch. The same build upgrades the quinn, AWS SDK, pcap, and postgres-protocol dependencies. Agent Injector 1.34.433 fixes RUSTSEC-2026-0185 in quinn-proto.

These updates shipped in the same build as the Edge components release with Agent Proxy fixes and expanded workload events.

Edge components release with Agent Proxy fixes and expanded workload events

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

  • Agent Proxy 1.34.5755
  • AWS Lambda Extension 1.34.175
  • Agent Injector 1.34.433
  • Sidecar Init 1.34.138
  • Helm Chart 1.34.566
  • AWS ECS Terraform 1.34.1
  • Aembit CLI 1.34.5772

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

Key Updates:

  • Workload events carry the authorization chain: Agent Proxy events now include the authorizationChain field, an ordered list of the context IDs of the authorization events behind the request, so you can trace an event back to the directive and credential retrievals that authorized it.
  • Aembit-generated responses keep their outcome fields: When Aembit answers a request in place of the Server Workload, the response event now reports the generated response’s severity, outcome.result, and outcome.reason. Earlier versions cleared those fields between the request and the response, so the event recorded an incomplete outcome.
  • Windows installer honors the gRPC keep-alive properties: The MSI now applies AEMBIT_TENANT_GRPC_PING_INTERVAL_SECS and AEMBIT_TENANT_GRPC_PING_TIMEOUT_SECS when you pass them as install-time properties. See Configuring gRPC keep-alives.
  • Linux installer validates Agent Proxy arguments: The Linux installer script now checks Agent Proxy arguments before it installs, so an invalid value in a numeric environment variable such as AEMBIT_HTTP_IDLE_TIMEOUT_SECS is reported at install time.
  • Container image updates: Agent Injector and Sidecar Init move to a newer Debian base image, and AWS Lambda Extension updates its Go version.

Dependency security fixes also shipped in this build. See Edge components dependency security updates.

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.

MCP Identity Gateway 1.34.5733 release

Aembit has released MCP Identity Gateway version 1.34.5733.

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

Key Updates:

  • Higher fanout timeout defaults: The Gateway now waits longer for your assigned MCP servers on most of the MCP methods it fans out, which gives a server that’s still starting up, or one answering from a cold cache, room to respond. A self-hosted Gateway can override any of these timeouts as a last resort; see MCP Identity Gateway raises fanout timeout defaults.
  • Nine new Prometheus metrics: The Gateway’s metrics endpoint reports on upstream fanout behavior, authentication failures, JWKS refreshes, session cleanup, and readiness probe stability.
  • Every Gateway metric documented: The metrics reference now lists all 20 MCP-specific metrics the Gateway exposes, with the type and labels for each and the values each label takes. See Prometheus metrics.

MCP Identity Gateway raises fanout timeout defaults

MCP Identity Gateway 1.34.5733 raises how long the Gateway waits for your assigned MCP servers when it fans a request out to them. The earlier defaults were short enough that a server still starting up, or one answering from a cold cache, could run past them.

Timeout1.33.56541.34.5733
initialize3s10s
notifications_initialized500ms1s
tools_list1s3s
proactive_tools_list3s5s
resources_list1s3s
reinit_initialize10s10s
reinit_notifications_initialized500ms1s
reinit_tools_list1s5s

reinit_initialize is the one timeout this build leaves unchanged.

The new defaults require no configuration and apply to both deployment models as soon as you upgrade. They’re high enough that an AI client typically reaches its own timeout before the Gateway reaches one of these, so most deployments never need to change them.

A self-hosted Gateway can override any of these timeouts as a last resort, using the AEMBIT_MCP_GATEWAY_TIMEOUT environment variable. The installer doesn’t forward this variable to the running service, so setting it takes a systemd drop-in. For the accepted names, the value format, and the drop-in, see MCP Identity Gateway environment variables. Aembit sets these values for you on the Aembit-managed service.

These updates shipped in the same build as the MCP Identity Gateway 1.34.5733 release.

Certificates replaces TLS Decrypt in Edge Components

The Aembit Admin UI page for managing your Aembit Tenant Root CA and your Standalone Certificate Authorities is now named Certificates, replacing the earlier name TLS Decrypt. Find it under Edge Components in the top ribbon menu.

The page keeps all its existing fields, and the TLS Decrypt capability keeps its name. Only the page label changed, so the TLS checkbox on a Server Workload and every other TLS Decrypt setting keep their current locations.

See Configure TLS Decrypt and How to configure a Standalone CA.

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.

MCP Identity Gateway 1.33.5654 release

Aembit has released MCP Identity Gateway version 1.33.5654.

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

For each Content Security decision, the Gateway records a single MCP Workload Event carrying the severity, outcome result, and outcome reason.

This build also broadens the MCP traffic that Content Security inspects; see MCP Identity Gateway content inspection coverage. For Content Security inspection of MCP traffic, use MCP Identity Gateway version 1.33.5654 or later.

MCP Identity Gateway content inspection coverage

A security update for the MCP Identity Gateway broadens the MCP traffic that Content Security inspects.

The Gateway normalizes responses that MCP servers stream as server-sent events before inspection, so Content Security inspects those responses along with the rest of the session. The Gateway also applies the policy’s Fail Open on Error setting to requests it can’t read and to protocol errors. A policy set to fail closed blocks those requests.

These updates shipped in the same build as the MCP Identity Gateway 1.33.5654 release.

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.

MCP Identity Gateway 1.33.5547 release

Aembit has released MCP Identity Gateway version 1.33.5547.

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

Key Updates:

  • More reliable upstream reconnection: When the Gateway reestablishes a connection to an MCP server, it now refreshes the available tools as part of that reconnection, and reports a clear error if the reconnection doesn’t succeed.
  • Deployment modes documented: The MCP Identity Gateway concepts page now describes the two ways to run the Gateway: self-hosted on your own host, or managed by Aembit at your per-Tenant endpoint. The traffic flow and policy model are identical in both. See MCP Identity Gateway concepts.

Dependency security updates also shipped in this build; see MCP Identity Gateway dependency security updates.