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.0577 ms | 0.0675 ms | 0.0923 ms | 0.0591 ms | 16,920/s |
| Short (2 steps) | 0.075 ms | 0.0847 ms | 0.0903 ms | 0.0761 ms | 13,141/s |
| Medium (4 steps) | 0.1393 ms | 0.1536 ms | 0.2252 ms | 0.1423 ms | 7,027/s |
| Long (8 steps) | 0.2637 ms | 0.3078 ms | 0.4182 ms | 0.2714 ms | 3,685/s |
| Very long (16 steps) | 0.5305 ms | 0.5491 ms | 0.61 ms | 0.5326 ms | 1,878/s |
| Multi-agent (joint) | 0.1061 ms | 0.1163 ms | 0.1326 ms | 0.1079 ms | 9,268/s |
Measured on Linux-6.17.0-1018-azure-x86_64-with-glibc2.39 · Python 3.12.13 · 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.0577 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.