Request a demo
Open mobile menu
Back
AIAuthorizationIAMIGANHIPrivileged AccessProductTechnical Thought Leadership

Inside Veza’s AI Agent Security for Amazon Bedrock Agents: A Technical Deep Dive

Prasanna Naik

How Veza Models Every Bedrock Agent, Action Group, Knowledge Base, and IAM Role in a Single Access Graph

When we launched AI Agent Security for Amazon Bedrock in December, we promised customers one thing: that every Bedrock Agent in their AWS account would show up in the Access Graph as a first-class non-human identity — with every IAM role it assumes, every resource it can touch, and every human who can invoke it traced end-to-end.

Five months in, the most common question we get from security architects is “show me exactly how it works.” This post is that walkthrough.

Key takeaways

  • Every Bedrock Agent is a non-human identity. Veza classifies it as such in the Access Graph, alongside humans, service accounts, and IAM roles.
  • The IAM role is where the real blast radius lives. Bedrock Agents don’t hold permissions — they assume an IAM role, and that role’s privileges become the agent’s reachable surface.
  • Discovery is automatic. If Bedrock is enabled in the AWS account, Veza picks up agents, action groups, knowledge bases, models, prompts, and guardrails on the next extraction. No new connector, no separate datasource.
  • Inbound and outbound access are both modeled. Who can invoke or modify an agent (inbound) and what each agent can reach across AWS, SharePoint, Confluence, and Salesforce (outbound) live in the same graph.
  • Existing Veza workflows just work. Access Reviews, Blast Radius scoring, Rules & Alerts, and natural-language Access Graph search all extend to Bedrock Agents on day one.

Why Amazon Bedrock Agents Need Identity-First Governance

Amazon Bedrock Agents are now the default way teams ship agentic workloads on AWS — orchestrating Action Groups against Lambda and OpenAPI backends, querying Knowledge Bases over S3, SharePoint, Confluence, and Salesforce, and invoking foundation, custom, and imported models behind the scenes.

Each agent is a non-human identity. Each one assumes an IAM role. Each one inherits whatever that role is allowed to touch across the AWS account. And in most organizations, no single team can answer:

Which Bedrock Agents exist, what IAM role do they run as, and what AWS resources can they actually reach?

That’s the gap Veza closes. For every Bedrock Agent in your AWS account, Veza answers the question we were built to answer:

What can take what action on what data — across every AI Agent in Bedrock?

This deep dive complements our recent AgentCore[NV1] [PN2]  coverage. AgentCore covers the production runtime layer for agents built with any framework. This blog covers the native Bedrock Agent service end-to-end — the agent, every tool it can invoke, every knowledge base it can read, every model it can call, and every guardrail attached to it.

What Veza Discovers in Amazon Bedrock

Veza extends the existing AWS integration to model Bedrock Agents and their full surrounding object graph. Discovery is automatic — if Bedrock is enabled in the account, Veza picks up every relevant object on the next extraction.

The following entities and relationships are visible in the Access Graph:

  • Bedrock Agents — every agent defined in the account, captured as BedrockAgent and classified as an AI Agent
  • Agent Aliases and Versions — pointers to specific deployable versions, captured as BedrockAgentAlias and BedrockAgentVersion
  • Action Groups — agent actions backed by Lambda functions or OpenAPI schemas, captured as BedrockActionGroup
  • Knowledge Bases — RAG-enabled data repositories, captured as BedrockKnowledgeBase, with their underlying connectors (S3, SharePoint, Confluence, Salesforce) modeled as BedrockKnowledgeBaseDataSource
  • Foundation, Custom, and Imported Models — captured as BedrockFoundationModel, BedrockCustomModel, and BedrockImportedModel, linked to the agents that use them via HAS_FOUNDATION_MODEL edges
  • Prompts and Prompt Routers — versioned prompt templates and routing logic, captured as BedrockPrompt, BedrockPromptVersion, and BedrockPromptRouter
  • Guardrails — content filtering and safety policies, captured as BedrockGuardrail and BedrockGuardrailVersion
  • The IAM role each agent runs as — connected via a CAN_ASSUME_ROLE edge so the delegation is auditable as a distinct hop, not silently merged into the agent’s identity

A Worked Example: A Claims Triage Bedrock Agent

Picture a Bedrock Agent named claims-triage-agent running in production for a property and casualty insurer:

  • It assumes the IAM role bedrock-claims-role
  • That role has s3:GetObject and s3:PutObject on claims-documents-prod
  • It also has dynamodb:Query on the Claims table and lambda:InvokeFunction on three claims-processing Lambdas
  • It is wired to a Knowledge Base (claims-policy-kb) backed by a SharePoint connector pointing at the underwriting policy library
  • It calls anthropic.claude-3-5-sonnet-v2 as its foundation model
  • It has a Guardrail attached for PII redaction
  • 14 IAM principals across 4 OUs hold bedrock:InvokeAgent on it

Before Veza, surfacing all of that required pulling from CloudTrail, Bedrock console, IAM Access Analyzer, and SharePoint admin — and even then, no one could traverse it. With Veza, a security architect opens the Access Graph, types “show me what claims-triage-agent can reach in S3 and SharePoint,” and gets the answer in one query.

