ADR 0193: discern does not enforce at the vendor security boundary

Amendments.

• ADR 0320 — point-in-time authority: setup may exercise representative required writes and ask the host to authorize the retry, but success grants nothing, persists nothing, and does not prove that a fresh provider session loaded its integration.

Status: accepted — grounds the vendor-facing half of design principle 7 (sovereign inside, deferential outside). Builds on ADR 0082 (the Codex writable-root and narrow Git rules) and ADR 0072/ADR 0074 (provider MCP wiring). ADR 0194 leans on this record for one of its explicit nos.

discern writes into vendor configuration surfaces today, and both writes look like security decisions without their context:

• Codex's exec-policy rules (prefix_rule grants for git add/git commit, ADR 0082) exist because Codex's sandbox blocks linked worktrees from writing Git metadata under the main checkout's central .git directory — without them, a fresh Codex install cannot operate the worktree lifecycle discern scaffolds.
• MCP pre-approval (enabledMcpjsonServers in Claude Code's shared settings, and equivalents per provider) removes a manual approval step for discern's own server — a step a non-technical user would otherwise hit as unexplained friction on first contact.

Each is workflow-smoothing: it unblocks discern's own documented workflow, nothing else. But the trust-model work makes the boundary tempting: once discern records who may land what, the natural-seeming next step is enforcing at the vendor boundary — intercepting tool calls, conditionally blocking Git operations, seeding permission allowlists, hardening sandbox defaults. Three forces argue against ever taking that step:

1. Vendor security surfaces churn constantly. Sandbox models, permission schemas, and approval flows change across providers on a cadence discern cannot track without making boundary enforcement a permanent maintenance treadmill — and a stale enforcement rule at a security boundary is worse than none, because it is trusted.
2. discern cannot know a project's security requirements. It is stack-neutral by design (principle 1) and makes no assumptions about the codebase it is installed into; a generic interception rule is either too loose to matter or breaks a legitimate workflow it never anticipated.
3. discern's trust surfaces are legibility mechanisms, not security controls. The consent gates are attestations, not proofs (ADR 0134 accepts this openly); the gate verifies quality, not intent. Presenting any of it as a security boundary would promise more than it delivers, exactly where an inflated promise is most dangerous.

The vendor security boundary is not discern's to enforce. Vendor sandbox rules, permissions, and approval flows belong to the vendors; responsibility for a project's actual security stays with the user.

• discern's writes into vendor configuration are workflow-smoothing only. Each existing and future write must be justifiable as unblocking discern's own documented workflow — the two writes above are the shape of the ceiling, not a precedent for expansion.
• discern never intercepts, filters, or conditionally blocks a vendor's tool calls, never manages a vendor's security defaults, and never seeds permission rules beyond what its own workflow needs.
• discern's trust surfaces are described as legibility, not prevention — decisions made in daylight, recorded where the owner can audit them — and user-facing prose never presents them as a security control.

Reversing this stance takes a superseding record, not an incremental feature.

• Maintenance stays bounded: vendor security churn does not propagate into discern's enforcement obligations, because there are none.
• Users who want tool-call restrictions, push protection, or sandbox hardening are pointed at their vendor's native controls; this record is the reasoning behind that answer.
• The honest-marketing line survives contact with the feature roadmap: discern claims that agent decisions are on the record, never that agents cannot do wrong.
• The cost is real: some genuinely useful guardrails will not be built here, even when a user asks, and the refusal must be re-explained each time. This record exists so the re-explanation is a pointer, not a debate.

• Enforce at the boundary (tool-call interception, conditional Git blocking). Rejected: the churn treadmill, the stack-neutrality conflict, and the false promise of security discern cannot deliver.
• Write nothing into vendor config at all. Rejected: ADR 0082's rules are required for the worktree lifecycle to function under Codex at all, and forcing manual approval steps onto users contradicts the zero-config setup contract (ADR 0077).