P2 F5.1a: extend the fail-closed PEP core to typed proposal admission

[gnanirahulnutakki]

Goal

Extend the existing P1 read-only PEP so a closed-vocabulary typed proposal can reach the same policy hook and mandatory audit boundary without gaining any provider mutation capability.

This is a buildable F5.1 seam. It does not complete F5.1, F5.3, F5.9, or gitops.open-pr execution.

Reconciled starting state

• F5.2 is already delivered by P1: Policy-hook seam at intent boundary (allow for reads) #11 / PR feat(pep): gate hub reads through policy hook #113: all hub reads use the mandatory policy hook and audit path, and the hook supports allow, deny, and require-approval.
• F4.1 and F4.2 provide the canonical action vocabulary and exact handler-owned arg schemas.
• F4.3a P2 F4.3a: define a deterministic GitHub PR proposal plan #228 provides a planning-only gitops.open-pr adapter with no execute or verify capability.
• The current PEP Request and AuditEvent validate read action and read verbs only.
• The runtime still mounts AllowReadHook, which must continue denying every write by default.

Required contract

1. Accept only a cryptographically verified tenancy Scope and ActionProposeIntent role permission.
2. Accept only a canonical action verb from internal/intent; do not duplicate the vocabulary.
3. Bind the policy request to a SHA-256 digest of a canonical, fully resolved intent envelope, including workspace, actor, intent identifier, verb, normalized target, and validated args.
4. Carry no raw args, target attributes, file content, justification, evidence payload, credential, header, or signature into policy audit events or metrics.
5. Send the normalized proposal request through the existing PolicyHook and mandatory Auditor.
6. Distinguish deny and require-approval as fail-closed outcomes suitable for later F5.9 handling; neither outcome may be mistaken for authorization.
7. Preserve all existing read behavior and keep AllowReadHook write-denying.
8. Keep the PEP pure: no network, connector execution, hub server, MCP, local operation, filesystem, shell, credential, or dispatch dependency.

Acceptance

• Operator can present a valid proposal request to the PEP; reader, approver, admin, foreign workspace, forged actor, unknown verb, malformed digest, and nil context are refused and audited where a safe normalized request exists.
• Policy allow, deny, require-approval, hook error, invalid decision, and audit failure have distinct bounded behavior; no raw input is echoed.
• Changing any bound resolved-intent field changes the digest and invalidates the prior decision input.
• Concurrent calls are deterministic and race-clean; fuzzing proves malformed proposal inputs never panic or leak caller material.
• Boundary tests prove no mutation-capable imports or interfaces enter internal/pep.
• Existing read PEP tests and all repository gates remain green.

Deliberate non-goals

• no Ardur network adapter or built-in allow policy for writes
• no approval issuance or consumption
• no MCP elicitation or UI endpoint
• no credential minting or custody
• no connector execute or verify capability
• no F5.1 parent checkbox until all write surfaces are structurally forced through one orchestrator

Security basis

• Deny by default and validate authorization on every request: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
• Server-side ordered transaction authorization and execution-time recheck: https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html
• Identity and resource authorization without implicit network trust: https://csrc.nist.gov/pubs/sp/800/207/final

Cost

This pure in-process seam adds no provider, KMS, database, or network charge. Future Ardur, audit persistence, and credential-mint calls will add latency and external-service cost and must be measured separately.

[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.