How do agents change runtime control?

Runtime control is a mature practice, but it was built for human-paced releases. AI agents break the three assumptions underneath it: that a human is present at each decision, that individual actions are the unit of inspection, and that the actor is a user.

By the end of 2026, 40 percent of enterprise applications will embed AI agents, up from fewer than 5 percent in 2025, according to Gartner. This article explains how agents change runtime control, and why governing action sequences and not individual API calls is what works at agent speed.

TL;DR

• Agents break three runtime control assumptions simultaneously, not just one.
• The governance unit shifts from API calls to action sequences.
• System prompts shape behavior; they can’t ensure compliance in high-stakes systems.
• 92 percent of CISOs can’t see the agents running in their environments.
• Governance enables agent adoption; it doesn’t slow it down.

Runtime control was built for human-paced releases

Runtime control was designed around a person at the keyboard. An engineer opens a pull request. A reviewer approves it. A deployment pipeline runs. A feature gate gets toggled after a staged rollout confirms behavior. The whole model assumes a human makes each consequential decision and acts on one change at a time.

Three assumptions sit underneath that model:

• Decision cadence is measured in minutes or hours, not milliseconds.
• Each action can be inspected in isolation: did this user have permission to make this API call?
• The actor is a person with a persistent identity, an organizational role, and a traceable authorization chain.

All three went unstated because they were always true. What separates runtime control from logging or orchestration is what it manages: the path taken during execution, not a record of what happened after the fact. With human engineers, the execution path was rarely non-deterministic.

Agents move governance from code to actions

Consider what an access control check evaluates: did this identity have permission to call this endpoint at this moment? The agent reads a customer database. Permitted. The agent drafts an external email. Permitted. The agent sends it. Permitted.

No individual step flags. The violation is invisible until you look at the sequence.

The violations that matter (data exfiltration, information barrier breaches, unauthorized external communication) are properties of action sequences, not individual actions. That’s a distinction researchers have started formalizing as governing “policies on paths”. A database read followed by an external email is a potential exfiltration event. Role-based access controls, API gateways, and network policies all operate one step at a time. Agents moved the unit of control to the path.

The objection is that a well-written system prompt can constrain this. Tell the agent not to send external communication after reading sensitive data, and it won’t. Prompt-based constraints hold in low-stakes environments with well-scoped tasks. A prompt shapes the probability distribution of paths the agent takes. It cannot enumerate every possible sequence, and it can’t prevent any specific path from occurring. In environments where certainty is the requirement (financial systems, healthcare records, regulated data pipelines), “usually complies” isn’t a strong enough guarantee. Enforcement must happen at the action layer.

Human-in-the-loop approval doesn’t survive agent speed

A single agent session can produce dozens of file changes, API calls, and commits. A human reviewer wouldn’t have opened their first notification yet. The human-approval model assumed there were minutes or hours between decisions. Agents compress that to seconds, sometimes simultaneously across multiple tasks.

Two failure modes follow. Approvals become a rubber stamp: a human clicking “approve” on outputs they can’t evaluate at that volume. Or the approval step disappears entirely because it’s blocking every workflow. Neither approach actually gives teams control.

84 percent of IT leaders agree that additional technical controls will be needed to govern AI agents, according to Gartner research. In other words, existing controls aren’t sufficient.

Control has to evaluate locally, in sub-millisecond time

If the control layer introduces latency the agent must wait for, it becomes a bottleneck. If it can be bypassed when it’s too slow, it isn’t a control. What agents need for runtime enforcement isn’t “fast enough for humans to not notice.” The control layer needs to intercept an action before it commits, within the execution loop.

That means three architectural properties:

• Evaluation must happen locally, not through a round-trip to a central server.
• The control layer must track the action sequence in memory, not reconstruct it from logs.
• Enforcement logic must run inline without re-invoking the model.

Research into runtime enforcement points the same way: AgentSpec intercepts unsafe actions inline, blocking more than 90 percent of unsafe executions in code agents while adding only millisecond overhead. That’s the performance floor. The runtime control layer must sit at the edge of execution, inside the agent’s loop, not at the API gateway downstream from it.

Agent identity is not user identity

Your access control model has historically asked one question: who is the user, and what are they allowed to do? Agents introduce a different set of questions. Which agent is this? Who authorized it? For what task? At what point in its execution path? With what scope of permitted actions?

An agent acting on behalf of a user inherits that user’s permissions but doesn’t share their intent, context, or accountability. The agent may be operating several steps deep into a task the user approved in general terms, without approving each specific action the path requires.

92 percent of enterprise CISOs and CIOs can’t identify the AI agents running in their environments, according to a 2026 CSA survey of 235 large-enterprise security leaders. 95 percent report uncertainty about their ability to detect or manage a compromised agent.

User identity is a solved problem. Agent identity is still catching up.

Feature flags become the runtime primitive for agent actions

