Platform · Runtime assurance
Govern360 receives observed runtime evidence from the OpenTelemetry collector you already run. It is not a hop in your request path, adds no latency, and cannot stop a call at request time. Every product that sees runtime by sitting in the path is a proxy. This one is not.
Real-time here means seconds to minutes after your collector exports. It has never meant inline blocking, and this page will not pretend otherwise.
Nearly every product in the category draws these as one line on a graph. Govern360 did too, until it went looking: 359 observed edges across 180 agents turned out to be policy decisions, one of them a DENY rendered as “sends to ServiceNow, 3 calls”. The fix deleted 359 of the product’s own findings, because they were not findings.
Traces arrive in standard OpenTelemetry format from the collector you already run. Each connector carries its own token with expiry, rotation with overlap and a quota, at most two live at a time. Test connectors stay separate from production, so trial traffic never lands in production evidence.
Your collector exports. We receive. No hop is added.
A trace is linked to a known agent only by an exact identifier. A name that merely looks right goes to a review queue for a person to confirm.
A wrong attribution is worse than none.
Every production agent gets a tiered, signed approval tied to its model, purpose, tools and autonomy tier. Change any pinned part and the approval is marked changed rather than quietly staying valid. It also expires on a schedule.
An approval is a statement about a moment. Agents change weekly.
Retired agents still running. Agents in production with no current certificate. Model drift. Tools called that were never approved. Data reaching destinations outside the allow list. Checked hourly, raised into the alert feed you already have.
Evidence, not enforcement. A finding never blocks anything.
Ask the live decision engine what it would decide, with nothing enforced. Replay the last 30 days of observed tool calls against today’s rules to see what a proposed change would actually have done.
A dry run is never a decision. It never enters the decision log.
Each model call is marked confirmed by both sources, seen only at runtime, or seen only in spend records. The middle column is the interesting one: it ran, and it is in nobody’s bill.
Counting runtime-only usage is opt-in, and no closed month moves.
For each AI provider: the connection, keys, projects, admin log, spend and runtime activity, side by side. It writes nothing, calls no provider and reads no credential.
Gaps are named in words. Not visible, never “no keys”.
Runtime findings and replay summaries can be forwarded to your SIEM through the existing outbound channel, off by default. Auditors get an evidence pack with a SHA-256 checksum list.
Outbound only. Off until you turn it on.
Every runtime surface draws the map rather than a table. Lines move only where something was observed, problems blink, a click opens the detail drawer, and Next issue steps through them.
Moving lines only where observed. Never for a decision.
No. Runtime evidence reaches Govern360 because the customer’s own OpenTelemetry collector exports traces to it. Govern360 receives those traces; it is not a hop the request passes through, adds no latency, and cannot hard-stop a call at request time. Every product that sees runtime by sitting in the path is a proxy you have to defend a latency budget for. This one is not.
Seconds to minutes after the source exports. It never means inline blocking. The figure depends on the customer’s collector export interval, not on anything Govern360 controls, so the honest description is that evidence lands shortly after the span is exported rather than at the moment of the call.
Configured means a source configuration permits or requires it — read from the agent’s setup, which it may never have exercised. Observed means a source event proves the call completed. Govern360 reports both, and never merges them: a policy decision such as a DENY is a permission or a refusal, not an observed action, and is never drawn as one.
Traces arrive in standard OpenTelemetry format from the collector the customer already runs. Each connector holds its own token with an expiry, rotation with overlap and a quota, and at most two live tokens at a time. Test connectors are kept separate from production so trial traffic never lands in production evidence.
Only by an exact identifier. A name that merely looks like a match is not accepted — it goes to a review queue for a person to confirm. Guessing here would attach real runtime behaviour to the wrong agent, which is worse than leaving it unattributed.
A tiered, signed approval for a production agent, tied to its model, purpose, tools and autonomy tier. If any of those pinned parts change, the approval is marked changed rather than silently remaining valid, and it expires on a schedule. An approval is a statement about a moment; agents change weekly, so the certificate has to know when it has been outrun.
Agents that were retired but are still running, agents in production with no current certificate, model drift away from what was approved, tools being called that are not on the approved list, and data going to destinations outside the allow list. They are checked hourly and raised into the existing alert feed rather than a second parallel pipeline.
No. A finding is evidence, not enforcement. It never blocks, never stops an agent and never changes a certificate. Where an enabled policy blocks a tool and the source reports the call completed anyway, the finding says the block did not hold — and it says that only when the source actually reported completion, never on suspicion.
Yes. A dry run asks the live decision engine what it would decide, with nothing enforced. A dry run is never a decision: it reads not enforced, never enters the decision log, and never opens an approval request. You can also replay the last 30 days of observed tool calls against today’s rules to see what a proposed change would have done.
By itself, not at all. Each model call is marked as confirmed by both sources, seen only at runtime, or seen only in spend records. The interesting column is the middle one — it ran, and it is in nobody’s bill. Counting runtime-only usage is opt-in per organisation and counts from the moment it is switched on, so no closed month ever moves.
A single read, per AI provider, putting the connection, keys, projects, admin log, spend and runtime activity side by side. It writes nothing, calls no provider and reads no credential. Gaps are named in words: a provider with no connection reads not visible, never no keys; an admin log that could not be read says so with the reason.
Yes, outbound only and off by default, through the existing SIEM forwarding rather than a new channel. For auditors there is a runtime assurance evidence pack with a SHA-256 checksum list, so what you hand over can be shown not to have changed since it was generated.
No. The capture mode permits metadata only and nothing else is accepted. Prompt text and model responses are never stored. What arrives is span metadata — which model, which tool, which destination, how many tokens — not what anyone typed.
Not by name on default screens. The initiator is stored as an HMAC under a per-organisation key held inside the database, together with the type of initiator. Runtime findings are about agents, not scores of people.
They say no runtime telemetry is connected. They never show zero runs, because zero is a measurement and this is an absence of one. If a connector exists but nothing arrived in the window, it says no events were observed in connected telemetry during the selected period — which is a different statement, and the difference matters.
What the agent actually did — from traces exported by the customer’s own telemetry collector, without sitting in the request path. That covers runtime intake, agent identity resolution, release certification, runtime findings, policy dry runs and replay, runtime spend reconciliation, provider posture, SIEM forwarding with an evidence pack, and linkage maps on every runtime surface.
What this page does not claim. Govern360 is not in the request path and cannot block a call at request time. Runtime findings are evidence and never enforce anything. Prompt text and model responses are never stored — metadata only. The initiator is pseudonymous. Where a source cannot be read, screens say so with the reason rather than showing zero. Figures cited here come from a connected demonstration tenant, not a customer estate.
More runtime questions, answered · Why Govern360 · The data-to-action graph · Control AI spend · All answers