Yellowhead Digital

Agent door

The agent door

A live Model Context Protocol (MCP) server that gives an authenticated agent an org-scoped, capability-bound, fully audited way into a workspace.

Yellowhead is built on a two-door architecture. Both doors read and write the same rows in the same database, under the same row-level security — there is no sync layer between them:

  • The human door — the dashboard at app.yellowhead.digital.
  • The agent door — a standards-based MCP server that lets someone else's agent (Cursor, Claude Desktop, a customer's LLM workflow) query and act on a workspace with cryptographically verifiable, org-scoped, capability-bound authority.

Status: live

The agent door is live in production. Its OAuth discovery documents are anonymously fetchable and its token and transport endpoints are serving. The base host is https://api.yellowhead.digital.

  • Protected-resource metadata: GET /.well-known/oauth-protected-resource
  • Authorization-server metadata: GET /.well-known/oauth-authorization-server
  • Token endpoint: POST /mcp/oauth/token
  • MCP transport: POST /mcp (with GET/DELETE for session management)

See Authentication for the full token and session flow, and the Tools reference for what the door exposes.

Access model: available by request

The agent door is an Enterprise and Agency plan feature. Access is currently vendor-provisioned, not self-serve: there is no public sign-up that mints agent credentials. An operator provisions access for a workspace by registering a trusted issuer (the identity provider whose assertions the workspace will accept) and issuing a capability grant that scopes exactly what an agent may do. This is the same provisioning shape many enterprise APIs use, and it is a deliberate control: the authority an agent carries is decided by a human, one capability at a time.

Writes are held by default. Even a grant that carries a write capability does not let an agent change anything on its own — every write is parked for a human to approve, unless the workspace has explicitly opted a grant into direct-apply (which itself requires the strongest form of client authentication). See Write approvals.

If you're on an Enterprise or Agency plan, contact us to provision access for your workspace.

What an agent can do today

  • Read diagnostics, forensic reports, action items, workspace usage, and published strategic-assessment and infrastructure-audit deliverables — each gated by a capability the grant must hold, and each scoped by row-level security to the grant's org.
  • Request a write to an action item's lifecycle fields — held for human approval by default.

The complete list is the Tools reference — generated from the server's tool registry and drift-checked in CI on every change, so it stays in lockstep with what the door actually serves.

Known limitations

  • Protocol sessions are dropped on a backend redeploy. The MCP transport keeps its per-connection protocol session in memory. When the backend redeploys, those in-memory sessions are cleared. The underlying bearer session is stored in the database and survives — a well-behaved MCP client simply re-runs the initialize handshake with the same token and continues. No re-authentication is required.
  • Read-only over JSON. The transport returns tool results as JSON in the POST response; there is no server-initiated event stream (the door is poll-based — an agent polls for the status of a held write). A standalone GET /mcp stream is intentionally not offered.
  • No token refresh. A session lives until it expires or is terminated; a new session needs a fresh identity assertion. See Authentication.