Omar SobhandClaude Opus 5
2656d73def
cm_decide:🚪 three Nouls per outbound action (data leaving the organisation, a credential in the content, unsolicited/abusive), the max is the deny probability. Measured on 24 hand-labelled door actions (eval/door-actions.json): AUROC 1.000, [email protected] 0.96, no false denies, no misses, 4 of 24 in the review band — three deny-labelled actions it would not refuse alone (db dump 0.71, delegate-exfil 0.74, threat 0.77) and the one genuinely borderline allow (repo name to a contractor 0.56). 168 ms, ~600 tokens per action, off the z.ai quota. mcp_door: PolicyOutcome::Hold. With TYPESAFE_API_KEY set, above DENY_AT (0.8) refused, below ALLOW_BELOW (0.2) executed, between them the action gets a pending approval (session_key door:<id>) and the agent is told it is queued and not to retry. The approvals route recognises a held door action and executes it on approve — the grant decide mints, the tool consumes — rather than resuming a chat run. The chat-model governor stays as the fallback without a key; it has no middle band. Fail-closed on an unreachable or malformed answer. Thresholds overridable per deployment (CLAWMATES_DOOR_DENY_AT / _ALLOW_BELOW). decide-eval --kind door reports the band outcome, not only a threshold. Harness: a door scenario exercising all three bands directly against /mcp with email_send (its effect is an outbox row), then approving the held one and checking it executes then and not before. Co-Authored-By: Claude Opus 5 <[email protected]>