Access Control Policy Testing for Agentic Systems

Eighty percent of organizations have already encountered risky behaviors from deployed agents, including unauthorized system access and sensitive data exposure, according to SailPoint's May 2025 research. Gartner projects agent presence in 40% of enterprise applications by end of 2026, up from under 5% in 2025. The window for getting access control testing right is not wide. A methodology calibrated to human behavior will systematically miss the failure modes agents produce. Here is what a methodology built for agents looks like.

Agents Are a Categorically Different Kind of Access Control Subject

Traditional access control testing assumes a human who ignores most of their permissions most of the time. People are selective, slow, and contextually bounded. They log in, do a specific thing, and leave. Agents do not operate this way. An agent holds credentials, calls APIs, reasons about which tools are relevant to its current objective, and invokes them accordingly, without waiting for a human to prompt each step. Ask an agent to summarize support tickets, and if nothing blocks it, it will infer that billing history would enrich the summary and call the billing API on its own initiative. This is not a bug. It is the feature.

The consequence for testing is profound. RBAC and ACLs were designed to govern deterministic software with predictable execution paths. Agents can pursue multi-step objectives, retain memory across sessions, spawn sub-agents, and adjust their behavior mid-execution. None of these properties were contemplated in the systems those controls were built to govern. Think of it this way: traditional access control is a locked room with a single door; agentic access control is a locked room the occupant can redesign while you are still deciding where to put the key.

The population of these identities is also expanding at a rate that makes informal tracking untenable. Enterprises averaged roughly 82 machine identities per employee in early 2024, and Palo Alto Networks projects AI-agent identities alone will grow 85% over the next 12 months. The attack surface is not static. It is accelerating, which means a testing practice that relies on manual enumeration and periodic review is already behind before it begins.

The most important conceptual shift: agents compress the window between a policy gap and its exploitation to near zero. At machine speed, a misconfigured permission is not a latent risk waiting to be discovered. It is an active exposure being exercised continuously.

Before Writing a Single Test Case, Get Identity Right

The most consequential access control decision happens before any behavioral testing begins, and most organizations get it wrong. Agents must be registered as distinct, enumerable identities. Not as features running under a human user's session. Not as services sharing a key with three other processes. As their own discrete principals with their own declared scope.

When an agent reuses a human session or a shared service account, three things break simultaneously. Permissions become excessive because the agent inherits everything the human was granted, not just what the task requires. Attribution becomes impossible because every action the agent takes is logged against the wrong identity, which OWASP NHI10 identifies as one of the primary reasons non-human identity abuse goes undetected. And classic confused-deputy vulnerabilities are created, where the agent can be induced to use the human's authority in ways the human never sanctioned. In short: if your agent is wearing someone else's badge, you have already lost track of who is in the building.

The prerequisite inventory step is unglamorous but non-negotiable: before testing, enumerate every agent running in the environment. Model, version, credential type, tool access, callable sub-agents. That inventory is the attack surface. You cannot test what you haven't mapped, and you cannot defend what you cannot enumerate.

Each agent identity should carry a declared scope: the specific tools, APIs, and data it is expected to access under normal operating conditions. This declared scope becomes the baseline against which all behavioral tests measure deviation. Agents that inherit credentials from humans, share credentials with peer agents, or hold long-lived API keys without expiration should be flagged as failures at this stage, before a single behavioral test is run. The credential hygiene is a prerequisite, not an afterthought.

Testing Least Privilege When Execution Paths Are Probabilistic

Static role assignment describes planned access. It does not capture runtime tool-chaining, contextual inference, or an agent invoking an API that was never intended to be part of its operational scope. Testing least privilege for agents requires accepting this ambiguity and designing for it.

The operative framing is: least privilege is a moving boundary. What access is needed for this task, at this moment, given this context? Not a one-time grant at provisioning that persists indefinitely. The testing methodology has to reflect that.

The basic approach is straightforward, if labor-intensive. Enumerate the full tool surface the agent's credentials permit. Run representative tasks and record every API call actually made. The gap between the permitted surface and the used surface is excess access that needs to be removed or gated. This delta is the starting point, not the conclusion.

From there, specific test types address specific failure modes. Just-in-time access controls require their own tests: agents should receive short-lived, scoped tokens per task rather than long-lived keys, and a test that runs a task and then verifies the credential is no longer valid is a basic check that is frequently absent in practice.