Execution-path evaluation replaces API-call inspection. Local enforcement replaces human approval cadence. Agent-scoped identity replaces user-inherited permissions. Feature flags used as runtime primitives provide the mechanism for all three.

Binary boundaries that decouple exposure from deployment

A flag doesn’t ask whether the agent has permission. It asks whether the agent should act in this context, at this point in the path, given the current state of the system. An agent can hold all the necessary permissions and still encounter a flag that pauses its execution until a runtime condition is met. The agent ships code without the code going live.

Programmable path policies

Because flags evaluate at runtime against the full execution context, they can carry path-dependent logic. A flag can pass when the agent reads a record and fail when the agent attempts an outbound write after reading it. The policy lives in the control plane, not in the agent’s instructions. Evaluating the current rules happens locally, in sub-millisecond time. When you change a policy, the update reaches your SDKs on their normal refresh cycle, or in real time if you run Unleash Enterprise Edge streaming.

Instant deactivation without rollback

During a staged rollout, the Visa team used an emergency toggle to disable a misbehaving feature in seconds, with no rollback and no redeploy. That moment, as the Visa team described it, converted internal skeptics. The speed requirement for agent governance is that: stop a misbehaving action in seconds, without triggering a full recovery cycle.

FeatureOps provides the operational framework for all three properties. Flags are the layer that makes agent output observable, reversible, and held to the same standards as human-written code. 46 percent of organizations with mature AI governance are early adopters of agentic AI. Among organizations whose policies are still developing, that number drops to 12 percent. Governance doesn’t slow adoption. It precedes it.

Implementing the management and data plane split

Building this model needs a clear architectural boundary. The management plane is where agents discover and configure runtime controls. The data plane is where those controls run during execution.

The management plane

The Unleash MCP server operates in the management plane and delivers flag management capabilities directly to AI coding agents. Three tools define the interface:

• evaluate_change determines whether a proposed code change needs a flag before it ships.
• detect_flag checks for duplicates before a new flag is created.
• wrap_change generates the framework-specific guarding code.

No agent-initiated change alters production state without first passing through this layer, and final approval for any state change remains with a human.

The data plane

Community-supported protocols like OpenFeature standardize how flags evaluate across vendors. Evaluation runs locally, without a round-trip, at the latency the agent’s execution loop needs.

For example, Wayfair runs this infrastructure at over 20,000 requests per second during peak traffic, at one-third the cost of their previous homegrown solution. That scale is what “reliable enough for agents” looks like in production.

Every action an agent proposes either clears a runtime check or waits for a human decision. Nothing commits to production state without passing through the control plane.

Governance at agent speed

Teams that build this model into their agent architecture ship faster, because every agent action either passes a runtime check or stops cleanly. No reactive troubleshooting. No emergency rollbacks. No post-mortems tracing back to a gap in the approval workflow.

The teams that won’t get there are the ones patching one broken assumption at a time: faster approvals, tighter prompts, stricter IAM scopes. Each fix addresses the symptom. None address the governance unit.

Agents moved control from individual calls to action sequences, and the only model that works at agent speed is one that governs sequences. The AI control plane is where that happens.

FAQs

Can a well-written system prompt replace a runtime control layer?

System prompts only shape the probability of agent behavior; they cannot guarantee compliance in high-stakes environments. While prompts provide soft guardrails, true governance requires deterministic enforcement at the action layer to prevent unsafe execution paths. Research on agent governance shows that violations like data exfiltration are properties of action sequences that prompts alone can’t reliably block.

What is the maximum latency allowed for agent runtime control?

A runtime control layer must evaluate actions in milliseconds to avoid becoming a bottleneck in the agent’s execution loop. If the control layer introduces perceptible latency or requires a round-trip to a central server, it often gets bypassed or disabled. The AgentSpec benchmark demonstrates that effective enforcement can maintain millisecond-level overhead while preventing more than 90 percent of unsafe executions.

How does agent identity differ from standard user identity?

Standard identity models ask who a user is, but agent identity must define which agent is acting, who authorized it, and for what specific task. According to a 2026 CSA survey, 92 percent of CISOs cannot identify the agents running in their environments. Agents require scoped identities that track intent and execution paths rather than just inheriting static user permissions.

What happens when the runtime control layer fails?

If the runtime control layer fails, the system must default to a “deny-by-default” state to prevent ungoverned agent actions. Without an active control plane, agents may execute non-deterministic sequences that lead to information breaches or unauthorized communication. Implementing a kill switch allows teams to disable misbehaving features in seconds, a capability that Visa used to maintain stability during production rollouts.

Does adding runtime governance slow down agent adoption?

Governance actually accelerates adoption by providing the safety framework necessary for production deployment. Organizations with comprehensive AI governance are nearly four times more likely to be early adopters of agentic AI. When teams trust the control layer to intercept errors, they can ship agentic features faster and with less manual oversight.