AWS Agent Registry Push Sync: CloudTrail, EventBridge, and MCP Metadata

On November 11, 2026, AWS published a push-based architecture that keeps AWS Agent Registry records aligned with live MCP tool lists whenever someone updates an Amazon Bedrock AgentCore runtime. The pattern matters because stale catalog metadata is how agent orchestrators silently call the wrong schema — and because registry search only helps when the record matches what tools/list returns on the wire.

explainx.ai previously covered what the registry does at runtime in the AWS Agent Registry discovery guide. This post is the operations layer: event triggers, cross-account routing, OAuth through AgentCore Identity, and diff-before-write semantics AWS engineers documented on the ML blog.

TL;DR

Why push sync beats pull reminders

AWS opens the post with a failure mode every multi-team agent shop recognizes: a developer ships a new tool Monday, the registry still shows last week’s schema Wednesday, and downstream agents either miss the capability or call tools with outdated arguments.

Manual catalog updates do not scale past a handful of MCP servers. Hardcoded endpoints — the anti-pattern our A2A versus MCP explainer warns about — reappear the moment teams stop trusting search results.

Push sync trades human discipline for infrastructure: the same deploy action that changes runtime behavior also enqueues a registry refresh. That complements runtime discovery (search at request time) documented in October; it does not replace approval workflows where records must stay DRAFT until security signs off.

A bell sending a green pulse to a cluster of gears

Architecture overview

AWS’s diagram shows Account B hosting the MCP runtime and Account A owning the registry, EventBridge rule, sync Lambda, and CloudTrail aggregation — though all components can live in one account for simpler pilots.

The event path:

1. Engineer updates an MCP server → UpdateAgentRuntime runs.
2. CloudTrail records the management event in Account B (~5–15 minute delivery per AWS).
3. EventBridge matches aws.bedrock-agentcore / API Call via AWS CloudTrail / UpdateAgentRuntime and invokes the sync Lambda (forwarding to Account A when needed).
4. Lambda URL-encodes the runtime ARN into the Bedrock AgentCore invocations endpoint.
5. AgentCore Identity issues OAuth tokens without storing client secrets on the function.
6. Lambda runs MCP initialize, then tools/list, diffs against the registry record, and updates only on change.

AWS Agent Registry push sync architecture from CloudTrail through EventBridge to Lambda updating MCP tool metadata Image: Amazon Web Services

That sits in the broader AgentCore stack we mapped in AWS’s seven-layer agentic AI framework: registry as catalog, Gateway and Identity as trust boundaries, runtimes as MCP hosts.

EventBridge pattern AWS documents

The rule JSON AWS prints is intentionally narrow — only runtime updates, not every Bedrock call:

{
  "source": ["aws.bedrock-agentcore"],
  "detail-type": ["API Call via AWS CloudTrail"],
  "detail": { "eventName": ["UpdateAgentRuntime"] }
}

Pin this rule in the registry account even when runtimes deploy elsewhere. Cross-account forwarding is the enterprise default: MCP builders keep deploy permissions in workload accounts; platform teams own catalog quality in a shared services account — the same separation Okta cross-app access on AgentCore Gateway assumes when agents touch SaaS APIs.

Latency expectation: AWS warns CloudTrail is not a webhook. Budget minutes, not seconds, between agentcore deploy and registry refresh. For CI gates, still run a direct tools/list smoke test; treat registry sync as eventually consistent catalog hygiene.

Building the MCP URL from CloudTrail

The Lambda extracts agentRuntimeArn from detail.responseElements, parses account and Region, URL-encodes the ARN, and calls:

https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{encoded_arn}/invocations?qualifier=DEFAULT

AWS’s sample rejects non-HTTPS URLs before any outbound fetch — a small but important guard when agents might otherwise be taught to follow arbitrary strings in events.

That dynamic URL construction is why pre-registration matters: the sync job must find a registry record whose mcpServer.data already embeds the same ARN or URL. Greenfield servers need a one-time onboarding step; the push pipeline handles drift after onboarding.

Authentication without secrets in Lambda env vars

Stale metadata is a reliability bug; long-lived OAuth client secrets in Lambda environment variables are a security bug. AWS routes auth through AgentCore Identity:

1. Lambda calls get_workload_access_token with a configured workload identity.
2. It trades that token for an OAuth2 M2M access token via get_resource_oauth2_token and a credential provider name (per-account CREDENTIAL_PROVIDER_{ACCT_ID} in the sample).

Cognito or another OAuth issuer config lives in Identity, not in plaintext env vars. That aligns with AWS trust-in-depth guidance — scope what the sync principal can reach, log what it did, and keep humans out of the token path.

