Built to drop into the stack you already run.
The questions a CTO, CISO, Head of AI, or risk committee asks after the live demo — how it integrates, how fast it is, how configurable it is, what happens across agents, and where to start. Answered directly, without overstating what has been measured.
Enterprise Integration
Runtime Governance is a pre-execution check at your tool-dispatch boundary. Your agents, planners, and models stay exactly as they are.
- No model retraining
- No fine-tuning required
- Model-agnostic
- Sits between planning and execution
- Existing agents unchanged
Integration patterns by stack
The hook is the same everywhere — evaluate the proposed tool call(s) before dispatch. These are integration patterns at the execution boundary, not vendor-certified plugins.
Gate function/tool-call dispatch: pass the proposed tool calls to the governance check before the runtime executes them.
Insert a governance node before the tool node; route on the verdict (continue on ALLOW, interrupt on BLOCK/ESCALATE).
Guard the AgentExecutor's tool invocation — a pre-tool callback/guard that runs before `tool.run`.
Evaluate proposed tool calls in the agent's execute step before function execution proceeds.
Evaluate the tool call at the MCP client/host before it is forwarded to the MCP server.
Call the governance API at your plan → act boundary; proceed only on ALLOW.
One pre-dispatch check in your tool router: deny on BLOCK, route to a human on ESCALATE.
from morrison_governance import GovernanceLayer, OmegaDomain
# 1. Initialise the layer once, with your Ω domains.
gov = GovernanceLayer(
domains=[OmegaDomain.FINANCE, OmegaDomain.CYBERSECURITY,
OmegaDomain.DATA_PRIVACY],
)
# 2. Evaluate the planner's proposed tool plan BEFORE execution.
result = gov.evaluate_plan(proposed_tool_calls)
# 3. Gate execution on the verdict.
if result.blocked:
raise GovernanceError(result.reason) # BLOCK / ESCALATE — never executes
execute(proposed_tool_calls) # PERMIT — safe to runOr call the governance HTTP service from any language. Copy-paste runnable examples (HTTP, LangChain, LangGraph, MCP): examples/ on GitHub ↗ · integration patterns.
How much work for my team? A single pre-execution check at the point where your agent dispatches tools. No changes to the model or the agent's reasoning.
Operational Performance
Governance runs before the tool executes, as lightweight middleware. The decision returns before any action is taken.
The verdict is computed and returned before the tool call runs — not after the fact.
A bounded evaluation over the proposed trajectory; no model inference in the governance path.
Runs the same whether the planner is a 7B or a frontier model — it evaluates the trajectory, not the weights.
Runtime cost scales with the number and shape of proposed steps, not LLM parameter count.
| Evaluation class | p50 | p95 | p99 | avg | throughput |
|---|---|---|---|---|---|
| Single-step | 0.3865 ms | 0.4183 ms | 0.4766 ms | 0.3902 ms | 2,563/s |
| Short (2 steps) | 0.9655 ms | 1.0063 ms | 1.0501 ms | 0.9694 ms | 1,032/s |
| Medium (4 steps) | 3.0308 ms | 3.1253 ms | 3.29 ms | 3.0419 ms | 329/s |
| Long (8 steps) | 7.025 ms | 7.1728 ms | 7.2723 ms | 7.0318 ms | 142/s |
| Very long (16 steps) | 14.9333 ms | 15.2072 ms | 15.6601 ms | 14.9658 ms | 67/s |
| Multi-agent (joint) | 2.0286 ms | 2.0929 ms | 2.2181 ms | 2.0359 ms | 491/s |
Measured on Linux-6.17.0-1022-azure-x86_64-with-glibc2.39 · Python 3.12.14 · 4 logical CPUs, single-threaded. Single-threaded, measured on this CI/build environment. Representative figures, not a production-hardware guarantee.
Latency Summary
Runtime Governance has been benchmarked at microsecond-scale latency, with benchmark averages typically around 0.1 ms per evaluation depending on trajectory length and rule count.
Across representative deployed-service evaluations, observed governance evaluation times have remained sub-millisecond, with sampled evaluations observed up to approximately 0.4 ms.
The governance layer therefore operates at a timescale that is typically negligible relative to model inference, tool execution, database operations, and network latency.
GovernanceLayer.evaluate_plan, warm-up then per-call timing, percentiles from the sorted sample. Re-run governance-service/benchmark.py on target hardware for deployment figures.Will this slow my production systems? No — on the benchmark environment a typical trajectory is evaluated in well under a millisecond (single-step p50 0.3865 ms), and cost scales with trajectory and rule count, not model size. These are measured figures; production latency depends on your host and transport.
Domain-Specific Governance
The enforcement invariant is fixed; the forbidden region Ω is configurable for your domain and policies.
- Unauthorized transfers
- Fraud states (structuring, velocity)
- Regulatory violations
- PHI disclosure
- Unsafe treatment / clinical states
- Credential exfiltration
- Privilege escalation
- Shell / command injection
- Customer-data leakage
- Unauthorized actions
- Internal artifact egress
Finance, cybersecurity, healthcare, data-privacy, enterprise, compliance and fraud Ω rule sets are implemented in the live engine today. Eight further target sectors — insurance, government, supply chain, energy, telecommunications, manufacturing, aerospace and defence — now have executable Ω rule sets authored and verified (BLOCK/PERMIT suites), rolling out to the live engine. See the live demo to evaluate against the live domains.
Can this work in my environment? Yes — the mechanism stays constant while you define Ω from your own regulatory and operational policy. New domains are added as rule sets, not as engine rewrites.
Multi-Agent & Orchestration Governance
Harm often appears only in the combination of actions across agents — never in any single step. Runtime Governance evaluates trajectories, not isolated actions.
What happens when multiple agents interact? Their steps are flattened into one joint trajectory and governed together — shared-memory, delegation, and cross-agent chains are evaluated as a whole, not as isolated, individually-innocent actions.
48-Hour Runtime Safety Assessment
The standard first engagement. A scoped review of your agent environment — no deployment commitment required.
- What would be blocked in your environment today.
- What would be allowed.
- What risks exist in your current agent architecture.
- Whether a runtime-governance implementation makes sense for you.
Why buy the assessment first? It turns an open question into a concrete, evidence-based map of your exposure — and you keep that assessment regardless of whether you deploy.
Trust the boundary, not the promise.
Run the live console, then have us evaluate your own agent architecture.