E5: Policy federation and governance

[gnanirahulnutakki]

Goal. govern the fan-out of a single intent to N clusters — one ordered enforcement pipeline, Ardur as the policy decision point and identity broker, environment gates and multi-approver flows, wave/canary ordering with a gate per wave, partial-failure and auto-rollback, idempotency, and honest abstention when the fleet view is incomplete.

Phase / depends. P1 (the policy-hook seam and pipeline shape, allowing reads) → P2 (Ardur PDP + identity broker on the first write) → P3 (the full fan-out reasoning). Depends on: E1 (identity), E2 (fleet model and staleness), and co-develops with E4 (every intent rides this pipeline). This is the genuinely novel, hard part of Sith and implements ADR-0004/ADR-0005.

Capabilities: policy federation — waves / canary / environment gates / multi-approver / abstention.

Features

• F5.1 — PEP enforcement pipeline
• F5.2 — policy-hook seam
• F5.3 — Ardur PDP integration
• F5.4 — Ardur scoped-identity broker
• F5.5 — environment gates and multi-approver
• F5.6 — wave/canary ordering with a gate per wave
• F5.7 — partial-failure semantics and auto-rollback
• F5.8 — federation-specific abstention
• F5.9 — elicited per-action approval bound to an arg-hash

Tracked issues

• P1: Policy-hook seam at intent boundary (allow for reads) #11 — F5.2 (completed by PR feat(pep): gate hub reads through policy hook #113)
• P2 F5.1a: extend the fail-closed PEP core to typed proposal admission #230 — F5.1a typed proposal admission through the fail-closed PEP core

Exit criteria

• Every intent, UI or MCP, passes one ordered PEP pipeline with no privileged path; the policy seam exists from P1.
• Ardur returns real allow/deny/require-approval verdicts, records reasons, and mints per-action scoped identities below the human ceiling.
• Prod never auto-acts; multi-cluster prod needs multiple distinct approvers; a max-clusters ceiling holds.
• A wave-ordered fan-out runs with a gate per wave and inter-wave health checks; a mid-rollout failure stops and auto-rolls-back that wave; retries dedupe.
• A stale targeted set produces a correct, logged abstention; approvals are arg-hash-bound and single-use.

---

Source: docs/EPICS.md, docs/SITH-NOTION.md · part of the Sith implementation backlog (see the master roadmap issue).

---

2026-07 research addendum (market research T4; standards §5.2)

MCP Elicitation is the native approval hook (standards §5.2). As of 2026-07-17, the latest published MCP specification is 2025-06-18. It introduced Elicitation (elicitation/create) as the standard server-initiated structured user-input primitive and explicitly requires that servers MUST NOT request sensitive information through elicitation. This is the correct published basis for Sith's per-action approval gates (F5.9, arg-hash-bound, single-use). Every governed intent — human or agent — passes the same PEP pipeline; the approval is elicited, never a header or a client-side flag.

• F5.9 acceptance: approval is elicited via the MCP elicitation primitive, bound to a hash of the resolved args, single-use; elicitation never requests secrets.

Primary source: https://modelcontextprotocol.io/specification/2025-06-18/client/elicitation

Abstention as a first-class governance output (F5.8). When the fleet view is incomplete/stale, a fleet-wide intent abstains with an honest message rather than acting on partial coverage — the same trust posture as the Investigation Brain's coverage-gate abstention (E14 #46), applied to the write path.

[gnanirahulnutakki]

F5.1a is complete through PR #231.

Landed boundary:

• immutable typed proposal binding for intent id, workspace, actor, closed verb, normalized resolved target, and validated-argument digest
• one shared fail-closed PEP path for reads and proposal admission
• deny / require-approval typed outcomes
• sanitized policy audit and bounded metrics
• invalid and tampered proposal requests are refused and audited without leaking raw proposal data
• no credential, connector, network, filesystem, shell, dispatch, approval-consumption, or execution capability

Proof:

• signed feature commit: 469d860
• dev merge: 4801a3e, with the feature commit as its second parent
• exact post-merge dev CI: https://github.com/ArdurAI/sith/actions/runs/29610488268
• exact post-merge dev CodeQL: https://github.com/ArdurAI/sith/actions/runs/29610487176
• post-merge security queues: 0 Dependabot / 0 code scanning / 0 secret scanning
• both CodeRabbit review threads resolved on the final code

F5.1 deliberately remains unchecked: this slice admits one resolved proposal but does not implement the complete phase pipeline through approval, dry-run, execution, and verification. The next dependency-safe governance slice is E6 audit-chain foundation #232.

[gnanirahulnutakki]

F5.9a durable exact single-use approval grants is complete via #250 / PR #251. The core is bound to the immutable resolved proposal digest, separates proposer/approver, uses atomic PostgreSQL consumption, stores no raw action payloads, and adds an additional-permissive-policy RLS bypass negative control. Exact dev merge 52cc1c1822d844751d5413dc8ff64f84799a87ec has green post-merge CI 29631847253 and CodeQL 29631847177; GitHub security queues are empty. MCP elicitation, PDP/multi-approver policy, credentials, connector dispatch, and production mutation remain outside this completed slice.

[gnanirahulnutakki]

F5.9b design escalation — approval lifetime

Confirmed gap. The durable grant added by #250 has no expires_at. If it is never consumed and the exact proposal binding plus current membership still match, it can remain usable indefinitely. That is incompatible with the intended fresh, per-action authorization posture.

What primary sources establish

• OWASP Transaction Authorization §2.9 requires authorization credentials to be valid only for a limited server-enforced window, but explicitly says the period must be selected to avoid disrupting normal user behavior: https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html#authorization-credentials-should-only-be-valid-during-a-limited-time-period
• MCP 2025-06-18 Elicitation defines accept/decline/cancel and contains no expiry contract: https://modelcontextprotocol.io/specification/2025-06-18/client/elicitation
• RFC 6749 §4.1.2 recommends at most 10 minutes for an OAuth authorization code: https://www.rfc-editor.org/rfc/rfc6749.html#section-4.1.2. That is useful security precedent, but Sith's approval grant is not an OAuth authorization code, so 10 minutes would be an explicit product inference rather than a standards mandate.

Decision required from GR

1. Fixed 10-minute absolute lifetime (recommended for the first-write seam). Smallest contract; fresh enough to limit delayed replay; no mutable operator policy. The usable interval is half-open: approved_at <= consumed_at < expires_at.
2. Operator-selected lifetime capped at 10 minutes. More flexible, but adds configuration, validation, rollout, and drift surface before real PDP/dispatch behavior exists.
3. PDP-selected lifetime capped server-side. Best eventual policy ownership, but blocked on F5.3's real Ardur PDP contract.

I recommend option 1 now, with expiry immutable, bound into the lifecycle evidence digest, retained after expiry for forensics, and checked in the same conditional UPDATE that consumes the grant. Expiry must return the existing indistinguishable ErrApprovalGrantUnavailable, append no successful lifecycle event, and leave consumed_at unchanged.

No code issue is being opened until this security/product choice is made. The backlog run will pivot rather than stall.