Execution Containment for Tool-Using AI Agents
Why probabilistic planners need deterministic execution boundaries
From Outputs to Side Effects
For most of the last few years, discussion around large language models focused on outputs.
Concerns centered on hallucinations, bias, toxicity, misinformation, and general reliability of generated text. The risk surface was linguistic. A model produced tokens. Humans interpreted them.
Agent systems change that boundary.
A tool-using agent does not stop at generating text. It reads internal documents, queries databases, triggers workflows, sends communications, and modifies state. The model’s output is no longer the final artifact. It becomes an instruction that drives real infrastructure.
The shift is subtle but important.
Text generation produces content.
Tool invocation produces side effects.
Side effects interact with systems that were designed for deterministic, human-authorized access. Databases assume queries come from authenticated principals. Email systems assume the sender intends to send the message. Workflow engines assume triggers are deliberate.
When an agent is given tool access, probabilistic reasoning gains execution authority.
This introduces a structural tension.
The planner is non-deterministic. Its control flow is shaped by prompts, retrieved context, and stochastic sampling. The infrastructure it drives is deterministic. It expects explicit, bounded authority.
As long as models only produced text, failure was visible and reviewable. Once models can execute tools, failure becomes operational.
The question is no longer what did the model say.
The question is what did the model cause to happen.
The Structural Risk of Non-Deterministic Planners
Tool-using agents introduce a planner into the execution path.
That planner is not a compiled program. It is a probabilistic system that produces intermediate reasoning and structured tool calls based on prompts, retrieved context, and model sampling. Its control flow is generated at runtime.
In most current agent frameworks, execution follows a loop:
The model observes context.
The model decides which tool to call next.
The tool executes.
The result is appended to context.
The loop repeats.
The final execution trajectory is not precompiled. It emerges step by step.
This design has practical advantages. It allows flexible composition of tools and adaptation to intermediate results. It also introduces a structural enforcement gap.
Divergence Between Declared Intent and Runtime Behavior
Some systems attempt to mitigate risk by requiring an agent to produce a plan before execution. The plan is reviewed or logged. However, without runtime enforcement, the plan is advisory.
Once execution begins, nothing prevents the agent from:
Calling a tool that was not in the declared plan.
Reordering tool calls.
Repeating a tool call.
Mutating arguments in ways not reflected in the plan.
If tool invocation is authorized solely by static permissions, infrastructure has no way to distinguish between:
A tool call that is part of the approved trajectory.
A tool call that is the result of reasoning drift or adversarial influence.
The infrastructure only sees an authorized principal invoking an allowed API.
The execution trajectory is not enforced. It is assumed.
Authority Without Structural Boundaries
The core issue is not that models can be manipulated. It is that execution authority is granted without binding it to a specific, validated structure.
A database does not know whether a query was part of an approved workflow. An email service does not know whether a message was part of a declared execution plan. Each system enforces its own access controls, but none of them enforce the global trajectory of actions.
As a result, enforcement is local while authority is global.
The agent holds a set of permissions. The infrastructure checks each permission in isolation. No component verifies that the sequence of actions matches an approved graph for a specific session.
This creates room for:
Runtime deviation from declared plans.
Composition of tool calls that were never explicitly authorized as a sequence.
Reuse of capabilities outside their original context.
These risks emerge naturally in systems that allow non-deterministic planners to drive deterministic infrastructure.
The enforcement gap is not semantic. It is structural.
Infrastructure lacks a primitive for binding execution authority to a declared trajectory.
Why Existing Defenses Are Structurally Insufficient
The enforcement gap described above is often approached through mechanisms that were designed for other threat models. These mechanisms are useful, but they do not address execution trajectory.
Static Role-Based Access Control
Role-based access control answers a narrow question: can principal X call API Y?
This model works when principals are deterministic actors with predictable control flow. A human operator invoking a database query does so intentionally. The authorization decision is evaluated per request.
In an agent system, the principal is a probabilistic planner. It may have permission to call multiple tools. Each individual call can be valid under RBAC.
RBAC does not encode sequence constraints. It does not bind a specific set of tool calls to a particular session-level execution graph. It cannot distinguish between:
A call that is part of an approved trajectory.
A call that was not part of the declared plan.
As long as the principal is authorized for the tool, the call is allowed.
RBAC enforces access, not trajectory.
Prompt Guardrails
Prompt guardrails attempt to constrain the model’s behavior through instructions or pattern detection. These approaches operate inside the probabilistic system.
They can influence behavior. They cannot enforce behavior.
If the enforcement boundary relies on the model’s internal compliance, then the system has no independent verification layer. A guardrail is a suggestion to the planner, not a constraint at the execution boundary.
Security properties that depend on model alignment are inherently probabilistic.
Heuristic or Model-Based Risk Scoring
Some systems evaluate generated plans using a second model or heuristic risk engine. The plan is scored, classified, or filtered before execution.
This adds analysis. It does not add deterministic enforcement.
A probabilistic evaluator layered on top of a probabilistic planner does not create a hard boundary. It creates another decision point that may be influenced by adversarial inputs or model limitations.
Even if the plan is evaluated before execution, there must still be a runtime mechanism that ensures the plan cannot mutate during execution.
Without binding execution to the evaluated structure, plan analysis is advisory.
Monitoring and Post-Hoc Detection
Logging and anomaly detection provide visibility. They do not provide containment.
If an agent sends an external email or queries a sensitive table, detection after the fact does not reverse the action. For execution authority, the relevant question is whether the action can occur, not whether it can be observed.
Monitoring can complement enforcement. It cannot replace it.
None of these mechanisms bind execution authority to a declared, session-specific trajectory.
They operate at the level of access, content, or observation. The structural gap remains: there is no primitive that ensures an agent may execute only and exactly what was pre-approved.
Defining Execution Containment
The gap described above is not a failure of access control. It is the absence of a structural primitive.
What is missing is a way to bind execution authority to a declared trajectory.
We refer to this property as execution containment.
At a minimum, execution containment requires the following elements:
An execution graph G, representing the set of nodes an agent is allowed to execute and the dependencies between them.
A session identifier S, representing a specific execution instance.
A runtime enforcement mechanism that ensures only nodes in G may execute under S.
The guarantee can be stated simply:
Given a validated execution graph G and a session S, the system must ensure that only and exactly the nodes declared in G may execute during S.
This is not a claim about intent.
It is not a claim about correctness.
It is not a claim about data safety.
It is a structural guarantee about authority.
Execution containment does not attempt to determine whether a tool call is wise, ethical, or secure in a semantic sense. It asserts something narrower and more concrete:
If a tool call was not declared in the approved graph for this session, it must not execute.
If a node was declared once, it must not execute twice.
If the graph declared a specific order, execution must respect that order.
If the session changes, authority must not carry over.
This reframes the problem.
Instead of asking whether an agent can be trusted to follow its plan, we require the infrastructure to enforce the plan independently of the agent’s internal reasoning.
The planner may be stochastic.
The enforcement must not be.
Execution containment introduces a boundary. On one side is reasoning, sampling, and adaptation. On the other side is deterministic infrastructure. The boundary verifies structure, not thought.
Without such a boundary, infrastructure implicitly trusts the trajectory of a probabilistic system.
With it, execution authority becomes explicit and bounded.
A Deterministic Enforcement Model
Defining execution containment as a property is not sufficient. It must be realized through a concrete enforcement mechanism.
The model described here is intentionally minimal. It is designed to demonstrate that execution containment can be enforced deterministically in a runtime system.
Let an execution plan be represented as a directed acyclic graph G, composed of nodes n1,n2,...,nkn, each associated with a specific tool invocation and a set of dependencies.
Let S be a unique session identifier for a particular execution instance.
The enforcement model proceeds in five phases.
1. Schema Validation
The execution plan is parsed against a strict schema.
Unknown fields, missing fields, or malformed structures result in immediate rejection. No graph logic executes until the plan structure is validated.
The schema is the first boundary.
2. Graph Validation
The runtime verifies that:
All node identifiers are unique.
All declared dependencies reference existing nodes.
The graph is acyclic.
All referenced tools exist in a fixed registry.
A deterministic topological order is produced. Given the same input graph, the execution order is stable.
At this stage, the system has a validated structure. It does not yet have runtime authority.
3. Context Binding
A canonical representation of G is constructed. The plan is serialized in a deterministic form. The session identifier S is combined with this canonical representation.
A context hash is computed:
This hash binds the execution graph to a specific session.
The same graph submitted under a different session produces a different hash. The same session with a modified graph produces a different hash.
Authority becomes graph- and session-specific.
4. Capability Token Minting
For each node ni in G, the system mints a scoped capability token containing:
agent identity claim
session identifier S
node identifier
tool name
context hash H
expiration timestamp
Each token is cryptographically signed.
The token represents authority to execute exactly one node, in exactly one session, under exactly one graph.
5. Runtime Enforcement
During execution, the runtime processes nodes in deterministic topological order.
Before invoking a tool for node ni, the system:
Retrieves the pre-minted token for ni.
Verifies the token signature.
Verifies that the embedded session identifier matches S.
Verifies that the embedded node identifier matches ni.
Verifies that the embedded tool name matches the declared tool.
Verifies that the embedded context hash matches H.
Verifies that the token has not expired.
Verifies that ni has not already executed.
Only if all checks pass does the tool execute.
Any mismatch results in immediate termination of the session.
There is no recovery path. There is no fallback. There is no partial execution.
Execution either matches the declared graph exactly, or it stops.
This model does not rely on the agent’s internal reasoning. It does not inspect prompts. It does not attempt to interpret intent.
It enforces structure at the boundary where reasoning meets infrastructure.
A stochastic planner can still decide what to do next. It cannot exceed the structure that was declared and cryptographically bound to the session.
Caltrop v0.1 implements this model as a minimal reference runtime. It is not a complete security system. It is a proof that deterministic execution containment is mechanically achievable.
Demonstration: What Is Actually Prevented
The enforcement model described above is mechanical. Its value is best understood through concrete failure scenarios.
The following examples are taken from a minimal deterministic runtime that implements execution containment.
Scenario 1: Runtime Deviation
Assume a declared execution graph G contains:
Read_Public_Wiki→Summarize_Text→Send_Internal_Slack
For session S=session_safe_abc, a context hash is computed:
A capability token is minted for each node.
Suppose the agent attempts to use the token minted for Read_Public_Wiki to authorize a call to Send_External_Email.
At runtime, verification fails because the embedded tool field does not match the requested tool.
Observed log fragment:
TokenVerificationError: Token tool mismatch for node ‘1’.
Expected ‘Send_External_Email’, got ‘Read_Public_Wiki’.The call does not execute. The session terminates immediately.
The deviation is detected at the enforcement boundary, not inferred from model behavior.
Scenario 2: Cross-Session Replay
Suppose a token minted under session S1 is replayed under session S2.
Because the context hash is defined as:
the hash embedded in the token for S1 differs from the hash computed for S2.
Verification fails:
TokenVerificationError: Token session_id mismatch for node ‘1’.
Expected ‘session_B’, got ‘session_A’.Authority is session-bound. A capability issued for one execution instance cannot be reused in another.
Scenario 3: Token Tampering
If any field inside the token payload is modified, or the signature segment is corrupted, HMAC verification fails.
Observed log fragment:
TokenVerificationError: Capability token for node ‘1’ has an invalid signature.The runtime does not attempt recovery. Execution halts.
These scenarios illustrate what execution containment enforces:
A node cannot execute unless its scoped capability is valid.
A capability cannot be reused outside its declared graph.
A capability cannot be reused outside its session.
A capability cannot be altered without detection.
What is prevented here is structural deviation from a declared trajectory.
What is not prevented is semantic misuse inside an approved graph. That distinction is intentional and explicit.
What Execution Containment Does Not Solve
Execution containment enforces structural boundaries on runtime authority. It does not evaluate the meaning or safety of what flows through those boundaries.
The distinction matters.
Execution containment ensures that only nodes declared in a validated graph G may execute during session S. It does not determine whether the declared graph itself is appropriate.
If a plan contains:
Read_Customer_DB → Send_External_Email
and both tools are valid and the graph is acyclic, execution containment alone will not reject the plan. The runtime enforces structure, not intent.
This model does not:
Inspect tool arguments or outputs.
Track data sensitivity across nodes.
Enforce information flow policies.
Detect prompt injection.
Prevent semantic data exfiltration inside an approved graph.
Authenticate the identity claim of the submitting agent.
Protect against a compromised host environment.
Prevent direct invocation of tool functions outside the enforcement boundary.
These are separate engineering problems.
Execution containment addresses a specific layer: binding runtime authority to a declared trajectory.
It is a necessary layer in agent security. It is not a sufficient one.
Deterministic infrastructure cannot safely rely on probabilistic planners without structural boundaries. Execution containment provides one such boundary. It does not replace other controls.
Why Determinism Matters
Agent systems combine two fundamentally different domains.
Reasoning is probabilistic.
Infrastructure is deterministic.
A language model samples tokens from a probability distribution. Its internal state evolves based on prompts, retrieved context, and prior outputs. Its next action is not fixed. It is inferred.
Infrastructure does not operate that way.
A database either executes a query or it does not.
An email is either sent or it is not.
A workflow either triggers or it does not.
There is no partial send. There is no probabilistic write.
When probabilistic planners are given deterministic authority, a boundary must exist between reasoning and execution.
Without a boundary, infrastructure implicitly trusts that the trajectory of a probabilistic system will remain aligned with its declared intent. That trust is structural, not earned.
Deterministic enforcement changes the posture.
It does not attempt to predict the planner’s behavior.
It does not attempt to correct the planner’s reasoning.
It does not assume compliance.
It verifies structure at the point of execution.
Execution containment does not make agents correct. It makes their authority explicit and bounded.
This distinction is subtle but important.
Security guarantees must be binary at the enforcement boundary. Either a node is authorized under the declared graph for this session, or it is not.
If the enforcement layer itself becomes probabilistic, the guarantee dissolves into heuristics.
Deterministic containment is not a complete answer to agent security. It is a prerequisite for building higher layers without relying on trust in the planner.
The planner may remain stochastic.
The boundary must not.
Closing
Tool-using agents introduce a new kind of authority into software systems.
A probabilistic planner is now capable of invoking deterministic infrastructure. Once side effects enter the picture, structural enforcement becomes necessary.
Execution containment addresses one layer of this shift. It binds runtime authority to a declared, validated trajectory. It does not reason about intent. It does not inspect content. It does not attempt to make the planner safe.
It enforces structure.
Without such a boundary, infrastructure implicitly trusts that a non-deterministic system will behave as declared. With execution containment, that trust is replaced by verification.
This is not a complete security model for agent systems. It is a primitive.
If agents are to operate with real authority, the systems that host them require deterministic boundaries at the point of execution.
Reference implementation:
Caltrop v0.1 — https://github.com/SpaceCypher/Caltrop