Proof of authority for AI agents

Every governed action, authorized before it runs.

Assign an agent bounded authority. Change that authority, and the next decision changes without redeploying the agent or touching its code.

Start free Read the Quickstart

No credit card required

Built for MCP, APIs, and AI agents

Claude Code v2.1.206

Welcome back!

Claude Code · governed session

keydris

~/dev/keydris-api

Tips for getting started

Keydris authority is checked before each governed action

What's new

Agent connected by Agent ID

Policy assigned centrally

/release-notes for more

update the API handler and open the pull request

Read(app/api/route.ts)1 result

Read(lib/auth.ts)1 result

·Thinking…(0s · ↑ 0 tokens · esc to interrupt)

Keydris · authority check

Agent: agt_4f21
Action: —
Authority: —

Keydris decision

—

reason · —

Tool outcome

—

Keydris evaluates the authority assigned to this agent when it reaches a governed action.

Illustrative

nothing executes here · decision kd_dec_5178

Install and connect

Add Keydris to your code

Your harness

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

Get started

Govern one action in 5 steps

01Register the agent, assign a policyIn the console, register the agent and assign it the policy you authored. You get an Agent ID.
02Install the CLINode.js 18+ on macOS or Linux. The package is public on npm.
03Sign inEstablishes your operator identity and enrolls this device.
04Connect the agentLinks this installation to the registered agent and its assigned policy.
05Run the agentA session starts, Keydris issues a short-lived KIT, and each governed action is checked against the policy before it executes.

Read the full quickstart ↗

Where it sits

You choose which actions require Keydris authority.

You integrate Keydris at the boundary that is about to carry out the action. That boundary obtains the authority decision and enforces it. Keydris supplies the decision; it is not the thing that executes.

Where the decision happens

Keydris governs the paths where your application requires Keydris authority. It supplies the decision; your boundary enforces it; your tool executes. The request payload stays on the execution path. A path that does not present Keydris authority reaches the tool through your application’s own authorization. Keydris is not a network firewall.

ALLOW
the governed action proceeds
APPROVAL REQUIRED
blocked pending a human · resolves to ALLOW or REJECT
REJECT
the governed action does not proceed

What it leaves behind

Every decision leaves a record you can read.

This is the same event you changed at the top of the page, opened. It answers why the decision happened, and it is explicit about what it does not establish.

Decision record

kd_dec_5183 · 2026-08-17T14:22:07Z

1 Decision

ALLOW

The requested action was inside the authority assigned to this agent at the moment it was evaluated.

reason · authority verified

2 Authority evaluated

policyrelease-policy / v13

permitsmerge_pull_request, read_record

evaluated atauthorization time · current policy

3 Request

agentagt_4f21

actionmerge_pull_request()

resourcekeydris/api

4 Tool outcome

completed

Reported by the tool after execution. Keydris decided; it did not execute the action.

5 Not established by this record

request payloadnot stored

tool response bodynot observed

downstream effectsnot established

A decision record is evidence of what was checked and decided, not a claim about everything that happened afterwards.

Claims, with receipts

Don’t take the claim. Take the link.

Every claim below links to a page you can read without a form. If Keydris cannot link it, it does not claim it.

Checked before the action, at the boundary

Authorization is evaluated per governed action, before execution. The receiving boundary obtains the decision and enforces the result.

Policy documentation

You author the policy, and it is versioned

Scope and limits are operator-defined and versioned, so each decision stays attributable to the policy that was in force.

Policy model

Revocation governs what comes next

A revoked authority fails its next verification. The agent process is not terminated; completed actions are not reversed.

Authority management

Decisions and outcomes are recorded

Decision records carry the evaluated action, the policy version, and the outcome, available for review and export.

Audit log documentation

The CLI is public on npm

Install @keydris/cli and read the documentation before you talk to anyone. No account required for either.

@keydris/cli on npm

Developer Preview, free to try

Sign up and run the first authority loop yourself: no invite, no sales call, no credit card. Production use is possible; there is no production SLA yet. The docs list the integrations supported today.

