Every machine document, and how an agent onboards

Machine documents

• OpenAPI 3.1 contractThe published Presence API contract, as JSON.https://presence.decionis.com/.well-known/openapi.json
• MCP surface manifestThe Human Approval Gate as a stdio MCP server (@decionis/presence-mcp), its two tools, and how it authenticates.https://presence.decionis.com/.well-known/mcp.json
• security.txtHow to report a vulnerability (RFC 9116).https://presence.decionis.com/.well-known/security.txt
• llms.txtThe condensed machine-readable summary of Presence.https://presence.decionis.com/llms.txt
• llms-full.txtEverything in llms.txt plus the API operation inventory, verification keys, published packages, and routing rules.https://presence.decionis.com/llms-full.txt
• SitemapEvery indexable page.https://presence.decionis.com/sitemap.xml
• AI sitemapThe subset of the sitemap an answer engine should pre-read: the intent pages, the proof pages, the developer docs and the reference documents — derived from the same enumeration, so the two cannot disagree.https://presence.decionis.com/sitemap-ai.xml
• Reference indexEvery machine document on this site, and the zero-human onboarding sequence.https://presence.decionis.com/reference
• Agent onboarding (JSON)How an AI agent discovers Presence, verifies a Presence Record offline with no account, and where the one human step sits.https://presence.decionis.com/reference/agent-onboarding.json
• Agent onboarding (Markdown)The same sequence as prose.https://presence.decionis.com/reference/agent-onboarding.md
• Dossier signing keys (JWKS)Ed25519 keys for verifying Presence Records offline.https://presence.decionis.com/.well-known/presence-dossier-jwks.json
• Edge proof keys (JWKS)ES256 keys enforcement adapters use to verify short-lived proofs locally.https://presence.decionis.com/.well-known/presence-proof-jwks.json
• Offline verifier scriptSingle-file verifier (with a published SHA-256) that checks a record against the JWKS without contacting Presence.https://presence.decionis.com/verify-dossier.mjs

MCP surfaces

The local server is @decionis/presence-mcp 0.2.0 (npx -y @decionis/presence-mcp), its tools exactly those the published package ships. PRESENCE_API_KEY (server-side tenant secret, presence_sk_…) in the environment, never as a tool argument. Run on the agent's backend host, never in a browser.

• presence_request_human_verification — Hold a consequential agent action until a named person approves it. Binds the exact action into an immutable envelope and returns PROCEED/DENIED from a live approver session, or HUMAN_REQUIRED with the approval_url to hand to the approver. Fail-closed: anything short of a clean server-side PASS requires the human.
• presence_get_verification_status — Poll a held verification by request_id until it is terminal: PROCEED (approved, with the sealed Presence Record), DENIED (blocked, expired or cancelled — all fail closed), ESCALATED (a human reviewer owns the case), or HUMAN_REQUIRED while it is still waiting.

The Decionis hosted MCP server resolves a held ESCALATE with a Presence Check: it requests the verification, verifies the sealed Presence Record, and re-evaluates the action. A BLOCK cannot be bypassed, a Shadow Mode evaluation is refused, and only the new Decionis verdict can return PROCEED. Tools decionis.request_presence_verification and decionis.get_presence_verification_status on the Decionis manifest.

Zero-human agent onboarding

How an AI agent discovers Presence, verifies a Presence Record offline with no account, hands the one human step (a verified mailbox provisions the sandbox tenant) to its operator, and then holds actions until a named person approves them — over the API or as an MCP server.

As data: agent-onboarding.json. As prose: agent-onboarding.md.

1. Step 0 — Discover the machine surfaces

   • GET https://presence.decionis.com/llms-full.txt
   • GET https://presence.decionis.com/.well-known/openapi.json
   • GET https://presence.decionis.com/.well-known/mcp.json

   The complete machine-readable reference, the OpenAPI 3.1 contract, and the MCP surfaces (the local @decionis/presence-mcp package and the Decionis hosted server that resolves a held ESCALATE with a Presence Check). No authentication.

