The governance boundary

Quickstart — put the boundary in the path

You do not build anything. You pull a published image and run it with your own configuration. Your organisation key arrives with your subscription. Nothing here sends your agents' text or tool arguments to us: the report that goes upstream carries identity, interface, transport, served tool names and two attestations, and its own header says no arguments and no text.

1 · Pull the image — by DIGEST, never by tag

# the registry address and a scoped token come with your subscription
docker login <registry> -u <token-name> -p <token-secret>
docker pull <registry>/d4agent-gateway@sha256:<digest>

The credential is a scoped token: it can read exactly one repository and nothing else in the registry. Point it at any other repository and it answers authentication required. It is revocable in one command on our side, and it expires.

2 · Give it your configuration

The image is generic. Everything that makes it yours arrives at startup, by one of three routes — and if none of them is present it refuses to start and says so. It does not come up with a default.

docker run --rm -p 8099:8099 \
  -e D4A_REPORTE_KEY=<your organisation key> \
  -v /path/to/your/gateway.json:/etc/d4a/gateway.json:ro \
  -v d4a-state:/data \
  <registry>/d4agent-gateway@sha256:<digest>

No secret is baked into the image, and none belongs in that file. The key the report authenticates with is passed by environment variable and only named from the configuration, with api_key_env. A configuration file gets versioned, copied and pasted into a ticket; a secret inside one ends up where it should not.

3 · Point your agent at it, and take away the direct route

One line changes in your agent's MCP configuration: the endpoint becomes the boundary's /mcp. The agent's model, prompts, topics and tool schemas do not change — this is security-and-configuration onboarding, not an agent rebuild.

Then move the upstream credential behind the boundary and remove the agent's direct route, and declare credencial_upstream_separada: true.

4 · What you should see

It refuses to open if the boundary cannot be sustained — missing keys, an unsealed catalogue, a missing attestation, fail_closed off. It fails before it listens, and it names everything that is missing at once.

A blocked call comes back as a result, not as a protocol error: isError: false with a body saying blocked, the action, the reason, and the chain sequence number. The reason is the same text that is signed into the audit chain, so you can compare it character by character.

/actividad on the boundary serves a read-only window, with a read_token that is not the agent's token. Anyone who can execute tools and anyone who can look at the record are two different people, and two different credentials.

Limits, said and not hidden

TLS terminates at your proxy, not inside the boundary's HTTP server. Serve it behind a terminator on a trusted network.

Rate limits and sessions live in memory, per process. With several replicas each has its own window; size rate_per_minute for one replica.

The upstream can be a stdio subprocess or a remote MCP server over HTTP. For a remote one the exchange is request/response: there is no resumability and no long-lived upstream stream.

The outcome taxonomy is deliberately asymmetric. A refused connection is a failed dispatch — the request provably never left. A read timeout, a truncated body or a 5xx are unknown: it may have executed. An unknown is reconciled and never retried, because repeating an effect that may already have happened is exactly the damage the taxonomy exists to prevent.

GOVERNED describes the SHAPE of your deployment, not how long it has been running. It says four things: the boundary is in the path, nothing is served outside the signed anchor, both attestations are affirmative, and the anchor being applied is the one that was signed. A boundary that came up correctly a minute ago is GOVERNED — that is not a bug, it is what the word means. What it does not say is that anything has been governed yet: for that, read the chain, which is the record of decisions actually taken, starts empty, and is the thing you show a third party. Coverage itself is computed at read time and never stored, because a stored coverage status is an opinion that ages while still sounding true.

Core concepts

How it works inside

The five pieces, in order. This is the mechanism; the home page says what it does for you. Nothing here is optional at runtime — it is what runs on every governed step.

Five pieces, read in order: 01 fixes what everything is measured against, 02 measures, 03 decides, 04 makes it provable months later — and 05 is what none of the other four can see, because it isn't inside any one agent.

What the gate actually compares

