Agentic AI security risks are outpacing conventional IAM controls

At a glance

What this is: This analysis explains why agentic AI changes the security model when systems can take actions, persist memory, and chain tool use across environments.

Why it matters: It matters because IAM, PAM, logging, and detection programmes must govern both the agent identity and its runtime behaviour, not just the underlying model or human operator.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Panther's analysis of agentic AI security risks and detection controls

Context

Agentic AI security refers to the identity and control problem that appears when software can choose actions, call tools, and complete tasks without a human approving each step. The issue is not model quality alone. It is that the actor now behaves like a runtime decision-maker, which breaks assumptions embedded in IAM, SIEM, and access review processes.

Panther's analysis frames the problem as an identity governance gap, not a chatbot issue. Once an agent can read logs, call APIs, modify configurations, and escalate tickets, the relevant questions become who can change the agent, what it can reach during execution, and how its actions are logged across systems.

That is why this topic sits at the intersection of NHI governance and emerging agentic AI controls. The article's starting point is typical of modern deployments: an agent is given useful access quickly, then its scope grows faster than the organisation's ability to observe, certify, or contain it.

Key questions

Q: How should security teams govern agentic AI that can execute IAM tasks?

A: Start by treating the agent as an NHI with bounded authority, explicit ownership, and revocation procedures. Require human approval for high-risk actions, log every decision path, and enforce least privilege at the workflow level. If the agent cannot be audited or rolled back, it is not yet ready for autonomous IAM execution.

Q: Why do AI agents complicate traditional IAM and PAM controls?

A: AI agents complicate IAM and PAM because they can make decisions, chain tools, and act faster than human review cycles can respond. They also blur the line between authentication and authorization, since the same identity may trigger multiple actions after a single approval. That means organizations need policy, telemetry, and revocation designed for autonomous behavior, not just human login events.

Q: What do organisations get wrong about logging AI agent activity?

A: Many teams log that an agent ran, but not enough to explain what authority it used or which user initiated it. Useful logs must include the initiating user, the agent identity, the target resource, the action, and the outcome. Without that context, audit trails cannot support investigations, compliance, or accountability.

Q: How can organisations reduce blast radius when an AI tool is compromised?

A: Limit the tool's scope, separate high-risk functions from general collaboration data, and make revocation fast enough to matter. Pair least privilege with short-lived tokens, clear ownership, and logging that links the agent, the user, and the downstream system. Containment only works when those paths are visible.

Technical breakdown

Why agentic AI behaves differently from generative AI

Generative AI produces output. Agentic AI can produce actions. That shift matters because a prompt injection against a chatbot may result in a bad answer, while the same attack against an agent can trigger writes, API calls, or external requests in connected systems. Agentic systems also retain working memory, long-term memory, and persistent credentials across sessions, which makes compromise durable rather than transient. When agents chain subtasks, spawn sub-agents, and adapt at runtime, the security boundary moves from model output to executed behaviour across multiple systems.

Practical implication: monitor actions, memory, and tool use as first-class security events, not just prompts and responses.

MCP servers, tools, and agent identity as attack surfaces

Model Context Protocol servers connect agents to tools and data sources, so they become trust boundaries in their own right. Tool descriptions, inter-agent messages, and retrieved content can all carry instructions that the agent may treat as legitimate context. That creates room for tool poisoning, indirect prompt injection, and message spoofing. At the same time, agents authenticate with API keys, service accounts, or OAuth tokens, which means every new agent adds another identity and another permission scope to govern. The result is an identity sprawl problem wrapped inside an orchestration problem.

Practical implication: inventory agent identities and their tool endpoints together, because separating them hides the true blast radius.

Why SIEM and IAM controls miss agent abuse

Traditional IAM assumes a human or fixed workload with predictable access patterns. Agents are different because their access needs emerge at runtime and can shift across systems inside one task. SIEM detection also struggles here, because authorised activity is not the same as authorised intent. An agent can perform fully logged, technically approved actions while still exceeding the purpose for which it was given access. Without a causal trail that links inputs, tool calls, and decision steps, investigators can see what happened but not why the agent did it.

Practical implication: add decision-chain logging and intent-aware detections to your SOC workflow.

Threat narrative

Attacker objective: The attacker wants to turn legitimate agent autonomy into a high-speed path for data exposure, system modification, and credential abuse without triggering traditional control boundaries.

