AgentCore, MCP, and Governed Tools

For a new managed AWS agent design, treat Amazon Bedrock AgentCore as the current greenfield direction. Amazon Bedrock Agents Classic entered maintenance and stopped accepting new customers on 2026-07-30. This does not make an existing workload unsafe by itself; it changes the default evaluation for new work and migrations.

AgentCore base capabilities, Policy, and Evaluations have separate release histories, and availability remains feature and Region specific. Managed session storage and latency-optimized inference should be assessed at their individual availability status, not assumed from the platform name. Check current service, Region, quota, model, and preview terms during design and again before deployment.

A governed agent architecture keeps the model-driven application distinct from the control points that authenticate callers, expose tools, retain approved state, observe execution, evaluate quality, and enforce policy. This separation lets a team audit a tool boundary without confusing it with the runtime or conversation state.

View full size

Amazon Bedrock User Guide: Amazon Bedrock AgentCore platform figure (CC BY-SA 4.0)Last verified: 2026-08-26

AgentCore Runtime provides a managed execution boundary and session isolation, but it cannot decide which application user or tenant a request represents. Configure each Runtime resource with a least-privilege execution role. Separately, the application must authenticate the caller, bind the runtime session to a server-side user and tenant record, and authorize every data or tool action at the owning backend.

Release tests should exercise the entire chain rather than treating a policy simulator as sufficient evidence. Send a valid allowed call, an unlisted tool, a mismatched tenant resource, an expired credential, malformed arguments, a direct backend request, a retryable read timeout, and an unknown write outcome. For each, assert what the caller receives, whether the target was invoked, the backend authorization outcome, the trace correlation, and the retained audit fields. This reveals gaps such as an authenticated gateway request that is not authorized for the target, or a target that accepts a direct request outside the intended gateway path. Keep responses concise enough not to disclose policy structure or resource existence.

Do not use the model prompt or a client-supplied tenant field as authority. Validate session ownership server side, scope retrieval and tool queries at the data boundary, and include negative tests for cross-tenant identifiers and replayed sessions.

MCP separates an AI host and client from a server that offers tools, resources, and prompts. The protocol shape does not grant authority. For every server, document connection lifecycle, authentication method, tool and resource allowlist, input schema, output classification, rate and cost boundary, timeout, error contract, and audit event.

AgentCore Gateway provides a governed integration boundary and AgentCore Policy evaluates requests routed through that Gateway. Policy is not an account-wide interceptor. A direct network route to the same backend can bypass that specific enforcement path, so remove it or give the backend independent identity and authorization controls.

Use Cedar policies only after modelling the resources, principals, and actions precisely. A policy that is syntactically valid but lacks tenant, purpose, or resource attributes cannot repair a weak application identity model.

Trace the request across application, runtime, gateway, policy, and backend tool boundaries using one correlation identifier. Detailed traces require application or framework instrumentation. They show what happened, but evaluation must still decide whether the path was grounded, authorized, useful, and within the workload’s reliability and cost constraints.

An MCP client may describe a tool call with JSON-RPC, but the server must derive its security decision from authenticated identity and validated request attributes, not from a model-produced explanation. At the gateway boundary, authenticate the caller, map the authenticated subject to an application principal, validate the named tool and arguments, and extract the action, resource, tenant, purpose, and request context needed by policy. Inbound authentication establishes who presented a credential. It is not authorization, and it does not remove the target service’s responsibility to authorize direct access to its own data or side effects.

Policy design begins with a resource model, not a permissive default. In Cedar terms, policy evaluation considers principals, actions, resources, and context. An allow rule grants only a stated relation; a deny rule prevents a stated relation; and a forbid rule provides an explicit safety boundary that overrides a matching allow. Design defaults so an absent allow fails closed, then use explicit forbids for conditions that must never pass, such as a cross-tenant resource or an unapproved write. Keep policy evaluation evidence separate from backend enforcement evidence: a gateway decision cannot protect a direct path that still reaches the target.

A denial is a valid security outcome, not a transient error to route around. Return a safe, user-appropriate explanation without leaking policy internals, record a correlation ID and decision category, and stop the tool chain unless an independently authorized alternate path exists. For a timeout, distinguish “not sent”, “sent but unknown”, and “target unavailable”. Retry only idempotent reads within a declared budget. For a write with unknown outcome, reconcile using the target’s idempotency or status mechanism before considering compensation. The bounded fallback is a static retrieval response, an approved human handoff, or abstention—not a wider tool search.

Inbound OAuth authorization validates a caller credential at the gateway boundary, but the application still needs a precise mapping from trusted token claims to its principal and tenant model. Define which issuer, audience, scopes, and subject attributes are accepted, reject missing or ambiguous mappings, and avoid copying raw access tokens into prompts, traces, or tool arguments. Independently validate each MCP tool schema with a closed parameter set, size limits, allowed resource patterns, and type checks before policy evaluation and target invocation. The tool name and arguments are untrusted client input even if the caller is authenticated. Confirm AgentCore Gateway feature and Region support for the target workload before adopting any configuration.

Validate with expired, wrong-audience, missing-tenant, over-scoped, malformed, oversized, and unknown-tool requests. The expected evidence is a controlled rejection before target invocation, a correlation record that does not contain the token, and an independent target-service denial if someone bypasses the gateway.

A tool’s effective authority changes when its schema, target, backend permission, token mapping, policy, or data classification changes. Treat that combination as a governed release. Require a named owner, diff review, compatibility decision, approval for high-impact scope changes, test evidence, and a revocation plan. Revocation should be demonstrable: disable a tool or principal, invalidate or reject affected credentials as the identity provider supports, remove backend access, and confirm both gateway and direct target paths refuse the action. Keep audit records of who changed the control and which policy and target versions handled each request.

Keep a time-bounded emergency procedure for situations where normal change review is too slow, but require a post-incident reconciliation. That receipt should identify the temporarily disabled principal, tool, route, policy or backend permission, the evidence that revocation worked, the scope of possible prior exposure, and the approval needed to restore access. Restoration is another authorization change: retest the minimum permitted action rather than re-enabling a broad role because the incident has ended.