AI agent security fails at runtime, not at the prompt

At a glance

What this is: This is an analysis of why AI agent guardrails do not control runtime behaviour and why the real security gap sits in tool calls, data access, and multi-step actions.

Why it matters: It matters because IAM, PAM, and AI security teams need controls that govern what agents do at runtime, not only what they say before or after execution.

👉 Read Straiker's analysis of why AI agent security needs runtime enforcement

Context

AI agent security is increasingly being defined by a control gap rather than a model flaw. Guardrails can shape output, but they do not stop an agent from using tools, reading data, or chaining actions in ways that exceed policy. In practice, that means the core risk sits in runtime execution, where identity, privilege, and context intersect.

For IAM and AI security practitioners, the important shift is that agent behaviour now has to be governed like a privileged runtime entity. That creates an identity and access problem as much as a model-safety problem, because delegated actions, tool permissions, and retrieved context all determine whether an agent stays inside its intended boundary.

Key questions

Q: What breaks when AI agent guardrails exist only in policy documents?

A: Policy-only guardrails fail when an agent can act at machine speed and the control cannot interrupt the action. Logging after the fact may help investigation, but it does not stop data movement or system change. Effective guardrails must operate where the agent calls tools, accesses data, or attempts escalation.

Q: Why do AI agents complicate existing IAM and PAM controls?

A: AI agents complicate IAM and PAM because they often inherit delegated credentials, operate across multiple systems, and keep acting after the initial approval moment has passed. Human session assumptions, periodic reviews, and static privilege models do not reflect that behaviour. The result is a governance gap between what was granted and what the agent can actually do.

Q: How do security teams know whether agent workspace controls are working?

A: Look for whether the agent can create configuration that changes execution behaviour without a second approval step. If auto-run files, startup hooks, or task definitions can appear in the workspace and later execute silently, the control is failing. Effective governance should make those writes visible, reviewable, and, by default, impossible.

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

Why pre-runtime AI guardrails miss the real control point

Pre-runtime controls such as prompt engineering, content moderation, and output filtering act before generation or after response. They can reduce unsafe language, but they do not govern the agent’s action loop. Once an AI system can call tools, fetch documents, query APIs, or chain decisions, the security question moves from text safety to execution safety. That is why runtime is the decisive layer: it is where context becomes action, and where policy must be enforced before the next step is taken. In practical terms, the issue is not only model alignment but whether the surrounding control plane can inspect and block each action in time.

Practical implication: treat agent execution as a privileged workflow that needs runtime policy enforcement, not just output controls.

How indirect prompt injection turns trusted context into an attack path

Indirect prompt injection occurs when malicious instructions are hidden inside content an agent retrieves and then treats as task context. The agent does not need to be “jailbroken” in the traditional sense because the instruction appears alongside legitimate material such as READMEs, code comments, PR descriptions, or external pages. That makes the attack especially hard to detect with conventional DLP, EDR, or IAM logic, because each individual request can look authorised. The failure mode is semantic: the input is untrusted, but the agent cannot reliably distinguish instructions from data unless the runtime controls are designed to do so.

Practical implication: classify retrieved content as untrusted input and inspect it before it can influence tool use or downstream decisions.

Why visibility is not the same as enforcement in agent security

Logs, traces, and dashboards tell you what an agent did after the fact, but they do not stop the action before execution. In AI security programmes, that distinction matters because behavioural visibility without blocking capability creates a false sense of control. A dashboard can support investigation, and it can help with tuning, but it does not prevent a tool call, a data read, or a credentialed action from happening. Runtime security must therefore sit inline with the agent, where it can validate intent, permission scope, and context before the next action proceeds.

Practical implication: require inline enforcement points for tool calls and data access, not just observability after the fact.

Threat narrative

Attacker objective: The attacker wants to hijack an otherwise legitimate agent workflow so the system performs harmful actions using its own permissions.

1. Entry occurs when an agent ingests poisoned context from sources such as documentation, comments, or retrieved web content.
2. Escalation happens when the injected instruction is interpreted as legitimate and the agent uses its permitted tools or credentials to act on it.
3. Impact follows when the agent moves data, executes commands, or exposes sensitive information in ways that appear individually authorised but are unsafe in combination.

NHI Mgmt Group analysis

