Endpoint seats
Policy enforced inside each vendor’s own administrator hook, decided offline against a signed bundle, because a hook that phones home fails open.
Your gateway cannot see the seats your developers work in
Inline governance works by being on the wire: Token Observe issues the credential, pins the endpoint, and refuses the call before it dispatches. A developer on a Claude Code, Codex or Copilot subscription defeats every part of that without trying: the credential came from the vendor, the endpoint is the vendor’s own, and the shell command the tool runs never traverses a gateway at all.
What the vendors ship instead is an administrative extension point: a hook that runs before a tool call and blocks it on a non-zero exit, from a location a device-management channel writes and the developer does not. It is also a control on a machine whose user is the subject of the policy, so device management is a prerequisite rather than a mitigation.
How it works
- 01
Register the seat
A seat names a vendor, a tool, one person by email and a team, and carries the same roles, budgets and rate limits an agent does, so the same policies select it. No per-request USD ceiling: a subscription prices the seat, not the call. - 02
Enrol the device, then push the managed configuration
Each machine declares a managementChannel of mdm, manual or unmanaged — required and never defaulted, because a default would be the product inventing evidence for its own coverage claim. The managed payload then carries the seat id, the device id, the trusted public key and the bundle URL through the channel the developer cannot remove. The key travels here rather than with the bundle: a verifier that reads its trust anchor out of the artifact it verifies verifies nothing. - 03
Decide locally, at the hook
The device presents its credential and receives its own bundle — no seat id is read from the request, so a seat cannot fetch a colleague’s. The hook verifies the signature BEFORE expiry or identity, then calls the same evaluator the gateway runs against the same tool namespace: mcp__github__create_pr becomes tool:github/create_pr, so one rule governs the agent and the editor. - 04
Spool the evidence, then report the coverage
One JSON line per decision (verdicts, policy ids, hashes and timings, never arguments, prompts or matched PII values) is appended locally after the verdict is rendered, so a full disk can lose a record and can never turn a deny into an allow.
The hook never phones home
Every vendor hook system fails open on timeout: the hook is slow, the client stops waiting, the tool call proceeds. A hook that round-trips to a server therefore turns every outage and every DNS blip into a silent, org-wide bypass, at the moment nobody is watching. The decision is made on the device instead, and a test asserts the absence of network calls.
That makes the hook the strict one, since nothing downstream of it will be. Two deadlines exist because the vendor’s expiry is an ALLOW and the hook’s is a DENY: the 50ms budget stops further work, and a verdict arriving after the 150ms wall is discarded even when it is an allow. An allow says nothing at all: exit 0, no output, never an explicit allow, which on clients that honour one would suppress the user’s own confirmation prompt.
no bundle | unreadable | not valid JSON -> DENY
trusted key missing, not root-owned, writable -> DENY
signature or envelope fails under that key -> DENY
issued for another seat, or another install -> DENY
past expiresAt, or older than maxAgeSeconds -> DENY
unknown vendor event | unreadable payload -> DENY
the 50ms budget or the 150ms wall elapses -> DENY
an internal throw anywhere in the runner -> DENY
allow -> exit 0, no output, never an explicit allow- Workspace configuration, registry, policies and decisions
- Billing evidence from the connections and imports you supply
- Supplied connection credentials, encrypted at rest
- Request metadata for traffic routed through the workspace
- Bounded, redacted prompt and reply text when capture is enabled
- Billing queries using the reporting permissions you supply
- Routed model payloads after the applicable policy checks
- Model-assisted search using a separately configured inference key
- Authorized evidence reads and CSV exports to your client
The cloud service processes and stores workspace evidence and supplied credentials. Supabase handles account authentication; Railway runs the cloud pilot. Cloud hosting does not keep all data inside your network.
Billing cannot recover historical conversations. Activity covers routed traffic or supported evidence supplied to the workspace. Text capture is off by default, and redaction is heuristic.
Customer hosting is an optional, separate deployment choice. Its infrastructure and data boundary differ from the cloud pilot.
The census argues with our own coverage claim
A customer who believes their developers are governed when they are not is the worst outcome this can produce, because they stop looking. So the census reports every control for every seat-day, including the absent ones. The local control reaches enforced only where a bundle was issued that day AND reached a live device enrolled as mdm. That is one joined question rather than two, because a seat whose managed laptop never collects policy while an unmanaged one collects daily would otherwise read as governed. A quiet day is absent, not all clear.
- Enforced
- Token Observe could have refused the action before it happened: inline at the gateway, or from a bundle delivered that day onto a device the developer cannot reconfigure.
- Recorded
- Evidence exists and nothing could have been stopped: shadow policies, telemetry-only days, a bundle that reached only hand-installed devices. Redaction and the flight recorder never reach enforced from a bundle at all.
- Absent
- Nothing configured, or nothing reached Token Observe. A day it saw nothing is a day it can evidence nothing.
Every clean result carries a coverage report beside it, because an empty findings list reads the same whether nobody is bypassing the gateway or the export died in July.
- connected_freshthe only all-clear
Evidence arrived inside the bound. The only state a clean result can stand on.
- connected_empty
Deliveries arriving, none of them carrying a row. The connector is alive and the estate has not been observed: two different facts, and this state says both.
- feed_failing
Evidence still inside its bound, and the thing that fetches it has stopped. Freshness alone would go on calling it covered for the whole bound, which is forty-five days on a seat export.
- connected_stale
Evidence arrived before, and not recently enough. The dangerous one: the connector, the credential and the last successful scan all still look right.
- never_connected
Nothing has ever arrived. A clean result from this source is not a result at all.
- billingquiet for 45 days → stale
the vendor’s master bill for a calendar month
- seatsquiet for 45 days → stale
a vendor’s per-user seat spend export
- egressquiet for 6 hours → stale
a network egress, proxy or VPC flow-log export
- service_accountsquiet for 10 days → stale
a vendor’s own listing of its API keys
- idequiet for 48 hours → stale
endpoint or MDM telemetry about coding agents on workstations
- selfquiet for twice the radar schedule → stale
Token Observe’s own gateway tables, which need no export
six feeds, five radar sources: seats is its own feed with its own cadence and files its findings under billing
A decision a person recorded about a service.
approved · prohibited · unknown
A measurement about a feed.
connected_fresh … never_connected
Neither answers the other. A service somebody approved can have no evidence feed connected to it at all, and a healthy feed says nothing about whether anybody approved what it found.
State names, stream names and bounds are the product’s own. Each bound is roughly two expected cycles, rounded up so a jittery export does not flap: a monthly bill is not late at forty days, and an egress feed that stopped at breakfast should not stay green until tomorrow.
Each line closes off an assumption a reader would otherwise carry into a proof of concept.
What this does not doWhat this leans on
Policy engine
One deterministic verdict on every governed request: allow, block, redact, or park it for a human.
MCP gateway
The half of an agent that moves money is a tool call, not a sentence. This is the checkpoint that call goes through.
Shadow AI radar
Five evidence sources for AI activity that never touched the gateway, and a coverage model that refuses to call a dead feed a clean estate.
Where this comes up
Jobs that draw on it
Guides that lean on it
Can a developer just delete the hook?
On an unmanaged device, yes, and the census reports it that way rather than counting it as coverage. The managed-settings files go to root-owned locations a device-management channel writes and the developer cannot, and the hook refuses a bundle or trusted key that is group- or world-writable, or a key not owned by root. Where a platform reports no meaningful uid or mode, the file is recorded as unchecked rather than protected.
Why is this a preview, and what would take it out of one?
Because the artefact and the observation path do not meet the production bar, and the code says so on the seat reads, the provisioning payload and the census rather than in a footnote. Four things close it: a code-signed native binary in place of a Node command, a rollback-resistant freshness anchor, attested evidence collection rather than an unsigned spool, and a live vendor compatibility matrix. Until then, run a bounded evaluation and read the census, not the configuration.
Prefer to ask a person? Write to James
Bring us the agent you are least comfortable with.
Create a cloud account and workspace. No card or server installation. Model calls and Google BigQuery scans can incur separate provider charges.