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:
| Verdict | Meaning | |
|---|---|---|
| allow | within charter and plan scope | proceeds — attested and ledgered |
| deny | outside scope or policy | blocked at the boundary; violation recorded |
| require_approval | needs a human | run pauses on an approval gate; approver identity recorded |
| corrected | proceed with guidance | the 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.