AI security vulnerabilities expose the gap between static controls and agents

At a glance

What this is: This is Akto’s overview of AI security vulnerabilities, focusing on how agentic systems expand the attack surface through prompts, tools, data, and runtime behaviour.

Why it matters: It matters because security teams must govern AI systems that can act, not just answer, and that means extending identity, access, and runtime controls into agentic workflows.

👉 Read Akto's analysis of AI security vulnerabilities, agentic risk, and mitigation

Context

AI security vulnerabilities are different from conventional application flaws because they emerge from probabilistic behaviour, tool use, and runtime decision-making rather than only from deterministic code defects. The article’s core claim is that once LLMs and agents can query data, call APIs, and take actions, static controls alone no longer provide meaningful containment. That creates a governance gap for security teams trying to apply familiar application security patterns to systems that behave dynamically.

The identity angle is direct: agentic systems depend on authenticated access to tools, APIs, memory stores, and external services, so every model or agent effectively becomes a non-human identity with its own permissions and blast radius. For IAM and PAM teams, the issue is no longer only who can log in, but what a model, agent, or MCP-connected workflow can reach, mutate, or exfiltrate once runtime permissions are granted.

Key questions

Q: How should security teams govern AI agents that call APIs instead of using a UI?

A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login. The key control is to limit which APIs, data sources, and write actions the agent can chain together in one session. That keeps machine-paced behaviour inside a reviewable boundary instead of relying on human-style session assumptions.

Q: Why do AI agents complicate traditional access reviews?

A: AI agents complicate access reviews because they can accumulate permissions across tools and environments faster than manual certification cycles can observe. A review process built for stable human accounts does not fit an executor that can act across systems, create new access paths, and complete work before the next review window begins.

Q: What breaks when prompt injection is not controlled in agentic workflows?

A: When prompt injection is not controlled, the agent can follow malicious instructions hidden in web content and perform actions the user never intended. That creates a direct path from ordinary page content to unauthorized execution, which bypasses normal access-control thinking.

Q: Who is accountable when an AI agent makes an unauthorised change?

A: Accountability should be assigned to the governance model that authorised the delegation, the owner of the workflow, and the team that set the policy boundary. In practice, organisations need clear responsibility for agent configuration, monitoring, and incident response because the machine’s speed does not remove human accountability for the delegated identity.

Technical breakdown

Why prompt injection succeeds against AI applications

Prompt injection works because the model cannot reliably distinguish trusted instructions from untrusted content once both enter the same context window. Direct injection places malicious instructions in the user prompt, while indirect injection hides them inside web pages, email, documents, or retrieved content that an agent later consumes. The failure mode is not simple syntax matching. It is boundary confusion, where natural language becomes both data and command. In agentic systems, that matters more because the prompt can trigger tool calls, API actions, or state changes, not just text output. Practical implication: protect both input and action boundaries, not only the model prompt.

Practical implication: enforce input filtering, tool-level authorisation, and output monitoring together, because prompt controls alone will not contain action-bearing agents.

How tool access turns models into operational attack surfaces

An LLM becomes materially riskier when it can call tools, because a harmless-looking instruction can translate into a real action. Tools, APIs, browser connectors, memory stores, and multi-agent handoffs extend the attack surface well beyond the model endpoint. If permissions are broad, a manipulated prompt can cause data retrieval, credential exposure, or workflow abuse. This is why agentic risk is really access control risk in a new form. The important distinction is between a model that answers and an agent that acts. Once action is possible, the model’s effective privilege becomes the security boundary. Practical implication: scope every tool to the narrowest task and separate read from write access.

Practical implication: treat each agent as a distinct identity, assign only task-scoped permissions, and review every tool connection as if it were a privileged integration.

Why shadow AI and runtime visibility matter for governance

Shadow AI appears when teams use models, agents, browser extensions, or personal API keys without central approval or visibility. That creates a governance blind spot because what security teams cannot inventory, they cannot policy, monitor, or investigate. Runtime visibility is the difference between knowing an AI exists and knowing what it is doing in production. This is especially important when agents chain actions across tools or share instructions across multiple systems, because the risk is not confined to one application. The deeper issue is lifecycle control, not just deployment approval. Practical implication: discover all AI assets continuously and tie them to ownership, scope, and monitored runtime behaviour.

Practical implication: build continuous discovery into AI governance so unapproved agents, tools, and credentials are not operating outside policy.

Threat narrative

Attacker objective: The attacker’s objective is to convert an AI system’s trust in prompts, tools, and connected identities into unauthorised access, data exposure, or destructive action.

