Quickstart

• A Keydris account. Create one (free, no credit card). The Free plan is the development and evaluation plan: it includes 3,000 KIT issuances per month, and verification and authority decisions are free, which is enough to build and prove a real integration.
• Node.js 18+ with npm, on macOS or Linux.
• A registered agent in that account. You will use its Agent ID below. Assign the agent a policy in the console; a safe first policy allows read-type actions and rejects everything else by default. (Policies are explained fully in Core concepts · Policies; you don't need that page to finish this one.)
• A supported agent harness. Claude Code and OpenAI Codex are the integrated workflows; pick yours in the commands below.

$ npm install -g @keydris/cli$ keydris login$ keydris init claude-code <agent-id>  # connect your agent$ claude  # every governed action now carries a KIT

If a step fails, the CLI says so. Nothing is silently left ungoverned: a failed login leaves no enrollment, and an unknown Agent ID fails the connection. The agent simply isn't governed until it succeeds.

1. login authenticated you against the Keydris account you created above, established your operator identity with the control plane, and enrolled this installation as a device.
2. init connected this installation to your registered agent. The Agent ID is the stable attachment point. The policy governing the agent is assigned in Keydris, and the agent cannot select or change its own policy. Create a new policy, update one, or assign a different one centrally. None of it requires redoing this setup.
3. Starting the agent began a session: Keydris issued it a short-lived KIT, the identity it presents with each governed action. Long-running work renews the KIT automatically; the agent never holds a long-lived credential.
4. Each governed action is now checked against your policy before it executes: ALLOW proceeds, REJECT is blocked, APPROVAL REQUIRED is held and the prompt renders in the agent's own harness. That check happens at the authorization boundary, and no path completes the decision without Keydris today. Where the decision cannot be completed, the current platform fails closed: the action does not proceed. That platform-unavailable behavior is currently fixed. It is separate from your policy's own default decision, which you author.

Ask the agent to do something your policy permits, then something it doesn't. Watching both is the whole point: you want to see the system REJECT before you trust what it allows.

agent → repo.read_file
{ path: src/billing/invoices.ts }

KIT presented · scope repo:read granted

ALLOW
in scope · policy permits
authority decision · completed with Keydris
→ proceeds to execute

agent → db.reset
{ instance: prod-users }

same agent · same KIT · identity unchanged

REJECT
reason: scope mismatch · db:admin not granted
authority decision · completed with Keydris
→ blocked before execution · recorded

The REJECT is expected behavior: the agent asked for more authority than it was delegated. The landing page shows the same decision from the other direction: hold the agent and the action constant, change the authority, and watch the next decision change. The authority demonstration is open there, no account required.

Open Audit in the console. Both requests above are now records: the agent, the action, the policy version that decided it, the decision, and, separately, the execution outcome for the allowed one. Decision and outcome are distinct facts; an allowed action can still fail at the provider, and the record says so.