TL;DR: By 2026, AI systems are embedded in business processes and can act across tools, data sources, and workflows, creating risks such as prompt injection, shadow AI, and unauthorized tool use, according to Akto. Traditional security assumes predictable software; agentic behaviour breaks that assumption and demands lifecycle governance.
At a glance
What this is: This is an analysis of why AI security platforms are becoming the control layer for agentic AI, LLMs, MCP servers, and related workflows, with the key finding that conventional security is not built for probabilistic, tool-using systems.
Why it matters: It matters because IAM, IGA, PAM, and security architecture teams now have to govern AI systems that can access data, invoke tools, and create audit and compliance exposure without fitting human-centric control models.
By the numbers:
- 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%).
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
👉 Read Akto's analysis of AI security platforms for agentic AI and LLMs in 2026
Context
AI security platforms are emerging because existing application and cloud security models were built for deterministic systems. Agentic AI, by contrast, can reason over context, choose tools, and interact with data sources in ways that are not fully predictable at design time, which creates a governance problem for AI security platforms and the IAM teams expected to supervise them.
The article frames this shift around lifecycle control, from discovery and inventory to runtime protection and incident response. That matters for NHI, agentic AI, and human identity programmes because once an AI system can access APIs, databases, or internal workflows, the question is no longer just whether it is authenticated, but whether its access, actions, and delegation paths are continuously governed.
Akto positions AI security platforms as the control plane for this new environment, but the deeper issue is category-wide. Security teams now need visibility into shadow AI, policy enforcement at runtime, and evidence trails that tie AI behaviour back to owners and approved use cases.
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 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 breaks when security teams rely on prompt filtering alone?
A: Prompt filtering breaks when the user can paste data through another route before inspection happens. Browser copy-paste, IDE extensions, API calls, and phone-tethered sessions often bypass content-only controls. That leaves organisations with partial enforcement and weak auditability, especially when the tool path is invisible to the security stack.
Q: Who is accountable when an AI agent accesses the wrong data?
A: Accountability sits with the team that defined the agent’s scope, the owner of the delegated user context, and the operators who allowed access to persist beyond the task. For customer workflows, audit logs should show both the agent and the user identity so responsibility can be traced clearly.
Technical breakdown
Agentic AI discovery and shadow AI visibility
Discovery is the first technical requirement because security teams cannot govern what they cannot enumerate. In this context, discovery means mapping approved and unapproved AI tools, models, MCP servers, browser-based assistants, IDE copilots, and local agents, then linking each to data access and tool calls. Shadow AI is especially difficult because it appears through employee endpoints and browser activity rather than centralized deployments. For IAM and security teams, the main technical problem is incomplete identity inventory: the system that can act is often not the system that was formally onboarded.
Practical implication: build an inventory that ties each AI system to an owner, data scope, and tool permissions before attempting policy enforcement.
Runtime guardrails for prompt injection and tool abuse
Runtime protection is the point where AI security differs most from static AppSec. Prompt injection occurs when attacker-controlled content changes the model’s behaviour, while tool abuse happens when the agent uses legitimate integrations to perform unintended actions. Because agentic systems can combine instructions, context, and tool access in a single session, controls must inspect both input and output and then enforce policy at the action layer. That makes guardrails, blocking, and sanitization operational controls rather than advisory ones.
Practical implication: enforce policy at the point of tool invocation, not only at model input and output boundaries.
AI-SPM and governance mapping across the lifecycle
AI security posture management extends traditional configuration review into the AI lifecycle. It covers misconfigurations such as overprivileged API keys, unsafe data storage in vector databases, weak access control on model endpoints, and gaps in audit trails. The article also links governance to standards such as the EU AI Act, NIST AI RMF, and ISO/IEC 42001, which reflects where the market is heading: evidence-based control, not just detection. For practitioners, the technical challenge is to convert those lifecycle signals into repeatable compliance and risk decisions.
Practical implication: align AI posture checks with formal governance mappings so that technical findings feed audit, risk, and policy workflows.
Threat narrative
Attacker objective: The attacker aims to convert trusted AI access into unauthorized data exposure, tool execution, or workflow manipulation without needing to compromise the underlying model directly.
- Entry occurs when an attacker manipulates prompts directly or indirectly through a web page, email, document, or other external source that the agent consumes.
- Escalation follows when the agent uses legitimate tool access to query systems, retrieve data, or invoke actions beyond the intended task boundary.
- Impact occurs when the agent leaks sensitive data, executes unauthorized actions, or enters runaway loops that consume resources or amplify downstream harm.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI security platforms are becoming the governance layer for agentic behaviour, not just a detection layer for model risk. The article is directionally right to treat discovery, runtime controls, and lifecycle governance as one stack because agentic AI crosses boundaries that traditional AppSec, cloud security, and IAM often handle separately. The key shift is that the subject of control is no longer only a model or an endpoint, but an acting identity with tool reach and data exposure. Practitioners should treat this as an identity governance problem with AI-specific mechanics.
Shadow AI is a visibility failure before it becomes an access failure. Unapproved assistants, embedded copilots, and unmanaged MCP-connected tools create blind spots that security teams cannot recertify, policy-check, or investigate later. That is why discovery and ownership mapping matter as much as runtime blocking. The governance lesson is simple: if the system cannot be enumerated, it cannot be trusted.
Prompt injection is really a boundary-collapse problem. The article shows that attacker-controlled text can become action when an agent interprets it inside the same session that holds credentials and tool permissions. That is the named concept to watch: context-to-action collapse. When context can change execution, security teams must rethink the assumption that prompt text is harmless until a human approves it.
AI-SPM will increasingly sit alongside IGA and PAM decisions. Overprivileged API keys, insecure vector stores, and poor auditability are not separate AI problems. They are the same privilege and lifecycle problems that identity teams already manage, but now applied to systems that can act continuously and at machine speed. The practical implication is that AI security programmes will fail if they stay isolated from identity governance.
From our research:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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, according to AI Agents: The New Attack Surface report.
- For a deeper defensive lens, see OWASP Agentic Applications Top 10 and compare it with the runtime control issues discussed here.
What this signals
Context-to-action collapse: once AI systems can read untrusted content and act on it in the same session, the old separation between data and execution stops being reliable. That pushes security teams toward runtime enforcement, stronger ownership, and identity-based policy rather than relying on content filters alone.
With 52% of companies able to track and audit the data their AI agents access, the other 48% face a governance and investigation problem before they face a technical one, according to AI Agents: The New Attack Surface report. That gap will matter more as AI systems become embedded in workflows and compliance evidence becomes harder to reconstruct.
The next programme decision is whether AI security stays a niche control stack or becomes part of identity governance, PAM, and cloud posture management. Teams that separate those disciplines will keep rediscovering the same overprivilege, audit, and ownership failures in different tools.
For practitioners
- Map every AI system to an accountable owner Create a live inventory of approved models, agents, copilots, and MCP servers, then tie each to an owner, purpose, and data scope. Include browser-based and endpoint-discovered shadow AI so unapproved systems do not sit outside governance.
- Enforce tool-level policy checks at runtime Move controls to the point where an agent invokes a tool, accesses a database, or calls an API. Input filtering alone will not stop unauthorized action once the system has legitimate runtime credentials.
- Integrate AI posture findings into IAM and compliance workflows Treat overprivileged API keys, exposed data stores, and weak audit trails as identity issues that belong in certification, remediation, and evidence collection processes. Connect posture findings to access reviews rather than keeping them in a separate AI security queue.
- Test for prompt injection and indirect attack paths continuously Add red-team scenarios that include malicious content in emails, documents, web pages, and other data sources the agent reads. Validate whether the system can be coerced into data exfiltration, tool misuse, or runaway action chains.
- Adopt policy mappings that support audit-ready evidence Align AI governance checks with frameworks such as the EU AI Act, NIST AI RMF, and ISO/IEC 42001, then retain immutable logs of agent actions, policy violations, and remediation steps.
Key takeaways
- AI security platforms are now being asked to govern AI behaviour across discovery, runtime, and compliance, not just detect model threats.
- The evidence points to a widening control gap: most organisations plan more AI deployment even as many still cannot fully audit what their agents access.
- Practitioners should treat agent ownership, runtime tool enforcement, and audit-ready lifecycle controls as one identity problem, not three separate initiatives.
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 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Prompt injection and tool abuse are central risks in this article. |
| MITRE ATLAS | The article discusses adversarial prompt attacks and agent manipulation patterns. | |
| NIST AI RMF | GOVERN | The article emphasizes governance, ownership, and auditability for AI systems. |
| NIST Zero Trust (SP 800-207) | Section 3.1 | Runtime verification and least-privilege access align with zero trust principles. |
| NIST CSF 2.0 | PR.AC-4 | Agent permissions and access scope are core to the article's governance model. |
Assign governance ownership for AI systems and tie policy, audit, and accountability to named controls.
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 AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
- 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.
- AI-SPM: AI Security Posture Management extends security visibility into AI models, prompts, outputs, and supporting workflows. It gives teams a way to identify risky AI usage, check policy alignment, and monitor how AI systems interact with data and identity controls over time.
What's in the full article
Akto's full blog post covers the operational detail this post intentionally leaves for the source:
- Implementation guidance for runtime protection across AI agents, MCP servers, and LLM applications.
- Examples of continuous AI red teaming, prompt-injection testing, and incident-response logging in production environments.
- A closer look at platform functions such as AI-SPM, shadow AI discovery, and policy enforcement across the AI lifecycle.
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 identity security practice, 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