Who Audits the Agents? Auditing AI Agent Access in AWS Bedrock

The Security GRC Guild is a monthly, open community that brings together practitioners in Governance, Risk, and Compliance to trade pain points, brainstorm solutions, and automate control testing or audit workflows using open source.

This month's session took place on August 12th, and for the first time, we opened a poll and let the community vote on the area to dig into. Access management won with 67% of the vote, so that's where we went.

From Access Reviews to an Unexpected Question: What About AI Agents?

The group got together and started listing the usual access management pain points: Segregation of Duties, Least Privilege access, User Access Reviews. Then one of our Subject Matter Experts raised a question nobody had fully answered yet: what about access for AI agents?

The tools organizations use to provision and manage identities for human users and service accounts don't yet address agents. The core question we set out to answer: how do you audit what access an AI agent has, and what it did with it?

We narrowed the scope to AWS and SailPoint, using SailPoint as the assumed provisioning system for entitlements. Here's the prompt we used to kick off the automation:

"Create a rule that audits for privileged access performed by agents on a given set of systems, such as AWS. Assume SailPoint as the provisioning system for entitlements. If any privileged access is identified for an agent, flag it as NON_COMPLIANT and note that a manual review is needed for each instance of privileged access."

We prompted our open-source AI agent to check whether SailPoint provisions access for agents. It was smart enough to get us back on track (yes, we went off track) by pointing out that AI agents aren't provisioned via SailPoint at all — that's exactly the gap we were investigating.

So we pivoted to AWS instead, and started researching how to differentiate AI agents from ordinary service accounts, and whether AWS Bedrock gave us a reliable way to identify them.

How to Identify AI Agents Using AWS Bedrock

This turned out to be a genuinely open question with a real answer. There is a way to identify AI agents in AWS using Bedrock, once you know what to look for.

What Is an AI Agent, in the AWS Context?

An AI agent is:

• An autonomous application using AWS Bedrock to make decisions.
• Something that uses large language models (LLMs) to reason and take action.
• Able to invoke AWS APIs based on AI reasoning, not just pre-programmed logic.
• An identity with intelligence, versus a traditional service account, which just executes pre-programmed logic.

That last distinction is the whole compliance problem in one sentence: a service account does what it was coded to do; an agent decides what to do. Auditing intent, not just permissions, is what makes this a different problem than standard non-human identity governance.

Method 1: AWS Bedrock API Usage Detection (Most Reliable)

AI agents call AWS Bedrock APIs. You can identify them through CloudTrail event detection, filtering for Bedrock event sources and agent-related event names:

{
  "eventSource": "bedrock.amazonaws.com",
  "eventName": [
    "InvokeModel",
    "InvokeModelWithResponseStream",
    "InvokeAgent",
    "CreateAgentActionGroup",
    "CreateAgent"
  ],
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::123456789012:assumed-role/ai-agent-role/session"
  }
}

Method 2: IAM Policy Analysis (Permission-Based)

AI agents need specific Bedrock permissions to operate. If an IAM role or user has bedrock:InvokeModel or bedrock:InvokeAgent permissions, it's likely an AI agent:

{
  "Effect": "Allow",
  "Action": [
    "bedrock:InvokeModel",
    "bedrock:InvokeAgent",
    "bedrock:InvokeModelWithResponseStream",
    "bedrock:Converse",
    "bedrock:ConverseStream",
    "bedrock:GetFoundationModel",
    "bedrock:ListFoundationModels"
  ],
  "Resource": "*"
}

Method 3: AWS Bedrock Agents Service (Native AI Agents)

AWS has a built-in Agents feature in Bedrock. Native Bedrock Agents have an Agent ID, an Agent ARN, an associated IAM service role, and action groups (the APIs the agent is allowed to call). You can list and inspect them directly:

# List all Bedrock agents
aws bedrock-agent list-agents

# Get agent details
aws bedrock-agent get-agent --agent-id ABCDEF123456

The response includes exactly the fields you need for an audit trail:

