Veza models Bedrock agents as first-class NHIs in one access graph

At a glance

What this is: This is a walkthrough of how Veza models Amazon Bedrock agents as first-class non-human identities and links each agent to its assumed role, reachable resources, and human invokers.

Why it matters: It matters because IAM teams need a way to review AI agent access with the same governance discipline used for service accounts, roles, and privileged human access.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Veza's walkthrough of Amazon Bedrock agent access graph modelling

Context

Amazon Bedrock agent governance is an identity problem before it is an AI problem. The practical gap is not whether an agent exists, but whether security teams can trace what it assumes, what it can reach, and who can change or invoke it across the AWS environment.

That matters because Bedrock agents inherit the permissions of the IAM roles they assume, while knowledge bases and action groups can extend reach into data stores and downstream systems. Without identity-first modeling, the agent becomes a hidden delegation path rather than a governed workload identity.

The article describes a control model for visibility, review, and blast-radius assessment across agents, roles, prompts, guardrails, and data sources. That is typical of the broader AI agent governance problem now emerging in cloud platforms.

Key questions

Q: How should security teams govern Amazon Bedrock agents as identities?

A: Treat each Bedrock agent as a first-class non-human identity and review the role it assumes, the tools it can invoke, and the people who can manage it. Governance should cover inventory, ownership, access certification, and blast-radius assessment together, because the agent’s effective permissions come from delegation, not from the model alone.

Q: Why do Bedrock agents create more access risk than standard workloads?

A: They combine delegated runtime behaviour with assumed IAM roles and connected data sources, so their effective reach can exceed what a simple workload inventory suggests. A narrow interface can still produce broad access if the attached role, action groups, or knowledge bases are over-scoped.

Q: What breaks when teams review AI agents without checking the assumed role?

A: They miss the true blast radius. The agent may look harmless, but the role can permit broad AWS and data access, and that access is what the agent actually uses. Reviews that ignore the role produce false confidence and leave delegated privilege ungoverned.

Q: Who should be accountable for changes to a Bedrock agent and its permissions?

A: The owner of the agent, the team that manages its IAM role, and the reviewers who certify its access should all be explicitly named. If a human principal can invoke or modify the agent, that entitlement must be part of accountability, not treated as an implementation detail.

Technical breakdown

How Bedrock agent delegation turns an AI agent into an identity path

A Bedrock agent does not carry permissions in isolation. It becomes effective through a delegation chain that starts with the agent, continues through the IAM role it assumes, and ends at AWS services and data stores that role can access. That distinction matters because the agent is the executor, but the role is the permission container. When action groups, knowledge bases, and prompts are added, the governance surface expands from a single runtime object into a multi-object access path that must be reasoned over as one identity graph.

Practical implication: Map the agent to its assumed role and downstream resources as a single reviewable path, not as separate technical inventories.

Why knowledge bases and action groups widen the agent’s effective scope

Knowledge bases and action groups are not decorative metadata. Knowledge bases can reach into S3, SharePoint, Confluence, or Salesforce, while action groups can invoke Lambda functions or OpenAPI-backed services that execute real business operations. In practice, this means the agent’s effective permissions are determined by the combination of what it can read, what it can call, and what those tools can in turn reach. A narrow agent prompt can still create a broad access surface if the attached tools are over-scoped.

Practical implication: Review tool attachments and data connectors as privilege multipliers, not as separate convenience features.

Why access review must extend to AI agents and human invokers

The governance question is not only what the agent can do, but who can invoke or modify it. Bedrock agents can be exposed through IAM identity-based and resource-based policies, so a human principal may have the power to trigger, update, or reconfigure the agent’s behaviour. That makes the access model bidirectional. Security teams need to understand both outbound reach from the agent and inbound control over the agent, because compromise or overreach on either side changes the resulting blast radius.

Practical implication: Include invoker and modifier entitlements in access reviews alongside the agent’s own permissions and attached roles.

Threat narrative

Attacker objective: The attacker aims to use a trusted AI agent as a delegated path into AWS resources, data sources, and operational tooling.

1. entry: A human principal or overbroad policy can invoke or modify a Bedrock agent through IAM permissions, creating a management path into the agent runtime.
2. escalation: The agent assumes an IAM role, and that role determines the effective privileges available to agent actions, data reads, and downstream calls.
3. impact: The agent can reach sensitive resources through its role, action groups, or knowledge bases, turning delegated access into a wider blast radius.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity-first modelling is the only workable control plane for Bedrock agents. The article shows why agent governance collapses when teams treat the model, the tool, and the runtime as separate problems. Bedrock agents assume roles, inherit tool reach, and can be invoked by humans, which means the real question is delegated authority across the full path. Practitioners should treat the agent as a governed identity object, not just an application feature.