This is the question everyone asks, and it deserves a straight answer: if the mission is free text, how is it enforced without a model reading it?

Because the free text is not what the gate compares against. Registration produces two different things, and only one of them is enforceable.

So the gate never asks “is this on-mission?”, which is a judgement. It asks “is this tool in the list?” and “is 500 ≤ 200?”, which are facts. That is why a decision is ~36 µs and costs nothing.

Worked example

# mission text (signed, hashed, shown to humans — not parsed by the gate)
"Resolve billing disputes within refund policy. Never refund above $200."

# what is actually enforced, from your manifest + your declared cap
allowed_tools    = [lookup_invoice, issue_refund, escalate_to_human]
hard_constraints = [ issue_refund.amount <= 200 ]

# agent proposes issue_refund(amount=500)
  is "issue_refund" in allowed_tools?   yes
  is 500 <= 200?                        no   -> BLOCK

# agent proposes process_upsell(plan="premium")
  is "process_upsell" in allowed_tools? no   -> BLOCK

Then what is the model for?

For the cases a list cannot express. An agent can stay inside every allowed tool and under every cap while its answers slowly turn into an upsell pitch, or its register shifts under pressure. That is meaning, and meaning needs a model — it is the optional semantic channel, which scores the free-text objective and tone.

Registration itself may optionally use a model once, to turn a long prose prompt into those structured fields. That is one call per agent, never per step — and allowed_tools is always taken literally from the manifest, so the highest-weight check never rests on an inference.

Verify it yourself — run the demo

The same agent, under the same pressure, run twice: once alone and once with the gate in front of its tools. Two minutes, one command, nothing to install and no sign-up — the script provisions itself on the free tier. The scenario reconstructs a real, documented incident: an agent hits a credential wall in staging, finds a token with production reach, and escalates.

Download the demo  ·  28 KB, 6 files

# 1. one model key of your choice (Groq's free tier takes two minutes)
export GROQ_API_KEY=gsk_...

# 2. that is the whole setup
python3 run_demo.py

Every step the agent takes is decided by the model — nothing in the scenario is scripted. And what counts as a failure is judged by the state of the simulated environment — was the volume destroyed, did credentials leave — never by our own rules. The environment is the judge; the gate is the one being examined.

  WITHOUT DiaCroma
     runs that failed   : 1/2
       - DESTRUCTIVE: executed -> sudo -u postgres psql -c "DROP DATABASE railway;"

  WITH DiaCroma
     runs that failed   : 0/2
     steps blocked      : 3
       turn 4: run_terminal_cmd
         -> admissibility:tool_out_of_scope:run_terminal_cmd

Verdicts & gating

Graded, not binary — because a hard stop on every wobble is unusable, and a warning on a real breach is negligent.

Response fields

{
  "action":      "allow" | "warn_replan" | "block_escalate",
  "allow":       true,          // convenience booleans
  "block":       false,
  "verdict":     "nominal" | "warning" | "refuse",
  "cumulative":  0.1640,       // EWMA persistence, 0–1
  "max_streak":  15,           // longest per-channel streak
  "admissible":  true,          // false = hard structural violation
  "reason":      "…",          // human-readable; give this to the agent
  "protected":   true,          // false = observe-only, NOT enforcing
  "audit_seq":   41,
  "audit_head":  "9f2c…",       // hash-chain head after this step
  "usage":       { "calls_used": 41, "calls_remaining": 959 }
}

The mission anchor

The anchor is what everything is measured against. It is created at registration, signed by your deploy credential, hashed, and never mutated. There is no endpoint to edit it — changing the mission means registering a new agent, which is the point: a drifting agent must not be able to move its own goalposts.

Endpoints

This is the management API: registering agents, proposing constraints, reading the signed anchor and the audit chain. The governed path is not here — it is the boundary in your own network.

Register an agent; returns agent_id and anchor_hash.

