AI Agent Identity Security: What a Cloud Pentest Must Prove
A cloud architecture review can show that an AI agent authenticates successfully, uses an approved service identity, and reaches documented tools. That still does not prove the agent is safe. The decisive question is whether valid credentials can be used outside the intended user, tenant, resource, workflow, or time boundary.
That is the core of AI agent identity security. An agent may be correctly authenticated and still be over-authorized, difficult to revoke, able to inherit the wrong user context, or permitted to cross a cloud data perimeter through an approved tool. These are cloud identity, authorization, and evidence problems as much as they are AI-security problems.
Recent platform changes sharpen the issue. Google Cloud added agent identities to VPC Service Controls rules and MCP attribute conditions. AWS published multi-tenant AgentCore resource-policy guidance. Microsoft now documents agent identities as a distinct identity type with dedicated authorization and lifecycle controls. The platforms are adding guardrails, but buyers still need independent proof that those guardrails are configured and enforced correctly.
A cloud penetration test for an agentic system should therefore prove the agent's effective authority, tenant isolation, delegation boundaries, revocation behavior, tool-level authorization, and data-perimeter enforcement under controlled conditions.
Why AI Agent Identity Is Now a Cloud Security Boundary
Cloud workloads already rely on non-human identities such as IAM roles, service accounts, managed identities, workload identities, API clients, and short-lived tokens. AI agents add a decision-making layer that can select tools, construct parameters, chain actions, delegate tasks, and act on behalf of a user. The security question becomes: "Should this agent be allowed to take this action, against this resource, for this user, now?"
Agent authority is assembled across layers. The effective permission may depend on the originating user's role, the agent identity, the runtime, an MCP client or server, a downstream API, a resource policy, a network perimeter, and business rules inside the application.
The requested action may also be influenced by untrusted content. A prompt, uploaded document, retrieved record, tool description, earlier output, or another agent can affect what action is selected. Strong authentication does not prevent an authenticated agent from misusing a legitimate tool.
Finally, one workflow may cross several security domains. It can read a customer record, query a vector store, create a ticket, and invoke a cloud function. If identity or tenant context is lost at one hop, a later action may still look valid.
This is why "we use OAuth" or "the tool is behind IAM" is not enough. The required assurance is outcome-based: permitted actions succeed, prohibited actions fail, failures are logged, and revocation stops access across every relevant layer.
Agent Identity Is Not Just Another Service Account
A service account usually represents a predictable workload. An AI agent may have a stable identity, but its actions vary according to context and orchestration. Treating it as a generic application identity can hide decisions about ownership, user delegation, tool authority, and lifecycle.
A defensible design distinguishes five principals: the originating human or system, the agent identity, the runtime identity, the tool or MCP server identity, and the downstream resource authorization context. These principals should not collapse into one shared integration account. Shared identities enlarge the blast radius and make it harder to identify who initiated an action or which credential must be revoked.
Microsoft's current least-privilege guidance for AI agents recommends unique ownership, effective-permission review, tool restrictions, action-level logging, and tested revocation. Google Cloud now allows individual agents or groups of agents in VPC Service Controls ingress and egress rules. The practical principle is consistent: give the agent a first-class identity, then constrain it by the user's authority, the tool's purpose, the resource boundary, and the approved lifecycle.
For systems using MCP, review identity together with the full protocol trust path. Our guide to MCP security testing before production covers authentication, tool discovery, invocation, user context, and downstream authorization.
AI Agent Identity Control Matrix for a Cloud Pentest
The matrix below converts architecture claims into testable evidence. Provider details vary, but the control objectives remain consistent.
| Control area | What the design should enforce | What the pentest should prove | Evidence expected |
|---|---|---|---|
| Unique identity and ownership | Every production agent has a distinct identity, owner, purpose, and environment | The agent cannot fall back to a shared human, developer, or integration identity | Identity inventory, ownership record, principal and environment mapping |
| Originating-user context | Delegated actions remain limited by the user's authority | A lower-privilege user cannot cause a higher-privilege action | Denied tests, token-claim trace, policy decision record |
| Effective permissions | Combined roles, policies, groups, inherited scopes, and conditions remain least privilege | The agent cannot reach unapproved tools, secrets, data, roles, or control-plane actions | Effective-permission graph and allowed/denied action matrix |
| Tool authorization | Tool discovery does not imply unrestricted execution | Read access cannot become write, delete, send, approve, deploy, or privilege change | Per-tool and per-method results, approval evidence |
| Tenant and resource isolation | Tenant, account, project, subscription, region, and environment boundaries hold at each hop | Valid Tenant B credentials cannot reach Tenant A resources | Cross-tenant negative tests, resource-policy and application logs |
| Data perimeter | Sensitive data stays inside approved network and service boundaries | The agent cannot move data through an unapproved endpoint or destination | Ingress/egress tests, perimeter logs, blocked-destination evidence |
| Credential lifecycle | Tokens are short-lived where appropriate and credentials are not shared | Expired, rotated, disabled, or revoked credentials stop working end to end | Revocation timing, token invalidation, rotation record |
| Delegation | Agent-to-agent handoffs cannot expand authority or erase the requester | A downstream agent receives no more authority than the approved task requires | Delegation trace, hop limits, signed context, deny results |
| High-impact actions | Sensitive actions require independent policy, limits, or approval | Alternate tools, parameters, or routes cannot bypass the control | Approval-path and alternate-route negative tests |
| Audit and containment | Logs connect user, agent, tool, action, resource, decision, and outcome | Investigators can reconstruct the action and disable one agent safely | Correlated trail, alert evidence, kill-switch test |
The matrix is broader than an IAM review. A policy can be valid while the workflow remains unsafe. Testing should follow the action from the initiating user to the final resource and verify the deny conditions that matter to the business.
Five Failure Paths Valid Credentials Do Not Prevent
1. A shared identity erases accountability
Several agents may use one service account during a pilot. Every action authenticates, but logs cannot reliably separate production, reporting, and test workflows. Revoking the credential disrupts all agents, while leaving it active preserves unnecessary access. Testing should confirm separate identities by purpose and environment, with no shared fallback path.
2. Delegation expands the user's authority
Agent A may delegate to Agent B, which has broader tools. If the original user's role and task scope are not carried and re-evaluated, Agent B can act under its own wider authority. AWS has highlighted this risk in multi-agent chains. Test each hop: agent-to-tool, agent-to-agent, and originating-user-to-resource.
3. Resource policies allow the right account through the wrong path
Cross-account access may be allowed without the intended VPC, endpoint, runtime, or environment restriction. AWS's June 2026 AgentCore guidance shows why identity and resource policies must work together and why explicit deny conditions matter. Verify runtime and endpoint policies together and test both approved and prohibited source paths.
4. Disabling the agent leaves downstream access active
A console may show the agent as disabled while a cached token, refresh token, shared key, delegated session, or downstream credential still works. Revocation testing must cover the complete path and record how quickly each service stops accepting access.
5. An approved tool crosses the data perimeter
An agent may legitimately read protected data and call an approved export or messaging tool. The combination can move data to an external destination. Google Cloud now supports agent identities and MCP attributes in VPC Service Controls. Testing should prove that read access cannot become a prohibited send, write, or export action and that perimeter controls survive MCP-mediated workflows.
What the Cloud Pentest Should Cover Across AWS, Azure, and Google Cloud
The objective is not to audit every tenant setting. It is to follow the highest-risk identity paths supporting the deployed workflows.
AWS
Review identity-based and resource-based policies, runtime and endpoint policies, cross-account trust, session conditions, source-VPC restrictions, organization controls where applicable, and downstream data permissions. Prove which principal can invoke the runtime, whether role chaining or secret access exceeds need, whether originating-user context reaches downstream tools, and whether explicit denies hold against broader allows.
Microsoft Azure and Entra
Distinguish agent identities, blueprint or parent permissions, managed identities, service principals, user-delegated access, role assignments, Conditional Access, application permissions, resource permissions, and lifecycle controls. Verify that restricted directory roles are not recreated through downstream API permissions, inherited scopes, or shared credentials. Test the kill switch by disabling the agent or blueprint and confirming that existing sessions no longer work.
Google Cloud
Connect IAM principals, agentic identities, principal sets, service accounts, workload identity, VPC Service Controls rules, MCP attributes, protected services, and downstream permissions. Prove that the intended agent principal is evaluated, ingress and egress rules hold, MCP conditions distinguish sensitive methods, revocation takes effect, and no public or alternate path reaches the same resource.
Provider controls are evidence, not a substitute for end-to-end validation. The final decision may still depend on application authorization, tenant filters, and tool parameters outside cloud IAM.
Evidence a Cloud and AI Pentest Must Produce
A buyer should be able to see what the agent could do, which prohibited paths were attempted, which controls stopped them, what failed, and what changed after remediation. A useful evidence package includes:
- Identity and ownership inventory for agents, runtimes, tools, services, downstream principals, environments, and approved purposes.
- Effective-authority map covering roles, scopes, resource policies, delegation, conditions, network boundaries, tools, and sensitive actions.
- Allowed and denied action matrix by user role, agent, tenant, tool, method, resource, and environment.
- Tenant-isolation evidence showing that one tenant's valid identity cannot reach another tenant's records, indexes, storage, runtime endpoints, or tool results.
- Delegation and audit trace connecting the requester, each agent hop, policy decision, tool call, and final resource action.
- Revocation and containment results recording what was disabled, how quickly access stopped, and which residual sessions required action.
- Data-perimeter and high-impact action results covering prohibited ingress, egress, destinations, approval bypasses, and alternate routes.
- Prioritized findings and retest evidence with business impact, minimal proof, remediation owner, and confirmation that prohibited paths now fail without breaking permitted workflows.
For broader model, RAG, tool, API, and infrastructure scope, see what an AI penetration test covers. Identity testing should be combined with workflow testing when prompts or retrieved content can influence tool selection.
Framework Mapping Without Turning the Test Into a Checklist
Frameworks organize evidence; they do not replace architecture-specific tests.
| Framework or control | Relevance | Expected evidence |
|---|---|---|
| OWASP ASI02: Tool Misuse | A legitimate tool is used outside its business purpose | Tool-level allow/deny results, method restrictions, approval and parameter controls |
| OWASP ASI03: Identity and Privilege Abuse | Credentials or delegated authority exceed intended scope | Effective permissions, delegation tests, user-context enforcement, cross-tenant results |
| OWASP ASI08: Cascading Failures | One action triggers amplified downstream impact | Chain trace, hop limits, stop conditions, downstream denies |
| OWASP LLM06:2025 Excessive Agency | Excessive functionality, permissions, or autonomy turns bad output into action | Restricted tools, least privilege, approval for sensitive actions, tested prohibited outcomes |
| NIST AI RMF | Structures governance, context, measurement, and treatment of AI risk | Ownership, context, measured control performance, remediation and monitoring decisions |
| NIST SP 800-53 AC-3 | Enforces approved logical authorizations for users and processes acting for them | Decisions at application, service, and resource layers |
| NIST SP 800-53 AC-6 | Applies least privilege to users and processes acting for them | Narrow roles, separate identities, restricted privileged actions, effective-permission evidence |
NIST notes that AI RMF 1.0 is being revised. Use it as a governance and evidence structure and check for updates during future refreshes. AC-3 and AC-6 are useful mappings, not an agent-specific certification.
Our guide on AI penetration testing and the NIST AI RMF covers governance and audit evidence. For financial and operational exposure, the cost of an unsecured AI agent serves a separate business-impact intent.
A Hypothetical Scenario: The Agent Authenticates Correctly but Acts for the Wrong Tenant
Consider a multi-tenant SaaS support agent. Customer records are separated, but one production runtime identity serves every tenant. The application passes a tenant identifier to an MCP tool, and the downstream API trusts that value because the runtime is authenticated.
The happy path works: Tenant A requests its tickets and receives the correct records. A controlled test asks whether a Tenant B user can make the agent request Tenant A's identifier, inherit cached Tenant A context, or use an alternate tool route that omits the tenant filter. It also checks whether the downstream API derives ownership from trusted identity context rather than a model-generated or client-supplied parameter.
A successful cross-tenant request is not merely a bad model answer. It is an authorization failure spanning agent identity, context propagation, tool design, and API enforcement. Remediation may require tenant-scoped identities, stronger downstream ownership checks, signed user and tenant context, resource-policy conditions, and role-by-tool regression tests. The retest must show that Tenant B is denied while each tenant's permitted workflow still works.
What Leadership Should Decide Before Production
Before approving a production agent, require written answers to these questions:
- Identity: Does every production agent have a unique, discoverable identity with a named owner or sponsor?
- Authority: What is the maximum effective action across all roles, tools, accounts, projects, subscriptions, and downstream services?
- User context: Which actions are performed as the agent, which are on behalf of a user, and where is that user's authority re-evaluated?
- Tenant boundary: Which control prevents valid credentials from reaching another tenant or environment?
- Tool boundary: Which methods are prohibited, which require approval, and which independent control enforces the decision outside the model?
- Data perimeter: Can an allowed read action be combined with another tool to transmit protected data?
- Revocation: How quickly can one agent and every dependent token, session, or credential be disabled?
- Evidence: Can the team reconstruct the full action path and show which policy allowed or denied it?
- Change control: Which changes to tools, roles, MCP servers, models, data sources, or agent chains trigger retesting?
The approval statement should be stronger than "IAM is configured." It should confirm that approved workflows work, prohibited workflows fail, failures are observable, and containment meets an agreed time objective.
Scope the Test Around the Agent's Real Authority
Start with the workflows that matter most: regulated or customer data access, cross-tenant operations, external communications, financial or approval actions, infrastructure changes, and multi-agent delegation. Then follow the identities, tools, policies, network paths, and downstream resources that make those workflows possible.
Pentest Testing Corp's cloud penetration testing service covers IAM, storage, secrets, exposed services, containers, serverless environments, and shared-responsibility gaps across AWS, Azure, and Google Cloud. When model behavior, RAG data, prompt injection, tool selection, or autonomous workflows are also in scope, combine it with AI penetration testing.
The goal is a bounded engagement that shows what the agent can actually do, which boundaries fail, how to reduce authority without breaking the product, and what leadership can safely approve after retesting.
Frequently asked questions about AI Agent Identity Security
What is AI agent identity security?
It is the identity, authorization, delegation, lifecycle, logging, and containment model governing what an agent can do, for whom, against which resources, and for how long.
Is a dedicated agent identity enough?
No. A unique identity improves accountability, but testing must still verify effective permissions, user context, tool restrictions, tenant isolation, data perimeters, revocation, and downstream authorization.
How is an agent identity different from a service account?
A service account usually represents a predictable workload. An agent can select tools, chain actions, act for different users, and delegate to other agents, so its authority must be evaluated per workflow.
Should an agent use the user's identity or its own?
Many systems need both: a stable agent identity for accountability and lifecycle control, plus verified user context for delegated authorization. The final resource should evaluate the relevant user, agent, tenant, action, and resource conditions.
What should a cloud pentest test for MCP authorization?
Identity at every hop, token audience and scope, discovery versus invocation, per-tool and per-method permissions, user-context propagation, tenant and data boundaries, approval, revocation, and audit correlation.
How should revocation be tested?
Disable the agent, invalidate sessions and refresh tokens, rotate shared credentials if present, remove inherited access, and verify that the runtime, tool, and final resource all deny further requests. Record time to containment.
When should agent identity security be retested?
After remediation and after material changes to identities, roles, policies, tools, MCP servers, models, orchestration, tenant architecture, data sources, perimeters, or delegation chains.
Does mapping to OWASP or NIST prove security?
No. Mappings organize risks and evidence. Assurance comes from tests showing that permitted actions succeed, prohibited actions fail, failures are observable, and containment works.
