How to inventory AI agents in AWS Bedrock: Find every agent, role, tool and endpoint

AI agents in AWS are spread across two Bedrock services, every Region and every account, and each one carries an IAM role, tools and endpoints that someone has to own. Bedrock Agents, AgentCore Runtime agents, AgentCore gateways and inline agents invoked at run time all leave different traces, and none of the console pages shows them together. This runbook builds a reconciled inventory with read-only AWS CLI calls, adds the IAM role and tool detail that makes the inventory useful for security, and uses CloudTrail to find agents that do not appear as resources at all. It then covers pausing and removal with a rollback. It is for cloud security and platform engineers working across one account or an AWS Organization. For the service's security model, see the Amazon Bedrock Security Guide and the AWS Bedrock AgentCore Security Guide.

This is an independent guide from NHI Mgmt Group, based on AWS's public documentation as of November 2026. It is not sponsored or reviewed by AWS. AgentCore APIs are changing quickly, so confirm commands and fields against the current AWS CLI reference.

Key takeaways

• There are two control planes. Classic Bedrock Agents live under aws bedrock-agent; AgentCore runtimes, gateways, workload identities and credential providers live under aws bedrock-agentcore-control. Inventory both, in every Region.
• The role is the risk. agentResourceRoleArn on a Bedrock agent and roleArn on an AgentCore runtime define what the agent can reach in AWS; record and review them with the agent.
• Tools hide in action groups. Each action group points at a Lambda function or returns control to the caller, and may enable built-in signatures such as AMAZON.CodeInterpreter or ANTHROPIC.Bash.
• Some agents are not resources. InvokeInlineAgent calls create agents at run time; only CloudTrail data events for AWS::Bedrock::InlineAgent reveal them.
• Pause before you delete. Setting an alias to REJECT_INVOCATIONS stops invocations and is reversible; deletion is not.

When you need this

• Before agents reach production: a baseline per account and Region lets every new agent be reviewed as a change rather than discovered after an incident.
• For audit or an AI register: NIST SP 800-53 CM-8 and NIST CSF 2.0 ID.AM-02 call for an inventory of system components and services. The AI Register and AI Inventory Template holds the governance record this inventory feeds.
• When cost or model invocation spikes: unknown agents often show up first as Bedrock spend or CloudTrail activity from a role nobody recognises.
• Before tightening IAM: you cannot right-size agent roles until you know which agents use them.

What counts as an agent in AWS Bedrock

The AWS Agent Registry is a catalogue that teams publish records into (record types AGENT, MCP, SKILL and CUSTOM), not a discovery tool. Its browse API returns only records whose latest revision is Approved, so draft and pending records are invisible there. AWS has moved the registry to the agent-registry namespace and announced that support for the preview bedrock-agentcore namespace would end on 30 October 2026; check which namespace your registries use. Treat the registry as the "declared" list and the CLI discovery below as the "actual" list.

Before you start

• Permissions: use a read-only role that allows the bedrock:List* and bedrock:Get* agent actions, the AgentCore control plane list and get actions, iam:GetRole and list policy actions, lambda:GetFunction and CloudTrail read. Keep update and delete permissions in a separate role behind approval.
• Scope: list the Regions enabled in each account (aws ec2 describe-regions --query "Regions[].RegionName") and run every step per Region. Agents in an unexpected Region are a finding in themselves.
• Logging: management events such as CreateAgent are in CloudTrail by default. Agent invocation is a data event and is only logged if you add advanced event selectors for AWS::Bedrock::AgentAlias and AWS::Bedrock::InlineAgent, which incurs extra CloudTrail charges.
• Record format: account, Region, agent type, ID and ARN, name, status, owner tag, IAM role, tools, data sources, inbound authoriser, last updated and decision.

Step-by-step

Steps 1 to 6 are read-only. Step 7 is reversible. Step 8 is destructive.

1. List Bedrock agents in each Region.

   aws bedrock-agent list-agents --region <region> \
     --query "agentSummaries[].{ID:agentId,Name:agentName,Status:agentStatus,Version:latestAgentVersion,Updated:updatedAt}" \
     --output table

   The CLI pages automatically. Note agents in NOT_PREPARED or FAILED status: they are often abandoned experiments that still hold a role.
2. Read each agent's configuration and role.

   aws bedrock-agent get-agent --agent-id <agent-id> \
     --query 'agent.{model:foundationModel,role:agentResourceRoleArn,guardrail:guardrailConfiguration,memory:memoryConfiguration,collab:agentCollaboration,orch:orchestrationType}'

   Record agentResourceRoleArn, then read the role's trust policy and attached and inline policies with aws iam get-role, list-attached-role-policies and list-role-policies. Flag agents with no guardrail, with memory enabled (SESSION_SUMMARY with a storageDays value up to 365), with CUSTOM_ORCHESTRATION (a Lambda in the loop) or with a SUPERVISOR collaboration mode that delegates to other agents.
3. Enumerate aliases and action groups.

   aws bedrock-agent list-agent-aliases --agent-id <agent-id> \
     --query 'agentAliasSummaries[].{id:agentAliasId,name:agentAliasName,status:agentAliasStatus,version:routingConfiguration[0].agentVersion}'
   aws bedrock-agent list-agent-action-groups --agent-id <agent-id> --agent-version <version>
   aws bedrock-agent get-agent-action-group --agent-id <agent-id> --agent-version <version> --action-group-id <id> \
     --query 'agentActionGroup.{executor:actionGroupExecutor,signature:parentActionSignature,state:actionGroupState}'

   Run action groups for DRAFT and for every version an alias routes to, since they can differ. For each Lambda executor, record the function's own execution role. Flag ENABLED action groups with the signatures AMAZON.CodeInterpreter, ANTHROPIC.Computer, ANTHROPIC.Bash or ANTHROPIC.TextEditor, and function schemas where requireConfirmation is DISABLED on actions that change data.
