Skip to content
Documentation menu

Start · 01

Introduction

Keydris is action-time authorization for AI agents. You assign an agent bounded authority in a policy; when a governed action is attempted, Keydris decides whether it may proceed. It binds that authority to the agent's identity. It does not issue or replace your identity system.

The problem Keydris exists for

An agent can be perfectly authenticated and still do the wrong thing. An API key proves someone holds a secret. It says nothing about who delegated the task, or whether this specific call is in scope right now. Your OAuth, IAM, and workload identity express authorization well, and Keydris depends on them rather than replacing them. What it adds is a check on the individual action, at the moment the agent is already moving faster than any human can review.

Keydris adds the missing check: before a governed action executes, the agent's authority (issuer, scope, expiry) is verified against the policy you assigned. In scope executes; out of scope is blocked. Every decision leaves evidence.

The mental model

These ten statements are the whole system. The rest of the docs is detail.

  1. AI agents take consequential actions.
  2. Knowing an agent's identity is not enough to establish authority for an action.
  3. Authority is delegated under constraints, by your organization, under a policy you author.
  4. A requested governed action carries a verifiable reference to that authority: the KIT.
  5. Authority is evaluated at the authorization boundary: the broker on your side, the KIT Reader on the receiving side, or a Keydris integration where the Reader cannot be installed.
  6. No path completes that decision without Keydris today. The KIT Reader requests verification from the Keydris platform, and no enforcement point reaches the complete decision on its own.
  7. Valid authority permits the governed action to proceed.
  8. Insufficient authority keeps the boundary closed. The action is rejected.
  9. The authorization decision and the execution outcome are recorded as distinct evidence.
  10. Keydris complements your existing stack. OAuth, gateways, policy engines stay where they are.

What is governed

Verified behavior

Governed = the resources you enroll + the policy you assign, for supported action types. What doesn't pass through the broker or Reader isn't governed. Keydris is a boundary you configure, not a claim of universal control over the host.

Governable surfaces include provider actions on connected systems (for example GitHub and Slack), MCP tool calls and resource reads, and supported local shell commands invoked through a supported harness. Which specific actions are governable depends on the integration and the current release.

What Keydris does not do

What Keydris does not do

Keydris never holds your money. It is not a wallet. The agent never receives the connected credential; whether secrets stay in your own environment or in a Keydris-managed vault depends on the integration mode. Keydris does not proxy all your traffic: on the broker and Reader paths only authorization crosses to Keydris, not your payloads. Where the Reader cannot be installed on a third-party system, though, a Keydris integration may participate in that data path. It does not guarantee an allowed action succeeds at the provider, does not control or read the model's intent, and a connected provider does not mean every action on it is supported. Revocation governs future actions; it never rewrites what already executed.

Who these docs are for

Platform and security engineers who will run the broker, founders and CTOs evaluating where Keydris sits in their stack, and the operators who own policies and review evidence day to day. Access in the console is scoped by role, so each person sees and changes only what their role permits.

These docs explain how Keydris works. The larger argument (why delegated machine authority may become infrastructure) lives in the Keydris thesis.