1. Entry occurs when the actor gains or abuses a legitimate agent identity, API key, or connected tool path rather than breaking in through a traditional malware foothold.
2. Escalation follows when the agent is given excessive permissions, persistent memory, or trust in unvetted tool outputs, allowing a small compromise or injection to spread across systems.
3. Impact occurs when the agent performs real-world writes, credential exposure, or configuration changes at machine speed, leaving authorised logs but an unauthorised outcome.

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 creates an identity governance problem before it creates a model risk problem. The core issue is not the sophistication of the model, but the fact that the actor can decide, sequence, and execute actions across systems. That means governance has to track runtime behaviour, not just the identity that launched the session. The practitioner conclusion is simple: treat the agent as a governed identity with a measurable blast radius.

Persistent agent memory is a trust multiplier, not just a convenience feature. Once memory survives across sessions, a single poisoned instruction can persist long after the original interaction ends. That turns context into durable attack surface and makes the reasoning chain part of the security boundary. The implication is that organisations must stop assuming that session boundaries reset risk.

Scoped permissions are necessary but not sufficient when actions are agent-timed. IAM and PAM frameworks assume a largely human-paced approval loop, yet agents can acquire context, select tools, and complete work in one uninterrupted flow. That is a broken premise for access reviews, recertification, and escalation controls. The practitioner conclusion is that control ownership must shift from static entitlement review to runtime governance of autonomous execution.

Identity blast radius is the right named concept for this category. Every additional tool, credential, or connected system expands the amount of damage a single agent action can trigger. The problem is not only privilege level, but the number of systems the agent can reach before a human can intervene. The implication for security programmes is to measure how far one agent decision can propagate, then design containment around that radius.

Traditional detection breaks because it watches actions, not agent intent. SIEM can confirm that a call was authorised, but it cannot tell whether the action aligned with the agent's authorised purpose. That gap matters most when a malicious instruction is embedded inside trusted content and only becomes visible in the downstream behaviour. The practitioner conclusion is that intent-aware logging and anomaly logic are now part of identity control, not just SOC enrichment.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That gap makes OWASP Agentic AI Top 10 a useful next lens for mapping tool abuse, prompt injection, and agent identity risk.

What this signals

Identity blast radius: the unit of control for agentic AI is no longer the user or the model, but the chain of systems an agent can touch before a human can intervene. With 92% of organisations agreeing that governing AI agents is critical but only 44% having implemented policies, according to AI Agents: The New Attack Surface report, the governance gap is already operational.

Agent logging needs to move from telemetry collection to decision reconstruction. If you cannot correlate inputs, tool calls, and outputs into a single causal trail, you will not be able to explain agent behaviour to auditors, legal teams, or incident responders.

The practical signal for security leaders is that agent governance will increasingly sit beside identity lifecycle management, not beside application monitoring. Programmes that already use the OWASP Agentic AI Top 10 as a threat lens should now map those risks to access scope, approval flow, and containment design.

For practitioners

• Inventory agent identities and tool dependencies together Map every agent to the APIs, databases, SaaS apps, and MCP servers it can reach. Keep access to the agent and access by the agent in the same inventory so blast radius is visible during reviews.
• Require human approval for high-impact actions Place approval gates on outbound external requests, production writes or deletes, and any credential or permission change. Use these as default checkpoints until you have evidence that the agent can operate safely within scope.
• Shift to short-lived workload identity for agents Prefer short-lived certificates or workload identity federation over long-lived API keys. This limits the value of a stolen secret and makes agent access easier to revoke when scope changes.
• Log the decision chain, not just the tool call Capture inputs, tool outputs, session identifiers, and the sequence of decisions that led to each action. Without that trail, you will know what the agent did but not why it did it.
• Write detections for agent abuse patterns Add rules for anomalous tool sequences, first-time tool usage, recursive loops, and rapid movement from data reads to external posts. These patterns are more useful than generic anomaly logic for spotting agent misuse.

Key takeaways

• Agentic AI creates a governance problem because the actor can take actions, not just generate outputs.
• The most useful control lens is runtime identity and blast radius, not model accuracy or prompt hygiene.
• Security teams need scoped identities, decision-chain logging, and human approval for high-impact actions before agent sprawl becomes control loss.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• 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.
• Decision-Chain Logging: A logging approach that captures inputs, tool outputs, and the sequence of decisions behind an action. For autonomous or semi-autonomous systems, it is the difference between seeing an authorised call and understanding whether that call matched the actor's intended purpose.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.

What's in the full article

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

• Step-by-step detection logic for agent-specific abuse patterns in Panther SIEM workflows
• Implementation guidance for tool-level human-in-the-loop approval on high-impact actions
• Examples of centralized logging fields such as session_id, tool_call, and token usage
• Detection-as-code and ingestion patterns for cross-cloud agent telemetry

👉 Panther's full post covers the attack surface, logging gaps, and practical detection patterns in more detail.

Deepen your knowledge

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