AI agent execution gaps expose a runtime governance blind spot

At a glance

What this is: Straikerai argues that AI agent security has to govern runtime execution, not just prompts, because agents can turn approved-looking actions into real system changes.

Why it matters: IAM, PAM, and agent governance teams need runtime context controls because action-level risk does not disappear once an agent is authenticated or the tool is approved.

By the numbers:

• 85% of successful attack scenarios involved agents operating beyond their intended authority.

Context

AI agent security is the practice of governing what an agent can do at runtime, not only what it says. The central problem is that a model output can become a tool call, API request, shell command, or MCP action that changes a real system.

That changes the identity question from whether the agent is authenticated to whether the requested action should be allowed in context. For IAM, PAM, and NHI programmes, the gap sits between approval of capability and approval of execution.

Straikerai’s article treats that execution point as the control boundary that matters most. The starting position is typical of current agent deployments, where prompt controls exist but action-time governance remains immature.

Key questions

Q: What breaks when autonomous AI agents are governed with prompt-level controls only?

A: Prompt-level controls can shape output, but they do not govern runtime action. Autonomous agents still choose tools, call systems and change state after the prompt is issued, so the real control point has to be the execution layer, where identity, authorisation and isolation can be enforced per action.

Q: Why do valid-looking agent actions still create security risk?

A: Because the final action may be the last step in a longer chain of instructions, retrievals, and prior tool calls that changed the meaning of the request. A valid request does not equal a safe request when the agent’s context shows manipulation, policy drift, or privilege misuse. Security teams must judge the full execution path, not the last message.

Q: How do security teams know if an AI agent is operating outside its approved role?

A: Teams should compare actual workflow behaviour against the approved use case. Signs of trouble include unexpected record access, unapproved action types, new system paths after an update, or repeated attempts to exceed the intended scope. In healthcare, behaviour review matters as much as entitlement review because unsafe actions often appear first as workflow drift.

Q: When should organisations use containment instead of only blocking one agent action?

A: Containment is needed when the agent has already shown unsafe or untrustworthy behaviour and continued execution would create more exposure. In that case, blocking one request is not enough because the session can keep producing harmful actions. Teams should be ready to suspend tools, freeze memory, or stop the agent before additional impact accumulates.

Technical breakdown

Why prompts and responses are no longer the control boundary

Traditional AI safety controls are built around inputs and outputs. They inspect prompts for malicious content and responses for policy violations, but they do not fully govern what happens when an AI agent converts a model decision into an external action. In agentic systems, the same request can become a database query, an API call, an MCP tool invocation, or a state change inside another application. That means the meaningful security decision is not whether the text looks safe, but whether the action is safe given the agent’s context, permissions, and execution history. Runtime security extends the decision point to the moment of action.

Practical implication: Treat prompt filtering as necessary but incomplete, and move enforcement to the point where the agent attempts to act.

What context changes an otherwise valid agent action

Context is what turns a legitimate-looking request into a security decision. A runtime control has to evaluate the original instruction, retrieved content, prior tool calls, permissions, and any agent-to-agent interactions that shaped the current action. This matters because a single approved API request can be the final step in an exfiltration chain if the agent was previously influenced by indirect prompt injection or unsafe retrieved data. The mechanism is cumulative: each step may appear acceptable alone, but the chain becomes risky when viewed end to end. Without that chain-aware view, security teams will miss abuse that only becomes visible across the full execution path.

Practical implication: Correlate instructions, retrievals, and prior actions before allowing a tool call or external request to execute.

Why shared capabilities widen the attack surface

MCP servers, Skills, APIs, plugins, browser integrations, and internal services all expand what an agent can do, but they also expand what can be abused. A capability is not only a function the agent can use; it is a path for instructions, permissions, and malicious behavior to travel through the system. A risky MCP server, for example, can introduce unsafe instructions, while a legitimate API can be used with harmful parameters. The technical issue is shared-surface trust: once multiple capabilities are reusable across sessions or agents, the organisation has to govern both what is exposed and how it is consumed at runtime.

Practical implication: Inventory shared agent surfaces and apply contextual enforcement to every reusable capability the agent can reach.

Threat narrative

Attacker objective: The objective is to turn a trusted agent session into a sequence of approved-looking actions that create real enterprise impact before controls intervene.