Separation-of-duties constraints require deliberate task design. Having a single agent attempt to complete an entire high-risk workflow end-to-end — approving and executing a transaction, for instance — is the only way to confirm the policy actually blocks the chain. Assuming the policy is configured correctly is insufficient; the test must demonstrate the block holds under realistic conditions.

ABAC and PBAC controls require contextual variation. Change the attributes: time of day, data sensitivity classification, transaction value. Verify that the policy decisions change as expected. RBAC alone will not surface context-dependent failures because RBAC does not evaluate context. If the only test run is role assignment verification, entire categories of misconfiguration will pass unexamined.

Delegation Chains Are Where Multi-Agent Systems Fall Apart

Multi-hop delegation is one of the most underappreciated risks in agentic architectures. A human authorizes Agent A. Agent A delegates a subtask to Agent B. Agent B delegates further to Agent C. Each hop should represent a valid narrowing of the original scope. In practice, there is often no mechanism to verify that constraint, and current protocols, including OAuth 2.1, were not designed to represent or validate these chains, as CSA documented in August 2025.

Johann Rehberger's documented Cross-Agent Privilege Escalation case, published in September 2025, is the canonical production example. A compromised GitHub Copilot agent wrote malicious instructions into Claude Code's configuration files. On startup, Claude Code loaded the poisoned configuration and executed attacker-controlled code. This is a confused-deputy attack executed across agent boundaries, and it succeeded not because the models were fooled but because the access control layer between agents was not enforcing scope boundaries at the delegation interface.

Test case design for delegation must address this directly. For every agent that can call another agent, write a test that verifies the receiving agent cannot be induced to act outside the scope of the original human delegation, including when the inducement comes from a manipulated instruction delivered by the calling agent. The threat model includes the upstream caller as a potential attack vector.

Credential forwarding deserves its own test class. When Agent A passes credentials to Agent B to complete a delegated task, verify that the forwarded credential is scoped to that specific task and expires when it ends. The failure mode to test for is Agent B inheriting Agent A's full access with no revocation mechanism, which is precisely what happens when delegation is implemented as credential copy-forwarding rather than on-behalf-of token issuance.

Chain verifiability is the deeper requirement. Agent C, receiving a request from Agent B, should be able to verify that B's authority derived from A, that A's derived from the originating user, and that each delegation was a valid narrowing of the prior scope. Test whether this verification actually occurs or whether downstream agents accept instructions from any caller claiming authority. The CoSAI Agentic Identity and Access Management Framework, published in April 2026, describes signed agent manifests and on-behalf-of tokens as mechanisms to make these chains auditable, and test infrastructure should be capable of producing and validating them.

Prompt Injection Is an Access Control Failure, Not a Model Problem

The framing matters here. Prompt injection, listed as LLM01 in OWASP's LLM Top 10 and ASI01 in the Agentic Security Initiative Top 10, is frequently categorized as a model safety or alignment concern. That framing lets security teams treat it as someone else's problem. It is not. When malicious instructions embedded in content the agent reads redirect the agent to take actions its access policy should prohibit, that is an access control failure. The policy layer failed to constrain the action. Whether the model was technically "fooled" is a secondary concern.

The numbers make the urgency concrete. Indirect prompt injection against Claude Opus 4.5 in agentic coding environments succeeded 4.7% of the time at one attempt, 33.6% at ten attempts, and 63.0% at 100 attempts, per Anthropic's November 2025 research. At machine speed and production scale, low per-attempt rates compound quickly. An agent processing hundreds of external documents per session is not operating at one attempt. Saying the per-attempt rate is low is like saying a dripping faucet is not a flood — technically accurate, and entirely beside the point once you have left it running for a week.

EchoLeak, documented as CVE-2025-32711 in mid-2025, illustrates the production manifestation. Engineered prompts in email triggered Microsoft Copilot to exfiltrate sensitive data without user interaction. The access control failure was specific: the agent's policy permitted data egress when the instruction came from content the agent had read, not only when the instruction came from the human operator. Testing must probe that distinction explicitly.

Test design for prompt injection is black-box testing of the policy layer. Embed adversarial instructions in the external content the agent will process during normal task execution: emails, documents, web content, database records. Verify the agent does not execute them. This is not prompt engineering experimentation. It is verifying that the policy boundary holds against realistic attack vectors.

Goal hijacking tests follow similar logic but target mid-execution manipulation. Provide the agent with a legitimate task, introduce competing objectives through tool outputs, memory contents, or sub-agent responses during execution, and verify the agent's actions remain within the access scope defined for the original task.