4. List AgentCore runtimes and their details.

   aws bedrock-agentcore-control list-agent-runtimes --region <region> \
     --query 'agentRuntimes[].{Name:agentRuntimeName,Id:agentRuntimeId,Status:status}'
   aws bedrock-agentcore-control get-agent-runtime --agent-runtime-id <id> \
     --query '{role:roleArn,network:networkConfiguration.networkMode,protocol:protocolConfiguration.serverProtocol,auth:authorizerConfiguration,identity:workloadIdentityDetails.workloadIdentityArn}'

   Record the protocol (MCP, HTTP, A2A or AGUI), whether the runtime runs in PUBLIC or VPC network mode, and the inbound JWT authoriser's discoveryUrl, allowedAudience and allowedClients. Review environmentVariables for anything that looks like a secret; see How to find secrets in AI agent transcripts and traces for the wider pattern.
5. List the AgentCore tool and credential layer. Run list-gateways and list-gateway-targets to see which APIs and Lambda functions are exposed as tools, then list-workload-identities, list-oauth2-credential-providers and list-api-key-credential-providers. Map each credential provider to the runtimes that use it: these are the third-party tokens your agents hold. The Cloud Agent Identity Services Compared guide explains how workload identities fit.
6. Find agents that are not resources. Query CloudTrail (Lake or your SIEM) for eventSource bedrock.amazonaws.com and the events InvokeInlineAgent and InvokeAgent, grouped by calling principal. Inline agents and callers of aliases you did not list are your shadow agents. Also search management events for CreateAgent over the retention window to find who creates agents and from where.
7. Reconcile, tag owners and pause (reversible). Join the results with the Agent Registry records and your AI register. Tag each agent and role with owner and purpose. For an unowned or unjustified agent, pause the alias:

   aws bedrock-agent update-agent-alias --agent-id <agent-id> \
     --agent-alias-id <alias-id> --agent-alias-name <alias-name> \
     --alias-invocation-state REJECT_INVOCATIONS

   The alias name is required even when only the state changes. Set an action group to DISABLED to remove a single tool. For an AgentCore runtime, add an explicit deny to its role or tighten the inbound authoriser's allowed clients. Hold for a full business cycle.
8. Delete (destructive). After owner sign-off and the hold period, delete aliases, action groups and the agent, or the AgentCore runtime, then decide separately whether the IAM role, Lambda functions and credential providers are still needed. Export the full configuration from steps 2 to 5 first: it is your only rebuild source.

Verify it worked

• Coverage: every account and enabled Region has a dated result for both control planes, including empty results.
• Paused state: list-agent-aliases shows REJECT_INVOCATIONS and CloudTrail shows no successful InvokeAgent for that alias.
• Reconciliation: every discovered agent has an owner tag and a register entry, and every Approved registry record maps to a real resource.
• No breakage: owners confirm no failed workflow during the hold period.

Rollback and common errors

Common failure patterns

• One Region only: teams test in a Region close to the model they want, so agents appear far from the main estate.
• Inventorying agents, not roles: the agent record without its role and Lambda execution roles hides the real blast radius. The agent's reach is the union of those roles.
• Checking DRAFT only: production aliases route to numbered versions whose action groups may differ from the draft.
• Trusting the registry as the inventory: it lists what teams declared and approved, not what runs.
• Ignoring inline agents: with no resource to list, they surface only if data events are on.

Hardening afterwards

• Turn on the data events: keep advanced event selectors for agent aliases and inline agents in your organisation trail, and alert on callers outside the approved list.
• Require tags at creation: enforce owner and purpose tags on agents, runtimes and roles through infrastructure as code checks.
• Right-size roles: use IAM last accessed data on agent roles and remove unused services. See How to find unused AWS IAM roles and access keys.
• Register what you keep: publish approved agents into the Agent Registry so the declared list matches the actual list. The AI agent registry guide covers the operating model.

Single account or AWS Organization

A single team account can run steps 1 to 5 as a short script per Region and keep the output in a spreadsheet. An AWS Organization should run the same calls from a central security account that assumes a read-only role in every member account, write results to one store, and use an organisation trail for the data events. Prioritise accounts with Bedrock spend first; they are where agents actually exist.

Metrics

Framework mapping

Practitioner checklist

• Enumerate enabled Regions in every account before listing anything.
• Run list-agents and list-agent-runtimes in each Region.
• Record the agent role, runtime role and every Lambda execution role.
• Check action groups for the draft and every aliased version.
• List gateways, workload identities and credential providers and map them to agents.
• Enable data events for agent aliases and inline agents, and group callers.
• Compare discovered agents with Approved Agent Registry records.
• Pause with REJECT_INVOCATIONS before any deletion and export configuration first.

Standards and references

• AWS CLI Reference: bedrock-agent list-agents
• AWS CLI Reference: bedrock-agent get-agent
• AWS CLI Reference: bedrock-agent get-agent-action-group
• AWS CLI Reference: bedrock-agent update-agent-alias
• AWS CLI Reference: bedrock-agentcore-control get-agent-runtime
• AWS CLI Reference: bedrock-agentcore-control list-workload-identities
• AWS: Browse approved records in AWS Agent Registry
• AWS: Monitor Amazon Bedrock API calls using CloudTrail

Related NHI Mgmt Group resources: AWS Bedrock AgentCore Security Guide · Amazon Bedrock Security Guide · AI agent registry · Cloud Agent Identity Services Compared · How to inventory AI agents in Microsoft 365