Risk: MCP agent can produce authoritative sign-offs without per-action human authority (H5)

[CST-100]

Type: Risk (register-style tracking issue) · Origin: security audit finding H5 (full audit report + design note kept as local working notes; this issue is self-contained)

Risk statement

Agent-driven MCP can produce authoritative human records — quality sign-offs (disposition, risk acceptance/review), requirement baselines, and part-lifecycle activation — without genuine per-action human authority. Today a "signature" is a plain attribution field the agent supplies (user_id), so the agent can attribute or perform an authoritative action in place of a human. The record is not bound to its content and is not non-repudiable.

Category

Security · data/audit integrity · compliance (the affected records are the AS9100/ISO-style "a human decided this" artifacts).

Impact

A forged or agent-performed sign-off silently undermines the audit trail that dispositions, baselines, and activations exist to provide. High consequence for any regulated or customer-facing quality claim.

Likelihood

Low in the trusted-LAN posture — the MCP transport is stdio-only and anyone who can run it already has DB access — but the integrity property ("only a human can sign") is violated by design, independent of an attacker.

Current controls / mitigation in progress (PR #75)

• Partial H5 already shipped: sign_disposition requires an active human; attach_to_step path-confined.
• Level 1 (this PR): the agent is blocked from pure-judgment sign-offs (sign_disposition, accept_risk, set_risk_disposition, stamp_risk_review, baseline_batch, reaffirm_requirement) — draft/prepare only; a human commits in OPAL. Identity is no longer agent-chosen.
• Part activation (activate_part, bulk_activate_parts): gated behind a default-off, admin-enabled per-project opt-in; blocker checks still enforced; attributed as agent-performed and audit-logged (activation is a mechanical blockers-only gate, not pure human judgment).

Residual risk (why this stays open)

• No per-action human consent or non-repudiation yet: the activation opt-in is a blanket standing authorization; nothing binds a human to a specific record.
• Gray-area tools unresolved: complete_step (emits immutable genealogy/output), bind_issue_hold.
• Signatures are still attribution FKs, not content-bound cryptographic signatures.

Treatment plan (deferred design — the "thought problem")

• Level 2 as the norm: agent proposes → a human approves in the OPAL web UI under their own login (per-action consent). Target end-state.
• Level 3 (regulated clients): WebAuthn assertion over a canonical record hash → non-repudiable, tamper-evident e-signature. OPAL already stores per-user passkeys.
• Decide the strategy for which actions an agent may ever be granted authority over, and under what standing/granted authorization.

The ladder (why per-action human authority needs an out-of-band gesture)

Any signature the agent can produce on its own, it can forge — so binding a real human to a specific sign-off requires an action through a channel the agent does not control. Keys don't remove the human gesture; they make it cryptographic.

Level	Mechanism	Agent can forge?	Proves human saw this record?
0 (today)	agent passes user_id	yes	no
1 (this PR)	authoritative tools refuse for the agent; draft/prepare only	no	n/a — human commits in OPAL
2 (target norm)	agent creates a pending record; a human approves it in the web UI under their own login	no	yes
3 (regulated)	human signs a hash of the record with a private key (OPAL already stores per-user passkeys); server verifies	no	yes, + non-repudiable + tamper-evident

Open questions

• Smallest set of actions an agent may ever be authorized to commit, and what authorizes it.
• Does complete_step count as an immutable change or routine attribution? (It emits genealogy/output.)
• Level 2 mechanics: pending-approval queue, notification, expiry, how the agent observes completion.
• Level 3: canonical record hashing; storing/verifying the WebAuthn assertion; passkey-absent behavior.

Owner

TBD

References

• src/opal/mcp/server.py → _require_human_user
• PR Security hardening for v1.4.0 #75 (Level 1 mitigation)
• Security audit finding H5 (report kept as a local working note)

[CST-100]

Follow-up surfaced while implementing Level 1: publish_version publishes an immutable procedure version but has no human gate today (it never went through _require_human_user). It wasn't in the decided Level 1 set, so it's intentionally left as-is for now — but it's arguably an authoritative/immutable act in the same family and should be classified under the gray-area review (alongside complete_step, bind_issue_hold). Noting so it isn't lost.