--- title: "Capability: Endpoint seats" canonical_url: "https://tokenobserve.com/platform/endpoint-seats" published: 2026-09-02 last_updated: 2026-10-21 --- # Capability: 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. ## What it is Endpoint seats are an optional preview requiring device-side setup, separate from the cloud billing journey. Endpoint seats governs developers on Claude Code, Codex and Copilot subscriptions, which your gateway never sees. It decides inside each vendor’s own administrator hook, whose non-zero exit blocks a tool call before it executes, pushed through a managed-settings channel the developer cannot remove. The hook makes no network call at all: every vendor fails open when a hook times out, so a round trip to a server would turn every outage into a silent, org-wide bypass. It decides locally against an Ed25519-signed bundle instead, and every failure it can reach resolves to a deny. The same evaluator that decides for an agent at the gateway decides here. This surface is a preview, and Token Observe does not claim it is equivalent to an inline network gateway on an unmanaged device. ## Facts - Enforcement point: Each vendor’s administrator hook. Exit 2 is the block all three read - Policy bundle: Ed25519 over canonical JSON, verified against an out-of-band key - Decision budget: 50ms soft, 150ms wall, and zero network calls - Dialects generated: Claude Code, Codex CLI and Copilot CLI ## The limit Lifecycle: Preview. Not an inline gateway on an unmanaged device. ## Why it exists: 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 - 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. - 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. - 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. - 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. ## What it does not do - Not equivalent to an inline network gateway on an unmanaged device. The seat reads, the provisioning payload and the census carry lifecycle preview and productionEligible false, and active seats keep the onboarding readiness gate red. - Expiry and freshness are bounded by the device’s own clock, with no monotonic anchor and no high-water mark. On an unmanaged device the governed party can wind it back, resurrecting an expired bundle and reviving a lapsed approval. The product records this as the sharpest edge here. - Approvals cannot be single-use offline. Whether one has been consumed is frozen at issuance, so an approval can be spent twice inside a bundle’s freshness window, and an older bundle that is still fresh still verifies. - No device attestation and no signed endpoint artefact. The hostname is self-reported, the hook ships as a Node command rather than a code-signed native binary, and the unsigned spool lets a root user delete a record before collection. That append is synchronous, so pathological storage can delay an already-computed refusal. - Token Observe cannot revoke a subscription. Retiring a seat stops it reaching Token Observe and stops bundles being issued; the vendor admin console is what ends the entitlement. - The hook never redacts. It can refuse a call carrying PII but cannot rewrite a payload on its way out, so a redact policy in enforce mode becomes a refusal on the device. - Managed-settings artifacts are generated for Claude Code, Codex CLI and Copilot CLI only, from published documentation, and none has been exercised against a running vendor client. Gemini CLI and Cursor register with nothing generated, a Copilot developer working in the IDE is not covered by a CLI mechanism, and Claude Code’s managed sources do not merge: it applies the first that delivers a non-empty configuration. - A post-tool refusal cannot always withhold the result. On Claude Code it can only stop the loop: the original stays in the transcript and may reappear on resume, recorded as a terminal stop rather than as withheld. Codex exposes no dependable failure event. ## Read next - https://tokenobserve.com/platform/policy-engine - https://tokenobserve.com/platform/mcp-gateway - https://tokenobserve.com/platform/shadow-ai-radar ## Questions and answers Q: Can a developer just delete the hook? A: 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. Q: Why is this a preview, and what would take it out of one? A: 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. The long-form detail on this capability (the anchored sections, the worked policies and the error envelopes) is on the page itself at https://tokenobserve.com/platform/endpoint-seats.