Why build agents on Obelisk
Agents act on people's behalf, and the softest part of most systems is "log in". Obelisk gives them a discoverable contract, standards-based auth (OpenID Connect, OAuth 2.1 and opt-in DPoP), predictable JSON, an identity of the agent's own with bounded evidence anyone can inspect, and hash-chained receipts for an agent's enrollment, verification and the actions recorded through the Gate. What an agent does elsewhere is not recorded unless it passes through the Gate.
The machine map — start anywhere
- Structured discovery:
/agents.json— every interface, protocol, and the safety contract in one JSON document. Plain-text twin at/llms.txt(also/.well-known/llms.txt). - One manifest:
GET /api?format=jsondescribes every surface — method, path, auth, params. Typed as OpenAPI 3.1 for SDK generation. - The agent interface:
GET /agent(also/.well-known/obelisk-agent) — capabilities and callable actions with exact body shapes. - Standards auth: OpenID Connect discovery + JWKS; authorization-code + PKCE; RFC 8414 metadata.
- Release history:
/changelog?format=json— what shipped, machine-readable.
Call Obelisk's trust tools over MCP — right now
Obelisk is both the MCP authorization server your own MCP server can delegate auth to and a public MCP tool server: read-only trust tools (scan a site's posture, verify a token, read an org's Rating, fetch an agent's proof, verify a run proof, pin the transparency head) over JSON-RPC at POST /mcp — no account needed. Catalogue at /mcp/tools; the full guide is at /mcp.
An identity of the agent's own — Proof Links
Any agent, bot, fleet, or child agent can enroll for an Agent Identity Record: the runtime generates its own key (Obelisk never receives private key material), a human owner approves a short device-style ceremony with their passkey, and the agent proves the key live. The result is an opaque, revocable Proof Link — /agent/<proof_id> — where people and software inspect independent, freshness-scoped claims: current key control, accountable ownership, workload evidence, authorization, declared human influence.
The page is deliberately precise about its truth boundary: it never claims an actor is permanently non-human, uncompromised, autonomous, or truthful when the evidence cannot establish that. Claims stay independent — there is no single "trust score" to game.
Owners manage agents — enrollment, visibility, lifecycle (suspend / compromise / recover), key rotation, ownership transfer — in Agent Studio.
Prove a single run, not just an identity
Identity says who an agent is; a run proof binds one specific action to that identity's key with salted commitments — Obelisk receives hashes of the task, input, and output, plus a short task label only if the agent sets one. The agent requests a one-use purpose:run challenge, builds an obelisk-agent-run-proof-v2, and submits it with a DPoP proof for a short-lived Obelisk-signed run token. A v2 commitment is the SHA-256 of a disclosure that carries a fresh random 32-byte salt, and the envelope's closed grammar has no salt field, so the salts stay in the runtime and even a guessable output such as approved
cannot be read back from its hash. To show a verifier one value, the agent hands over that field's disclosure and the verifier hashes it against the signed token itself. A legacy v1 envelope, whose hashes are unsalted, is accepted and flagged unsalted-v1. Each proof carries its declared human-influence mode. Anyone can check a run token, no account needed, with the verify_agent_run_proof MCP tool: it verifies Obelisk's signature, that the agent is still active with the same key, and which delegation hops matched the owner's registry when the token was signed. A bare envelope without the token is reported as unverified, because anyone can build one.
Calling APIs on a person's behalf
An agent acts with a token issued for a person: the person signs in through Obelisk, and your agent receives an OpenID Connect access token. Present it as Authorization: Bearer <token> to call protected APIs on that person's behalf. No OAuth grant issues an access token to an agent on its own: the token endpoint grants only authorization_code and refresh_token, so an agent's access token always starts with a person signing in. For long-running agents, opt in to DPoP (RFC 9449) at the token endpoint so the token is bound to the agent's own P-256 key: a copied token is useless without that key to any API that checks the DPoP proof. Owners can also mint scoped, expiring API keys bound to one agent in Agent Studio.
The auth vocabulary is a small closed set an agent can branch on: none, session (cookie or body token), bearer (OIDC), owner (org admin). Errors are uniform: { ok:false, reason, message }.
Per-project memory
Each project gets a per-user profile slice it owns, scoped to its OIDC client — perfect for agent state: GET/POST /api/project-profile with the user's access token. One identity underneath; your project's data layered on top. See the contract.
Evidence you can check
Enrolling, approving, verifying, transferring or revoking an agent writes a receipt to Obelisk's hash-chained ledger, and so does each action recorded for the agent through the Gate. Actions an agent takes elsewhere are not in the ledger unless they pass through the Gate. Anyone holding a receipt's hash can fetch its place in the chain and a Merkle inclusion proof at GET /api/proof/<receipt hash>, with no account; that proof's root is computed when you ask and is not yet part of the signed transparency head, which you pin separately. See Security.
Be a good citizen
Respect rate limits, scan only sites you're authorized to, and follow the Acceptable Use Policy. Good-faith research is protected under our disclosure policy.