{
  "agent": {
    "agentId": "ABCDEF123456",
    "agentName": "CustomerSupportAgent",
    "agentResourceRoleArn": "arn:aws:iam::123456789012:role/AmazonBedrockExecutionRoleForAgents_ABC",
    "foundationModel": "anthropic.claude-3-sonnet-20240229-v1:0"
  }
}

Method 4: Resource Tags (Best Practice)

Organizations should tag AI agent identities directly, which makes every downstream method faster and more reliable:

{
  "Tags": [
    {"Key": "IdentityType", "Value": "AI-Agent"},
    {"Key": "BedrockEnabled", "Value": "true"},
    {"Key": "AgentFramework", "Value": "Bedrock"},
    {"Key": "ModelUsed", "Value": "Claude-3-Sonnet"}
  ]
}

Building the Audit Rule: From 6 Tasks to 8

With four identification methods on the table, we asked our AI agent to take a multi-method approach: Bedrock-native detection, CloudTrail API usage analysis, and invocation tracking (who invoked the InvokeAgent event). It came back with a game plan, splitting the automation into modular tasks.

Refined Workflow (6 Tasks)

• Task 1 — fetch_bedrock_agents: calls bedrock-agent:ListAgents and bedrock-agent:GetAgent to output all Bedrock native agents with their IAM service roles (AgentId, AgentName, AgentArn, AgentResourceRoleArn, FoundationModel, Status).
• Task 2 — fetch_bedrock_api_callers: queries CloudTrail LookupEvents for Bedrock API calls, filtered to eventSource = bedrock.amazonaws.com and event names including InvokeModel, InvokeAgent, and Converse, to output every IAM identity that invoked a Bedrock API (custom AI agents).
• Task 3 — consolidate_ai_agents: unions native Bedrock agents with custom agents calling Bedrock APIs and deduplicates by IAM role ARN, producing a comprehensive list of all AI agents, native and custom.
• Task 4 — fetch_ai_agent_policies: for each AI agent IAM role, fetches attached and inline policies (iam:ListAttachedRolePolicies, iam:GetRolePolicy, iam:GetPolicy, iam:GetPolicyVersion) to output all permissions for each agent.
• Task 5 — filter_privileged_ai_agents: matches agents against a privileged-access definition file using a JQ filter, outputting only the AI agents that hold privileged access.
• Task 6 — add_compliance_status: adds compliance fields with AI-specific reasoning — ComplianceStatus: NON_COMPLIANT, a ValidationStatusCode of PRIV_AI_AGNT_ACCS, and a ComplianceStatusReason noting that an autonomous AI agent with privileged permissions requires enhanced manual review and continuous monitoring due to prompt injection risk, model hallucination potential, and autonomous decision-making capability.

Refined Workflow (8 Tasks, 12 Required Inputs): Tracking Who Invoked the Agent

Six tasks told us which agents had privileged access. It didn't tell us who — human or non-human — actually invoked that agent. We asked for one more check to close that gap, and the workflow grew into eight tasks with twelve required inputs, explicitly tracking invocations:

• Task 1 — fetch_bedrock_agents: RequestConfigFile (TOML) against the Bedrock ListAgents API.
• Task 2 — fetch_bedrock_api_callers: RequestConfigFile (TOML) against CloudTrail for Bedrock API calls.
• Task 3 — fetch_agent_invocations (new): RequestConfigFile (TOML) against CloudTrail for InvokeAgent events specifically.
• Task 4 — consolidate_ai_agents: unions the two agent input files via a SQL query.
• Task 5 — join_agents_with_invocations (new): joins the agent list with the invocation list via a SQL query.
• Task 6 — fetch_ai_agent_policies: RequestConfigFile (TOML) against IAM policies, using the agent list as input.
• Task 7 — filter_privileged_ai_agents: AIAgentPrivilegedAccessDefinitionFile plus a JQ filter and output method.
• Task 8 — add_compliance_status: JQ transform and output method for the final compliance record.

