Every agent constraint is either declared or enforced. Execution control is the enforced kind.
On July 30, 2026, Anthropic disclosed that a review of 141,006 evaluation runs where Claude could have obtained internet access found three incidents, across six runs, where its models reached real third-party organizations during cyber capability evaluations. One model reached a real company's production infrastructure, pulled credentials and hundreds of database rows, and kept going after concluding it was probably not in a simulation; another published a package to PyPI that ran on 15 real systems.
An evaluation prompt had told the model it had no internet access. The machines it ran on were online anyway—an environment misconfiguration Anthropic attributes to a misunderstanding with its evaluation partner. Egress isolation would have closed that specific hole. It would not close the case this piece is about: an agent with production access it is actually supposed to have, doing something that access permits and its purpose doesn't.
These particular incidents were exploits, not that case—vulnerabilities exploited, a booby-trapped package, SQL injection through an exposed debug page. The case this piece is about is narrower and more common: nothing gets broken into. The caller authenticates normally, the command is one it's allowed to run, and nothing in its path compares the action to what that session was supposed to be for.
Every constraint on an AI agent is one of two kinds. Declared constraints live in a prompt, a config, a tool description, or a classifier the agent consults itself. Enforced constraints sit in the path, outside the agent, and get a vote before the action lands. Execution control is the second kind.
It is not a new budget line. Privileged access management is the line enterprises already fund, and AI-native PAM is the category they shop in. Execution control is the layer that decides the evaluation inside that category, not a standalone category waiting on an analyst to name it.
What is AI agent execution control?
AI agent execution control is the layer that evaluates a specific action an AI agent is about to take—a shell command, a tool call, a privileged operation—against policy and against the purpose the session declared, just before it reaches the target system, and returns one of three answers: allow, block, or escalate to a human. Comparing the action to policy is table stakes; of the vendor descriptions surveyed below, none returns a pre-execution verdict on whether the action matches the purpose the session declared.
Four properties make it a layer, not a setting on something already in the stack.
- It judges the action, not the principal. Access control decides what an agent may do in general; execution control decides whether this command, formed from this input, in this session-scoped context, runs now.
- It decides before the action lands. The evaluation point is after authentication and before execution. Anything later is a record.
- It lives outside the agent. Policy, decision, and audit entry sit in a control plane the agent cannot edit or disable.
- It compares the action to declared purpose, not just to a fixed rule. A pattern, an allowlist, or a mediator like
dzdomatches the command against a rule written before the session existed; it doesn't ask whether this action fits the job this session was opened for.
Several names compete for this box. Gartner's inaugural Market Guide for Guardian Agents, February 2026, makes runtime inspection and enforcement one of three mandatory core capabilities (as covered by The Hacker News). Trade press covering recent Delinea and Neo announcements calls it runtime authorization—tool calls, API requests and privileged actions evaluated before execution. Neo, which launched in July on a real-time control layer for agentic software, calls its product "Agentic Software Control"; Delinea uses both runtime authorization and "continuous identity authorization" (per its own StrongDM-acquisition release). We call it execution control: the interesting failures are the ones where the caller is fully permitted and the action is still wrong.
Why does AI-native PAM need a new execution layer?
Because the PAM controls that already inspect commands match them against rules written before the session started. The closest published answer on timing—Delinea's runtime authorization—evaluates the action before it runs and scopes the credential to the task; of the vendors named in this piece, none publishes a pre-execution verdict on whether this specific command matches the purpose the session declared.
Legacy PAM can judge a command. CyberArk's PSMP filters typed commands in the SSH session against an allow/deny list (per CyberArk's own documentation). StrongDM, now part of Delinea, applies per-statement policy against parsed SQL (per StrongDM's own blog). Delinea ships dzdo, a sudo-equivalent that runs privileged commands through its Server Suite agent (per Delinea's own documentation), and per the same trade coverage cited above, its platform can analyze SSH commands, database queries, and Kubernetes interactions before the agent executes—returning the same allow/block/escalate shape this piece defines above.
What those mechanisms share is the shape of the comparison. Each matches the command against a fixed description of a bad command—a pattern, an allowlist, a parsed statement checked against a protocol policy—written before anyone knew what the session would be for. That works with a human at the keyboard: an engineer who opened a shell to rotate a certificate knows that dumping a customer table is not the job.
An agent removes that half. It works faster than anyone reviewing it, has no durable sense of what the session was for, and can be redirected by what it read five minutes ago. Each command it forms can sit inside the rule set and still be wrong for the task—a permitted command in the wrong session. Kiteworks' 2026 risk forecast found 63% of 225 security, IT, and risk leaders could not enforce their agents' purpose limitations.
The missing comparison is not command-versus-rule but command-versus-purpose: this session was opened for a particular job, and this action is not that job. Identity does not make that comparison, a policy document does not, and pattern-matched filtering cannot—the pattern was fixed before the purpose existed. Hence a new box, not a bigger rule pack.
Why isn't a self-checked constraint a boundary?
TL;DR: A control run by the same agent it constrains is a preference, not a boundary. A better classifier doesn't change that, and the same agent still can't reliably terminate itself either.
AI Now Institute's Friendly Fire brief planted a decoy source file, a malicious binary, and injected instructions in a repository's documentation, then pointed two major coding agents at it. Both executed the attacker's code with no warning and no approval box. The attack depends on the optional autonomous modes, which use a model-side classifier to decide which commands are safe to run unattended. Asked point-blank whether the package contained hidden instructions, both models said no; in some runs they noticed the binary did not match its stated source and ran it anyway.
Read that as architecture, not a product defect. A control administered by the thing it constrains is a preference. A better classifier does not change that: the one that misses an injected instruction and the one that catches it are both the agent deciding whether to obey itself. In the same Kiteworks survey, 60% can't ensure they can terminate a malfunctioning agent at runtime.
What the MCP spec standardized, and what it left to implementers
The MCP specification released on July 28, 2026 is a serious piece of work: RFC 9207 issuer validation, Client ID Metadata Documents deprecating dynamic client registration (DCR stays functional for backward compatibility), issuer-bound client credentials, Tasks promoted to an official extension. It also adds Multi Round-Trip Requests, so a server can return resultType: 'input_required' and ask for confirmation mid-tool-call.
MRTR standardizes the asking. The spec settles how an agent asks and who it is; whether the command may run is left to implementers. Akamai's security research reads the release as pushing decisions the protocol used to make onto server developers and platform operators.
A protocol can standardize the question. Only the operator's stack answers it.
Why "ask a human every time" is not the answer
TL;DR: Asking about everything trains people to stop reading; asking about nothing is just monitoring. The workable shape is graded—rules resolve the obvious cases, judgment handles the middle, and only genuinely risky actions reach a person.
The obvious response is to put a person in front of every action. Practitioners have described where that goes: the first prompt reassures; by the fiftieth it is background noise, and the developer starts approving by reflex. A prompt everyone clicks through is the feeling of safety without the substance. The escape hatch is documented: Anthropic's dev-container docs scope --dangerously-skip-permissions to a non-root container and tell you to pair it with network-egress restrictions. That is a boundary around the environment, not a decision about the action.
So the failure mode dictates the design. A control that asks about everything trains the person to stop reading; one that asks about nothing is monitoring. The workable shape is graded: deterministic rules resolve what is obviously fine and obviously forbidden, judgment handles the ambiguous middle, and only genuinely risky actions reach a person—one action held, not the whole session.
What execution control is not
TL;DR: Identity, policy, alignment, observability, and sandboxing are all real controls that answer a different question than this one—none of them judges whether a specific action matches the purpose the session declared.
Each of these is a real control; none answers this layer's question. Observation gets mistaken for control most often: Gravitee's State of AI Agent Security 2026—a vendor-published survey—found 91.8% of senior technology leaders report confidence in their AI agent visibility, yet only about half of deployed agents are actually monitored. As summarized by OODA Loop, Arkose Labs' 2026 Agentic AI Security Report (also vendor-published) found 97% of security leaders expect a material agent-driven incident within twelve months, while only 6% of security budgets address the risk.
| Neighboring layer | The question it settles | Why it is not a substitute |
|---|---|---|
| Identity | Who is calling? | The hard case is a valid caller doing the wrong thing |
| Policy frameworks | What is permitted in principle? | Written before the task exists |
| Alignment and guardrails | How likely is a bad action? | Changes the odds; does not bound the action |
| Observability | What happened? | After the fact; confidence in visibility (Gravitee: 91.8%) isn't coverage—only about half of agents are actually monitored |
| Sandboxing | Where can it run? | Bounds the environment, not the action; the agents worth governing touch production |
Five neighbors, one open question each. Gartner's inaugural guardian-agents Market Guide names runtime inspection and enforcement a mandatory capability alongside AI visibility and traceability, and continuous assurance and evaluation; in the table above, identity and policy already have strong incumbents—this is the box this piece is about, usually right after something in that table went visibly wrong.
One boundary sits on the layer itself: it does not detect injected instructions—that is an upstream filter's job. Where a layer draws the line on child-process syscalls varies by product.
The question worth carrying into an evaluation
TL;DR: Every competing label—runtime authorization, risk scoring, Agentic Classifiers—still leaves the same decision unowned. The question to ask a vendor is what their product's default does with that decision, not what it's capable of in principle.
The market moved on this box in 2026: Delinea completed its acquisition of StrongDM in March, Neo launched in July on a real-time control layer for agentic software, and Teleport previewed agent risk scoring and Agentic Classifiers at Black Hat, with hands-on customer availability stated for the fall.
The labels will keep competing—runtime authorization, risk scoring, Agentic Classifiers. On the purpose comparison specifically, Teleport's Agentic Classifiers come closest: they flag behavior against a declared objective, which is more than the others publish. Even that stops at a flag, not a verdict returned before the command runs. The decision underneath the labels will not change: when an agent forms a command, something has to allow it, block it, or hand it to a person before it reaches the system. If no layer owns that decision, the agent owns it—as it did in the eval environments Anthropic wrote up, and in every stack where the constraint is a paragraph in a prompt.
So the question to take into an evaluation is two-part: what does this product actually compare the action against, and what does it do about the answer in the deployment you would actually run? A judgment that lands as a record and a judgment that lands as a block are different controls, and which one you get is a deployment question rather than a datasheet line—so ask for the default, not the capability.
This piece is from AlpacaX, where we build execution control for AI agents.
FAQ
What is AI agent execution control? The layer that evaluates a specific action an AI agent is about to take—a shell command, a tool call, a privileged operation—against policy, just before it reaches the target system, and returns allow, block, or escalate to a human. It sits after authentication and before execution, outside the agent so the agent cannot disable it.
Is execution control a new category, or part of PAM? Part of PAM. AI-native PAM is the category enterprises budget for; execution control is the differentiating layer inside it. Legacy PAM already inspects commands—SSH command filtering, per-statement SQL policy, sudo-style execution mediators—and newer runtime-authorization, risk-scoring, and classifier products evaluate the action itself. What distinguishes the layer is whether the verdict lands before the command runs, bound to that specific action and the purpose the session declared—of the products named in this piece, none does both today.
Does the MCP specification handle execution control? Only partly. It settles how an agent asks and who it is—including enforceable requirements like RFC 9207 issuer validation and issuer-bound client credentials—and adds mid-execution confirmation requests. What it leaves to implementers is whether the command may run.
