AI Agent Runtime Security: Authorizing Every Action
On July 29, 2026, Delinea shipped runtime authorization for AI agents. The claim behind it was small but pointed. It enforces policy on what an agent does inside a session before each action executes. That framing captures why AI agent runtime security is now its own discipline. For two years, most teams secured agents at the wrong layer. They verified identity when a session opened, then hoped for the best.
An agent is not a static service. It reasons, plans, calls tools, reads memory, and hands work to other agents. A single session can fire dozens of tool calls, each with a different risk profile. Verifying the connection once tells you who the agent is. It tells you nothing about what the agent is about to do. That gap is where data leaks, unsafe writes, and hijacked workflows live.
Build-time guardrails did not close the gap either. Prompt filters and system instructions shape what a model says. They cannot stop a tool call that has already left the model. When indirect prompt injection succeeds, a trusted agent becomes the attacker. The instruction now comes from inside your own perimeter. Static allowlists and after-the-fact logs cannot catch that in time.
This blog explains what changed and why it matters, and where KriraAI's AI consultancy services fit for teams weighing how to secure their own agent deployments. It covers how runtime authorization for AI agents works mechanically. It compares the new model against connection-time authentication and build-time guardrails. It walks through the MCP gateway pattern, now emerging as the enforcement point. It reviews the July 2026 launches and gives a practical adoption path. It also names the honest limits, because no enforcement layer is free.
Why connection time authentication left a gap agents walk straight through
Connection time authentication verifies who an agent is, not what it will do. This design fit software that followed fixed, predictable code paths. Agents broke that assumption in a fundamental way. They decide their next action at runtime, based on data they just read. That data can come from a web page, a document, or another agent.
The result is a control model that authorizes too early. You grant broad access at the door and lose sight of the room. Gartner forecasts that 40 percent of enterprise applications will embed task-specific agents by the end of 2026. That is up from under 5 percent in 2025, per the same forecast. The attack surface is growing faster than most security teams can map it.
Build time guardrails stop at the model boundary
Build time guardrails operate on prompts and responses, not on actions. They catch unsafe language before it reaches a user. They do not sit between the agent and the database it is about to write to. Once the model emits a tool call, the guardrail's job is already over. Enforcement has to move downstream, to the point of action.
Indirect prompt injection makes this concrete and urgent. Greshake and colleagues formalized the attack in 2023. A poisoned document or web page carries hidden instructions. The agent reads them as trusted input and acts on them. The model was not broken, yet it now issues dangerous calls on your behalf.
Why legacy security tools cannot see what an agent does
Legacy security tools were built to inspect files, packets, and static artifacts. Data loss prevention, firewalls, and SIEM systems watch network and file activity. They cannot parse an agent's reasoning or intercept a tool call mid-session. They see a valid session from a valid identity and let it through. The malicious action hides inside otherwise legitimate traffic.
OWASP made the risk landscape official in December 2025. It published the first Top 10 for Agentic Applications, a taxonomy built for autonomous agents. The list names the failure modes that runtime controls now target:
Goal hijacking is when injected input redirects the agent toward an attacker's objective.
Tool misuse is when the agent invokes a legitimate tool for an illegitimate purpose.
Identity abuse is when an agent's credentials are borrowed or escalated beyond their scope.
Memory poisoning is when tainted context corrupts future decisions across a session.
Cascading failures are when one bad action propagates through a chain of connected agents.
Rogue agents were unmonitored agents that operated outside their intended boundaries.
Each of those risks shares one trait. None of them are visible at connection time. All of them show up only when the agent acts.
How AI agent runtime security works under the hood
AI agent runtime security works by evaluating each action against policy before it executes. The enforcement point sits inline, between the agent and the tools it calls. Every tool call, memory read, and outbound request passes through this checkpoint. The checkpoint decides in real time to allow, block, or escalate the action. It records the decision as evidence a reviewer or auditor can replay later.
This is a shift from perimeter thinking to action thinking. The question is no longer whether the agent may connect. The question is whether this specific action, right now, is within policy. Context drives the answer, not a static rule set alone. That context includes the agent's identity, its task, its history, and its target.
The per-action decision point inside the agent loop
The per-action decision point wraps the agent's execution loop. An agent proposes an action, usually a structured tool call. The runtime intercepts that proposal before it reaches the tool. It checks the action against policy, scope, and behavioral baselines. Only then does it forward, deny, or route the call for human approval.
Latency is the hard constraint at this layer, and our closer look at Microsoft's Agent Governance Toolkit illustrates exactly how that target gets hit in practice. Its Agent OS is a stateless policy engine that intercepts actions in under 0.1 milliseconds at p99. It supports YAML rules, OPA Rego, and Cedar as policy languages. Enforcing this fast can gate every action without visibly slowing the agent.
Behavioral baselines add a second, adaptive layer of defense. Some platforms learn an agent's normal action patterns over time. They flag a sequence that deviates from that baseline for review. A billing agent who suddenly reads the HR database is a signal. Static rules would miss it, but a learned baseline will not.
Just-in-time credentials and scoped authority
Just-in-time credentials remove the standing secret that an attacker wants to steal. The agent never holds a long-lived key. The platform injects a credential at the moment of access, scoped to the task. When the task completes, the credential is revoked automatically. There is no lingering secret to exploit between sessions.
Delinea's July 2026 launch demonstrates this pattern in production. It scopes the injected credential to the task, not to the human who deployed the agent. It then enforces policy on each tool call individually. A single session may carry dozens of calls, each judged on its own. When an agent misbehaves, the blast radius stays contained to that action.
Runtime authorization for AI agents versus older control models
Runtime authorization for AI agents differs from older models on one axis: when the decision happens. Connection time authentication is decided once, at the start. An after-the-fact audit decides later, when the damage may be done. Runtime authorization is decided continuously, at each action, before execution. That timing difference is the entire point.
It helps to compare the three models across the criteria that matter in production:
Decision timing: connection time acts at session start, audit acts after execution, and runtime acts before each action.
Visibility: connection time sees identity, audit sees history, and runtime sees the live action in its full context.
Blast radius: connection time and audit allow broad damage, while runtime contains it to a single blocked call.
Injection resistance: only runtime enforcement can stop a hijacked but authenticated agent mid-task.
Evidence quality: runtime produces per-action, replayable decisions suited to regulated environments.
None of this makes older controls useless. You still authenticate the agent at the door. You still keep audit logs for forensics and compliance. Runtime authorization for AI agents adds the missing middle layer between them. It governs the interval where autonomous agents actually create risk.
The MCP gateway becomes the enforcement chokepoint
The Model Context Protocol has become the standard interface between agents and tools. It has crossed 200 server implementations, which makes it a natural control point. If every tool call speaks MCP, then an MCP gateway can see every call. That single chokepoint turns a sprawling problem into a governable one. Route the traffic through the gateway, and you can enforce policy on all of it.
Google Cloud shipped this idea as Agent Gateway in 2026. It routes agent traffic so policy applies to every agent-to-agent and agent-to-tool connection. Because agents behave nondeterministically, all of that traffic now flows through one path. Its Identity-Aware Proxy extends zero trust to agents using context derived from MCP. The gateway can block access to endpoints the agent was never meant to reach.
Intercepting tool calls, memory reads, and agent handoffs
An effective gateway inspects more than outbound tool calls. It also watches memory reads, retrieved context, and handoffs between agents. Retrieved content is a common injection vector, so it deserves inspection before it enters the context. Agent-to-agent handoffs carry authority, so they need signed, scoped mandates. A gateway that sees all three closes the paths attackers actually use.
This is also where KriraAI focuses its production work. KriraAI builds and delivers agentic systems for enterprises, and it treats the gateway as core infrastructure. In practice, that means routing tool calls, retrieval, and handoffs through one enforced path. KriraAI applies emerging techniques like per-action authorization only once they are ready for real workloads. The goal is measurable reliability, not novelty for its own sake.
Inside the July 2026 wave of agentic AI security solutions
July 2026 marked the moment agentic AI security solutions matured from concept to product. Several launches landed within weeks of each other. The common thread was enforcement that moved inline and per action. Each treated the agent as a nonhuman identity with a real lifecycle. Each aimed to allow, block, or escalate an action in real time.
The most telling launches of the month included the following:
Delinea released runtime authorization that evaluates and gates each tool call before it executes.
Google Cloud generalized its Agent Gateway to enforce policy on agent-to-agent and agent-to-tool connections.
Microsoft open-sourced its Agent Governance Toolkit, including a policy engine that intercepts actions in under 0.1 milliseconds.
Identity vendors shipped MCP gateways that enforce least privilege and just-in-time access for agents.
Runtime engines such as PromptHalo reported per-action decisions in under 100 milliseconds.
The differences among these agentic AI security solutions lie in deployment and depth. They do not lie in core philosophy. Every one of them rejects connection time control as sufficient. Every one of them governs the action itself. That convergence is the real signal for practitioners.
Regulation is arriving on a similar timeline. The EU AI Act's high-risk obligations take effect in August 2026. Colorado's AI Act becomes enforceable in June 2026. Both push enterprises toward provable control over automated decisions. Per action evidence maps cleanly onto that expectation.
How to secure AI agents in production
To secure AI agents in production, you start by making every action observable. You cannot govern what you cannot see. The practical path is a sequence, not a single control. It moves from inventory to interception, to policy, to scoped access, to evidence. Each step builds on the one before it.
A workable adoption sequence looks like this:
Inventory every agent, tool, and MCP server, including the shadow agents nobody registered.
Route all agent traffic through a gateway so tool calls and handoffs pass through one enforced path.
Write policy at the action level, expressed in a language like OPA Rego or Cedar.
Replace standing credentials with just-in-time secrets scoped to each task.
Insert human approval for high-risk actions such as payments, deletions, or external sends.
Baseline normal agent behavior, then alert on deviations from that baseline.
Record every decision as replayable evidence for audit and incident response.
Voice agents raise the stakes on this sequence. An agent that books, cancels, or pays acts in the physical and financial world. KriraAI runs OnDial, an AI voice agent platform, and applies these controls to real calls. A booking or a refund is exactly the high-risk action that deserves per-action gating. Building this in from the start is cheaper than retrofitting it later.
Performance, latency, and the limits are worth naming honestly
Runtime enforcement is not free, and pretending otherwise helps no one. Every action now passes through an extra decision step. That step adds latency, and latency compounds across a long agent loop. The engineering answer is to make each decision extremely fast. The published targets show why this is achievable.
The latency budget every enforcement layer must respect
The latency budget for per-action enforcement is measured in milliseconds, not seconds. PromptHalo reports per-action decisions in under 100 milliseconds. Microsoft's Agent OS intercepts actions in under 0.1 milliseconds at p99. Those numbers exist because anything slower breaks the agent's rhythm. An agent making forty calls cannot absorb forty slow checks.
The design lesson is to keep the policy engine stateless and local. State lookups across the network are where latency dies. Cache identity and scope decisions where you safely can. Push slow, expensive checks only onto genuinely high-risk actions. Fast paths and slow paths should be explicit in the architecture.
Coverage gaps, false positives, and shifting threats
Coverage is the first honest limitation of runtime authorization. A gateway only governs traffic that actually routes through it. Direct connections that bypass the gateway are invisible to it. This is why several vendors stress discovering shadow agents first. Enforcement without complete coverage is a false sense of safety.
False positives are the second limitation, and they carry a real cost. A policy that blocks legitimate actions trains teams to disable it. Behavioral baselines drift as agents and tasks legitimately change. Tuning is continuous work, not a one-time configuration. The threat models themselves keep shifting as attackers adapt.
Verification remains an open research problem worth watching. Academic work in 2026 explored hardware-rooted and formally verified enforcement. Those approaches promise stronger guarantees than policy engines alone. They are not yet production defaults for most enterprises. For now, layered defense beats any single mechanism.
What this means for agent governance in enterprise AI
Agent governance for enterprise AI now has a concrete technical anchor. For years, governance meant documents, committees, and acceptable use policies. Runtime authorization turns those written rules into enforced runtime decisions. Policy becomes code that executes on every action. That is the difference between intent and control.
This reframes how you should design agentic systems from day one. Treat every agent as a nonhuman identity with least privilege by default. Assume any input the agent reads could be hostile. Make the enforcement point a first-class part of the architecture. Design the audit trail before the incident, not after it.
The strategic payoff is the ability to scale agents safely. Databricks reported that multi-agent workflows grew 327 percent between June and October 2025. Gartner estimates that only around 130 of the many vendors marketing agents are genuinely agentic. The teams that win will pair real autonomy with real control. Agent governance for enterprise AI is what lets you deploy without flying blind.
Conclusion
Three ideas are worth carrying out of this piece. First, AI agent runtime security works by judging each action against policy before it executes, not by trusting a session after it opens. Second, it matters most wherever agents take consequential actions, in payments, data writes, infrastructure changes, and voice interactions. Third, the practical response is to route agent traffic through an enforcement point, scope credentials just in time, and record every decision. Do that, and you can scale agents without losing control of them.
This is the frontier where KriraAI does its work. KriraAI builds and delivers production AI systems for enterprises, and it stays close to the research and standards frontier. It adopts techniques like runtime authorization when they are ready to produce measurable value, not merely when they are new. Its own voice platform, OnDial, applies per-action controls to live customer calls. Agent governance for enterprise AI is treated as core engineering, not paperwork.
If your organization is moving agents toward production, this shift deserves your attention now. Talk to KriraAI about what AI agent runtime security could mean for your specific systems and risk profile. The connection is no longer the thing to authorize. The action is.
FAQs
AI agent runtime security is the practice of evaluating and enforcing policy on each agent action at the moment it happens, before that action executes. Instead of only verifying identity when a session opens, it inspects every tool call, memory read, and handoff in real time. It can allow the action, block it, or route it to a human for approval. It also records each decision as replayable evidence for audit. This model exists because autonomous agents decide their next step at runtime, so security has to be enforced at runtime too.
Connection-time authentication confirms who an agent is when a session begins, and then trusts it for the rest of the session. Runtime authorization instead evaluates what the agent is about to do, action by action, before each one runs. The distinction matters because a single agent session can carry dozens of tool calls with very different risk levels. Authenticating once cannot catch a hijacked but authenticated agent mid-task. Runtime authorization closes that gap by judging each action in its own context and scope.
Traditional tools like firewalls, data loss prevention, and SIEM were built to inspect files, network packets, and static artifacts. They cannot parse an agent's reasoning or intercept a structured tool call inside an active session. To these tools, a hijacked agent looks like a valid identity performing valid traffic, so the malicious action passes through untouched. Agents also behave probabilistically and decide their actions at runtime, which legacy controls were never designed to model. Protecting them requires an inline layer that understands agent context and enforces policy on the action itself.
An MCP gateway is an inline enforcement layer that sits on the Model Context Protocol path between agents and the tools they call. Because most agent tool calls now speak MCP, routing them through one gateway gives security teams a single point of visibility and control. At that chokepoint, the gateway inspects each tool call, retrieved context, and agent handoff against policy. It then allows, blocks, or escalates the request before execution. This lets teams enforce least privilege and just-in-time access without rebuilding the agents themselves.
You secure AI agents in production by making per-action enforcement extremely fast and selective. Modern policy engines make decisions in well under 100 milliseconds, and some intercept actions in under 0.1 milliseconds, so most checks are invisible to users. The practical approach keeps the policy engine stateless and local, caches safe identity and scope decisions, and reserves slow, expensive checks for genuinely high-risk actions like payments or deletions. You route traffic through a gateway, apply just-in-time credentials, and add human approval only where the risk truly justifies it.
Ridham Chovatiya is the COO at KriraAI, driving operational excellence and scalable AI solutions. He specialises in building high-performance teams and delivering impactful, customer-centric technology strategies.