That’s the difference identity-first modeling makes for AI agents.

Answering Critical Security Questions

How do I see what a Bedrock Agent can actually reach in AWS?

Bedrock Agents do not hold permissions directly. They assume an IAM role, and that role is where the real blast radius lives — every S3 bucket, every DynamoDB table, every Lambda the role can invoke is reachable to the agent. Veza models the delegation as a clear graph path:

Bedrock Agent → CAN_ASSUME_ROLE → IAM Role
             → HAS_PRIVILEGE → AWS Resource
             → HAS_EFFECTIVE_PERMISSION → S3 / DynamoDB / RDS / Lambda

Questions answered in a single query:

  • Which Bedrock Agents can read or write specific S3 buckets, DynamoDB tables, or RDS instances?
  • Does any agent’s IAM role hold *:* or other broadly privileged actions?
  • Which agents share an IAM role, and therefore share blast radius?
  • Which Knowledge Base data sources reach into SharePoint, Confluence, or Salesforce — and which agents inherit access through those connectors?

Who can invoke or manage a Bedrock Agent?

In AWS, the right to invoke or administer a Bedrock Agent flows through IAM identity-based and resource-based policies. Veza wires those into the graph:

IAM User / Role / Group → HAS_PRIVILEGE → bedrock:InvokeAgent / bedrock:UpdateAgent
                                       → ON_RESOURCE → Bedrock Agent

Questions answered:

  • Who in the AWS organization can invoke each Bedrock Agent?
  • Which agents are exposed broadly via account-wide policies versus locked down to specific roles?
  • Which IAM principals can update an agent’s instructions, action groups, or attached models?
  • When a developer changes team or leaves, which agents do they retain — or lose — the ability to invoke or modify?

What models, tools, and guardrails are running under the hood?

The Bedrock object graph is rich, and each piece is its own governance question. Veza inventories all of it:

  • Which foundation models are enabled in the account, and from which providers?
  • Which custom and imported models exist, and which agents use them?
  • Which Action Groups are wired to which Lambda functions or OpenAPI schemas — and what does the underlying execution environment have access to?
  • Which Knowledge Bases are connected to which data sources, and how broad is the ingestion scope?
  • Which Guardrails are attached to which agents — and which agents are running without one?
  • When a model is deprecated, which agents, prompts, and prompt routers are impacted?

What This Unlocks for Security and IAM Teams

For every Bedrock Agent, Veza surfaces:

  • The agent and the IAM role it assumes
  • The AWS services and resources that role can effectively reach
  • The Action Groups, Knowledge Bases, Prompts, and Prompt Routers wired into the agent
  • The foundation, custom, and imported models the agent calls
  • The Guardrails attached to the agent — and the ones missing
  • The IAM principals that can invoke or manage the agent

That visibility plugs into everything Veza already does:

  • Access Reviews — Bedrock Agents become reviewable entities alongside humans, service accounts, and IAM roles
  • Blast Radius — over-privileged agents surface against the same risk model as any other identity in AWS
  • Rules & Alerts — trigger on a new agent without an owner, an agent assuming a role with *:* privilege, an agent running without a Guardrail, or an agent newly granted access to a sensitive S3 bucket
  • Access Graph search — natural-language and graph queries traverse the full chain from human invoker to Bedrock Agent to data, including across Knowledge Base connectors that reach into SharePoint, Confluence, and Salesforce

Frequently Asked Questions

Do I need a new connector to enable Veza for Bedrock Agents? No. If you already have the Veza AWS integration in place, Bedrock Agent discovery is automatic on the next extraction. There’s no separate connector, no additional datasource configuration, and no agent runtime to deploy.

Does Veza support Bedrock AgentCore in addition to classic Bedrock Agents? Yes. AgentCore covers the production runtime layer for agents built with any framework; this blog covers the native Bedrock Agent service. Both surface in the Access Graph as AI Agents and share Veza’s identity-first governance model.

How does Veza handle the IAM role a Bedrock Agent assumes? The CAN_ASSUME_ROLE edge is intentionally modeled as a distinct hop rather than silently merging the role’s permissions into the agent’s identity. That makes the delegation auditable — you can answer “which agents share this role” and “what does this role grant” as separate questions.

Can I run access reviews on Bedrock Agents the same way I do for human users? Yes. Bedrock Agents become reviewable entities in Veza Access Reviews, with the same campaign cadence and reviewer assignments you already use for humans, service accounts, and IAM roles.

Does Veza alert on Bedrock Agents running without a Guardrail? Yes. Rules & Alerts can trigger on a missing Guardrail attachment, an unowned agent, an agent assuming an over-privileged role, or an agent newly granted access to a sensitive resource.

Which data sources behind Bedrock Knowledge Bases does Veza model? S3, SharePoint, Confluence, and Salesforce — captured as BedrockKnowledgeBaseDataSource entities and traversable in the Access Graph. So you can ask “which Bedrock Agents reach into SharePoint” and get a single answer.

Getting Started

Veza AI Agent Security for Amazon Bedrock Agents is generally available for existing AWS integrations. Once Bedrock is enabled in the account, Veza picks up agents, action groups, knowledge bases, models, prompts, and guardrails on the next extraction.

Related Reading

Table of Contents

    Related Posts