TL;DR: As organisations move from generative AI to agentic AI, the security problem shifts from prompt safety to governing agents that call tools, assume identities, and act across APIs, according to Akto. The operating model now depends on inventory, risk assessment, guardrails, and response because static IAM assumptions break when software can act independently.
At a glance
What this is: This is an Akto CISO strategy post arguing that agentic AI security in 2026 depends on visibility, risk assessment, guardrails, and response, with the central finding that traditional security models do not see enough of agent behaviour.
Why it matters: It matters because IAM, PAM, and governance teams now have to account for software actors that impersonate identities, invoke tools, and cross compliance boundaries faster than human review cycles can keep up.
By the numbers:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
- 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%).
👉 Read Akto's CISO strategy for agentic AI security in 2026
Context
Agentic AI security is the problem of governing software that can decide, call tools, and act on its own authority rather than only responding to prompts. This post argues that CISOs need an identity-led operating model because once an agent can assume service accounts, tokens, or API access, the security question becomes who or what is acting, under which identity, and with what blast radius.
Akto frames the shift as a move from visibility to control, starting with an agent, tool, and identity inventory and extending into red teaming, guardrails, and response. For IAM, IGA, PAM, and cloud security teams, that means agent identity has to be treated as a governed actor class, not as a side effect of automation.
The article’s starting position is typical of the current market: most organisations can describe AI ambition more easily than they can describe the identities, permissions, and tool paths their agents already use.
Key questions
Q: How should security teams govern AI agents that can choose tools at runtime?
A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.
Q: Why do AI agents create new risk in non-human identity management?
A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.
Q: What breaks when organisations only inventory AI agents without watching their actions?
A: Inventory alone creates a false sense of control because it records existence, not behaviour. A known agent can still abuse authorised access, move sensitive data, or trigger unexpected third-party actions if no one is watching what it does at runtime. Visibility into action is the missing layer.
Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?
A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.
Technical breakdown
Agentic asset graphs and identity inventory
An agentic asset graph is a living map of every agent, the tools it can call, the identities it assumes, and the data domains it can reach. The technical problem is not just discovery, but relationship mapping across APIs, service accounts, tokens, and environments. Without that graph, defenders cannot answer basic questions about privilege, ownership, or blast radius. In agentic systems, the identity layer is dynamic because the same agent may reuse multiple credentials or tool paths over time. Security visibility therefore has to bind runtime behaviour to an accountable identity object.
Practical implication: inventory agents, their assumed identities, and tool scopes before expanding use cases beyond low-risk sandboxes.
Continuous red teaming for prompt injection and tool chaining
Agentic risk is best exposed through active testing because static checklists miss runtime behaviour. Prompt injection, tool chaining, context poisoning, and over-permissioned actions test whether the agent can be induced to move laterally, expose memory, or escalate from advice to impact. The important mechanism is that the attack surface sits in the reasoning-to-action path, not only in the model output. Continuous reassessment matters because the tool graph, data exposure, and agent autonomy can change as workflows evolve.
Practical implication: build repeatable red-team scenarios that validate how agents behave when inputs, tools, and context are manipulated.
Runtime guardrails for MCP and sensitive operations
Guardrails turn policy into enforcement by constraining which tools are approved, which operations require human validation, and which data the agent may touch. For agentic AI, the Model Context Protocol widens the importance of runtime control because the agent’s reach is mediated through tool connections and context. Logging every decision and tool call creates the audit trail needed for incident response and compliance. The objective is not to trust the model less, but to limit the damage when reasoning goes wrong or input is malicious.
Practical implication: enforce tool allowlists, step-up validation for high-risk actions, and full decision logging at the runtime layer.
Threat narrative
Attacker objective: The attacker wants to convert a trusted agentic workflow into a high-privilege execution path that can exfiltrate data or change systems at scale.
- Entry occurs when a malicious prompt, poisoned context, or compromised tool connection reaches an agent through a permitted interface.
- Escalation follows when the agent chains tools or uses inherited credentials to touch systems and data beyond the intended task boundary.
- Impact is realised when the agent leaks sensitive data, changes production state, or amplifies a compromised instruction into wider enterprise action.
Breaches seen in the wild
- Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
- CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agent identity is becoming a governed actor class, not an automation detail. The article correctly treats agents, tools, and assumed identities as one security problem because the privilege boundary lives at runtime, not at deployment. That matters for IAM and PAM teams because the control surface now includes software entities that can use human-grade access paths without human pacing. Practitioners should stop treating agent identity as an edge case and govern it as a first-class subject.
Runtime visibility is the new prerequisite for agentic accountability. The article’s inventory-first framing is the right starting point because you cannot assign ownership, review privilege, or explain behaviour if the agent-to-tool-to-identity chain is undocumented. The named concept here is agentic asset graph: the live relationship map that binds agents to tools, credentials, data, and environment. Without that graph, blast radius is unknowable and incident response becomes forensic guesswork. Practitioners should treat visibility as the control that makes every other control possible.
Continuous red teaming is the only practical way to test agent trust boundaries. Static policy review does not expose prompt injection, context poisoning, or tool-chaining behaviour because those failures emerge only when the agent is executing. That aligns with OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, which both assume adversarial testing and operational measurement. Practitioners should regard agent red teaming as a governance function, not a lab exercise.
Guardrails matter most where agent decisions can alter state or move data across trust zones. The post is right to prioritise sensitive operations such as payments, configuration changes, and production API access because those are the points where agent error becomes enterprise impact. The governance question is no longer whether AI is useful, but which actions can occur without review and which cannot. Practitioners should define those thresholds before scaling agent deployment.
Autonomous behaviour collapses the assumption that access is stable long enough to review. Access review processes were designed for identities whose privileges persist between review cycles. That assumption fails when an agent can acquire tools, execute, and complete a task within one session, leaving little durable state to certify. The implication is that identity governance for autonomous systems must be redesigned around runtime conditions, not periodic attestation.
From our research:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- 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, according to AI Agents: The New Attack Surface report.
- For a broader control lens, the OWASP Agentic AI Top 10 maps the agentic attack surface that runtime guardrails need to contain.
What this signals
Agentic asset graph: enterprises will need a living inventory of agents, tools, identities, and data domains before they can claim meaningful control over agent behaviour. As the AI Agents: The New Attack Surface report shows, 80% of organisations have already seen agents act beyond intended scope, which means discovery and governance have to move together.
The next programme risk is not simply more AI, but more unowned AI. Teams that cannot tie an agent to an accountable owner, a bounded tool set, and a reviewable approval path will struggle with both incident response and audit evidence, especially where production APIs or financial workflows are involved.
CISOs should align agent governance with NIST AI Risk Management Framework and the OWASP Agentic AI Top 10, then decide which workflows are permitted to act without human review and which are not.
For practitioners
- Build an agentic asset graph Map every AI agent, the identities it assumes, the tools it can invoke, and the data domains it can reach. Make ownership explicit for each agent so IAM, AppSec, and platform teams can answer who is accountable when behaviour changes.
- Red-team agent decision paths Test for prompt injection, context poisoning, tool chaining, and unexpected data exposure in workflows that can reach production systems or financial APIs. Re-run the tests whenever tools, permissions, or context sources change.
- Enforce runtime guardrails on sensitive actions Require human validation for payment approvals, configuration changes, and other state-changing operations, and keep approved tool catalogues narrow. Use decision logging so incident responders can reconstruct what the agent saw and did.
- Separate high-risk agents from low-risk experiments Start with the agents that touch customer data, production APIs, or financial systems, then expand only after controls are stable. Sequencing matters more than coverage breadth when governance maturity is still forming.
Key takeaways
- Agentic AI changes identity security because software can now assume identities, call tools, and take actions without human pacing.
- The evidence is already showing policy lag, with most organisations recognising the need for governance but far fewer having implemented it.
- CISOs should start with inventory, runtime guardrails, and continuous testing, then expand governance only after the highest-risk agent workflows are under control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AGENT-01 | The post centres on agent inventory, tool control, and runtime abuse. |
| NIST AI RMF | MANAGE | Continuous assessment and guardrails align with AI risk management. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and identity governance are central to the article. |
| NIST Zero Trust (SP 800-207) | Runtime verification and bounded access fit zero-trust principles. | |
| NIST SP 800-53 Rev 5 | IA-5 | Agent credentials and tokens require managed authenticator controls. |
Adopt zero-trust controls that verify every agent action and limit implicit trust.
Key terms
- Agentic Asset Graph: A living inventory that connects each AI agent to the tools, identities, data sources, and environments it can reach. It turns an opaque agent estate into something security teams can govern, review, and audit. For autonomous systems, the graph must capture runtime relationships, not just deployment metadata.
- Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
- Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
- Tool chaining: Tool chaining is the practice of using one capability to unlock the next, such as searching for a secret, authenticating with it, and then using that access to reach another system. For AI agents, tool chaining is the mechanism that turns broad permissions into compound risk.
What's in the full article
Akto's full blog post covers the operational detail this post intentionally leaves for the source:
- The article’s step-by-step framing for building an agent, tool, and identity inventory across a live environment.
- The specific guardrail patterns the vendor recommends for sensitive actions such as payments and configuration changes.
- The vendor’s practical examples of what to monitor, block, and log during agentic incidents.
- The survey prompt and benchmark callout tied to the vendor’s broader AI agent security programme.
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 identity security capability across human, machine, and AI-driven programmes, it is worth exploring.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org