Security
Failure modes
Fail-closed rule
Safety under partial failure.
“In all failure scenarios, execution is blocked or hard-failed — never allowed to proceed.”
Verification checklist
Validate that fail-closed behavior is working end-to-end.
Expected invariant: BLOCK or hard-fail — never PASS.
1) Service unavailable (network outage, upstream dependency outage) → validation must be treated as a hard stop; caller must not execute.
2) Corrupt JSON body → validate returns 400 and records a BLOCK validation event.
3) Invalid payload format → validate returns 400 and records a BLOCK validation event.
4) Unknown ActionKind → validate returns BLOCK (deterministic deny).
5) Abuse-control failures → requests are blocked (fail-closed) rather than allowed.
Service unavailable
Enforcement cannot safely evaluate.
If the service is unavailable, validation endpoints hard-fail.
Your system must treat this as blocked and avoid executing the action.
Partial failures are treated as hard failures rather than allowing execution.
Misconfiguration
Safety configuration is part of enforcement integrity.
Misconfiguration causes hard failure.
Do not treat configuration errors as a reason to proceed.
Validation errors
Malformed payloads must not execute.
Invalid JSON or invalid payloads receive hard errors (4xx).
Callers must fail-closed and stop execution when validation fails.
Unknown ActionKind
Unknown actions are blocked by default.
If the action type is unknown, enforcement cannot be deterministic.
Outcome is blocked / hard-failed rather than allowed to proceed.
Disclaimer
This documentation is provided for general information only. It is not legal advice, not a guarantee of compliance, and not a substitute for your own security review. You are responsible for evaluating and meeting any legal, regulatory, and contractual obligations applicable to your use case.