Testing the Rule: Sample Audit Output

We then executed the rule to test it. Since this is a community event and we value data privacy, we tested against demo data instead of real infrastructure. It produced clean, audit-ready output.

Primary Evidence: The Flagged Agent

[
  {
    "System": "aws",
    "Source": "bedrock",
    "AgentId": "ABCD1234EFGH",
    "AgentName": "CustomerSupportAgent",
    "AgentType": "BEDROCK_NATIVE",
    "ResourceID": "arn:aws:bedrock:us-east-1:123456789012:agent/ABCD1234EFGH",
    "ResourceName": "CustomerSupportAgent",
    "ResourceType": "BedrockAIAgent",
    "ResourceLocation": "us-east-1",
    "ResourceTags": {},
    "IAMRoleArn": "arn:aws:iam::123456789012:role/BedrockAgentRole",
    "FoundationModel": "anthropic.claude-3-sonnet-20240229-v1:0",
    "PrivilegedPermissions": [
      "iam:CreateRole",
      "s3:DeleteBucket",
      "lambda:InvokeFunction"
    ],
    "AttachedPolicies": ["PowerUserAccess"],
    "TotalUniqueInvokers": 3,
    "ValidationStatusCode": "PRIV_AI_AGNT_ACCS",
    "ValidationStatusNotes": "AI agent with privileged access detected. Agent type: BEDROCK_NATIVE. Invokers: 3. Total invocations: 487",
    "ComplianceStatus": "NON_COMPLIANT",
    "ComplianceStatusReason": "Privileged AI agent with multiple invokers (3) - unclear accountability and potential for misuse. Autonomous AI agent with privileged permissions requires enhanced manual review and continuous monitoring due to prompt injection risks, model hallucination potential, and autonomous decision-making capabilities.",
    "EvaluatedTime": "2026-08-12T17:55:00Z",
    "UserAction": "MANUAL_REVIEW_REQUIRED",
    "ActionStatus": "PENDING",
    "ActionResponseURL": ""
  }
]

Secondary Evidence: Who Invoked It

[
  {
    "InvokerArn": "arn:aws:sts::123:assumed-role/SSO-Developer/john.doe",
    "InvokerType": "Human-Federated",
    "InvokerName": "john.doe@example.com",
    "InvocationCount": 245,
    "MFAAuthenticated": true,
    "LastInvocation": "2026-08-12T10:30:45Z",
    "SourceIPs": "203.0.113.42"
  },
  {
    "InvokerArn": "arn:aws:iam::123:role/svc-chatbot-backend",
    "InvokerType": "ServiceAccount",
    "InvokerName": "svc-chatbot-backend",
    "InvocationCount": 230,
    "MFAAuthenticated": false,
    "LastInvocation": "2026-08-12T09:15:20Z",
    "SourceIPs": "10.0.1.45"
  },
  {
    "InvokerArn": "arn:aws:iam::123:user/api-test-user",
    "InvokerType": "IAMUser",
    "InvokerName": "api-test-user",
    "InvocationCount": 12,
    "MFAAuthenticated": false,
    "LastInvocation": "2026-08-05T14:22:10Z",
    "SourceIPs": "192.0.2.100"
  }
]

Key Insights From the Sample Output

• Identified: a Bedrock native agent with privileged access.
• Risk level: HIGH — multiple invokers, including a service account.
• Privileged permissions: IAM role creation, S3 bucket deletion, Lambda invocation.
• Invokers: 3 distinct identities (2 humans, 1 service account).
• Usage: 487 total invocations over 42 days.

Try the Rule Yourself

Want to test this rule against your own infrastructure? Leave a comment and we'll send you the link to the open-source rule the GRCers authored as part of the Security Guild.

Have a pain point of your own? Join the Security Guild next month, on September 9th, 2026, at 12 PM CT — or jump into the conversation any time in our Slack.

Special thanks to Mosi Platt for bringing the use case, and a huge thanks to all the GRCers who shared their insights and helped build this automation.