Pentesting agentic systems needs a different security model

At a glance

What this is: This is an analysis of why agentic systems require a different pentesting model because their risk comes from chained actions, tool use, and persistent context, not just a web-facing prompt.

Why it matters: It matters to IAM, PAM, and NHI practitioners because agent permissions, inherited access, and delegated tool use can turn AI systems into over-privileged identities that conventional web testing will miss.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read terra's analysis of pentesting agentic systems

Context

Agentic systems change the security problem because the thing being tested is no longer just a prompt or a chat interface. In an agentic architecture, the model can call tools, consume data from multiple sources, chain decisions, and persist context. That creates an identity and access issue as much as an application security issue, because the agent often operates with delegated permissions and implicit trust boundaries that are not visible at the web layer.

This is why standard web application pentesting only covers part of the picture. The governance gap is in how teams test inherited privilege, tool permissions, memory persistence, and multi-step behaviour across the full runtime path. For IAM, PAM, and NHI teams, the core question is whether an agent is being treated like a user session, a workload identity, or a privileged automation path.

The article's starting position is typical of many organisations adopting AI quickly: the interface is visible, but the operational model behind it is not yet fully governed.

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 AI agents increase non-human identity risk in existing IAM programmes?

A: AI agents increase non-human identity risk because they create more autonomous actors that can hold credentials, access systems, and perform tasks without direct human supervision. Existing IAM programmes often focus on human users first, so agent lifecycle management, privilege review, and behavioural monitoring are frequently missing or incomplete.

Q: What breaks when agents are given a human user's permissions?

A: Privilege cloning inflates access because human workflows and machine workflows are not the same. An agent can chain actions faster than a person, use more tools, and cross system boundaries without the same judgement or pause points. Scoped delegation with explicit time, scope, and approval limits is the safer model.

Q: Who should own security for agentic systems?

A: Ownership should be shared, but not diffuse. IAM, PAM, application security, and AI governance all have a role, because the risk spans identity, tools, memory, and model behaviour. The accountable team should be the one that can enforce lifecycle controls, approve privilege, and retest changes when the agent's runtime or integrations change.

Technical breakdown

Why agentic systems expand the attack surface

An agentic system is not just a model responding to input. It is a runtime that can decide, sequence, and execute actions across tools, APIs, memory stores, and external content. That means the attack surface includes retrieval inputs, tool connectors, context windows, inter-agent messages, and any permissions inherited from the surrounding application or platform. Traditional pentests focus on a bounded request-response path. Agentic systems require testing for manipulation that occurs before, during, and after a model call, especially where business logic is encoded in tool use rather than in application code.

Practical implication: test the full action chain, not only the chat endpoint.

Identity and privilege abuse in AI agents

When an AI agent is allowed to act on behalf of a user or a system, its identity becomes operationally sensitive. If it inherits broad credentials, static tokens, or shared service account access, attackers can steer it into actions beyond intended scope. This is the same failure pattern seen in NHI governance, but with a runtime that reasons and adapts. The risk is amplified when the agent can choose tools dynamically, because privilege is no longer tied to a fixed workflow. Instead, access can become context-driven and therefore harder to bound with traditional controls.

Practical implication: map every agent action to a distinct identity and least-privilege boundary.

Memory poisoning and tool misuse in agentic workflows

Agentic systems can retain memory or retrieve contextual data over time, which creates a persistence layer for malicious influence. If an attacker can inject poisoned instructions, unsafe data, or manipulated tool outputs, the agent may reuse that input in later decisions. Tool misuse follows the same pattern: legitimate connectors, once reached through manipulated context, can be used to exfiltrate data or trigger unintended workflows. This is why agentic pentesting must look for multi-step abuse, not only direct prompt injection. The issue is not whether the model can answer safely once, but whether the system can resist repeated manipulation across a session or chain.

Practical implication: validate memory, retrieval, and tool boundaries as persistent attack paths.

Threat narrative

Attacker objective: The attacker wants to steer the agent into unsafe actions that expose data, misuse tools, or extend access beyond the intended scope.

1. Entry occurs when an attacker manipulates prompt input, retrieved content, or connected data sources that feed the agent's context.
2. Escalation happens when the agent uses inherited permissions or unsafe tool access to take actions beyond the intended workflow.
3. Impact follows when those actions expose data, trigger unintended system changes, or propagate compromise through chained agent behaviour.

NHI Mgmt Group analysis

Agentic pentesting is really identity testing in disguise: once an AI system can call tools and take actions, the core question becomes who or what is authorised to do what. The web layer may look like the entry point, but the actual control problem sits in delegated identity, inherited privilege, and runtime trust. That is why NHI governance must extend to AI agents as first-class identities, not just to conventional service accounts or API keys. Practitioners should evaluate every agent as a bounded identity with explicit lifecycle, scope, and revocation requirements.

Over-privileged agents create a control gap that traditional pentests do not surface: a single request can trigger many downstream actions, and each action may cross a different tool or system boundary. That makes blast radius the most important design variable, not just prompt safety. OWASP Agentic AI Top 10 and OWASP NHI Top 10 both point to the same problem space: when permissions are broader than the task, manipulation becomes an access issue. Practitioners should treat excessive agent privilege as a design flaw, not a tuning problem.

