Morrison Runtime Governance: A Bounded Reproduction

Morrison Runtime Governance evaluates an agent’s proposed action and can issue a lease for a separate executor to verify. The lease becomes an execution boundary when that executor controls the only usable route to the resource. Resurrection Tech built Morrison; its founder is Davarn Morrison.

The kernel checks individual actions against policy and governed history. The public finite-model experiments exclude configured unsafe states in some scenarios. Other synthetic models contain unsafe paths despite PERMIT decisions. The repository leaves complete mediation to the deployment that holds credentials and closes alternate routes.

We checked commit fba06b75dd6b16fb6e093364eee67359afa3942b on 7 October 2026. We reran the quickstart, selected tests, finite verifier, and offline adversarial script. The work covered repository-supplied models and mocks; it did not include a deployed gateway or real resource.

The property under test

In the repository’s secret_exfiltration model, a secret read and an external post are distinct actions. A local check evaluates one proposal in its current state. A global check evaluates the resulting trajectory, including the earlier read and pending actions. The finite graph shows whether governed transitions reach its declared exfiltration state. Real file and network paths require a separate deployment inventory. Concurrent proposals need an atomic reservation or shared update so both cannot evaluate against the same stale prefix.

An unpublished technical note supplied for this review writes local admissibility as L(a, s, P), with frozen action a, state s, and policy P. It writes the history-sensitive check as G(a, s, h, P), where h includes relevant pending actions. The finite verifier enumerates declared transitions offline. The runtime kernel evaluates policy against the governed trajectory online. These are separate mechanisms with separate costs and guarantees.

A consequential effect must depend on authorization from an authority the proposing agent cannot rewrite or bypass. The NIST reference-monitor definition calls for complete invocation, tamper resistance, and verifiability. Schneider’s execution-monitor work established that some trace properties can be enforced by stopping the first violating step. Both precede Morrison’s implementation.

We use three separate questions throughout this review:

• Envelope completeness: Did the model name the relevant states, effects, and forbidden outcomes? It fails when a harmful effect falls outside the declared state or policy model.
• Decision soundness: Does the authority decide correctly for a proposal it receives? It fails when a modeled forbidden effect receives PERMIT.
• Mediation completeness: Must every consequential effect pass the authority? It fails when another credential, executor, or network route reaches the resource.

The finite models can test envelope and decision failures. Mediation requires examining the installed routes and credentials, as Morrison’s complete-mediation analysis explains.

Where Morrison places authority

The agent proposes a structured action. Morrison’s GovernanceKernel.authorize evaluates that proposal against configured rules and governed history, returning PERMIT, ESCALATE, or BLOCK. A permitted decision can mint an ExecutionLease bound to the action and identity. A LeaseVerifier can sit in a gateway, sidecar, or tool server and reject a request without a valid lease.

The verifier can turn a library verdict into an enforced decision when it runs outside the agent’s process and controls the resource route. A direct API key or open network path would bypass that verifier. Morrison’s deployment checklist therefore calls for credential isolation, resource-side verification, restricted egress, protected policy state, and effect reconciliation.

The public browser console accepts proposed trajectories and displays decisions. Its repository documentation says the console does not execute the submitted workflow or expose production credentials.

Follow one request through the stack

The repository is more specific than “run a safety check before a tool call.” Consider an agent proposing http_post with a destination and payload. The following stages are visible in the pinned GovernanceKernel implementation:

