Skip to content
Documentation menu
On this page

Core concepts · 05

The execution boundary

A governed action cannot cross into execution until authority is verified. The boundary's resting state is closed. This page shows every artifact involved in one crossing, and one REJECT.

The shape of the system#

The whole model, in one line: you define the policy; Keydris issues a KIT bound to that policy; the agent presents its authority; the authorization boundary evaluates it by requesting verification from Keydris; the action is allowed or rejected; the decision becomes evidence. You define the authority. Keydris expresses and evaluates it.

Your environment

Agent · presents a KIT

governed action + KIT ↓

Broker · checks the KIT · scope · expiry against your policy

↕ no authority decision completes without Keydris

in scope → executes
out of scope → blocked · recorded

Your MCP server + KIT Reader (optional) · checks inbound agent requests

KIT verification · policy check · revocation state (authorization only) ↕

Keydris platform · evaluates the authority when the boundary asks

An agent presents a KIT with each governed action to the broker in your environment, which checks its scope and expiry against your policy. No path completes that decision without Keydris today. In-scope actions execute; out-of-scope actions are blocked and recorded. An optional KIT Reader checks inbound agent requests on your MCP servers, requesting verification from the Keydris platform before the action is authorized. On these paths only the authorization crosses to Keydris, not your payloads.

Enforcement has two possible points, and you can run either or both. The broker runs in your environment and governs what your agents send out. The KIT Reader is middleware on your MCP servers governing what they accept: it checks each inbound agent request and its KIT before your server acts. Enforcement on either side of the request.

Which path enforces depends on where Keydris can sit. Where the Reader can be installed, it enforces at the authorization boundary. Where it cannot, enforcement is an in-path Keydris integration instead. That second case is why we do not tell you Keydris is never in your data path: sometimes it is. On the broker and Reader paths, your payload traffic stays in your environment and only the authorization crosses.

Verified behavior

On the broker and Reader paths, only authorization crosses the boundary: KIT verification, the policy decision, and revocation state, not your payloads. Verification itself depends on the Keydris platform: the KIT Reader evaluates at the authorization boundary by requesting verification from Keydris, and no enforcement point reaches the complete authority decision on its own. Authority is evaluable at the point of authorization, not independently of us. So if the platform is unreachable the boundary fails closed: actions that cannot be verified do not proceed. In the current platform that unavailable behavior is fixed, not operator-configured. It is separate from your policy's own default decision. A policy can (and typically should) reject unmatched actions, and that policy default is yours to author.

One crossing, fully inspected#

The agent requests a deploy. Here is what the broker sees, and the authority decision that is completed with Keydris before the action is authorized.

KIT · the authority the agent presents

organizationacme-corp

acting forrelease-eng

agentkd_agt_7c2 · claude-code

policydeploy-guard · v14

scoperepo:deploy · db:read

expires17:00Z

policy · v14 · illustrative

# deploy-guard · v14 · assigned by your operator
default: reject                    # policy default: unmatched actions are rejected
allow:
  - repo:deploy                    # env: staging | production
  - db:read
require_approval:
  - payments.refund                # renders in the agent harness
# rules compose most-restrictive on overlap · every decision
# records the policy version that made it

repo.deploy { env: staging }

KIT verified · scope repo:deploy granted · policy v14 permits

ALLOW

Audit record

kd_evt_29fa41 · decision: allow · repo.deployagent kd_agt_7c2 · acting for release-eng · policy v14outcome: executed · recorded separately from the decisionappended to the organization's trail
Decision and outcome are distinct facts. An allowed action can still fail at the provider; both facts are recorded.

The same agent, REJECT#

Now the same agent (identity unchanged, same KIT, same policy) requests something else:

db.export { table: customers }

KIT verified · identity unchanged · db:export not granted · blocked before execution

REJECT

Audit record

kd_evt_29fa42 · decision: reject · db.exportagent kd_agt_7c2 · acting for release-eng · policy v14reason: scope mismatch · rejectedappended to the organization's trail
Each action is checked independently against the same policy. A REJECT is evidence too.

This is the whole lesson of the system in two records: identity stayed the same; authority for this action did not. Nothing here inspected the agent's intent or history. The second request simply exceeded the authority the first one fit inside.

Runtime modes#

Note

The client runtime offers three deployment modes: sandbox (default; works with supported agent sandboxes, no administrator privileges), transparent (Linux host-level interception where your deployment grants it), and proxy-environment (for applications that honor proxy settings). Concurrent agent sessions stay isolated with separate identities in every mode.