Create your account

Authority decisions are free

Free includes 3,000 KIT issuances per month, with authority decisions and verification free and no credit card. Pro starts at $99/month for teams operating agents in production. Enterprise governance is a conversation. Talk to us.

Developer Preview · pricing is early and will evolve

See pricing

For MCP & API platform teams

See how a receiving system can check the authority attached to a governed agent action before accepting it.

Change the authority

For enterprise security & agent teams

See how policies, approval requirements, revocation, and decision records govern agents acting across enterprise systems.

Run the quickstart

Both paths use the same authority model: policy-defined scope, action-time verification, revocation, and decision evidence.

Why
Keydris

Read the docs

Why this exists

OAuth, IAM, and API credentials establish access. They do not by themselves establish that this specific governed action is inside the policy assigned to this agent, and valid at the moment it is attempted.

That gap appears wherever agents act through MCP servers, APIs, and enterprise systems, before a human can review every call.

Keydris adds the action-time authority decision under the policy you defined: ALLOW, APPROVAL REQUIRED, or REJECT.

Authority before action.

Skeptical by design

FAQ

The questions a technical founder, platform engineer, or security reviewer should ask before adopting new infrastructure.

Why isn’t OAuth or IAM enough?

OAuth, IAM, service accounts, and workload identity establish who or what has access. Keydris works alongside them and adds a per-action authority check: whether this specific governed action is inside the policy assigned to this agent right now.

Is Keydris identity, authentication, or an MCP gateway?

No. Keydris is the authorization layer for AI agents. It is not an identity provider, agent runtime, monitoring product, or universal traffic proxy.

MCP already supports authorization. Why use Keydris?

MCP authorization and existing identity systems remain part of the foundation. Keydris adds a governed authority lifecycle across the agent, the policy you author, the authority it presents, per-action verification, revocation, and decision evidence.

Where does verification happen? Can it complete locally?

The receiving boundary evaluates the governed action by requesting verification from the Keydris platform. That boundary can run in your environment, but it does not evaluate the policy by itself.

Does Keydris proxy my traffic or see my payloads?

Keydris does not claim to be a universal proxy for your application traffic. On supported self-hosted paths, payload traffic stays inside your environment and authorization information crosses to Keydris. On third-party systems a Keydris integration may participate in the data path. Keydris does not claim it is never in any data path.

What happens if Keydris is unavailable?

The current platform fails closed: an action whose authority decision cannot be obtained does not proceed. That platform-unavailable behavior is currently fixed, not configurable. It is separate from a policy's own default decision, which you author (for example, reject unmatched actions). Keydris does not claim governed work continues uninterrupted through a control-plane outage.

What exactly gets revoked? Can the agent keep running?

The authority is revoked, not the agent process. The agent may continue running and attempting actions, but revoked authority fails subsequent verification.

Who defines the authority and who issues it?

You define and change the policy. Keydris issues the agent an authority bound to that policy. Updating or reassigning the policy does not require redoing the agent’s CLI setup.

What does the decision record prove?

A decision record preserves the evaluated action, agent, scope, policy version, checks, outcome, and timestamp for review and export. It is evidence of what the system checked and decided, not a guarantee of universal safety or compliance, and not a copy of the underlying request payload.

Why shouldn’t I build scoped checks myself?

You can build pieces of the model yourself. Keydris is for teams that want the policy, authority issuance, per-action verification, revocation, administration, and decision evidence to operate as one governed system across supported integrations. The public docs and CLI let you evaluate that tradeoff directly.

Does Keydris publish a latency benchmark?

Not yet. The current public material makes no latency claim. Evaluate the supported architecture and integration paths in the documentation rather than relying on an unsourced performance adjective.

What is available today?

Developer Preview, free to try. The CLI is public on npm, the documentation and the in-browser authority demonstration are open, and you can sign up and use the hosted application yourself without speaking to us. Production use is possible; there is no production SLA yet. The docs list the integrations currently supported.