1. Capture the proposed action. The kernel canonicalizes the tool name and arguments and computes an action_hash for the exact action that may execute. It separately computes a semantic_action_hash over a normalized tool family and content. The distinction matters: an executor must not swap the actual request after authorization, while policy should recognize equivalent spellings of a destination or tool. The canonicalization code makes both identities explicit.
2. Separate claims from authority. Agent-supplied fields that look like approval or destination facts are quarantined as untrusted input. Capability classification, destination resolution, and approval verification use the server’s context. A string such as approved: true in a proposal cannot create an approval artifact. The kernel still examines quarantined content for destinations and sensitive material, because removing it from authority must not make it invisible to risk classification.
3. Evaluate the action and its prefix. Capability policy can deny, require a verified approval, or require a principal grant. The trajectory engine receives the executed history plus the candidate action. Additional checks cover undeclared tools, sensitive external egress, external egress after a data read, prior denied reads, and missing continuity. PERMIT, ESCALATE, and BLOCK therefore express different outcomes; escalation is not execution authority.
4. Reserve before dispatch. A permitted execution decision can reserve its place in the history. This matters for cumulative limits: two simultaneous actions should not each see the same unused capacity. The strength of that guarantee depends on the continuity store being shared and atomic at the scope the deployment claims. A process-local lock does not serialize separate workers.
5. Bind permission to one request. The lease format and verifier bind a signed, expiring token to an action hash, semantic hash, principal, tenant, session, decision, and tool family. The resource-side verifier checks the signature and expiry and can recompute the action hash from the request it is about to forward. Its redemption store must be shared and atomic if more than one verifier instance exists.
6. Record what happened. The evidence chain links decision records by hash and appends a separate execution record. If an in-process executor raises after dispatch, Morrison treats the effect as possibly landed. unconfirmed() and reconcile() provide a way to record later attestation. A hash chain exposes edits to records it has; it does not detect a resource effect that never passed through the system.

The authority-separation documentation assigns proposal, decision, and execution to separate components. The executor needs custody of the resource credential and control of the route that carries the effect.

Where the implementation boundary matters

LeaseVerifier.verify(token, request=None) permits a caller to omit the request argument. The verifier then checks the lease without matching it to the forwarded action. A gateway must pass the actual request it will forward and must not substitute another one after verification. A locally “single-use” lease also needs a shared atomic consume store across verifier replicas; each replica’s private seen set leaves the token usable elsewhere.

The history boundary is equally concrete. A policy such as “never export after a sensitive read” depends on which reads count, how session or principal identity is carried across workers, and whether a released reservation or retried call changes the recorded prefix. The offline release counterexample below shows why lease lifecycle and trajectory lifecycle must agree. A result from the decision engine alone does not settle that composition.

What we reproduced

We used Python 3.13.15 for the quickstart and CLI experiments, and an isolated Python 3.12.14 environment with pytest 9.1.1 for the selected tests. We set PYTHONIOENCODING=utf-8 because the quickstart’s box-drawing characters raised a Windows UnicodeEncodeError under the default console encoding. The rerun then completed. Commands were executed from the pinned repository root; they require no model key.

The quickstart completed. Its built-in graph reported two unsafe control states, no unsafe governed states, and three removed transitions. The selected mediation, authority, veto, finite-verification, falsification, and provenance tests returned 154 passed in 7.39 seconds. We did not run the whole repository suite.

The control-versus-governed verifier gave these results:

• secret_exfiltration: eight control states, two unsafe; three governed states, none unsafe; SAFE_WITHIN_MODEL.
• privilege_persistence: seven control states, four unsafe; one governed state, none unsafe; SAFE_WITHIN_MODEL.
• governance_bypass: 16 control states, 15 unsafe; one governed state, none unsafe; SAFE_WITHIN_MODEL.

The --perturbations run returned SAFE_WITHIN_MODEL for four variants. Its variant with monitoring already disabled returned UNSAFE_COUNTEREXAMPLE_FOUND at distance zero. The --composition-experiment run reported no new unsafe path in the supplied composition and returned SAFE_WITHIN_MODEL.

The first three scenarios exhaust their declared state graphs. The reachability results apply to those graphs. The disabled-monitoring perturbation supplies a negative control: the verifier reports an unsafe initial state. The global-verification guide also defines an INCONCLUSIVE outcome when enumeration cannot complete.

We also ran python docs/prior-art/reproduce_adversarial_2026_10_05.py. Seven investigator-supplied synthetic model variants had fully enumerated unsafe paths made entirely of PERMIT decisions. The investigator supplied each transition function and forbidden predicate. A permit for the normalized proposal did not certify the effect attached to it in those variants. The repository’s falsification report documents the same scope.

