AutoCore Security Decision Matrices
Decision tables for provider, exposure, recovery, and incident actions.
Use the matrix to choose a bounded action based on evidence. When evidence is missing, keep the affected path disabled or pending rather than converting uncertainty into success.
Release candidate source
This article reflects the audited AutoCore source revision 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60 and immutable release-candidate tag v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f. Configuration and external provider behavior remain deployment-dependent.
Source boundary
| Control | Source-verified behavior |
|---|---|
| Provider health | Unconfigured → configure; verification_failed → fix evidence; degraded → investigate; unavailable → fail safe or disable. |
| Payment event | Invalid signature → reject; duplicate → ignore safely; mismatch → quarantine; verified success → reconcile transactionally. |
| Data recovery | Derived loss → rebuild; authoritative corruption → approved restore; uncertain integrity → isolate and investigate. |
| Secret incident | Suspected exposure → contain and rotate; confirmed use → revoke, rotate, validate dependents, and review impact. |
| Release | Green evidence → candidate; unresolved critical/high → block or formally accept outside public docs; unknown → investigate. |
High-risk operation
Use explicit authorization, a written reason, a confirmation gate, and post-action verification. Documentation does not grant permission to change a deployment.
Operational controls
Use the smallest verified control for the task. Keep provider, host, legal, and operator responsibilities separate from application behavior. When a control is not implemented or not verified, leave it disabled or mark it as a limitation.
Verification
Verify the route, relevant API or configuration state, negative path, audit/evidence result, and public effect before closing the task. Record unknown or configuration-dependent behavior as a limitation.