GovernorAIby SentinelLayer Request a briefing
Find and qualify
Discovery & Shadow AIInventory the AI activity nobody registered AssuranceEvaluate an agent snapshot before production
Decide and enforce
Policy & GovernanceKeep the policy engine you already run Runtime EnforcementDecide at the action boundary Inference & Model GovernanceGovern the model call itself Multi-cloudOne policy, each cloud's own controls
Prove and observe
Evidence & ComplianceTamper-evident record, mapped to controls Decision ObservabilitySee the decision behind the action
Risk and security
RiskScore the action, and act on the score ContainmentStop a runaway run before it lands Security architectureHow the control plane itself is built
By persona
SecurityPer-call authorization and stop controls GRCEvidence chains and control mapping Platform & AI EngineeringGovern without touching the agent
By risk
Shadow AIUnmanaged agents and connections Data leakageIn prompts, completions and tool calls Destructive actionsChanges to systems of record
By platform
AWS BedrockInbound path, guardrail attachment ServiceNowNow Assist discovery and scoped control SalesforceAgentforce and Einstein Bots, in-org MCPRegistry, proxy, argument-aware inspection
By cloud and runtime
AzureConnect, discover, govern at the gateway Google CloudValidated connect mode, bootstrap session DatabricksCluster-side egress, pinned at create Kubernetes & sidecarIn your cluster, on the agent host

Developers / Benchmark

Sidecar enforcement latency, with the method that produced it.

Policy evaluation in the sidecar deployment model is CPU-bound: the decision never leaves the host. This page publishes that measurement together with the conditions that produced it, because a latency figure without its method is not evidence.

Sidecar topology only Method stated before the number Not a platform-wide SLA

SCOPE

What this figure is, and is not.

Stated first, deliberately, because the same number is misleading one topology over.

It is

Policy evaluation latency measured in the sidecar deployment model, where the engine runs alongside the agent on the same host and the decision path involves no network round-trip.

It is not

  • A service-level guarantee. It is a measurement under stated conditions, not a commitment.
  • A figure that transfers to other seams. A gateway adapter, a transparent MCP proxy or an HTTP forward-auth hop each add their own cost, on their own path.
  • A comparison against other products. Nothing here is measured against another vendor, so nothing here claims to beat one.

METHOD

The conditions a figure has to carry.

This is the contract this page will publish against. It is here before any number, because a latency figure whose conditions arrive afterwards is a marketing claim wearing a lab coat.

Condition
What will be stated
Deployment topology
Sidecar. The policy engine runs on the same host as the agent; evaluation is CPU-bound and no policy decision crosses the network. Fixed — this is the only topology this page will ever describe.
Hardware
Instance type or machine spec, vCPU count, memory.
Runtime
OS, kernel, container runtime, and the GovernorAI build identifier the run was produced on.
Policy set
Rule count, rule complexity, and whether the engine was embedded or a remote OPA.
Payload
Tool-call payload size, argument count, and whether arguments were inspected on the measured path.
Concurrency
Concurrent in-flight evaluations sustained during the run.
Sample size
Number of evaluations, run duration, and whether the run was warm or cold.
Measurement boundary
Whether the figure covers policy evaluation alone or the adapter hop as well. Network transit is excluded by construction in this topology.

RESULTS

No figure is published yet.

A load harness exists in the product repository and runs the sidecar policy-evaluation path. What it does not yet have is a run recorded under stated conditions that we are willing to put a number behind in public.

What exists
Status
Load harness
In the product repository, with a policy-evaluation scenario against the gateway execute path.
The threshold it enforces
The harness fails a run at a p99 above 100 ms, an error rate above 1%, or throughput under 80% of the configured target. That is a regression gate, not a performance claim.
A lower design target
The harness also carries a lower figure as a design target in its scenario description. A target is an intention, and this page does not print intentions as though they were results.
p50 · p95 · p99 · max
Will be published together, from one run, with every condition above filled in.

The percentile belongs in the headline. “Sub-10 ms” means nothing until it says whether that is p50 or p99 — and p99 is the number an SRE will ask for.

WHAT WAS WITHDRAWN

The figures that used to be here.

Honesty note

An earlier draft of this material published a per-stage breakdown — policy lookup, context retrieval, decision logging — totalling 4–9 ms, alongside a comparison claiming 50–500 ms for “traditional cloud enforcement”. Neither carried a method, and the comparison named no product it was measuring. Both were withdrawn rather than restated, and the breakdown is not reproduced here even as an estimate: republishing an unsourced number in a smaller font is still republishing it. When a measured run exists, the breakdown returns with the same conditions attached as the headline figure.

Continue

IntegrationsEvery seam, and what each one costs Runtime EnforcementDecide at the action boundary QuickstartA first governed tool call