By Miller Technology Group (opens in a new tab) · Published · Updated
The definition
Governed execution is the control layer between an authorized request and a consequential change to a real system. It applies resource context, policy, and validation before an operation runs, bounds how that operation is carried out, verifies the resulting state, and preserves evidence of what happened.
Why the category separated out
For most of the history of enterprise IT, the thing on the other end of a credential was predictable. A deployment pipeline did what it was written to do. A person at a terminal could be asked afterwards what they were thinking. Under those conditions, governing access was a reasonable proxy for governing consequence: decide carefully who gets the credential, and the rest largely follows.
AI agents broke the proxy. An agent's behaviour is not fully predictable in advance, not reliably reproducible, and not explainable by reading a script — and it now arrives holding a credential and a set of tools. The question stopped being who may hold this authority and became what may be done with it, on which resource, under what conditions, and how would we know afterwards.
That question has no natural owner. Identity systems answer who. Policy engines evaluate rules, usually without knowing much about the target. Automation platforms execute, and report success by exit code. Audit systems record what they were told. Each covers part of the path, and the gap between them is where an authorized intent becomes a real change — which is exactly the part nobody was governing.
That gap is now being approached from several directions. Identity platforms are extending to non-human callers, gateways authorize individual tool calls, and runtime authorization evaluates an action against policy at the moment it is attempted. These are real controls, and governed execution does not replace them. What it adds is everything bound to the resource: a decision about a specific operation on a specific target, execution through a capability no wider than that operation, an independent look at the resulting state, and a record that connects all of it.
Three questions, not one
The single idea underneath the category is that these are different questions, asked at different moments, and that answering the first tells you nothing about the other two:
- Access governance and tool authorization ask
May this identity reach the system, or invoke this tool?
- Execution governance asks
May this specific operation execute against this specific resource under current conditions?
- Outcome verification asks
Did the intended state actually result?
A yes to the first is a statement about the caller and the call. A yes to the second is a statement about the change. A yes to the third is a statement about the world. Incident reviews and the person who owns the affected service are asking the second and third — which is why AI agent governance that stops at access leaves infrastructure automation ungoverned at exactly the point it matters.
Governed execution is the second and third together: a platform that decides on the specific operation, and then checks the result.
“It worked” is four separate facts
Conventional tooling collapses these into one word. Any one of them can be true while the next is false, and the false one is usually the one that mattered.
Four separate questions about a change. One: is it allowed, established by policy and approval. Two: did it run, meaning the operation executed. Three: did anyone look, meaning the result was observed afterwards. Four: is it now right, meaning the resource matches the intent.
Why resource-native matters
A governed execution platform has to be able to reason about what is being changed, and that constrains how a request can be expressed. A command string cannot be reasoned about: systemctl restart api is text until it runs, and by the time its meaning is established it has already taken effect.
Modelling the resource instead — a named service, container, file, or configuration entry, with a typed operation on it — is what makes every later control possible. Policy can decide on a specific target. An approval can be bound to precisely that request. Verification knows what to go and look at. And the record left behind describes the change rather than the keystrokes.
The trade is real and worth stating: a system with no provider modelling it is outside the boundary. A governed execution platform that quietly falls back to running arbitrary commands against unmodelled systems has given the guarantee back.
What it is not
Governed execution is adjacent to several established categories and is regularly mistaken for each of them. It is not an agent framework — it builds no agents and takes no part in how one reasons. It is not an identity platform, access manager, or agent gateway — it needs to know who is asking, works alongside whatever already answers that, and adds everything after the permission decision. It is not an automation, pipeline, or workflow tool — those decide what should happen and when; governed execution decides whether, how, and whether it worked. And it is not an audit product, because half of what it does happens before the change rather than after it.
The useful summary is that governance should not stop at the decision to act. It should extend through execution and verification.
Eight questions to ask of any governed execution platform
These are written to be useful against any platform in this category, including ones that are not resh. Where the current resh release fails one of them, that is stated on the limitations list rather than omitted.
What exactly is being authorized — an action, or an ability?
If the answer is a credential, a session, or a tool that can take an arbitrary command, the thing granted is an ability and its bounds are whatever that credential can reach. A platform in this category should grant a specific operation on a specific resource, and nothing adjacent to it.
What does policy actually see when it decides?
A policy engine handed an opaque string is pattern-matching. One handed a resolved resource — with its environment, criticality, declared risk, and current condition — is making a decision. Ask which one is happening, because the two look identical in a diagram.
Does permission to request imply permission to execute?
Teams need different views of the same infrastructure, and it is tempting to let a team’s workspace double as its authority. Ask whether being able to see a resource and request an operation through a team surface grants anything at execution time — and whether the system that executes decides independently of where the request came from.
Can an approval cover more than what was asked for?
An approval should be bound to the specific request — this resource, this operation, these arguments. Ask what happens to an existing approval when any of those change. “It still applies” is the wrong answer.
Where is policy enforced when the management plane is down?
If enforcement is central, an outage is either a total stop or a silent bypass, and neither is acceptable. If enforcement is local, the answer should be that nothing changes — which is also the answer to what a compromised management plane can make machines do.
How does the platform know the change worked?
An exit code, an HTTP 200, and a tool call that returned are transport signals. Ask whether anything goes back and looks at the resource, what it compares against, and what the platform reports for an operation it has no way to observe. “Assumed successful” is the wrong answer.
What does it claim to undo, and can it actually do that?
Undoing a change is the most commonly claimed and least commonly reliable capability in this space. A platform that stops honestly and tells you precisely what changed is more useful than one that attempts a recovery it cannot guarantee.
Can one person request and approve the same change — and what did they have to do to become an approver?
If being able to request an operation, or simply being signed in, is enough to approve one, then an automated caller inherits approval authority by accident. Ask where approval authority is granted, and whether the record afterwards distinguishes who asked from who approved.
The vocabulary
The terms this page and the rest of the site use precisely.
- Governed execution
- The control layer between an authorized request and a consequential change to a real system. It applies resource context, policy, and validation before an operation runs, bounds how the operation is carried out, verifies the resulting state, and preserves evidence of what happened.
- Purpose-scoped Application
- A purpose-oriented management surface over resources in one governed estate — a team’s area of responsibility such as Security Operations or Deployment Operations. Application permissions decide who may inspect resources and request operations through that purpose. An Application is not a tenant and carries no execution authority, and a resource may belong to more than one.
- Runtime governance
- The canonical policy decision made by the runtime on the managed server that owns the resource, at the moment of execution. It is evaluated independently of how the request arrived, so permission to request an operation through an Application never substitutes for permission to execute it.
- Resource-native execution
- Modelling the actual enterprise resource and a typed operation on it — a service, a host, a configuration, a secret — rather than an opaque command string or tool call. Policy and execution then share one understanding of the target, the operation, and the expected outcome.
- Controlled execution
- Carrying out an approved operation through a bounded provider capability instead of a general-purpose execution surface, so the authority granted to an autonomous caller stays limited to the operation that was actually governed.
- Execution verification
- Evaluating the resource state that resulted from an operation, independently of whether the underlying call returned success. A zero exit code or an HTTP 200 is a transport signal, not proof that the resource reached the intended state.
- Execution evidence
- The durable, structured record connecting the original request and actor to the policy decision, the executed operation, and the verified outcome, so the sequence can be reconstructed afterwards for operations, audit, and incident review.
For how one implementation answers these questions in practice, the governed execution lifecycle follows a single service restart through every step, the security model states the rules the architecture is derived from, and the design partner program is how to test it against an operation of your own.