DEFINITION

WHAT IS EXECUTION-LAYER SECURITY?

Execution-layer security is control over what an AI system does, applied at the point where its decision becomes a real action. It sits after the model has produced output and before an API call, a database write, a payment or a message actually happens. Every proposed action is checked against policy first, and the action does not execute until it has been checked.

Mountain Theory set out this problem in a white paper published on 1 November 2024, independently archived by the Internet Archive on 7 November 2025.

Where the execution layer sits

An agentic system runs in a straight line. A person or a trigger provides input. The model reasons. The model requests a tool or an action. That action reaches a real system and something changes in the world.

The execution layer is the last step before the world changes. Almost all AI security operates earlier than that, on the input or on the output, where the only thing available to inspect is language. By the time an agent is about to write to a database, the argument is over. What matters is whether the write happens.

Why it is not the same as filtering the prompt

Prompt filtering and output filtering read text and decide whether the text is acceptable. They are useful and they are not control. A filter can be argued with, because persuasion is exactly what a language model responds to, and once the model is convinced there is nothing left for the filter to catch.

An execution check never reads the argument. It reads the action. A request to read a credentials file is the same request whether the agent was jailbroken, manipulated through a poisoned document, or simply wrong.

Why it is not the same as access control

Authorization is the problem, not the protection. Identity systems decide in advance what an agent may do, and they decide it once. An agent that has been compromised or manipulated then acts inside exactly those permissions, which is why access logs show nothing unusual while something is going badly wrong.

The unanswered question is not what this agent is allowed to do. It is whether this particular action should happen right now, given what else has occurred. That question can only be asked at the moment of execution.

What it looks like in practice

Three outcomes, evaluated per action, before the action runs.

• ALLOW. The action is within policy. It proceeds and it is recorded.
• HOLD. The action needs a human. It waits, and a person decides. This is an option an organisation switches on where it wants one, not a requirement of the model.
• BLOCK. The action is refused and never reaches the system it would have touched.

Every outcome is written down with who, what, when and why, because an execution record that cannot be audited is not evidence of anything.

The evidence

Two published runs, both recorded, both naming the third-party technology involved.

The same 10 actions, three configurations. Ungoverned, 10 of 10 executed. Under NVIDIA OpenShell alone, all 5 sandbox-boundary crossings were denied at the kernel and all 3 in-bounds bad decisions still went through, including a secrets read that printed credentials to the screen. Under OpenShell plus Mountain Theory, those same 3 returned HOLD, HOLD and BLOCK, and the credentials never printed. Read the run.

Behaviour nobody had seen before. A third-party provider updated the foundation model driving an autonomous agent. Nothing on our side changed. The agent began attempting multi-step actions it had never tried, and every attempt was stopped on the days the behaviour first appeared. No new rule, no signature, no patch. Read the drift event.

And a prediction, made before the events. In November 2024, two years before this page existed, our white paper argued that access control would not help once an AI already held the permissions: “Role-based access control and such do not suffice when the AI model has already been granted access… most cybersecurity defenses are focused on network access, rights, permissions, and inappropriate sending of data. This does not trigger when the AI model already has such access and is allowed to perform these things.” Read the 2024 white paper.

We wrote the same argument up against what actually happened: In 2024 we said permissions would not save you.

How to evaluate anyone claiming it

Ask every vendor for the same four things and put the answers side by side.

1. The action set. Exactly which actions were attempted, in what order.
2. The control condition. What happened with nothing in the path, so there is a baseline.
3. The outcome for every action, including the ones the product did not stop.
4. The recording or the log.

We publish all four, including the actions Mountain Theory has no policy for. Apply the same test to us. Compare Mountain Theory against 58 companies.

Common questions

What is execution-layer security?

Execution-layer security is control over what an AI system does, applied at the point where its decision becomes a real action. It sits after the model has produced output and before an API call, a database write, a payment or a message actually happens. Every proposed action is checked against policy first, and the action does not execute until it has been checked.

How is execution-layer security different from AI guardrails?

Guardrails inspect language, execution-layer security inspects actions. A guardrail reads the prompt or the response and decides whether the text is acceptable. It has no view of what the system is about to do. Execution-layer security does not care how the model was persuaded, because it evaluates the action itself against policy. The two operate at different layers and are not substitutes for one another.

Does execution-layer security stop prompt injection?

It stops what prompt injection is trying to achieve. An injection succeeds when it convinces the model to do something, so any control that reads text can be argued with. An execution check evaluates the action that results, not the argument that produced it. If a manipulated agent proposes an action policy does not allow, the outcome is the same whether the agent was compromised, confused or working exactly as designed.

Is execution-layer security the same as identity and access management?

No, and the gap between them is where most autonomous AI risk lives. Identity controls decide what an agent is permitted to do, once, in advance. A compromised or manipulated agent then uses exactly those permissions, so access controls see nothing unusual. Execution-layer security asks a different question at a different moment: not what is this agent allowed to do, but should this specific action happen right now.

Does execution-layer security work with any AI model or framework?

It should, and that is a fair test to apply to any vendor claiming it. Control that attaches to one provider's API stops working the moment an institution self-hosts a model or swaps frameworks. Mountain Theory governs the action rather than the API, so it reaches hosted models, open weights, custom agents and research code alike, and it does not need to know which model produced the decision.

How do you prove execution-layer security actually works?

By running the actions and publishing what happened, including the ones that were not stopped. Ask any vendor for four things: the exact action set attempted and in what order, the ungoverned control condition so there is a baseline, the outcome for every action including the failures, and the recording. A vendor publishing all four is making a checkable claim. A certification, an integration list or a customer logo answers a different question.

More questions answered.