Agent blast radius is defined by the IAM role, not the prompt. That is the control truth embedded in this walkthrough. The prompt may shape behaviour, but the role determines what the agent can actually touch across AWS and connected systems. Access governance fails if it stops at model policy and does not inspect the effective permissions attached to the assumed role.

Bedrock reveals a broader NHI governance gap: AI systems now sit inside the same lifecycle problem as service accounts. Discovery, access review, and offboarding all become necessary once an agent can be created, granted access, and left behind. The article’s model validates the need to govern AI agents through the same lifecycle discipline already expected for NHIs. Security teams should align agent inventory, ownership, and review cadence before scale turns exceptions into normality.

Named concept: agent delegation blast radius. The article makes clear that blast radius is no longer only a function of privileged accounts, but of delegated AI paths that combine human invocation, role assumption, and connected data sources. That is a specific governance concept practitioners can use to reason about agentic workloads. Identity programmes should measure it as a distinct risk dimension across cloud AI deployments.

The market is moving toward identity graphs that unify humans, NHIs, and AI agents. The article’s value is not in the connector mechanics alone, but in the direction it signals. Security platforms that cannot model invocation, assumption, and effective permission in one view will struggle to govern agentic systems at scale. Practitioners should expect access governance to become graph-centric rather than application-centric.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• NHIs outnumber human identities by 25x to 50x in modern enterprises, which is why agent inventories now need lifecycle controls rather than ad hoc tracking.
• The next step is to pair access review with lifecycle offboarding, and Ultimate Guide to NHIs provides the broader governance model behind that shift.

What this signals

Agent delegation blast radius: security teams need a new way to measure effective privilege when AI agents assume roles and inherit tool reach. The governance unit is no longer the agent alone, but the chain from human invoker to role assumption to downstream resource access, which is where review and containment should focus.

Bedrock-style modelling will pressure IAM programmes to become graph-native, because access decisions now span humans, NHIs, models, tools, and data connectors in one system. Teams that still certify identities in isolation will miss delegated pathways that only appear when the full relationship map is visible. That is where platform-wide identity governance has to move next.

For practitioners

• Model each Bedrock agent as a governed NHI Inventory the agent, the IAM role it assumes, and every resource that role can reach as one access path. Use that path in reviews, exception handling, and ownership assignment instead of treating the agent as a standalone app object.
• Review tool and connector reach as privilege expansion Inspect every action group and knowledge base connector for downstream reach into S3, SharePoint, Confluence, Salesforce, Lambda, and OpenAPI-backed services. Treat attached tools as part of the agent’s effective permissions, not as neutral integrations.
• Add agent invokers to access certification Include the humans and IAM principals that can invoke or modify an agent in the same certification cycle as the agent itself. This closes the gap between delegated authority and runtime execution.
• Alert on unowned or over-privileged agents Create rules for agents without an accountable owner, agents assuming roles with broad permissions, and agents running without a guardrail attachment. These are the earliest signs that identity control has drifted away from governance.

Key takeaways

• Bedrock agents become governable only when they are treated as NHIs with explicit role assumptions and traced delegation paths.
• The real security boundary is the IAM role and connected tooling, not the agent prompt or model label.
• Identity programmes should extend inventory, review, and offboarding to AI agents before delegated access becomes routine.

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.
• AI Agent Blast Radius: The amount of sensitive data, systems, or business action an AI agent can affect if it is misused or manipulated. In practice, blast radius is determined by the agent’s permissions, tool access, and the sensitivity of the data it can reach.
• Knowledge Base Connector: A knowledge base connector is the integration that lets an AI system retrieve data from external repositories such as SharePoint, Confluence, Salesforce, or S3. In identity terms, the connector matters because it can extend the agent’s effective reach beyond the native cloud account into third-party data environments.
• Can Assume Role Edge: A can assume role edge is the explicit relationship showing that one identity can take on another role’s permissions. For AI agents, this edge is critical because it preserves accountability in the graph and prevents delegated privileges from being mistaken for native agent permissions.

What's in the full article

Veza's full article covers the implementation detail this post intentionally leaves for the source:

• The exact Access Graph relationships used to model Bedrock agents, roles, prompts, guardrails, and knowledge bases.
• The worked claims-triage example showing how permissions, data sources, and model attachments are traversed end to end.
• The specific Access Reviews, Blast Radius, and Rules & Alerts behaviours that extend to Bedrock on day one.
• The Bedrock and Bedrock AgentCore distinctions for teams comparing runtime coverage and native service coverage.

👉 Veza's full post shows the exact graph paths, permissions, and review workflows for Bedrock agents.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle control, it is worth exploring.