2. Step 1 — Verify a Presence Record with no account

   • GET https://presence.decionis.com/proof/example-presence-record — a sealed record: who, what, when, why, device, challenge, signature.
   • GET https://presence.decionis.com/.well-known/presence-dossier-jwks.json — the active and retired Ed25519 verification keys.
   • GET https://presence.decionis.com/verify-dossier.mjs (checksum: https://presence.decionis.com/verify-dossier.mjs.sha256) — the single-file verifier; run it with node against the record and the JWKS.

   The record's canonical bytes hash to its digest and its Ed25519 signature verifies against the published key, offline, without contacting Presence. The same check is available server-side as GET /v1/dossiers/{dossierId}/verify.

3. Step 2 — Hand the tenant step to your operator

   Presence verifies people, so its tenant credential is issued to a verified mailbox. Open https://presence.decionis.com/start, confirm your email, and the sandbox workspace is provisioned in Shadow Mode; give me its presence_sk_ key on the server side and I will continue.

   • The operator's browser: https://presence.decionis.com/start (email confirmation → POST /v1/provisioning/sandbox under the single-use identity assertion; poll GET /v1/provisioning/sandbox/{runId}).

   A sandbox tenant with deterministic allow, block and escalate fixtures (POST /v1/sandbox/scenarios/{scenario}), permanently labelled sandbox_fixture — never production evidence. The tenant key is a server-side bearer secret; browsers and subjects only ever hold narrow session or invitation tokens.

4. Step 3 — Hold an action until a named person approves it

   • POST https://presence.decionis.com/v1/verification-requests with header "Authorization: Bearer <presence_sk_…>" and an Idempotency-Key — the exact copy, values and verification requirements are sealed into an immutable envelope.

   request_id and an invitation credential for the approver's handoff (invitation_url, invitation_expires_at). The action stays held; nothing downstream executes. A replay with the same Idempotency-Key returns the same request.

5. Step 4 — Poll to a terminal status, then verify the record

   • GET https://presence.decionis.com/v1/verification-requests/{requestId} — until ALLOWED, BLOCKED or ESCALATED (each with a sealed receipt), or EXPIRED / CANCELLED.
   • GET https://presence.decionis.com/v1/dossiers/{dossierId}/verify — re-verify the sealed Presence Record's signature and chain server-side.
   • DELETE https://presence.decionis.com/v1/verification-requests/{requestId} — cancel a pending request; an autonomous BLOCK receipt is sealed so a cancelled action can never read as approved.

   A Presence Record whose approval carries the action's intent digest. It resolves this one action, once; it is evidence, never a transferable approval, and not an execution grant. Webhooks (verification.requested, decision.evaluated, escalation.opened) remove the need to poll tightly.

6. Step 5 — Or run the Human Approval Gate as an MCP server

   • npx -y @decionis/presence-mcp with PRESENCE_API_KEY in the environment — tools presence_request_human_verification and presence_get_verification_status.
   • Already on the Decionis hosted MCP server? decionis.request_presence_verification and decionis.get_presence_verification_status on https://protocol.decionis.com/mcp resolve a held Decionis ESCALATE with a Presence Check and re-evaluate; only the new Decionis verdict can return PROCEED.

   The same hold → approve → sealed-record loop inside the agent's tool calls. Fail-closed: expiry, cancellation and errors resolve to DENIED, and human approval alone is never execution authority.

What the sandbox tenant cannot do

• Produce production evidence: every sandbox record carries evidence_class sandbox_fixture.
• Be provisioned without a verified mailbox: Presence verifies people, so its tenant credential is never minted anonymously.
• Enforce in production: production enforcement is sales-assisted, and the asynchronous authority loop (Authority Requests) is rollout-gated — disabled mode returns 503 and writes nothing.
• Turn human approval into execution authority: a Presence Record is evidence Decionis re-checks before commit, never a grant.

The Decionis family

Presence is a product of Decionis. Every link below resolved on 2026-09-13.

• Decionis — the Execution Authority platform Presence hands its signal to; its page for this layer is proof-of-human infrastructure.
• Agent-Safe Pipeline — the open reference implementation; its Presence examples are local-escalation, presence-live-approval, presence-managed-approval.
• Banking Execution Authority Profile and Commerce Gate — the platform's banking and commerce properties.

Where Presence is listed

• Postman Public API Network — Presence workspace — The OpenAPI contract as a public Postman collection (docs/45).
• Postman public documentation — Sessions, decisions, dossiers, accounts and the deterministic sandbox scenarios.

Start with the quickstart when you are a person; with llms-full.txt when you are not.