Governing Amazon Bedrock Agents and Action Groups

Amazon Bedrock Agents extend a foundation model's capability beyond text generation through action groups: a declared API schema, backed by an AWS Lambda function, that the agent can invoke when a user's request requires an action rather than just a response. Bedrock governs whether the agent is authorized to invoke an action group at all; it does not, by itself, constrain what that Lambda function is actually permitted to do once invoked. That permission boundary lives in the Lambda's own IAM execution role, and it is frequently wider than what a review of the agent's own configuration would suggest.

What action groups are and how Bedrock Agents use them

A Bedrock Agent breaks a user's request into steps and, where a step requires more than generating text, calls an action group to carry it out. Each action group is defined by an API schema — commonly an OpenAPI specification — that tells the agent what parameters an action expects and what it returns. Behind that schema sits a Lambda function that actually executes the logic: querying a database, calling an internal API, writing a record, or reaching out to a third-party service. Bedrock Agents can also be given knowledge bases, a separate mechanism for retrieval-augmented generation over an organization's own documents, which is a read-only grounding capability distinct from the read-write reach an action group can have.

This is a genuinely useful design: it lets a team compose an agent's capabilities out of ordinary, independently testable Lambda functions rather than building a monolithic tool-execution layer. It is also why the resulting privilege footprint is easy to lose track of — each action group is, from AWS's own resource model, just a Lambda function with an IAM execution role like any other, and the review discipline applied to Lambda functions generally does not always get applied specifically to the ones an agent can trigger autonomously.

A different question from agent identity

It is worth being precise about what this covers versus what it does not. AWS AgentCore Identity — a separate, newer part of AWS's agent tooling — governs how an agent authenticates and what identity it presents. Action groups on Bedrock Agents govern something that comes after authentication succeeds: once the agent has proven who it is, what is it allowed to actually do when it decides to call a tool. Both questions matter, and neither one answers the other. An agent can have an impeccably scoped identity and still trigger an action group whose underlying Lambda function has a permission footprint nobody has reviewed in months.

Where the risk concentrates: the Lambda execution role

The concrete failure mode is straightforward and common to Lambda-based architectures generally, not unique to Bedrock: an execution role granted broader permissions than the function's current logic needs, because a permission was added during development and never revisited, or because a wildcard resource scope was used to avoid debugging a narrower policy. For an ordinary application Lambda, that overprovisioning is a latent risk. For a Lambda backing a Bedrock Agent action group, it is a risk an autonomous agent can trigger on its own initiative, based on how it interprets a user's natural-language request — with no human confirming that the specific invocation was appropriate unless the action group is explicitly configured to require one.

The specific things worth checking in any Bedrock Agent deployment:

1. Does the action group's Lambda execution role grant only the AWS actions and resources that action group's declared function actually needs? A role scoped for convenience during development, rather than pruned before production, is the most common source of over-broad action group privilege.
2. Can the Lambda function call resources or APIs outside AWS entirely? If the function's code makes outbound HTTP calls to a third-party API, that call is invisible to AWS IAM's own permission model — IAM governs AWS resource access, not what a Lambda function's code does with an outbound network call to an external endpoint.
3. Is there a record of every action group across every Bedrock Agent, mapped to the Lambda function and execution role behind it? Bedrock's own console shows action groups per agent; it does not automatically give you the reverse view — every Lambda function that is reachable by an autonomous agent, across your entire account.
4. Does the action group require human confirmation for consequential actions? Bedrock Agents support configuring a confirmation step before an action executes; whether that is turned on for actions that write data, spend money, or send communications is a deliberate configuration decision, not a default you can assume.
5. Are action group invocations logged with enough detail to reconstruct why the agent chose to call that action? Post-incident forensics for AI agents covers what a useful reconstruction actually needs to capture.

The cross-boundary risk in practice

The reason this matters beyond ordinary Lambda hygiene is the same reasoning that applies to over-broad tool scope generally, covered in the threat model for over-broad MCP tool scope: a capability an agent can reach becomes a capability an attacker can reach, through prompt injection or a manipulated input, without ever needing valid credentials of their own. The confused deputy problem in AI agents is the general pattern — a party without permission to perform an action gets a more privileged party, in this case the agent and its Lambda function, to perform it instead. An action group with a broad Lambda execution role is a concrete, concentrated instance of exactly that pattern, and it is one that lives entirely inside a single Bedrock Agent's configuration, which is precisely why it is easy for a security review scoped to "check the agent's IAM role" to walk past it.

A governance checklist for action groups

Independent controls beyond the Bedrock console

The generic cross-account inventory and anomaly-monitoring layer here is the same shared control set covered in what is an AI control plane and building an AI agent inventory — the specific and higher-leverage work for Bedrock is at the Lambda execution-role layer itself:

• Sub-agent and tool-call scoping that binds each invocation to a narrower, purpose-specific credential rather than letting an action group inherit the full reach of its Lambda execution role by default. Sub-agent delegation with scoped tokens covers this structural mitigation in more depth.
• A cross-account, cross-agent inventory of every action group and the Lambda function and execution role behind it, since Bedrock's own console view is scoped per agent, not per account.
• Monitoring for anomalous invocation patterns — an action group suddenly called at a volume or against parameters outside its normal range is a signal worth alerting on independently of whether the invocation was, individually, authorized.
• A governance model that treats identity and tool authorization as separate, both-required controls, since neither AgentCore Identity nor action group configuration alone answers the full question of what an agent can safely do. The AI agent security guide covers both halves of that model together.

What good looks like

1. Every action group across every Bedrock Agent in the account is inventoried, mapped to its Lambda function and execution role.
2. Execution roles are scoped to current function logic, reviewed on a schedule, not left at whatever was convenient during development.
3. Human confirmation is required for any action group capable of writing data, spending money, or sending communications.
4. Outbound calls from action group Lambda functions to non-AWS endpoints are documented, reviewed, and treated as a distinct risk from AWS resource access.
5. Invocation logs are detailed enough to reconstruct an agent's reasoning for calling a specific action after the fact.

Bedrock's action group model is a well-designed way to give an agent real capability without hand-building a monolithic execution layer. The governance work it requires is not different in kind from ordinary Lambda security hygiene — it is that an autonomous agent, rather than a predictable application code path, is now the thing deciding when to invoke it.