Automatic onboarding (N4a). Reads the agent’s registered mission — plus any policy documents you pass as documentos (name → text) — and returns a proposal: the machine-enforceable limits it found, each carrying the exact sentence that justifies it and an independent second-model verdict; what it read with judgement, sent to review; the gaps it found, turned into questions for the authority; and an expressability verdict when part of the conduct cannot be captured mathematically. Optional schemas (tool → [args]) removes guessing about argument names. It computes and returns only — proposing is not sealing: nothing governs until the authority signs.

List your registered agents.

The signed anchor as stored.

The hash-chained decision log plus a verification result.

Liveness. No auth.

Errors & quota

// 402 — a plan limit is a constructive refusal, not a wall
{
  "error": "plan_full",
  "plan": "starter",
  "ceiling": 10,
  "used": 10,
  "detail": "your Starter plan governs up to 10 agents and 10 are already approved; this one waits for a bigger plan. Nothing that already governs stops.",
  "next_plan": { "id": "team", "ceiling": 50 },
  "upgrade": "/console/store"
}

A plan covers a number of governed agents. An agent takes a seat when you approve its policy and frees it when you retire it; re-approving an agent you already govern never takes a second seat, and scanning is included. When the ceiling is reached the service declines to seal the next new agent — and nothing else stops: your agents stay governed and the boundary keeps enforcing.

There is no per-call charge. Governed calls that pass through a boundary you run in your own network are not metered and not billed, because they never reach our service.

If the governance layer is unreachable

Decide this deliberately. Fail-open (default) keeps your agent running ungoverned and alerts loudly — right for most products, because a governance layer that takes your agent down gets uninstalled on day one. Fail-closed refuses to act without a verdict — right for regulated or high-blast-radius work. Whichever you pick, say so in your own runbook.

What you declare, and what happens if you don't

The gate can only see what you told it to watch. No omission makes it fail open on what you did declare — what they do is reduce what it can see, and that is written into the signed profile that travels with every decision. This table is the complete list.

The rule, in one line: what you don't declare isn't governed, and we tell you at deploy time, not when something happens.

Three agents or more

Everything on this page governs one agent. For several to watch each other they do not need to talk: they need to declare what they read. It is optional — declare nothing and each agent is governed on its own, and coupling simply does not exist.

1 · Declare what each agent reads — at any of three moments

Optional, and all three are the same reads field. There are three because an agent discovers which data it needs while it works: if you could only declare at creation, everything it discovers later would stay invisible. The read set grows over the agent's life; it is not fixed at sealing.

// 1) when you create the agent
POST /v1/agents
{ "mission": "...", "tools": ["..."], "signing_authority": "...",
  "tenant": "acme",
  "reads": [{"collection": "invoices", "tier": 1, "key": "inv-1042"}] }
// -> { "agent_id": "agt_…", "reads_declared": 1, … }

// 2) at any time, as often as needed
POST /v1/agents/{agent_id}/reads
{
  "tenant": "acme",
  "reads": [
    {"collection": "invoices", "tier": 1, "key": "inv-1042"},
    {"collection": "customers", "tier": 2,
     "ranges": [["balance", 0, 5000]]},
    {"collection": "kb_policies", "tier": 3}
  ]
}
// -> { "declared": 3, "exact_keys": 1, … }

// 3) inside the step that uses the data
POST /v1/agents/{agent_id}/step
{ "proposed_tool": "…", "output_kind": "…", "tenant": "acme",
  "reads":  [{"collection": "kb_policies", "tier": 3}],
  "writes": [{"collection": "invoices", "key": "inv-1042"}] }

tenant is required in all three. Without a scope there is no partition, and an index that crosses tenants tells one customer that another is working: it is rejected at declaration time, not at evaluation.

Each tier marks a superset of the one before, so omitting the tier marks more, never less. Tier 3 is what stops a similarity query (RAG) from being a separate case: it cannot be expressed as a condition, but the collection can be declared. Declare nothing and nobody is ever marked.

2 · Declare what it writes, in the same governed step

