Keydris documentation

How Keydris works, in dependency order.

Start with the CLI quickstart, then learn how identity, authority, policies, integrations, and evidence fit together. Read top to bottom the first time; every page also stands alone.

The learning path

(01)IntroductionWhat Keydris is, the mental model, and what it deliberately does not do.(02)QuickstartInstall the CLI, connect an agent, start the proxy, and verify a governed session.(03)Identity vs authorityThe core concept: why knowing which agent is calling is not enough.(04)KITs & devicesThe short-lived session identity an agent presents, and what it binds.(05)The execution boundaryThe broker, the KIT Reader, and exactly what crosses to the control plane.(06)PoliciesAuthoring the rules: decisions, defaults, conditions, and versioning.(07)Audit evidenceDecisions and outcomes as distinct, reviewable, exportable facts.

Then, by need

(08)MCPGoverning MCP tool calls and resource reads, in both modes.(09)GitHubGoverning repository actions without handing the agent your access.(10)SlackGoverning what agents may read and post in selected public channels.(11)Local commandsSupported shell commands checked before the harness executes them.(12)Console & operationsThe workflows an operator owns: agents, policies, evidence, members.(13)CLI & vocabularyCLI installation, setup, daily commands, cleanup, and the exact meaning of each term.

Vocabulary

Agent: an operator-managed identity for an AI workload.
Device: an enrolled installation on which an agent runs.
KIT: the short-lived runtime identity for one agent session.
Local proxy: the CLI's TLS-terminating egress proxy; it matches each governed request to a route before anything reaches the network.
Broker: the legacy authorization path in your environment, on the agent's side.
Reader: optional enforcement on your MCP servers, on the receiving side.
Policy: operator-authored rules governing an agent's actions.
Decision: what Keydris concluded about one governed action: ALLOW, REJECT, or APPROVAL REQUIRED. Exactly these three.
Reason: why a decision came out that way (for example scope mismatch, or authority verified). A reason travels under a decision; it is never the decision.
Outcome: what happened when an allowed operation was attempted, recorded separately from the decision.
Governed: resources you enroll + the policy you assign, for supported actions.