Policies

# illustrative · authored visually or from a template
default: reject                    # the safe default
actions:
  - allow: repo.read_file, repo.deploy
    where: repo in [keydris/api], branch in [main]
  - allow: mcp.call_tool
    where: server in [internal-tools]
  - allow: slack.read_history
    where: channel in [#deploys]
  - require_approval: crm.export_contacts
# unmatched or unsupported action types are rejected

• Rules name governed actions and carry one of three decisions: ALLOW, REJECT, or APPROVAL REQUIRED (written allow, reject, and require_approval in the policy above).
• Conditions scope a rule: the resource, repository, branch, channel, MCP server or provider it applies to, and, in a limited form, the environment. A condition can also bind a vault credential the action must use. The credential itself is never exposed to the policy or the agent.
• The default decision catches everything no rule matches. Reject-by-default is the pattern these docs assume everywhere.

Preview and lint a policy before relying on it: the builder shows a plain-English summary of what you've authored, and flags rules that can never match or that conflict.

Looking to stop a running agent rather than change its rules? That's revocation, not policy editing. See KITs & devices.

Saving a policy compiles it to a versioned, enforceable module. The version matters for evidence: every audit record names the policy version that decided it, so a decision from last March is judged by the policy as it stood last March, not as it stands today.