Agentic AI security frameworks expose the limits of legacy IAM

At a glance

What this is: This is a stepwise guide to agentic AI security frameworks, with the key finding that autonomous agents expand effective permissions and outgrow traditional application security and IAM models.

Why it matters: It matters because IAM, PAM, and governance teams now have to control identities that can select tools, chain actions, and change scope at runtime, not just humans and predictable service accounts.

By the numbers:

• 69% of enterprises already have AI agents deployed, while just 21% have a complete inventory of AI agents.
• Non-human identities already outnumber humans by a factor of approximately 50:1 in the average enterprise.
• 67% of organisations suffered incidents related to AI agents in Q2 2026.
• 80% of IT leaders report that agents are operating outside of normal behavior.

👉 Read Akto's guide to agentic AI security frameworks and runtime controls

Context

Agentic AI security frameworks matter because agentic AI changes the identity problem, not just the application layer. These systems can plan, call tools, remember prior context, and adjust their next steps without a human approval gate, which means effective permissions expand beyond what was intentionally provisioned.

For IAM and governance teams, the critical issue is that legacy models assume stable subjects and predictable authorisation boundaries. Once an agent can chain tools, inherit credentials, and pass tasks to other agents, the control surface becomes runtime behaviour rather than static entitlement.

That is why agentic AI security now sits at the intersection of NHI governance, application security, and zero trust. The article’s starting point is typical for organisations that have adopted agents faster than they have built inventory, policy enforcement, and runtime oversight.

Key questions

Q: How should security teams implement zero trust for workloads and AI agents?

A: Start by giving each workload or agent a verifiable runtime identity, then enforce request-level policy and issue short-lived credentials only after the identity and context checks pass. The practical goal is to remove standing secrets and make access decisions at the point of use, not at deployment time.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: What do security teams get wrong about agent inventory and ownership?

A: They often assume that once an agent is found, a single inventory record is enough. In practice, you also need behavioural classification, accountable ownership, and lifecycle tracking, because different agent types create different access and secrecy risks across the environment.

Q: How do security teams know runtime AI guardrails are actually working?

A: Look for blocked poisoned inputs, flagged anomalous outputs, and traceable enforcement before responses reach users or downstream systems. If controls only inspect prompts or only inspect outputs, they leave a gap that attackers can exploit through manipulated data sources or tool responses.

Technical breakdown

Agentic AI security frameworks and runtime identity boundaries

Agentic AI security frameworks exist because autonomous agents do not behave like conventional applications. A chatbot answers; an agent can choose tools, retain memory, and replan after each result. That loop creates a moving permissions boundary, because every connected API, data source, and downstream agent becomes part of the agent’s effective access. Static pre-deployment scanning misses this runtime expansion, and traditional IAM often stops at the account level instead of the task and session level.

Practical implication: define controls around task-scoped identity, not just application deployment reviews.

Why zero trust for AI agents changes least privilege

Zero trust for AI agents means continuously verifying both the agent’s identity and the action it is trying to take. The article highlights the core break from legacy service-account practice: agents should not operate through standing API keys with broad, persistent permissions. Instead, privilege needs to be short-lived, limited in scope, and tied to the task the agent is actually executing. That shifts security from provisioning-time trust to runtime validation.

Practical implication: treat standing permissions for agents as a design failure, not an operational convenience.

Agent discovery, posture management, and runtime protection

The article’s stepwise model follows a logical control sequence: discover the agents, baseline their access and configuration, test them against prompt injection and tool poisoning, then monitor live behaviour for unexpected calls. This is a security operations pattern, not a model training problem. It also reflects the reality that agents can be deployed in shadow form, including embedded tools and MCP-connected services, which makes inventory and policy drift central governance issues.

Practical implication: build continuous discovery and runtime detection before attempting broad agent rollout.

Threat narrative

Attacker objective: The attacker wants to hijack agent behaviour to reach sensitive systems, steal data, or execute actions that the operator never explicitly authorised.

1. Entry occurs through shadow agents, exposed tool connections, or unreviewed prompts that influence an agent’s next action path.
2. Escalation happens when the agent inherits credentials or broad permissions and chains tools beyond the original task scope.
3. Impact follows when the agent accesses sensitive data, executes unintended actions, or propagates trust across downstream systems and other agents.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic AI exposes an assumption collapse, not just a control gap. Traditional IAM assumes a subject’s authorisation is stable long enough to be provisioned, reviewed, and certified. That assumption fails when an agent can alter its action sequence, select tools dynamically, and chain decisions at runtime. The implication is that governance must stop treating agent access as a static entitlement problem and start treating it as a time-bound behavioural problem.

