TL;DR: Amazon Bedrock agents, roles, knowledge bases, prompts, and guardrails can be represented as first-class non-human identities in a single access graph, with the IAM role carrying the true blast radius and automatic discovery following the next AWS extraction, according to Veza. That matters because identity review, least privilege, and access tracing must extend to AI agents, not stop at human users.
At a glance
What this is: Veza maps Amazon Bedrock agents as first-class non-human identities and ties each agent to the IAM role, data sources, models, and guardrails it can use.
Why it matters: This matters because identity teams need to govern AI agents through the same access, review, and blast-radius controls they already apply to other non-human identities.
Context
Amazon Bedrock agents are AI-driven workloads that can invoke tools, query knowledge bases, and act through delegated AWS permissions. In this model, the agent is not the permission boundary by itself; the assumed IAM role is. That makes the identity governance problem materially different from a simple application inventory.
Veza’s article argues that teams need a single view of who can invoke or modify an agent, what role the agent assumes, and which resources that role can reach. For IAM and NHI programmes, the central issue is whether agent identity is being governed as an auditable access path rather than as a loose AI feature.
The article’s starting point is typical of current Bedrock deployments: strong AI intent, but fragmented visibility across AWS, knowledge bases, and identity controls. That is the common condition identity teams now have to close.
Key questions
Q: What breaks when a Bedrock agent is treated as an application instead of an identity?
A: The governance model breaks because the agent’s permissions are really inherited through a delegated IAM role, not expressed by the agent itself. That makes blast radius, review, and offboarding impossible to assess correctly if the agent is not tracked as a first-class identity with an auditable role chain.
Q: Why do Bedrock agents increase NHI governance risk even when the model is unchanged?
A: Because the risk comes from delegated access, not model quality. Once an agent can invoke tools and inherit role permissions, the control question shifts to who can trigger it, what role it assumes, and which resources that role can reach across the environment.
Q: How do security teams know whether an AI assistant is actually constrained?
A: They know by testing whether the model stays inside its boundaries across many prompt variants, not just direct requests. If the assistant changes behaviour when benign and harmful terms are combined, or if it leaks internal instructions, the controls are not stable. Real constraint requires layered enforcement, logging, and repeated adversarial validation.
Q: Should teams use one access review process for humans, service accounts, and Bedrock agents?
A: Yes, but with actor-specific evidence. Humans are reviewed on authentication and role membership, while Bedrock agents must be reviewed on their assumed roles, connected data sources, guardrails, and invocation rights, because those are the controls that define their actual reach.
Technical breakdown
Why the assumed IAM role defines Bedrock agent blast radius
Amazon Bedrock agents do not carry permissions in isolation. They act through an assumed IAM role, which means the effective security boundary is the role’s entitlements, not the agent label. In access-graph terms, the useful path is agent to role to resource, because that is where effective permission, resource reach, and escalation potential can be traced. This is the same reason NHI governance treats workload identities as first-class subjects: the credentialed delegation hop is what creates operational risk.
Practical implication: govern the assumed role as the control point, not the agent name.
How Bedrock discovery changes NHI inventory and review
Automatic discovery matters because AI agent sprawl is often invisible until someone asks a pointed question. If the platform can identify agents, action groups, knowledge bases, prompts, guardrails, and model links on the next extraction, then inventory becomes a governance function rather than a manual audit exercise. The architectural point is that AI agent metadata, delegated permissions, and connected data sources can be represented together, which is what makes review and search usable at scale.
Practical implication: require automated discovery for every new AI agent before it enters production review cycles.
Why inbound and outbound access both matter for Bedrock governance
Bedrock governance is not just about who can start an agent. It is also about what the agent can touch after it starts, including S3, SharePoint, Confluence, Salesforce, Lambda, DynamoDB, and RDS-style resources exposed through the delegated role. That split between inbound invocation rights and outbound resource reach is critical because a broadly invocable agent with a narrow role is a different risk from a tightly invoked agent with broad downstream access. Identity-first modeling makes both directions visible in one graph.
Practical implication: review invocation rights and downstream resource reach as separate governance questions.
Threat narrative
Attacker objective: The objective is to use a delegated AI agent path to reach data or actions that were never meant to be exposed through the agent.
- Entry occurs when a principal is allowed to invoke or modify a Bedrock agent, giving it a path into delegated execution.
- Privilege is inherited when the agent assumes an IAM role whose permissions define the agent’s effective reach across AWS services and connected data sources.
- Impact follows if that role is over-privileged or the agent is widely invokable, because the agent can touch sensitive resources at machine speed.
Breaches seen in the wild
- 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
- Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Bedrock agents should be governed as non-human identities, not as feature objects. The article’s strongest contribution is the access-graph framing: the agent, the assumed role, the knowledge base, and the downstream resources belong in the same governance model. That is exactly how NHI programmes should treat delegated machine action, because the permission boundary lives in the identity chain, not in the product label. Practitioners should make AI agents reviewable, searchable, and attributable in the same control plane as other non-human identities.
The real blast-radius question is not what the agent does, but what its role can reach. A Bedrock agent can look narrow while inheriting expansive AWS privileges through a single assumption hop. That makes least privilege a role-design problem, not an agent-description problem, and it validates why access tracing must preserve delegation as a distinct step. Practitioners should measure agent risk by the effective permissions of the role, not by the intent of the prompt or the model behind it.
Identity governance for AI agents fails when outbound data reach is treated as an integration detail. Bedrock agents can span S3, SharePoint, Confluence, Salesforce, Lambda, and more, which means the governance surface is cross-domain from the start. The important question is not whether the agent exists, but whether every connected source and invoked action is still inside an approved trust boundary. Practitioners should align NHI inventory with connected-data review, or the access graph will outgrow the review process.
Access review cadences designed for humans are not enough for fast-moving agent estates. Bedrock agents can be discovered automatically, but that does not automatically solve accountability or ownership. What matters is whether the programme can certify who can invoke an agent, which role it assumes, and which guardrails are missing before the agent becomes operational drift. Practitioners should treat AI agent onboarding and offboarding as lifecycle events, not just deployment events.
First-class AI agent identity is now a baseline expectation for cloud governance. The article signals where the market is heading: identity-first controls are moving upstream from traditional IAM into AI runtime governance. That is a validation of NHI as a discipline, but it also complicates current operating models because the same control must cover humans, service accounts, and AI agents together. Practitioners should plan for one access model across all three actor types.
From our research library:
- Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
What this signals
Bedrock agent governance now sits at the same table as NHI governance. Once an AI agent can assume a role, reach data sources, and be invoked by multiple principals, it is no longer a sidecar workflow. The programme question becomes whether your identity inventory can show the full delegation chain before the next access review cycle starts.
Access graph visibility is most valuable when it connects ownership to execution. AI agent sprawl is not only a discovery problem. It is a governance problem when no one can answer who may invoke the agent, who approves its role, and which connected sources sit behind it.
Cross-domain reach is the hidden risk signal in Bedrock deployments. A single agent can bridge AWS services and external knowledge sources, which means the attack surface expands along the data graph rather than inside one application boundary. Practitioners should watch for that boundary drift as the estate grows.
For practitioners
- Treat Bedrock agents as reviewable NHI records Add every agent to the identity inventory with its assumed role, connected knowledge bases, guardrails, and invoking principals so reviewers can assess it as an access-bearing entity.
- Trace the assumed role as the true control boundary Document the CAN_ASSUME_ROLE hop and use the role’s effective permissions as the basis for blast-radius assessment, privilege review, and exception handling.
- Separate invocation rights from downstream resource reach Review who can invoke or modify the agent independently from what the agent can read, write, or execute across S3, DynamoDB, Lambda, SharePoint, Confluence, and Salesforce.
- Flag agents without guardrails or ownership Use policy checks to detect unowned agents, missing Guardrail attachments, and agents newly granted access to sensitive data sources before they are left in production.
- Align AI agent onboarding with lifecycle governance Require registration, access review, and offboarding steps for every Bedrock agent so agent creation and deletion follow the same governance path as other non-human identities.
Key takeaways
- Bedrock agents become governance-relevant the moment they inherit an IAM role and start acting through delegated permissions.
- The article shows that the most important security view is the access graph, not the agent name, because the role defines the blast radius.
- Identity teams should inventory, review, and offboard AI agents with the same discipline they use for other non-human identities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Bedrock agents authenticate by assuming roles, so delegated identity handling is central here. |
| NHI-05 — Overprivileged NHI | The article centers on role-driven blast radius and over-broad effective permissions. | |
| NHI-08 — Environment Isolation | Agents can reach across AWS and external data sources, so isolation between tools and datasets matters. | |
| Recommendation — Model Bedrock agents as authenticated non-human identities and trace every role assumption end to end. Review the agent’s assumed role for excess permissions and remove anything beyond the agent’s task scope. Separate sensitive data sources and tool paths so one agent cannot cross boundaries by default. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Bedrock agents and their roles are service-style identities that authenticate through delegated credentials. |
| Recommendation — Apply IA-9 to govern service-style agent authentication and each role assumption hop. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about permissions, entitlements, and auditable access paths for AI agents. |
| Recommendation — Map agent entitlements and approvals to PR.AA-05 so permissions remain traceable and reviewable. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Compromised or over-broad delegated access can turn an AI agent into a lateral movement path. |
| Recommendation — Hunt for delegated credential abuse and follow the agent’s role chain when investigating suspicious reach. | ||
Key terms
- Bedrock Agent: A Bedrock Agent is an AWS-hosted AI agent that can orchestrate actions, query knowledge bases, and invoke models on behalf of a workload. In governance terms, it behaves like a non-human identity because its effective access comes from delegated permissions and attached tools, not from human login state.
- Assumed IAM Role: The AWS role an agent uses to obtain effective permissions at runtime. For AI agents and other non-human identities, this is the real control boundary because the role determines what the actor can read, write, invoke, or modify across connected services.
- Access Graph: An access graph is a relationship model that links identities, permissions, data objects, and system interactions. In NHI governance, it helps security teams see the full path from an agent or user to the action it can take, which is more useful than isolated account reviews.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 25, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org