AI security solutions for LLMs and agents need runtime governance

At a glance

What this is: This is an analysis of AI security solutions for LLMs, AI agents, and enterprise AI, with the key finding that runtime protection and governance now matter as much as model hardening.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agent tool access, secret exposure, and auditability in the same control plane as human and workload identities.

By the numbers:

• 48% of the firms' cybersecurity professionals have considered Agentic AI the top threat to security.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• While 71% of IT teams have been advised on AI agent data access, only 47% of compliance teams, 39% of legal teams, and 34% of executives have the same visibility.

👉 Read Akto's analysis of AI security solutions for LLMs and AI agents

Context

AI security solutions have become a governance problem, not just a model-hardening problem. The article argues that LLMs, agentic workflows, and MCP-connected tools create runtime risks that traditional application security and network controls were not designed to govern, especially when autonomous agents can act inside enterprise systems.

The primary identity question is how to control access when the actor is a software system that can choose tools, invoke external APIs, and chain actions across internal services. That shifts the centre of gravity toward visibility, permissioning, runtime protection, and lifecycle governance for AI agents and the non-human identities they use.

The article's starting position is typical for 2026: enterprises are moving into AI operations faster than their security and compliance processes can keep up. That gap is now visible in prompt injection exposure, data leakage, shadow AI, and agentic tool abuse.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

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 security teams get wrong about prompt injection defence?

A: They often assume better blocklists will solve the problem, but obfuscation simply changes the shape of the payload. Real defence requires examining meaning across the full interaction, including retrieved content and model responses. If the control cannot interpret intent, it will keep missing the attack class it is meant to stop.

Q: How can organisations tell whether AI agent governance is actually working?

A: Look for evidence that agent access is ephemeral, traceable, and constrained at the action level. If the organisation cannot show which runtime acted, what it touched, and which endpoint or command it used, then governance is still too coarse. Effective control produces auditable decisions, not just authentication events.

Technical breakdown

LLM runtime security and prompt injection

LLM security at runtime focuses on controlling what enters and leaves the model during inference. Prompt injection works because the model treats untrusted text as instructions, so malicious content in email, web pages, or documents can override intended behaviour. Guardrails, input sanitisation, and output filtering reduce exposure, but they do not eliminate the architectural problem that a model cannot reliably distinguish intent from content without surrounding policy controls.

Practical implication: place policy and inspection between untrusted content and model execution, not just after the response is generated.

Agentic AI tool abuse and MCP-connected access

Agentic AI extends the attack surface because the system can call tools, query databases, and act across APIs. In MCP-style environments, the protocol links an agent to tools and data sources, which means a prompt compromise can become a tool abuse event if permissions are too broad. The key technical failure is not the model alone, but the coupling of reasoning, tool invocation, and data access in one execution path.

Practical implication: scope tool access tightly and separate model reasoning from high-risk execution paths wherever possible.

Identity and privilege abuse in enterprise AI

When AI systems use non-human identities, the security problem becomes identity governance. Access tokens, API keys, and service credentials can be exposed, overused, or inherited into workflows that were never meant to be persistent. Once an agent can reach internal systems with standing privilege, a single malicious instruction can turn an ordinary action into data leakage, unauthorised deletion, or lateral movement across connected services.

Practical implication: treat AI agent identities like high-risk NHIs and govern them with least privilege, auditability, and lifecycle controls.

Threat narrative

Attacker objective: The attacker aims to convert trusted AI workflow access into credential exposure, unauthorised tool use, and downstream data compromise.

1. Entry occurs when an attacker plants hidden instructions in a document, email, webpage, or third-party tool that an AI agent will read during normal operation.
2. Escalation follows when the agent interprets the malicious content as a legitimate task and uses approved tools, APIs, or connected data sources beyond intended scope.
3. Impact arrives when the agent reveals credentials, leaks sensitive data, performs unauthorised actions, or cascades the compromise through linked enterprise systems.

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

Identity-aware AI security is now a governance discipline, not a point-product feature. The article is right to frame visibility, runtime protection, and continuous monitoring as core requirements because agentic systems blur the line between application behaviour and identity behaviour. Once an AI system can reach internal tools and data, the programme must govern what it can do, when it can do it, and under which identity. Practitioners should treat AI security as part of identity governance, not an overlay on top of it.