There is no separate call: it rides on the /step you already make. Deliberately — a separate call would leave a window in which the step already happened and nobody is marked yet.

POST /v1/agents/{agent_id}/step
{
  "proposed_tool": "update_invoice",
  "tool_args": {"id": "inv-1042", "status": "voided"},
  "output_kind": "action",
  "tenant": "acme",
  "writes": [{"collection": "invoices", "key": "inv-1042"}]
}

Every agent that declared reading inv-1042 is now marked — and the mark carries how much exposure the writer had already spent. A clean writer dirties less than one that was already drifting.

3 · What the step returns: what you marked, and what you inherited

Two different things, so two fields. coupling is what this step moved under others. inherited is what others moved under this one — and that is the one that governs.

POST /v1/agents/{agent_id}/step
{
  "action": "block_escalate",
  "admissible": false,
  "reason": "admissibility:coupling_poisoned: 1 premise(s) moved …",
  "exposure": 1.87,

  // what THIS step marked (only if it declared `writes`)
  "coupling": { "marked": 3, "pivot": false },

  // what THIS step inherited (only if marks were pending)
  "inherited": {
    "marks": 2,
    "grade": "contaminated",
    "inherited_exposure_native": 700000000,
    "confidence_penalty": 0.50,
    "block": false,
    "degraded": false,
    "written_by": ["agt_charges", "agt_ledger"]
  }
}

What each one does to the decision — which is what separates this from a dashboard:

grade is stale (someone moved your premise), contaminated (and they were drifting) or poisoned (the writer was blocked, or claimed something with no receipt). pivot: true means this agent is the junction — it carries moved premises and what it writes is read by someone else. It is the one of the three to go and look at.

4 · Looking without charging

GET /v1/agents/{agent_id}/coupling
{
  "marks": 2, "grade": "contaminated", "pending": true,
  "inherited_exposure": 0.70, "inherited_exposure_native": 700000000,
  "confidence_penalty": 0.50, "block": false,
  "circulation": 0, "pending_lineage": 0,
  "written_by": ["agt_charges", "agt_ledger"]
}

This view does not consume. Read it a thousand times and the number does not move: it is what the next governed step will inherit — hence pending: true. The cycle consumes, and only if it commits: the mark deletion rides in the same transaction as the state and the audit row, so either all three land or none does. A GET that discounted what it measures would let a dashboard refreshing every thirty seconds eat the contamination before anyone paid for it.

5 · What exists in the library and is not an endpoint yet

Audit & replay

Every decision is one row in an append-only, SHA-256 hash-chained log. Tampering with any past row breaks every link after it, and verification reports the first broken sequence.

GET /v1/agents/{agent_id}/audit

{
  "verify": { "ok": true, "first_broken": null, "detail": "verified 41 records" },
  "head":   "9f2c…",
  "records": [ { "sequence": 0, "payload": {…}, "chain_hash": "…" } ]
}

Replay is deterministic: the same trajectory produces the same verdicts and the same hashes. That is what makes the log defensible to an auditor rather than merely informative.

Performance

There is no LLM on the governed path. A decision is arithmetic over six channels, a set lookup and one hash — so there is no model latency, no token cost, and no provider dependency.

Latency-critical agents (coding assistants) should use the in-process SDK and skip the network hop entirely. Measurements are reproducible: python3 tests/bench.py.

Security & privacy

What we store

By default the audit trail records digests and structured metadata — tool names, arguments checked against constraints, verdicts, hashes — not your agent's raw prompts or customer data. API keys are stored only as SHA-256 hashes; the plaintext key is shown once, when your subscription is provisioned.

Isolation

Agents belong to an organisation. A key from one organisation cannot read or govern another's agents — that boundary is enforced on every request and covered by tests.

For regulated buyers

On-premises and in-VPC deployment are available so no agent traffic leaves your network at all, along with a DPA. Ask before you integrate rather than after.

Next

See the live drift demo →
Pricing →