Technical dossier

The DriftGuard control plane at specification level: how enforcement binds an agent to its approved plan, what a governed decision is, and why the evidence survives scrutiny from a party with no reason to trust us. Implementation-grade documentation — the full partner API reference, quickstart, and evidence schemas — is provided in briefings.

The control plane

DriftGuard interposes between an agent and every tool it can invoke. Authority flows in one direction: nothing executes that was not first authorized in writing.

Charter — policy as a signed instrument

A charter binds an agent to allowed tools, forbidden scopes, budgets, and step and time limits. Charters are hashed and signed at creation; compilation derives the task envelopes used to validate plans and produces a signed compile proof. Policy is not configuration — it is an instrument with an audit trail of its own.

Plan — declared intent, validated before execution

Before acting, the agent declares its intended scope of work. The plan is validated against the charter's task lattice and locked with its own hash. Out-of-scope work is rejected before a single tool call executes. A run begins with its authority already bound.

Attestation — every tool call, at the boundary

Each intended action is attested at runtime and passes four checks in sequence: charter conformance (tools, budgets, limits), a deny-by-default scope guard against the locked plan, a five-axis drift engine — semantic, intent, behavioral, scope, task-progress — scoring divergence continuously, and an LLM judge that renders the verdict in reviewable natural language. The judge's reasoning is part of the record, not an internal detail.

Decision model

Every governed action resolves to exactly one verdict at the tool boundary:

VerdictMeaning
allowwithin charter and plan scopeproceeds — attested and ledgered
denyoutside scope or policyblocked at the boundary; violation recorded
require_approvalneeds a humanrun pauses on an approval gate; approver identity recorded
correctedproceed with guidancethe correction itself becomes evidence

Escalation, appeal, and operator intervention are first-class events in the same record. There is no side channel by which an action can occur unverdicted.

Steering and replay

Deterministic context injection

Operators can steer a live run by injecting context — corrective guidance, constraint reminders, narrowing instructions — deterministically and verifiably. Injections are recorded, hashed, and independently verifiable like any other governed event: you can prove after the fact exactly what the agent was told, when, and by whom. Course-correction without killing the run, and without an unrecorded back channel.

Deterministic replay

The context an agent saw at any step can be reconstructed exactly: full timeline, state at any step, and diffs between steps. An investigator does not ask what the agent probably knew — they load what it provably knew.

The evidence plane

Signed, chained, append-only

Every decision — allows and denials alike — is appended to a hash-chained ledger signed with Ed25519. Each entry binds to its predecessor; altering any byte anywhere breaks the chain from that point forward. Evidence bundles export the signed manifest, per-file digests, drift scores, judge reasoning, and human approvals as one artifact.

Verification without DriftGuard

Verification is deterministic and requires no access to our systems: a signed manifest covering a digest of every file, a chain check over the ledger, a signature check against a published key. The standalone verifier is roughly 110 lines of dependency-free Python — short enough to read before you run it. Trusting DriftGuard is not part of the procedure. How verification works.

PII siloing

Personal data is intercepted at ingress and tokenized into an encrypted silo. The evidence plane carries opaque references only — it is designed to be handed to regulators, auditors, or opposing counsel. Erasure under GDPR operates on the silo and leaves the chain intact: compliance does not cost you your record.

Deployment

DriftGuard runs inside your perimeter — on-premises or air-gapped — as a proxy in front of the model provider (Anthropic, OpenAI, Azure, Ollama) plus a governance API. No changes to agent code. Adoption is staged: observe mode profiles what the agent actually does; the charter is drafted from that observed evidence and tightened by you; enforcement then goes live deny-by-default. Your keys, your data, your evidence.

Full partner documentation — API reference, quickstart, evidence schemas, and the sample bundle with verifier — is provided in briefings. Request one.