Prompt injection is only the entry point; the real failure is tool-authority mismatch. A malicious prompt matters because the downstream agent is trusted to act on behalf of the enterprise. That means the vulnerability is not just content manipulation, but the mismatch between the agent's interpretive flexibility and the authority granted to its tools. Security teams should read every agent workflow as a delegation problem, because the compromise often begins where the tool boundary is too broad.

Autonomous agents break the assumption that access can be reviewed after it is granted. Access review processes were designed for actors whose privileges persist long enough to be observed, certified, and revoked on a schedule. That assumption fails when the actor can acquire, use, and combine access within runtime execution. The implication is that governance must account for within-session privilege use, not just periodic certification.

Agentic AI introduces a new named concept: runtime authority collapse. This is the point at which a model's conversational surface, tool permissions, and data access merge into one operational trust decision. When that happens, the usual separation between request, approval, and execution becomes too thin to enforce meaningful boundaries. Practitioners should expect this to become the dominant control issue in enterprise AI rollouts.

Shadow AI is not just discovery debt, it is identity debt. Unmanaged AI tools matter because each one can introduce hidden identities, hidden permissions, and hidden data paths that evade IAM, PAM, and audit workflows. Once those identities are outside inventory, the organisation cannot apply lifecycle governance, revoke access cleanly, or prove compliance. Teams should treat discovery as an identity control, not merely an asset-management task.

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.
• 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, see OWASP NHI Top 10 for the recurring agentic risks that most often show up in runtime governance failures.

What this signals

Runtime authority collapse: the control boundary is moving from static permission assignment to session-level execution oversight. That means AI programmes need inventory, ownership, and logging at the same speed as the agent's own actions, or governance will always trail behaviour.

With 92% of organisations saying AI-agent governance is critical but only 44% having policies in place, the gap is no longer about awareness. It is about whether IAM, security, and compliance teams can operationalise policy before agent deployment outruns review cycles.

For teams building controls around MCP and agent workflows, the practical signal is whether each tool call can be tied back to an accountable identity and an approved purpose. Without that linkage, agent security remains observation without control.

For practitioners

• Inventory every AI agent and MCP-connected workflow Map models, tools, APIs, and data sources to a single ownership record so security, IAM, and compliance teams can see which AI actors exist and what they can touch.
• Separate reasoning from execution authority Do not let the same agent both interpret untrusted content and execute sensitive actions without scoped approval boundaries, especially where financial, customer, or administrative systems are involved.
• Apply least privilege to AI agent identities Treat every token, API key, and service credential used by an AI system as a high-risk non-human identity and restrict it to the narrowest tool set and data set required.
• Instrument runtime logging for agent decisions Record which prompt, tool call, identity, and data source were involved in each action so investigations can reconstruct agent behaviour after a security incident or compliance review.
• Build red-team tests for prompt injection and tool abuse Test how agents behave when malicious instructions appear in emails, documents, or web content, and validate whether the workflow can be coerced into revealing credentials or taking unsafe actions.

Key takeaways

• AI security now depends on runtime governance of agent behaviour, not just model hardening or perimeter controls.
• The biggest exposure is delegated authority that allows an AI system to turn untrusted content into tool use, data access, or credential exposure.
• Practitioners should inventory agent identities, scope tool permissions tightly, and insist on audit trails that make each action attributable.

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.
• 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.
• 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.
• 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.

What's in the full article

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

• A breakdown of AI security solution categories across LLMs, agents, MCP-connected workflows, and runtime protection layers.
• The article's specific examples of prompt injection, tool abuse, memory poisoning, and identity and privilege abuse in enterprise AI.
• Operational guidance on AI-SPM, guardrails, automated red teaming, and continuous monitoring for deployed AI systems.
• The source's own framing of compliance, governance, and runtime enforcement across the AI stack.

👉 Akto's full post covers prompt injection, tool abuse, runtime protection, and AI governance controls 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 programme, it is worth exploring.