AWS Bedrock AgentCore Security and Governance: A Technical Best Practices Guide

AgentCore security components at a glance

AgentCore is a modular set of services for deploying and operating AI agents at scale. Each component addresses a distinct part of the agent lifecycle. For security engineers, the practical question is not whether AgentCore has security features, but where each feature’s boundary ends.

What AgentCore is and where security fits

AWS Bedrock AgentCore is composed of Runtime, Identity, Gateway, Memory, and Observability, along with a Browser Tool and Code Interpreter. Each component addresses a distinct part of the agent lifecycle: authenticating the agent, exposing tools it can call, isolating its execution environment, storing context across sessions, and tracing what it did.

As agents move from answering questions to invoking tools, calling APIs, and acting on stored context, the authentication and audit surface expands well beyond a typical application. AgentCore governance decisions need to be made deliberately rather than assumed by default.

Agent identity and access control

AgentCore Identity provides workload identity for agents, supporting OAuth 2.0 alongside integration with AWS IAM for authentication and authorization. It includes a token and credential vault for securely storing and retrieving OAuth tokens and third-party API credentials used by agents at runtime.

This gives security teams a defined path for AI agent identity in AWS Bedrock: agents authenticate through IAM-backed constructs rather than embedded static secrets. However, AWS IAM roles and policies remain the underlying enforcement layer, so existing least-privilege IAM design practices still apply and are not replaced by AgentCore.

The token vault stores credentials, but rotation schedules, revocation processes, and access scoping across a growing number of agents are configuration decisions the implementing team must make. Identity gives you a mechanism, not an automated governance policy.

Gateway and tool-call permissions

AgentCore Gateway converts existing APIs, AWS Lambda functions, and other services into tool endpoints that agents invoke through the Model Context Protocol. Gateway supports inbound authentication (verifying the calling agent) and outbound authentication (verifying the agent-to-tool call itself). This is the primary control point for tool-call permissions in AgentCore.

Policy granularity is configured per gateway and per target, which means least-privilege enforcement across many tools requires deliberate mapping rather than a default restrictive posture. Centralizing tool exposure through Gateway simplifies management, but each agent’s access must be explicitly scoped: unused or overly broad tool grants directly increase the attack surface available to a compromised or misdirected agent.

Public documentation describes authentication checks at this layer but does not confirm finer-grained authorization such as per-parameter or per-action policy enforcement.

Runtime isolation and memory handling

AgentCore Runtime provides per-session isolation using dedicated microVMs, separating agent execution environments, and supports extended execution sessions for long-running agentic workflows. This addresses runtime-level tenant separation between sessions, but it does not enforce business-logic authorization on the actions an agent takes within its own session.

Isolation prevents one session from interfering with another; it does not decide whether a given tool call within a session should be permitted.

AgentCore Memory is a managed service providing short-term, session-scoped storage and long-term storage separate from the underlying foundation model. Because Memory persists conversational and contextual data, it introduces retention, encryption, and residency considerations distinct from standard IAM resource permissions. These should be reviewed against applicable regulatory requirements during deployment planning.

Observability and audit trail limitations

AgentCore Observability integrates with Amazon CloudWatch and supports OpenTelemetry-compatible tracing for visibility into agent invocations and tool calls. This gives security teams a monitoring layer for AgentCore runtime controls, showing what an agent did and when.

AWS documentation describes Observability primarily as a monitoring and tracing capability rather than a real-time policy enforcement or blocking mechanism, so it records activity rather than intervening in it. CloudWatch-based observability also requires explicit configuration of log groups, retention periods, and alerting to meet enterprise audit and compliance retention needs; none of this is enabled automatically.

Native observability is scoped per agent and per session, so enterprises requiring a centralized, cross-agent audit trail typically need to aggregate this data with an external SIEM or governance tool.