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 local proxy or 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 the local proxy and broker paths only the authorization crosses to Keydris; on managed provider and MCP gateway paths Keydris participates in the data path.

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

Keydris governs the origins and paths you configure. On the local proxy, only authorization crosses to Keydris: KIT verification, the policy decision, and revocation state, not your payloads. On managed provider and MCP gateway paths, Keydris participates in the data path: it executes the request upstream with your organization's connected credential, or mints and injects a short-lived action token. No enforcement point reaches the complete authority decision on its own: it requests verification from the Keydris platform. If the platform is unreachable, the boundary fails closed and actions that cannot be verified do not proceed. That unavailable behavior is fixed platform behavior, separate from your policy's own default decision. A policy can, and typically should, reject unmatched actions; that 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 Keydris console
# 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.