1. Entry occurs when an agent receives unsafe instructions through retrieval content, a shared capability, or an external interaction that influences later behaviour.
2. Credential or authority abuse follows when the agent uses approved permissions, tools, or APIs in a way that exceeds its intended scope.
3. Escalation happens when the agent keeps acting after the behaviour becomes untrustworthy, allowing a single session to produce multiple harmful actions.
4. Impact is created when the agent completes the final tool call or system change that affects data, users, or downstream services.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The execution gap is a governance boundary problem, not a prompt-safety problem. Once an AI agent can take action, the relevant control question becomes whether the action should execute in context. Prompt and response filters remain useful, but they do not govern the state change that follows a valid-looking request. Practitioners should treat action-time enforcement as the real control plane for agentic systems.

Access review processes assume access persists long enough to be reviewed; autonomous behaviour collapses that window. That assumption was designed for identities whose privileges remain stable across a measurable lifecycle. When an agent can acquire, use, and discard capability inside a short execution chain, the review model loses its artefact and its timing basis. The implication is that governance has to move toward issuance- and execution-time decisions, not periodic certification.

Shared capabilities create an identity blast radius that exceeds the original agent boundary. MCP servers, Skills, APIs, and other reusable surfaces let one agent inherit risk from another path, which makes containment depend on context-aware execution rather than static approval lists. This is where OWASP-NHI and agentic control models converge: the organisation is not only governing a tool, it is governing who or what can safely use that tool in the moment. Practitioners should assume every shared surface can widen the blast radius unless runtime policy narrows it.

Runtime containment is now part of identity governance. The article’s kill-switch framing is a useful reminder that stopping future agent actions can be as important as allowing the first one. In practical governance terms, revocation, suspension, and containment have to operate at the speed of agent execution, or the control arrives after impact. The practitioner conclusion is to make containment a first-class identity control, not a last-resort incident response add-on.

MCP configuration files create secret exposure debt that compounds agent risk. The Statraikerai evidence on exposed secrets shows that shared agent infrastructure is also a secrets problem, not just a behaviour problem. If MCP configuration already leaks credentials at scale, runtime governance must assume the surrounding trust material is fragile. Practitioners should treat configuration hygiene and execution governance as one control plane, not separate workstreams.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Runtime governance has to move closer to execution. Agentic systems do not fail only at the prompt layer. They fail when a valid-looking request is allowed to change state without enough context, which means policy has to travel with the action path rather than sit only at the model boundary.

Shared surfaces now define the identity blast radius. If one agent can reach MCP servers, Skills, APIs, and other reusable capabilities, then the real governance problem is not isolated access approval but cross-surface containment. That is the point where agent security starts to look like identity governance with runtime enforcement attached.

Execution-time review is the new control challenge. Access reviews and recertification still matter, but they are too slow if the risky action completes inside a single session. Practitioners should move toward decisions that are made when the agent requests capability, not after the fact.

For practitioners

• Implement action-time enforcement Block or permit agent actions at the moment of execution using context from instructions, retrievals, permissions, and prior tool calls rather than relying on prompt filters alone.
• Inventory shared agent surfaces Map every MCP server, Skill, API, connector, and reused capability an agent can reach, then assign runtime policy based on the risk of each surface.
• Add containment for unsafe agent behaviour Define a containment path that can suspend tools, freeze memory, or stop the agent from continuing when a request-level block is no longer enough.
• Separate approval of capability from approval of execution Require a distinct runtime decision before a trusted tool, API, or shared surface is allowed to execute a state-changing action.
• Review agent sessions for scope drift Look for cases where the agent’s earlier retrievals, messages, or tool calls make the final request unsafe even when the request itself looks normal.

Key takeaways

• AI agent risk is no longer limited to unsafe prompts or outputs because approved-looking actions can still change enterprise systems.
• The execution gap is where runtime context must decide whether a tool call, API request, or MCP action should be allowed to proceed.
• Containment matters when an agent keeps acting after trust has eroded, because blocking one request may not stop the next harmful one.

Key terms

• Inline Agent Runtime Security: Inline agent runtime security is the practice of evaluating and enforcing policy while an AI agent is executing, not before it starts or after it finishes. It focuses on live decisions, tool calls and data movement so unsafe behaviour can be blocked in the execution path.
• Execution Gap: An execution gap exists when policy is defined correctly but cannot be carried out consistently in the target system. In identity governance, this usually appears where integrations are missing, evidence is fragmented, or lifecycle actions depend on human coordination instead of deterministic enforcement.
• Answer-Time Enforcement: Answer-time enforcement is policy control applied when an AI system is about to return a result, not just when it reads a source. It matters because an identity may be entitled to query a repository but still should not receive certain recombined content from a GenAI workflow.
• Shared Agent Surface: A shared agent surface is any reusable capability an agent can reach, such as an MCP server, Skill, API, connector, or browser integration. These surfaces increase flexibility, but they also expand the paths through which instructions and risk can flow.

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.