Pentesting agentic systems needs a different security model

At a glance

What this is: This is Terra's analysis of why agentic systems need a different pentest model because the real attack surface includes tools, memory, permissions, and multi-step behaviour, not just the chat interface.

Why it matters: IAM, PAM, and AI security teams need to test how agentic systems inherit and exercise access, because the security failure often sits in privilege boundaries and tool trust rather than the prompt itself.

Context

Agentic systems are software that can choose actions, use tools, and carry state across steps, so their security boundary is wider than a single request and response. That matters for identity governance because the effective risk sits in delegated access, inherited privilege, and the controls around what the system is allowed to do once it starts acting.

A traditional web pentest is useful when AI remains an embedded feature, but it does not fully expose the behaviour of systems that persist context, call APIs, and make decisions over time. In this article's framing, the key problem is not AI in the abstract, but the mismatch between request-based testing and action-based systems that now touch workload identity, tool trust, and agent governance.

Key questions

Q: How should security teams pentest agentic systems differently from web applications?

A: Security teams should test agentic systems as action-taking runtimes, not just as input surfaces. That means validating prompt injection, tool misuse, inherited privilege, memory persistence, and multi-step abuse paths across the full workflow. A web pentest can still find some issues, but it will miss the runtime behaviour that creates the highest-risk failures in agentic systems.

Q: Why do agentic systems create more risk than AI features embedded in web apps?

A: Agentic systems create more risk because they can act across multiple steps, use tools, persist context, and inherit broader permissions than a normal AI feature. Once the system can decide and execute, the security problem shifts from input control to authority control. That makes privilege scope, tool trust, and state persistence the main risk drivers.

Q: What are the signs that an agentic system's security controls are failing?

A: Warning signs include broad inherited permissions, unreviewed tool additions, memory that can be influenced by untrusted content, and actions that continue after the original user request should have ended. If the agent can move from advice to execution without a clear boundary, the control model is already too loose. Testing should surface those transitions explicitly.

Q: What should teams do when an agent can access tools, APIs, and memory at the same time?

A: Treat the combined capability as a high-risk control boundary and require explicit ownership for each tool, data source, and permission path. The operational question is not whether the agent is useful, but whether each enabled action is necessary, observable, and revocable. Without that structure, one compromised context can propagate through the whole workflow.

Technical breakdown

Why agentic systems expand the pentest boundary

An agentic system is not just a model answering a prompt. It may retrieve data, call tools, maintain memory, and decide the next step without a human in the loop. That means the attack surface includes runtime state, connected services, and the permissions attached to those services. A test that only probes the user input path will miss indirect influence through stored content, retrieved documents, APIs, and inter-agent exchanges. In practice, the unit of analysis shifts from a single interaction to a multi-step execution chain that can be steered across time.

Practical implication: pentest scope must include the agent's toolchain, memory, and permission boundaries, not just the visible interface.

How identity and privilege abuse shows up in agentic systems

Identity and privilege abuse happens when an agent can act with more authority than the task requires, or when the system inherits access from a broader human or service account. In agentic environments, that can turn a normal workflow into an escalation path because the agent can invoke tools, move data, or trigger changes that a user never directly approved. The security issue is not only authentication. It is the combination of delegation, implicit trust, and operational reach across multiple steps. That is why agentic systems need testing for permission scope, authority reuse, and boundary crossing.

Practical implication: verify that every tool and action is constrained to task-scoped privileges and cannot exceed the intended authority boundary.

Why context poisoning and cascading failure are different from prompt injection

Prompt injection is one input path, but agentic systems also absorb memory, retrieved content, tool outputs, and cross-agent messages. If any of those channels are poisoned, the bad instruction can persist and affect later decisions, which makes the failure durable rather than momentary. The article also points to cascading failures, where one bad action or compromised component propagates through a wider workflow. That is a different risk model from classic web exploitation because the harm compounds as the agent continues to operate with trusted context.

Practical implication: test persistence channels and downstream propagation, because the first malicious input is often not the last security event.

Threat narrative

Attacker objective: The attacker aims to redirect agent behaviour so the system performs unsafe actions, exposes data, or executes operations outside its intended scope.

