Notifications
Clear all
Topic starter
02/08/2026 11:38 am
TL;DR: Agentic AI agents can call APIs, modify systems, and chain actions across tools, creating attack paths that traditional IAM, SIEM, and logging were not built to interpret, according to Panther. The real governance break is that human-paced review and static permission models assume the actor is reactive, not independently actioning tasks at runtime.
NHIMG editorial — based on content published by Panther: Agentic AI Security Risks: What Changes When AI Can Take Action
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.
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory agent identities and tool dependencies together Map every agent to the APIs, databases, SaaS apps, and MCP servers it can reach.
- Require human approval for high-impact actions Place approval gates on outbound external requests, production writes or deletes, and any credential or permission change.
- Shift to short-lived workload identity for agents Prefer short-lived certificates or workload identity federation over long-lived API keys.
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
👉 Read Panther's analysis of agentic AI security risks and detection controls →
Agentic AI security risks: are your IAM and logging controls ready?
Explore further
02/08/2026 12:51 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Agentic AI security risks are outpacing conventional IAM controls
