Notifications
Clear all
Topic starter
02/08/2026 11:45 am
TL;DR: Agentic systems expand the attack surface beyond a single chat interface because agents can chain actions, use tools, persist context, and inherit permissions across multiple steps, according to Terra. The security problem is no longer just input testing, but validating how action-taking systems behave over time and where identity, privilege, and tool trust break down.
NHIMG editorial — based on content published by terra: Everything You Need To Know About Pentest of Agentic Systems
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read terra's analysis of pentesting agentic systems →
Agentic system pentesting: are your controls keeping up?
Explore further
02/08/2026 12:56 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Pentesting agentic systems needs a different security model
