Updated October 6, 2026. Part 5 of APERION's Agent Platforms series.
On AWS, agents are governed through Amazon Bedrock AgentCore: AgentCore Identity for who the agent acts as, AgentCore Gateway and Policy for which tools it may call, Bedrock Guardrails for content, and AgentCore Observability and CloudTrail for the record. AgentCore Policy evaluates the calls that pass through AgentCore Gateway, so the governance work is routing every tool call, and every model call you want governed, through the Gateway or another endpoint you control, tying each call to a person, and turning on the logs AWS leaves off by default.
Amazon Bedrock AgentCore became generally available on October 13, 2025, with Runtime, Memory, Gateway, Identity and Observability, and it works with "any model in or outside Amazon Bedrock" (AWS, October 2025). AgentCore Policy followed on March 3, 2026 (AWS, March 2026), and AgentCore Evaluations on March 31, 2026 (AWS, March 2026). Agents built with Strands, LangGraph, CrewAI or custom code can all run on AgentCore Runtime.
What AWS Ships for Governance
| Service | What it does | What to check |
|---|---|---|
| AgentCore Identity | Workload identities for agents, a token vault, and OAuth consent so an agent can act on a user's behalf; works with Cognito, Entra ID and Okta | Whether each agent acts as itself or on behalf of a user |
| AgentCore Gateway | Turns Lambda functions, OpenAPI and Smithy APIs, and MCP servers into tools behind one MCP endpoint, routes model calls through inference targets, and applies inbound and outbound authorization | Which tools are reachable around the Gateway |
| AgentCore Policy | Cedar policies, written directly or from natural language, evaluated on calls through the Gateway, including every tool call; default deny, forbid wins | Mode: LOG_ONLY or ENFORCE |
| Bedrock Guardrails | Content filters, denied topics, word filters, sensitive information filters, contextual grounding and automated reasoning checks; the ApplyGuardrail API works with any model | Which agents call it, and on which paths |
| AgentCore Observability | OpenTelemetry traces of model calls, tool calls, tokens and latency in CloudWatch, exportable to other tools | CloudWatch Transaction Search must be enabled |
| AgentCore Evaluations | Built-in and custom evaluators, run on live trace samples or on demand | Which agents are scored, and how often |
Sources: AWS documentation for AgentCore Identity, Gateway, Policy, Bedrock Guardrails and Observability, verified October 6, 2026.
Where the Control Points Are on AWS
Tool calls through the Gateway. AgentCore Policy evaluates each tool call that passes through AgentCore Gateway, using the caller's identity claims, the tool name and the tool input. Gateway interceptors, written as Lambda functions, run before policy evaluation and can exchange tokens or add context (AWS, June 2026). A tool the agent reaches directly, without the Gateway, is outside Policy's view.
Model calls in your own code. AgentCore Runtime runs the agent code you deploy, and that code chooses its model endpoint. Strands Agents, AWS's open-source agent SDK, supports Bedrock, Anthropic, OpenAI and any OpenAI-compatible endpoint (AWS, July 2025). AgentCore Gateway can also route model calls to Bedrock, OpenAI, Anthropic or OpenAI-compatible providers through inference targets, and AWS documents that Bedrock Guardrails and AgentCore Policy then apply to those calls (AWS documentation). Calls that agent code sends directly to a provider are outside Policy's view.
Logs. Bedrock model invocation logging is off by default, and AWS documents that it only captures calls made through the bedrock-runtime endpoint (AWS documentation). When an agent calls with a service role, the log names the role rather than the end user, so add the user to the request metadata.
Data location. Bedrock's geographic cross-region inference profiles keep processing inside a geography such as the U.S. or EU. Global profiles may process a request in any supported commercial region (AWS, October 2025). Choose the profile your data residency rules allow.
How to Govern AI Agents on AWS in 7 Steps
1. Put every tool behind AgentCore Gateway
Register each Lambda function, API and MCP server an agent needs as a Gateway target, and remove direct network paths from agent code to those systems. Policy can only evaluate calls it sees.
2. Write policies in log-only mode, then enforce
Start AgentCore Policy in LOG_ONLY mode, review the decisions against real traffic, then switch to ENFORCE. Review any Cedar generated from natural language before it goes live, and keep policies in version control.
3. Give each agent an identity and act on behalf of users
Use AgentCore Identity workload identities instead of shared IAM roles. When an agent acts for a user, use the OAuth consent flow so the user's token, scoped to that agent, goes with the call, and connect AgentCore Identity to the identity provider you already run.
4. Send model calls through an endpoint you control
Point agent code at one governed endpoint for models, either an AgentCore Gateway inference target or another gateway you control. Apply Bedrock Guardrails through ApplyGuardrail on every model path that needs it, and include the user's identity in request metadata so the invocation log names a person.
5. Isolate code execution and browsing
Run AgentCore Code Interpreter and Browser in the network mode your security team has tested, and block outbound DNS where policy requires it. Researchers showed in early 2026 that sandbox network behavior allowed outbound DNS lookups usable as a data channel, and AWS updated its documentation to state that the sandbox allows DNS resolution, and changed metadata-service defaults for new agents (Unit 42, April 2026).
6. Turn on the logs AWS leaves off
Enable model invocation logging, CloudTrail for Bedrock and AgentCore, CloudWatch Transaction Search for Observability, and export traces to your SIEM or observability tool. Note which endpoints each log covers.
7. Score agents continuously
Run AgentCore Evaluations on a sample of live traces, add custom evaluators for your own policies, and review results with the agent's owner on a fixed schedule.
What the 2025 and 2026 Findings Show
In July 2025, malicious code was committed to version 1.84.0 of the Amazon Q Developer extension for VS Code using an inappropriately scoped GitHub token. AWS released version 1.85.0 and stated that the code failed to execute because of a syntax error, which "prevented the malicious code from making changes to any services or customer environments" (AWS-2025-015). In 2026, researchers reported that AgentCore's sandboxed tools allowed outbound DNS lookups and exposed instance metadata, and AWS changed defaults for new agents. Both point to the same lesson: an agent's software supply chain and its execution environment are part of the attack surface, and both need review before production.
Operating Limits
- AgentCore Policy covers calls through the Gateway. Model calls and tool calls that go around it need their own controls.
- Model invocation logging is off by default and covers the
bedrock-runtimeendpoint only. - Invocation logs name the IAM caller, which for an agent is usually a role. Add the user to request metadata.
- Global inference profiles may process in any supported commercial region.
- AgentCore Policy can require a recorded approval before an action, and does not collect the approval itself. Build the approval step as a tool or in a gateway (AgentCore FAQ).
How APERION Fits
On AWS, APERION's Smartflow can serve as the model endpoint your agent code calls, so every model call carries a per-agent key and a user identity from your OIDC provider, and is checked against policy before it reaches Bedrock or another provider. Its MCP gateway can front the MCP servers your agents use, pausing out-of-authority calls for a person with approval rights. AgentCore Policy keeps governing calls through the AgentCore Gateway, and both write to your SIEM. Talk to APERION.
More in This Series
- How to govern AI agents across platforms
- CrewAI security and governance
- Glean agents governance
- Agentforce governance
- Microsoft Copilot agent governance
- Google, ServiceNow, OpenAI, Anthropic and LangChain
Frequently Asked Questions
What is Amazon Bedrock AgentCore?
AgentCore is AWS's set of services for running agents in production: Runtime, Memory, Gateway, Identity, Observability, Policy, Evaluations, Optimization, and managed Browser and Code Interpreter tools, with Agent Registry and Payments in preview. It works with any agent framework and with models inside or outside Amazon Bedrock.
What is AgentCore Policy?
AgentCore Policy evaluates calls that pass through AgentCore Gateway, including tool calls, against Cedar policies, which you write directly or generate from natural language. Policies deny by default, a forbid rule overrides any permit, and each gateway runs its attached policy engine in log-only or enforce mode.
Does AgentCore Policy govern model calls?
Only when model calls pass through an AgentCore Gateway inference target. Calls that agent code sends directly to a model provider are outside its view; govern those with Bedrock Guardrails, an endpoint you control, and invocation logging.
How do AWS agents act on behalf of a user?
AgentCore Identity supports user-delegated OAuth flows: when a user grants consent for an agent to act on their behalf, it collects and stores the user's tokens in its vault. It works with identity providers including Cognito, Microsoft Entra ID and Okta.
Can Bedrock Guardrails protect models outside Bedrock?
Yes. The ApplyGuardrail API evaluates text against a guardrail independently of the model, so agents can apply the same guardrail to calls to any provider.
Is Bedrock model invocation logging on by default?
No. You enable it per account and region, and it writes to S3, CloudWatch Logs or both. AWS documents that it captures calls through the bedrock-runtime endpoint only.
Can AgentCore run agents built with other frameworks?
Yes. AgentCore Runtime runs agents built with Strands, LangGraph, CrewAI or custom code, and the code chooses its own models and tools.
Craig Alberino is the CEO and Founder of APERION, which provides Smartflow, the runtime governance layer for enterprise AI in regulated industries. Learn more about Smartflow →
Put this in the path of your own agents.
Policy enforced inline between your agents and every model and tool they reach, with a record bound to the human who owns it.
Request a Demo Read the docs