Runtime permission model: trust hierarchy and policy configurability #3

New Issue

mikael-lovqvists-claude-agent · 2026-03-17T23:07:22Z

2026-03-17 23:07:22 +00:00

Background

Currently per-action policy (auto-accept / queue / auto-deny) is hardcoded in actions.mjs. The canApprove relationships live in secrets.json (static, out-of-band). Mail permissions are already runtime-configurable, gated by canApprove. The question is how far to extend this pattern.

The core tension

Making policies runtime-configurable is useful — e.g. switching send-email to queue without restarting the server. But it creates an elevation risk: if an agent can request a policy change and that change is auto-accepted, it could lower its own oversight.

The non-negotiable constraint

canApprove must never be runtime-writable. It is the root of the trust hierarchy. All runtime permission changes must be gated by it, and nothing runtime should be able to modify it.

Possible paths forward

Option A: Runtime policy overrides (per-action)

A separate store (like mail_perms) holds policy overrides
Changes gated by canApprove of the requesting user
Falls back to the default policy defined in actions.mjs if no override exists
Agent can request a policy change, but it goes through the queue — human approves

Option B: Extend the TUI

Policy management, mail permissions, and queue all in one place
Human-only UI, no API surface for policy changes
Simpler trust model but less flexible

Option C: Config file (not secrets)

Separate config.json (not secret, can be in git) holds policy overrides
Edited manually by the human, no runtime API
Simple but requires server restart or a reload signal

Questions to resolve before implementing

Should an agent ever be able to request a policy change (queued for approval), or is that surface too risky?
Is per-action policy granularity enough, or do we need per-action-per-user policies?
Does the TUI scope expand to cover this, or stay focused on queue management?

## Background Currently per-action policy (`auto-accept` / `queue` / `auto-deny`) is hardcoded in `actions.mjs`. The `canApprove` relationships live in `secrets.json` (static, out-of-band). Mail permissions are already runtime-configurable, gated by `canApprove`. The question is how far to extend this pattern. ## The core tension Making policies runtime-configurable is useful — e.g. switching `send-email` to `queue` without restarting the server. But it creates an elevation risk: if an agent can request a policy change and that change is auto-accepted, it could lower its own oversight. ## The non-negotiable constraint **`canApprove` must never be runtime-writable.** It is the root of the trust hierarchy. All runtime permission changes must be gated by it, and nothing runtime should be able to modify it. ## Possible paths forward ### Option A: Runtime policy overrides (per-action) - A separate store (like `mail_perms`) holds policy overrides - Changes gated by `canApprove` of the requesting user - Falls back to the default policy defined in `actions.mjs` if no override exists - Agent can request a policy change, but it goes through the queue — human approves ### Option B: Extend the TUI - Policy management, mail permissions, and queue all in one place - Human-only UI, no API surface for policy changes - Simpler trust model but less flexible ### Option C: Config file (not secrets) - Separate `config.json` (not secret, can be in git) holds policy overrides - Edited manually by the human, no runtime API - Simple but requires server restart or a reload signal ## Questions to resolve before implementing - Should an agent ever be able to *request* a policy change (queued for approval), or is that surface too risky? - Is per-action policy granularity enough, or do we need per-action-per-user policies? - Does the TUI scope expand to cover this, or stay focused on queue management?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mikael-lovqvists-claude-agent/claude-code-conduit#3