Technology

Admissible Operating Envelopes, enforced at runtime.

A global claim that an autonomous system is “safe” is too broad to operate on. Morrison evaluates safety locally: in a specified environment, with specified tools, permissions, policies, state transitions, and reachable consequences. That bounded operating region is the Admissible Operating Envelope.

Admissible Operating Envelope

Define where safe autonomous operation ends.

An Admissible Operating Envelope is the set of states, actions, transitions and operating conditions that a system is permitted to occupy or execute within a defined environment. It is scoped to the actual environment — the agents, tools, permissions, policies, trajectory horizon, and reachable states in front of us — not to an abstract universal claim about the underlying model.

Environment defines envelope
Transition proposed
Runtime Governance
ALLOW
Environment defines envelope
Non-admissible / Ω-bound transition
Runtime Governance
BLOCK / ESCALATE

Local safety is a bounded claim: what this system can safely reach, in this environment, under these constraints.

Before execution

Most safety reacts. Governance enforces the boundary.

Traditional AI safety often inspects outputs or incidents after the system has acted. Runtime Governance evaluates the proposed trajectory before execution and decides whether it remains inside the Admissible Operating Envelope.

After-the-fact control
01 Output generated
02 Action taken
03 Boundary violation discovered later
VS
Runtime Governance
01 Trajectory evaluated
02 Envelope status determined
03 ALLOW / ESCALATE / BLOCK
AI Agent
Trajectory leaves envelope
Runtime Governance
BLOCKED
AI Agent
Trajectory remains inside envelope
Runtime Governance
Execution
Universal governance layer

The envelope is local. The enforcement layer is portable.

The Admissible Operating Envelope changes with the environment; the enforcement mechanism does not. Runtime Governance operates at the execution boundary, independent of model weights, architectures, providers, or training methods.

Provider-agnosticModel-agnosticAgent-framework agnosticDeployment-agnosticThird-party compatibleFuture-model compatible
Any provider · model · agent · system
OpenAIAnthropicGoogleMetaDeepSeekQwenMicrosoft PhiMistralGrokCustom ModelsThird-Party AgentsInternal Systems
Ω
Admissible Operating Envelope · Runtime Governance Layer
Morrison Runtime Governance™
Trajectory evaluation · Boundary enforcement · Pre-execution interception
Protected enterprise systems & data
Customer DataCRM SystemsBanking APIsEmail SystemsCloud InfrastructureInternal ToolsDatabasesAutonomous Workflows
Authorized trajectories inside the Admissible Operating Envelope pass through to your systems
Boundary-violating or Ω-bound trajectories are blocked or escalated pre-execution

Models will change. Tools and permissions will change. The local envelope can be revalidated without changing the enforcement architecture.

Methodology

Map, define, enforce, and revalidate the Admissible Operating Envelope.

Autonomous systems operate in changing state-spaces. Morrison turns that environment into a bounded operating claim that can be tested and enforced at runtime.

01 — IDENTIFY

Identify

Map the deployment context: reachable states, tools, permissions, policies, data flows, and Ω exposure.

02 — CONSTRAIN

Constrain

Define and validate the Admissible Operating Envelope and the boundaries proposed transitions must satisfy.

03 — EMBED

Embed

Integrate Runtime Governance at the execution boundary so every proposed action is evaluated before it runs.

04 — MONITOR

Revalidate

Revalidate the envelope as models, tools, permissions, policies, and the operational environment change.

The claim stays bounded to the environment. The boundary stays enforceable as the system evolves. Ω remains the forbidden region inside that geometry.

Admissible Operating Envelope Geometry

Local safety, expressed as reachability.

States are nodes. Transitions are edges. The Admissible Operating Envelope describes the region the system may occupy under the current environment and constraints. Runtime Governance evaluates each reachable path and denies transitions that leave the envelope or enter the forbidden Ω set — before execution.

Inside the Admissible Operating EnvelopeLocally admissible transitions propagate under the validated constraints.
Boundary violationTransitions leaving the validated region are blocked or escalated pre-execution.
Ω — forbidden regionStates the system must not reach. Constrained, contained, unreachable.
Boundary coverage

What can push a system outside its Admissible Operating Envelope.

Traditional security evaluates individual events. Runtime Governance evaluates the trajectory those events create and whether that trajectory remains locally admissible before execution.

Enterprise critical risks
Unauthorized Financial Execution