Least privilege becomes task-relative instead of account-relative once agents can replan. A service account model assumes the actor will keep doing roughly what it was assigned to do. An autonomous agent can change its next step based on tool output, which means the effective permission set can grow or shrink mid-session. Identity blast radius: the real control target is no longer the identity record alone, but the maximum harm reachable through one agent session.

Shadow agents are the NHI equivalent of shadow IT, but with faster blast-radius growth. The article’s inventory problem matters because what security teams cannot see, they cannot govern. In agentic environments, embedded assistants, low-code agents, and MCP-connected tools can appear without central approval, creating a hidden identity estate that inherits production reach. Practitioners should read this as a discovery and offboarding failure waiting to happen.

Runtime protection is the control point where agentic AI stops being theoretical. The article is right that pre-deployment testing alone is insufficient when the system can change behaviour after release. The useful governance lesson is that agentic risk is measured at execution time, not design time. Security teams should therefore align their controls to runtime observation, because that is where unexpected tool use, data access, and delegation actually surface.

From our research:

• Non-human identities already outnumber humans by a factor of approximately 50:1 in the average enterprise, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows why discovery and inventory remain unfinished business.
• That same governance gap is why the Ultimate Guide to NHIs remains a useful baseline for organisations preparing to extend identity control to autonomous systems.

What this signals

Identity blast radius: the next governance fight is not about whether agents exist, but about how far they can move before a control notices. With 50:1 non-human identities to humans already shaping the enterprise baseline, agent sprawl will expose any gap between inventory and enforcement.

Security teams should expect agentic AI programmes to force a tighter connection between identity governance and runtime telemetry. That means discovery, policy enforcement, and detection have to be reviewed as one continuous control plane, not separate projects with separate owners.

The practical signal to watch is whether access is still being managed at the account level while actions are happening at the task level. If that mismatch persists, the programme is already behind the behaviour it is trying to govern.

For practitioners

• Inventory every agent and MCP-connected workflow Build a complete register of in-house agents, embedded assistants, and external connectors, then reconcile it against production data sources and APIs. Treat anything that can act on behalf of a system as an identity subject, even if no one formally approved it.
• Replace standing agent permissions with task-scoped access Remove persistent API keys and broad shared accounts where an agent can reach tools or data directly. Tie authorisation to the smallest executable task, then expire it as soon as the task is complete.
• Test multi-step behaviour, not single prompts Run red-team scenarios that simulate prompt injection, tool poisoning, and chained actions across several steps. Validate what happens when the agent changes plan after receiving tool output, because that is where real control failures appear.
• Add runtime containment for unexpected tool use Monitor live agent actions for data access outside the approved baseline, then automate containment when the agent begins calling unapproved tools or systems. Incident response must be fast enough to stop chained execution before it completes.
• Map agent governance to zero trust and AI risk frameworks Align policy and evidence collection to zero trust principles and the NIST AI Risk Management Framework, then connect those controls to audit, exception handling, and ownership records.

Key takeaways

• Agentic AI changes identity governance because runtime decisions expand effective permissions beyond the original account design.
• Inventory and visibility remain the weakest controls, with shadow agents and embedded connectors creating unmanaged access paths.
• The control model has to move from static provisioning to continuous discovery, task-scoped authorisation, and runtime containment.

Key terms

• Agentic AI Security: Agentic AI security is the discipline of securing autonomous AI systems that can take actions, use tools, and chain decisions without direct human approval at each step. It covers identity and access management for AI agents, prompt injection defence, tool call governance, credential scoping, and runtime monitoring. As agentic systems acquire real-world authority — API access, file writes, workflow triggers — the security model must treat them as non-human identities with explicit lifecycle controls, not trusted processes.
• Shadow Agent: An AI agent deployed without formal registration, identity governance, or security oversight — the agentic equivalent of shadow IT. Shadow agents are more dangerous than typical shadow NHIs because they actively take actions using their credentials.
• Runtime Protection: Runtime protection is a control model that observes application behavior while software is running and blocks unsafe actions as they occur. In Java estates, it helps distinguish active exploit paths from dormant vulnerable code, which is essential when patching is delayed or impossible.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

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

• The full step-by-step framework for discovery, posture management, red teaming, runtime protection, and incident response.
• Specific examples of prompt injection, tool poisoning, shadow agents, and agent spoofing in multi-step workflows.
• The article’s compliance crosswalks to NIST AI RMF, ISO 42001, SOC 2, and the EU AI Act.
• Operational notes on using automated guardrails and runtime containment across 80+ connectors and 1,000+ probes.

👉 Akto's full post covers the attack patterns, implementation steps, and framework crosswalks in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.