Memory poisoning requires longitudinal test design, which is where most testing programs currently have no coverage at all. A Palo Alto Unit42 case from October 2026 documented a procurement agent manipulated over three weeks into believing it could approve purchases up to $500,000 without review. The access control drift was incremental, below any single-session detection threshold. The test design implication: inject subtly erroneous context into the agent's memory or knowledge base across multiple interactions and verify the agent's access decisions do not drift from their original policy bounds. This requires test infrastructure that persists across sessions, which most current frameworks do not support.

Audit Logs Are Worthless If the Agent Can Touch Them

An audit log the agent can write to is not an audit log. It is evidence the agent can tamper with, selectively omit from, or fail to populate without immediate detection. This is not theoretical; it is a predictable consequence of deploying agents with write access to logging infrastructure. Testing must verify that logs are stored in a system outside the agent's access scope. This is a control configuration test before it is anything else.

Completeness testing is the next layer. Run a known task, then verify the log contains a record of every tool call, every API invocation, every credential use, and every delegation step that occurred during execution. Gaps in log coverage are as significant as policy misconfigurations because they are how those misconfigurations go undetected. If the log has a gap, the assumption must be that something happened in that gap.

Attribution testing addresses the identity problem introduced earlier. Confirm that each logged action is attributed to the specific agent identity that took it, rather than to an inherited human credential or a shared service account, and that the record includes enough context to reconstruct the delegation chain that authorized the action. A log entry that says "billing API called" is not useful. A log entry that says which agent called it, under what delegated scope, on behalf of which originating user, at what point in a multi-step workflow, is useful.

Immutability verification is the check that is most frequently skipped because it feels too obvious to test. Attempt to modify or delete log entries using the agent's credentials. Verify the attempt fails. It is a basic control. It is also frequently unverified.

Real-time detection, not forensic reconstruction, is the standard agents require. A complete, immutable, attributed log loses almost all its value if anomalies are only discovered in post-incident review. At machine speed, a single agent session can span thousands of actions. By the time a forensic analysis identifies a policy violation, the exposure may have been ongoing for hours. Test whether the monitoring layer surfaces violations as they occur. If it does not, the logging architecture is providing an illusion of oversight rather than actual enforcement.

Mapping to the Frameworks Teams Already Have to Answer To

The testing methodology above does not require building a compliance argument from scratch. It maps onto frameworks teams are already accountable to, with some important caveats about where those frameworks are thin.

The OWASP Agentic Security Initiative Top 10, published in December 2025 and covering ASI01 through ASI10, is the most directly applicable technical reference. Its categories correspond directly to the test types above: goal hijacking (ASI01), tool misuse (ASI02), identity abuse (ASI03), supply chain risk (ASI04), memory poisoning (ASI06), and insecure inter-agent communication (ASI07). If the testing program needs a checklist that drives individual test case design, the ASI Top 10 is the right starting point.

The OWASP LLM Top 10 v2.0, also from 2025, covers model-level risks well but was designed for applications that call a model. Agents call tools, spawn sub-agents, and reach across the environment through orchestration layers and MCP servers. The LLM Top 10 only partially addresses agent identity, inter-agent trust, and tool misuse in orchestration contexts. It is a useful supplement, not an adequate primary framework for agentic systems.

NIST AI RMF 1.0, published in January 2023, provides the governance layer: the GOVERN, MAP, MEASURE, and MANAGE functions that give CISOs and audit committees a language for program-level accountability. NIST AI 600-1, the generative AI profile published in July 2024, builds on it. The testing methodology above maps into the MEASURE and MANAGE functions, but NIST does not prescribe technical test cases. It provides the accountability structure; OWASP ASI provides the technical content.

The practical mapping is clean: use NIST AI RMF for program-level audit readiness, use OWASP ASI Top 10 as the technical checklist. They are complementary, not redundant.

The honest gap to name: no current published framework fully addresses continuous authorization testing. The ongoing verification that policy decisions remain correct as an agent's context, memory, and delegated scope evolve across a long-running session is not covered by any standard that exists today. The memory poisoning and goal drift scenarios described above fall into this gap. This is where the methodology has to extend beyond published requirements, not because the standards are poorly designed, but because the threat model is genuinely novel and the frameworks have not caught up. They will. In the meantime, the agents are already in production.