When you wire this in production, pair Identity scopes with registry IAM: publishers, approvers, and the sync role should be three different principals.

MCP session mechanics the Lambda must respect

AWS uses streamable HTTP MCP: initialize first (protocol version 2025-03-26 in the sample), capture optional Mcp-Session-Id header, then tools/list. The helper parses SSE-framed JSON responses — the same transport quirks teams hit when exposing MCP behind AgentCore as in our serverless MCP on ECS Fargate guide.

If your server requires sessions, dropping the session header on tools/list yields empty or error responses and a false “no change” diff. Test with the exact AgentCore qualifier (DEFAULT in AWS’s URL) your orchestrators use in production.

Matching registry records and respecting APPROVED status

The sync code loops list_registry_records, skips DRAFT, and matches APPROVED entries by:

• Decoded runtime ARN inside descriptors.mcpServer.data
• URL-encoded ARN variant
• Full MCP URL substring

If nothing matches, the Lambda returns skipped — not an error storm — which is correct for runtimes that are not cataloged yet.

That behavior interacts with governance: auto-sync should not publish tools your approvers have not cleared. Keep unpublished servers out of the registry entirely, or leave records in DRAFT so the Lambda’s skip path fires until approval flips status.

A rounded stack of papers with a green stamp

Diff-before-write: what actually updates

AWS normalizes tools (sort by name; compare name, description, inputSchema) before calling the registry update API. Identical normalized lists short-circuit with no_change — important at scale when many deploys touch unrelated runtime settings.

When diffs exist, the sample logs additions and removals, then pushes fresh inline tool definitions. That is safer than blind overwrite: you keep an audit trail in CloudWatch for what schema delta triggered a write.

Teams running Bedrock AgentCore evaluation playbooks can add a post-sync check — sample queries against the registry API confirming tool counts match harness expectations.

Single-account versus multi-account rollout

Multi-account is the pattern large enterprises want before they connect dozens of internal MCP servers spawned by coding agents. It also pairs with the local test loop in AWS Emulator: emulate APIs locally, deploy runtimes to a sandbox account, let production registry accounts ingest changes only from approved promotion pipelines.

Failure modes to plan for

No matching record. Usually means onboarding never embedded the runtime ARN in mcpServer.data. Fix registry authoring, not the Lambda.

Auth errors. Misconfigured workload identity or credential provider names per account. AgentCore Identity logs are the first stop.

Stale tools after deploy. Check CloudTrail delivery delay and EventBridge rule metrics. A silent rule is worse than a failing Lambda.

Unauthorized registry writes. If sync role can edit any record, a compromised runtime account could poison catalog metadata. Restrict update_registry_record to records tagged by environment and tie EventBridge rules to organization paths.

DRAFT records. Expected skip. Do not auto-approve via sync — that defeats the registry’s purpose.

How this differs from October’s discovery sample

The October registry guide showed orchestrators searching approved MCP and A2A entries at request time. November’s post answers who updates the catalog when tools change without a human filing a ticket.

You likely need both: push sync for freshness, semantic search for selection, Gateway or Okta for invocation auth at call time.

Implementation checklist for platform teams

1. Embed runtime ARN in each MCP registry record at onboarding.
2. Deploy EventBridge + Lambda in the registry account; grant cross-account PutEvents or forward CloudTrail per AWS blog IAM appendix.
3. Register workload identity + credential providers per MCP account in AgentCore Identity.
4. Alarm on skipped rate spikes (onboarding drift) and updated rate spikes (possible rogue deploys).
5. Keep approval workflow for new records; let sync mutate only APPROVED rows.
6. Document expected lag (~5–15 minutes) for internal agent users so they do not rerun deploys blindly.

What to watch at re:Invent and beyond

AWS tied Agent Registry to AgentCore launches all quarter. If re:Invent sessions expand registry APIs — versioning, batch sync, or A2A agent cards — this CloudTrail hook may become a managed feature rather than sample Lambda code. Until then, the November 11 post is the reference implementation for MCP catalog hygiene.

Also watch whether third-party registries (self-hosted MCP indexes, Hugging Face MCP listings adjacent commerce) adopt the same push-on-deploy contract. Stale metadata is a protocol problem, not uniquely AWS’s.

Related reading

• AWS Agent Registry runtime discovery (October sample)
• AWS Emulator for local agent loops
• Bedrock AgentCore seven-layer framework
• A2A versus MCP for agent tool wiring
• AgentCore evaluation playbook
• Trust, scope, and observe for AgentCore autonomy