Runtime enforcement is now the defining control gap in AI agent security. The article correctly identifies that guardrails live outside the agent’s action loop, while real risk emerges during tool use and chained decisions. That makes runtime security, not pre-runtime content filtering, the governance issue security teams must own. Practitioners should assess whether their AI controls can block action, not merely inspect output.

Semantic-layer risk is a distinct attack surface that conventional security tooling still misses. The article’s strongest contribution is its description of a control plane gap between retrieved context, reasoning, and action. That is where indirect prompt injection, tool misuse, and multi-hop leakage operate. The implication is that AI programmes need policy enforcement that understands semantic context, not just packets, processes, or static permissions. Practitioners should treat the semantic layer as part of the security boundary.

AI agents create an identity problem because they act through delegated permissions. In NHIMG terms, an agent with tool access is not just an application component. It behaves like a non-human identity whose authority must be scoped, reviewed, and constrained. That intersection matters for IAM and PAM teams because the question is no longer only what the model can generate, but what the agent can do with credentials, tokens, and service access. Practitioners should manage agents as privileged identities with bounded runtime authority.

Observable behaviour without control is the wrong operating model for agentic AI. The article makes clear that dashboards and traces are useful but incomplete, because security outcomes depend on intervention before execution. That mirrors a wider market pattern: buyers are being offered visibility products while the real need is policy enforcement at runtime. Practitioners should evaluate whether their controls can prevent unsafe actions, not just explain them after the fact.

What this signals

Runtime security for agents is becoming the practical test of whether AI governance exists at all. If a programme cannot block unsafe tool calls before execution, it does not have a control problem, it has an observability problem. Teams should review whether their architecture can enforce policy at the semantic layer, using guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework.

Agent access will increasingly need to be governed as non-human identity. Once an AI system can read, decide, and act through credentials, the operational question becomes who owns its privileges, how they are reviewed, and when they are revoked. That is where identity teams should connect agent controls to The 52 NHI breaches Report and to the broader NHI lifecycle model.

Semantic-layer attacks are likely to force a split between visibility tooling and enforcement tooling. Many products can explain what happened, but fewer can stop the next action from happening. Practitioners should look for controls that inspect prompts, tool calls, and retrieved context inline, then tie those checks back to privilege boundaries and service identity management.

For practitioners

• Implement inline runtime policy checks Place approval and blocking logic before each tool call, file read, or API request so the agent cannot act outside policy even when its prompt appears benign.
• Classify retrieved content as untrusted input Treat READMEs, PR descriptions, code comments, external pages, and similar retrieved material as potentially malicious instructions until they are validated.
• Scope agent permissions by task and session Limit terminal access, shorten session length for sensitive work, and remove broad wildcard permissions that allow a single prompt to fan out into multiple unsafe actions.
• Instrument the semantic decision layer Capture which context influenced each decision, which tool was selected, and why the action proceeded, so security teams can review agent reasoning before harm occurs.
• Map agents to privileged identity controls Assign ownership, review, and revocation processes for agent credentials, tokens, and service access in the same way you would for other high-risk non-human identities.

Key takeaways

• AI agent risk lives at runtime, where tools, data, and credentials turn model behaviour into business impact.
• Hidden instructions inside trusted context can bypass conventional security assumptions without ever looking like a classic exploit.
• Security teams need inline enforcement, not just guardrails and dashboards, if they want agentic AI to stay inside policy.

Key terms

• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Runtime Security: Runtime security is the practice of detecting and constraining malicious behavior while software is executing. It focuses on live workload activity, not just code quality or pre-deployment checks, so teams can contain abuse after a system is already running.
• Action Layer: The action layer is the point where an identity moves from asking for access to doing something with that access. For AI agents, this layer matters because tool use can happen faster than human review, and the meaningful risk appears when actions are chained across systems.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

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

• How the vendor maps AI agent discovery across environments, including agent and MCP server inventory.
• How runtime inspection is applied to prompts and tool calls as actions occur at the semantic layer.
• How the vendor approaches proactive red-teaming for agent workflows under realistic attacker conditions.
• How the vendor frames production coverage for inline enforcement, logging, and detection across agent actions.

👉 Straiker's full post covers the runtime control model, attack patterns, and defensive skills in more detail

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security practitioners connect identity controls to emerging agentic AI risks and broader non-human access patterns.