1. Entry occurs when an attacker uses prompt injection, malicious content, or exposed credentials to influence an AI system’s context or access path.
2. Escalation happens when the agent trusts that input enough to invoke tools, query data, or use overbroad permissions on the attacker’s behalf.
3. Impact follows when the agent leaks sensitive data, triggers unauthorised actions, or amplifies business logic abuse across connected systems.

NHI Mgmt Group analysis

AI security is becoming identity security by another name. Once models and agents can act through APIs, browsers, and tools, they behave like non-human identities with scoped privileges and measurable blast radius. The article correctly shows that the main control problem is no longer just model safety, but permissioned access to operational systems. That makes IAM, PAM, and NHI governance central to AI security rather than adjacent to it. Practitioners should govern agents as identities, not abstractions.

Runtime control is the missing layer in most AI governance programmes. Static content filters and one-time testing cannot contain a system that makes decisions during execution. The article’s emphasis on probabilistic behaviour and autonomous tool use exposes a governance gap that traditional application security rarely addresses. The practical consequence is clear: if you cannot observe and constrain actions at runtime, you are governing only the prompt, not the system.

Shadow AI creates policy failure before it creates technical failure. Unapproved models, personal keys, and browser agents are not just hidden assets, they are hidden authorities. That is why discovery and ownership are foundational controls, not housekeeping tasks. The named concept here is governance blind spot: the inability to see models, agents, tools, and credentials means you cannot assign accountability or enforce least privilege. Security teams should treat visibility as a prerequisite for control.

Agentic AI requires a blast-radius model, not a feature checklist. The article’s recurring theme is that capabilities expand faster than containment. As agents gain memory, tool chaining, and multi-step autonomy, the relevant question becomes how far a single compromised instruction can travel. That moves the discipline toward scoping, segregation, and approval boundaries. Practitioners should measure the maximum damage a single agent can do, then reduce it systematically.

What this signals

The programme-level signal is that AI governance is now an access governance problem. Teams that already manage IAM, PAM, and NHI controls have the right operating model to extend into agentic environments, but only if they stop treating AI as a standalone innovation track. The relevant next step is to align model, tool, and identity inventories so policy can follow actual runtime authority.

Governance blind spot: unapproved agents, hidden tools, and personal API keys create a condition where access exists without accountability. That is where incidents begin, and it is why discovery plus ownership must precede any serious policy effort. Teams should expect more pressure to prove control coverage across AI systems, not just describe intended guardrails.

The practical direction is toward continuous assurance. Use runtime telemetry, approval gates, and scoped permissions to reduce blast radius across AI workflows, then map that evidence into NIST AI Risk Management Framework and Zero Trust reporting. If the organisation cannot show what an agent can touch, it cannot credibly say the agent is governed.

For practitioners

• Inventory every AI system and connected tool Build a live register of models, agents, browser extensions, APIs, and MCP-connected tools, including shadow AI discovered on employee devices and cloud workloads. Assign each item an owner, a business purpose, and a permitted action scope.
• Scope each agent to task-level permissions Separate read and write access, block unnecessary tool calls, and remove broad API scopes that let a manipulated prompt reach unrelated systems. Treat every agent as a non-human identity with its own least-privilege profile.
• Monitor runtime actions, not only prompts Capture which tools an agent invoked, what data it touched, and which state changes it attempted. Use that telemetry to detect tool chaining abuse, recursive loops, and unauthorised execution paths.
• Validate AI supply chain inputs Review third-party models, plugins, extensions, and training sources for poisoning, backdoors, and unapproved permissions before they are allowed into production workflows.
• Add approval gates for high-impact actions Require human approval before an agent can change access, move data, or trigger destructive operations. Keep those gates outside the model path so prompt manipulation cannot bypass them.

Key takeaways

• AI security vulnerabilities are increasingly an identity and access problem because agents act through tools, APIs, and connected services.
• The strongest evidence in the article is the gap between AI capability and governance visibility, especially where agents operate beyond intended scope.
• Practitioners should prioritise discovery, least privilege, runtime monitoring, and approval gates before expanding agentic deployments.

Key terms

• 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.
• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
• 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.

What's in the full article

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

• Step-by-step mitigation guidance for prompt injection, model poisoning, and tool misuse in production AI systems
• A practical checklist for inventorying AI agents, APIs, plugins, and shadow AI across environments
• Operational advice for protecting vector stores, context windows, and third-party AI dependencies
• Examples of runtime guardrails and red teaming approaches for agentic workflows

👉 Akto's full post covers the attack surface details, mitigation checklist, and runtime control guidance

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and access control patterns that also apply to agentic AI. It helps security practitioners translate identity principles into practical controls for modern systems that act as well as answer.