The same offline script minted a lease for a permitted query_db read, released that decision from the local ledger, and then had a LeaseVerifier accept the released lease. With that history cleared, a later external http_post received PERMIT. Inert list appenders recorded both mock effects. Two verifier instances also accepted one token when they lacked a shared consume store. The reproduction used local mocks to test lease cancellation and redemption; no deployed gateway was involved.

To reproduce the core observations at the pinned commit:

python quickstart.py
python -m pytest -q morrison_governance/test_mediation.py morrison_governance/global_verification/test_aoe_falsification.py morrison_governance/test_authority_continuity.py morrison_governance/test_governed_execution_veto.py morrison_governance/global_verification/test_global_verification.py morrison_governance/global_verification/test_provenance.py -k 'not slow'
python -m morrison_governance.global_verification --scenario secret_exfiltration --compare-control
python -m morrison_governance.global_verification --perturbations
python -m morrison_governance.global_verification --composition-experiment
python docs/prior-art/reproduce_adversarial_2026_10_05.py

The other two control-versus-governed commands use --scenario privilege_persistence and --scenario governance_bypass. Counts can change with the repository, policy configuration, or test environment; retain the commit and output when comparing results.

Comparing the enforcement boundaries

A text or model-facing guardrail can catch a suspicious instruction before tool use. Morrison checks structured proposals against governed history and can require a signed lease at the resource. That lease controls the effect only across routes where the executor demands it. The classifier also needs to capture the relevant consequence of each action.

Safe Multi-Agent Reinforcement Learning via Shielding describes centralized and factored shields that correct unsafe joint actions in a bounded environment. Morrison carries authorization toward a tool or resource boundary and records history along that path. Both results depend on the transitions their respective executors mediate. Neither paper-level result establishes credential custody for an arbitrary deployed agent.

CaMeL extracts trusted control and data flow before enforcing policy at tool calls. FIDES uses information-flow labels in an agent planner. CaMeL can track whether untrusted content influenced the proposed action; Morrison’s lease can bind a downstream executor to the exact request authorized. These mechanisms can operate together. Their coverage follows the tools and effects brought inside each runtime or resource boundary.

AWS AgentCore documentation describes gateway policies over session history, including an external-call denial after sensitive data access. Its outbound authorization documentation places target credentials at the gateway. History-sensitive decisions and credential-bearing gateways therefore already coexist in published architecture. Morrison provides inspectable leases, finite control-versus-governed models, and adversarial scripts. A containment comparison would need matching tools, policies, and alternate routes in deployed systems.

An operating-system sandbox or network policy constrains the sockets and files available to the agent process. Morrison evaluates the meaning and sequence of declared actions before execution. Network isolation closes raw routes around a semantic gate; the gate can enforce a cumulative business limit that a network policy cannot express.

Morrison packages trajectory-sensitive decisions, reservations, action-bound leases, resource-side verification, decision evidence, and finite comparisons in an inspectable repository. Its 6 October prior-art correction withdraws one earlier complete-match reading. The narrow autonomous-agent novelty question remains unresolved.

From library to an actual governance stack

The repository’s M1–M7 mediation conditions provide a deployment acceptance test. Inventory consequential resources, move their credentials to executors, and require verification before forwarding. Deny alternate egress from the agent. Keep policy and lease keys outside its write access. Collect effect receipts from the resources so bypasses can appear in the audit.

The continuity store, lease verifier, and effect ledger need the same principal and transaction identity. A global limit covers only the workers and resources sharing that state. Releasing a reservation or revoking authority must invalidate its lease; redemption must be atomic across replicas. The verifier must check the exact request it forwards, then reconcile the resource receipt against the decision.

The industry-wide case is in Can the Agent Bypass the Gate?. Morrison’s public tests cover decisions and leases; unavoidable execution authority would require the executor to hold the only credential and every protected route to pass its verifier.

                  @article{kalaris2026_morrison_agent_execution_boundary,
  title = {Morrison Runtime Governance: A Bounded Reproduction},
  author = {Chowdhury, Sayan},
  journal = {Kalaris Labs Research Notes},
  year = {2026},
  url = {https://kalarislabs.com/research/morrison-agent-execution-boundary}
}