Developer Quickstart — your first governed decision

Five steps to a verified decision

Each step is concrete and ordered. Run them top to bottom and you will have a real verdict from KYE™ and a proof an auditor can re-check without trusting you. The endpoint and request shape below are the canonical runtime decision call from the KYE™ Core API — copy them verbatim.

1. Get a sandbox key and endpoint

   Open the sandbox and generate a scoped API key for your tenant. The sandbox issues a short-lived bearer token and a base URL — no production credentials, no billing, fully isolated from real tenant data. Keep the key in an environment variable; never commit it.

   export KYE_BASE_URL="https://sandbox.kyeprotocol.com" export KYE_API_KEY="sk_sandbox_..." # from the sandbox console

2. Send an authority-decision request

   Call the canonical runtime decision endpoint — operation authorizeRuntime, POST /v1/runtime/authorize — with the actor that wants to act and the action it is attempting. KYE™ resolves authority, scope, and policy before the action and returns one verdict.

   curl -sS -X POST "$KYE_BASE_URL/v1/runtime/authorize" \ -H "Authorization: Bearer $KYE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "actor": { "entity_id": "kye:agent:sandbox:aml:alert-closer-1", "entity_type": "agent" }, "action": "alert.close", "resource": { "resource_entity_id": "kye:case:sandbox:aml:case-9001" }, "requested_scope": { "purpose": "aml-alert-disposition" }, "context": { "channel": "sandbox" } }'

3. Read the response — a decision plus an evidence reference

   You get back a PolicyDecision. The decision field is the verdict — KYE™ resolves Action Admissibility™ to one of the canonical outcomes (allow, deny, require_approval, allow_with_constraints, stop, …) — and policy_decision_id is the handle to the sealed record.

   { "policy_decision_id": "kye:decision:sandbox:7f3a9c1e", "decision": "require_approval", "reasons": ["scope.purpose granted for read, not disposition"], "obligations": ["two_person_review"], "created_at": "2026-06-28T10:14:02Z" }

   Whatever the verdict — admit, deny, or escalate — KYE™ records it as evidence. A denial is proof too: you can show a regulator the action was attempted and refused, at the instant it happened.

4. Verify the Evidence Pack™ offline against the JWKS

   The decision seals into a signed Evidence Pack™. Fetch it, then verify the signature against KYE™'s published JWKS using public keys alone — no call back to KYE™, no "trust our log". That offline-reproducible property is Replay-Proof™.

   # 1. fetch the sealed pack for your decision curl -sS "$KYE_BASE_URL/v1/evidence/kye:decision:sandbox:7f3a9c1e" -o pack.json # 2. fetch the published key set (public keys only) curl -sS "https://kyeprotocol.com/trust/self-audit-jwks.json" -o jwks.json # 3. verify the pack signature against the JWKS — offline, anyone can

   The same JWKS backs KYE™'s own self-audit: the protocol verifies itself with the keys it publishes to you.

5. Next steps

   You now have a governed decision and a verifiable proof. Go deeper:

   • Schemas — the canonical JSON Schemas for the request, the decision, and the Evidence Pack™.
   • Events — the §0.3 evidence-event family every governed action emits.
   • SDKs & developer portal — TypeScript and Python clients that wrap authorizeRuntime for you.
   • MCP — govern tool calls from an agent through the KYE MCP Server™.

Why this matters: when your AML agent closes an alert, KYE™ proves who authorised it and on what basis — turning exam-prep from days into minutes, because the auditor replays the signed decision instead of reconstructing it. You wired that proof in five steps and under 10 minutes.

This page is the first-session fast path. For every endpoint, parameter, and error code, see the full API reference; for the plain-language model behind the call, see how KYE Protocol™ works.