An agent moves money — a transfer, payment, or refund — outside approved limits or to an unverified destination.

PreventedThe transfer is denied before it executes, preventing irreversible financial loss.

Credential & Secret Exfiltration

An agent reads API keys, tokens, or secrets and routes them toward an external destination.

PreventedThe credential-to-external path is blocked before any secret leaves the boundary.

Data Leakage (PII / PHI / customer data)

Customer or regulated data is read and then sent beyond the approved boundary.

PreventedThe exfiltration trajectory is stopped before a notifiable breach can occur.

Privilege Escalation

An agent acquires permissions — for itself or another agent — beyond its authorised scope.

PreventedEscalation is denied before elevated access is ever granted.

Autonomous agent risks

Failure modes that point-in-time monitoring cannot see, because the danger only exists across the full trajectory.

Chained Multi-Step Attacks

Each step looks benign in isolation; the risk only appears across the full sequence. Event-level monitoring never sees the chain.

Cross-Agent Delayed Intent

Intent formed by one agent executes through another, later — breaking the cause-and-effect link monitoring relies on.

Silent Trajectory Collapse

The system drifts toward an unsafe state with no single alerting event. Nothing trips a threshold until it is too late.

Long-Horizon Agent Drift

Over many steps an agent migrates outside its original mandate — gradually, below the radar of point-in-time checks.

Advanced multi-agent boundary risks
Featured risk

Cascading Failures Across Agent Pipelines

Multiple individually safe agents can combine into an unsafe system.

Runtime Governance evaluates the full trajectory across the pipeline — not each agent in isolation — and denies the combined unsafe path before any agent acts.

Multi-Agent Collusion

Agents coordinate to achieve together what none could alone.

  • Collusive exfiltration
  • Role-split credential theft
  • Split unauthorized transfer
  • Tool delegation chains
Composite Cross-Domain Risk

Separate risk categories combine into one unsafe trajectory.

  • Financial execution + data exfiltration
  • Credential theft + privilege escalation
  • Multiple risk categories in one trajectory
Hidden-Trajectory Catastrophic Risk

An unsafe path that never surfaces as an obvious unsafe step.

Multi-Representation Forbidden-State Reachability

The same forbidden outcome reached through different encodings or tools.

Memory Contamination Between Agents

Unsafe state passed between agents through shared memory or context.

Existing controls watch individual events. Multi-agent systems can leave a safe operating region across the whole trajectory — which is exactly what Runtime Governance evaluates, before execution.
Plain-English clarity

The concepts, without the jargon.

Runtime Governance uses precise technical language. Here is what each core term means in plain English, so the boundary of the claim is explicit.

Admissible Operating Envelope
The set of states, actions, transitions and operating conditions a system is permitted to occupy or execute within a defined environment. It is a bounded deployment claim, not a universal claim that a model is safe.
Ω — The Forbidden Region
The set of states your AI must not reach. Ω sits inside the broader safety geometry as the explicitly forbidden region that governance makes unreachable.
Reachability
Whether your system can reach a given state from where it is now through available transitions. Governance uses reachability to test whether a trajectory stays inside the envelope or approaches a forbidden region.
Trajectory
The sequence of decisions, tool calls, or actions that lead your system from its current state toward an outcome. Governance evaluates the trajectory, not only the final action.
Runtime Constraint
A rule embedded directly in the execution path that prevents or escalates a prohibited transition before the tool call runs.
Pre-Execution Interception
Evaluating and governing an action before it happens — not detecting a boundary violation after the fact.
Invariant
A property that must remain true throughout execution — for example: 'This system will never authorise a payment above threshold X without human approval.'
Interactive demonstration

See an Admissible Operating Envelope enforced in real time.

Select a scenario. Runtime Governance evaluates the agent’s proposed trajectory before execution — trajectories inside the envelope flow through, while boundary- violating or Ω-bound paths are intercepted pre-action.

User requestTransfer £25,000 to unapproved account
Initialising governance evaluation…
Safety is enforced before execution, not after failure.
Want to test your own action chain — or don’t have an agent yet?Try the trajectory demo →Test without your own agent →
Next steps

Map the Admissible Operating Envelope in your environment.

Start with a live trajectory, then evaluate the real tools, permissions, policies, and reachable states that define the boundary for your deployment.

Try the Live Demo →Developer quickstartBook an Operating Envelope Assessment