Continuous validation is becoming necessary because agentic attack paths change faster than scheduled testing can track: the article's central point is that new tools, new MCP-style connectors, and new data sources immediately change the risk profile. This creates governance debt when testing remains periodic and application-scoped. NIST AI Risk Management Framework and MITRE ATLAS both reinforce the need to measure, monitor, and reassess runtime behaviour as systems evolve. Practitioners should move from point-in-time assurance to continuous control validation.

Memory and tool chains create a new failure mode we can call context-to-action drift: malicious input does not have to succeed immediately if it can survive in memory, retrieval, or tool output until the agent later reuses it. That makes the trust boundary temporal as well as technical. The same pattern appears in NHI abuse when a credential or token remains valid long enough to be repurposed. Practitioners should focus on lifecycle controls that limit how long poisoned context or over-broad access can remain effective.

The category is converging on agent governance rather than model governance alone: once agents are making decisions across systems, the governance unit is the agent's identity, permissions, memory, and tools as a single control surface. That widens the scope for IAM, PAM, and AI governance teams, because the risk is distributed across disciplines. Organisations that keep treating agentic systems as just another feature will keep missing the real attack path. Practitioners should align testing, policy, and ownership around the agent as an operational identity.

What this signals

Agentic systems are forcing a shift from application testing to identity-aware runtime assurance. When an AI system can choose tools, persist context, and act across workflows, the meaningful control boundary is no longer the chat interface but the permissions, memory, and integrations that sit behind it. That is why NHI governance, PAM design, and AI risk management need to converge around a single runtime model, not separate review cycles.

Context-to-action drift: this is the failure mode that will trip up many early agent deployments. If malicious input can survive in memory or retrieval long enough to influence later actions, the attack does not need to succeed on the first turn. Practitioners should look for controls that limit persistence, constrain tool scope, and make runtime behaviour auditable against intended policy.

The market signal is clear: organisations will need continuous validation for agentic systems, not periodic assurance after go-live. That means security teams should expect more demand for testing that covers tools, connectors, and delegated identity together, with NIST AI Risk Management Framework language increasingly used to justify governance ownership and monitoring.

For practitioners

• Define a distinct identity for each agent Assign each agent a unique identity, explicit ownership, and a bounded permission set so that tool use, API access, and data retrieval can be traced and revoked independently. Avoid shared credentials for multiple agents or workflows, especially where the system can act across business-critical tools. Use least privilege as the default design rule.
• Test multi-step abuse paths, not only prompts Build pentest scenarios that start with manipulated retrieval content, poisoned memory, or unsafe tool outputs and then trace how the agent behaves across successive actions. Validate whether the system can be steered into data exposure, workflow abuse, or privilege escalation after the initial input is accepted.
• Bound agent tool access by task and session Scope connectors, APIs, and high-risk actions to the minimum task window possible, and separate read, write, and destructive operations wherever the platform allows it. Use step-up approval for actions that materially change state or access sensitive records, and make revocation immediate when a session ends.
• Instrument memory and retrieval for tamper evidence Log what content enters agent memory, what data is retrieved at runtime, and which outputs influence downstream decisions. That evidence lets you detect poisoned context, explain unexpected decisions, and compare intended behaviour with actual behaviour over time.
• Retest after every new connector or model change Treat every added tool, MCP server, data source, or model update as a new security event that can alter the agent's attack surface. Re-run targeted validation when the runtime changes, because the security posture of an agentic system can shift immediately after integration.

Key takeaways

• Agentic systems break the assumption that a web pentest can fully assess AI risk, because the real exposure lives in tool use, memory, and delegated action.
• The dominant governance issue is over-privileged AI identity, and the evidence shows most organisations are already granting AI systems more access than they would give people.
• Teams need continuous runtime validation, bounded permissions, and identity-aware testing if they want agentic systems to stay within intended scope.

Key terms

• Agentic Soc: An agentic SOC is a security operations model where AI systems assist with triage, investigation, and response using tool access and execution authority. The control challenge is not just accuracy, but governance of what the machine can see, decide, and do.
• Identity And Privilege Abuse: Identity and privilege abuse happens when delegated authority, cached credentials, or inherited access lets an agent act beyond the intent of the original owner. In agentic systems, the problem is often ambiguity in who owns the action and whether the granted authority still matches the task.
• Memory Poisoning (ASI06): An attack where malicious content is injected into an AI agent's memory or context, causing it to alter its behaviour in subsequent tasks — potentially exfiltrating secrets, escalating privileges, or acting against its intended purpose.
• Identity-To-Action Drift: The gap between an identity that appears legitimate and the actual actions performed under that identity. In agentic environments, drift can happen within a single session, which means authentication alone does not prove safe execution or bounded intent.

What's in the full article

Terra's full blog covers the operational detail this post intentionally leaves for the source:

• How Terra maps agentic system testing to OWASP ASI01 through ASI10 in practice
• Examples of near-real-time pentest signals for new tools, connectors, and data sources
• How continuous testing is operationalised across web apps, internal networks, and AI red teaming
• The article's own product framing for continuous validation workflows and demo flow

👉 The full Terra post covers the OWASP mapping, continuous testing model, and agentic attack surface examples.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical operational terms. It is designed for practitioners who need to align identity controls with modern runtime and automation risk.