1. Entry occurs through manipulated input, retrieved content, or a compromised connected tool that the agent trusts during runtime.
2. Credential or privilege abuse follows when the agent uses inherited permissions to invoke tools, reach APIs, or perform actions beyond the original user intent.
3. Escalation and impact occur as the agent persists poisoned context, spreads bad decisions across chained steps, or triggers wider workflow compromise.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic system pentesting is a separate security discipline, not an extension of web testing. The visible chat layer is only one control surface in systems that can retrieve data, invoke tools, persist memory, and chain actions over time. That makes request-response testing structurally incomplete. Practitioners need a testing model that follows the agent's execution path, not just its user interface.

Identity and privilege abuse is the central governance problem in agentic systems. When an agent inherits access from a human, service account, or connected tool, the real failure is often that the delegated authority is too broad for machine-driven action. That is where NHI governance and AI governance meet: the system is only as safe as the permissions it can exercise without review. Teams should treat authority scoping as a first-class test condition, not a policy footnote.

Context persistence creates a governance debt that traditional pentests do not measure. Memory, retrieved content, and tool outputs can carry malicious influence forward after the initial interaction ends. This creates a named control gap we would call persistent agent influence: malicious steering that survives beyond a single prompt and shapes later decisions. The practitioner conclusion is straightforward: if the system remembers, the attacker can too.

Continuous validation is becoming the right operating model for agentic risk. The article is right that new tools, MCP servers, and data sources can alter the attack surface immediately. Static, periodic testing leaves a window where a newly connected capability is effectively unassessed. For security programmes, this validates a shift toward continuous assurance of agent behaviour, access scope, and tool trust.

OWASP's agentic model is a useful starting point, but governance teams must translate it into control ownership. ASI01 through ASI10 describe the failure modes well, yet the operational question is who owns the permission boundary, who reviews tool additions, and who signs off on agent scope changes. The practitioner implication is to map agent risk to identity, application, and AI governance controls before the next integration expands the system further.

From our research library:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Persistent agent influence: once context, memory, and retrieved content can shape future actions, the control problem moves from prompt safety to lifecycle governance. Security teams need to know which inputs can survive long enough to steer later behaviour, because that persistence is where agentic compromise becomes operationally durable. Continuous validation matters more than a one-off test cycle when the system itself keeps changing.

Pentest programmes should now distinguish between AI as a feature and AI as an actor. That distinction determines whether the right control question is output safety, or whether delegated authority, tool trust, and cross-step execution need to be governed as part of the production security baseline.

For practitioners

• Define the agent boundary before testing Separate AI-enabled features from true agents, then document which components can act, which can only respond, and which tools each one may invoke.
• Test delegated privilege, not just prompts Build test cases for task-scoped access, inherited permissions, and tool execution paths that can exceed the intended user action.
• Exercise memory and retrieval abuse paths Validate whether poisoned stored content, retrieved documents, or tool outputs can influence later decisions or persist across sessions.
• Reassess every new tool and connector Treat each MCP server, API, plugin, or data source as a new attack surface that needs explicit validation before production use.
• Operationalise continuous validation Move from periodic pentests to continuous checks that reflect how fast agent behaviour changes when tools, context, and permissions evolve.

Key takeaways

• Agentic systems widen the attack surface because they can retrieve data, call tools, retain context, and make decisions across multiple steps.
• The main governance failure is not just prompt manipulation, but overbroad delegated authority and persistent influence inside the agent runtime.
• Pentest and assurance programmes need to move from single-interaction testing to continuous validation of tools, permissions, memory, and chained actions.

Key terms

• Agentic Pentesting: An approach to penetration testing that uses AI-driven systems to support planning, execution, or interpretation of tests. The key issue is not automation by itself, but whether the environment provides enough context for the output to be accurate, prioritised, and operationally useful.
• Persistent Agent Influence: A security condition where data placed into an agent's memory, retrieval layer, or context can shape later decisions after the original interaction ends. It matters because the compromise survives beyond one prompt and can steer future actions in ways that normal output checks will miss.
• Delegated Privilege: Delegated privilege is access granted to a tool or system so it can perform actions without direct human intervention. The risk rises when delegation is broad, hidden, or hard to revoke, because the delegated actor can continue operating after trust has changed.
• Tool Output Trust Boundary: The point at which information returned by an external tool re-enters the agent’s reasoning context. If that boundary is not validated, the agent can confuse attacker-controlled content with trustworthy system input, making data retrieval a path to manipulation rather than just information gathering.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for teams that need to control delegated machine access. It gives security and IAM practitioners a common language for governing identities that act on behalf of people and systems.