Fail-closed execution enforcement

Technical specification: policy-before-execution, argument-bound approvals, fail-closed defaults, and normative invariants.

This is not logging. This is enforcement.

1. Concept Definition

Fail-closed execution enforcement is the system property that prevents any action from executing unless it has explicitly passed policy evaluation and obtained a valid approval binding. The system defaults to denial when confidence in approval state is absent, degraded, or ambiguous.

This is distinct from logging-only systems (which record actions after execution but do not prevent unauthorized execution) and fail-open systems (which permit execution when evaluation cannot be completed).

The core principle: the absence of a valid approval is insufficient to permit execution.

This document is v1.0 of the AI Syndicate Fail-Closed Execution Enforcement Specification. Other implementations claiming fail-closed behavior SHOULD be evaluated against these invariants.

2. System Model

The system comprises three components:

Syndicate Gate (Gateway): First checkpoint for all execution requests. Normalizes incoming requests into signed envelopes. Performs pre-flight validation. Executes at request time, not callback time. Mounted as a network-level proxy to prevent bypass.

Syndicate Control Plane: Policy evaluation engine. Binds approvals to specific parameter sets. Maintains approval state and audit records. Returns signed approval envelopes to Gate.

Execution Layer: Receives approved envelopes from Gate. Executes only parameters within approval bounds. Reports execution outcome to audit system.

Trust Boundaries:
• Gate trusts Control Plane only when responses signed with control plane's verifiable key
• Execution Layer trusts Gate only when presenting valid approval envelope
• No component trusts any other component without cryptographic verification of identity

3. System Invariants (NORMATIVE)

The following invariants MUST hold for the system to be considered fail-closed. These are normative requirements, not suggested behavior.

INV-1: Pre-Execution Policy Check
Any action submitted for execution MUST have passed policy evaluation. The system SHALL block execution attempts that have not received a signed approval envelope.

INV-2: Parameter Binding
An approval MUST be bound to a specific, bounded parameter set. Execution SHALL proceed only with parameters that fall within the approved bounds. Parameters outside approved bounds MUST be denied, not silently truncated.

INV-3: Cryptographic Attribution
Every approval MUST be attributable to a specific identity and timestamp. Approval envelopes MUST contain: requester identity, approval timestamp, and a nonce that prevents replay.

INV-4: Fail-Closed Default
When approval state cannot be verified, execution MUST NOT proceed. The system SHALL deny on: missing approval, invalid signature, expired approval, or Control Plane unavailability.

INV-5: Audit Attribution
Every execution decision (including denial) MUST be attributable. The system SHALL emit an audit record for every request.

INV-6: Enforcement Completeness
All execution-capable entry points MUST pass through Gate. No unauthenticated execution interfaces SHALL be exposed.

4. Parameter Bounds Enforcement

CRITICAL: The handling of parameters outside approved bounds is a security-sensitive operation.

Behavior by default: REJECT

Parameter bounds are expressed as prefix matches and regex constraints:
{
  "tool": "^database_query$",
  "query": "^SELECT.*FROM users WHERE id = .+$",
  "params": "^[a-zA-Z0-9_]+$"
}

Validation rules:
1. For each parameter: check against its bounds pattern
2. If parameter matches bounds: execute with original parameter
3. If parameter exceeds bounds: attempt narrowing to bounds pattern
4. If narrowing produces valid, semantically-safe transformation: execute with narrowed parameters
5. If narrowing is not provably safe: DENY execution

DO NOT TRUNCATE: Silent truncation of parameters CAN change semantic meaning. The system denies by default. Truncation/narrowing only occurs when:
• Transformation is provably safe (e.g., regex capture group extraction)
• Transformation is explicitly configured as allowed by policy
• Audit record reflects original vs narrowed parameters

Example rejection (MUST):
Input: "SELECT * FROM users WHERE id = 'abc'; DROP TABLE users;"
Bounds: query must start with "SELECT"
Result: DENIED_BOUNDS_EXCEEDED

5. Enforcement Mechanisms

Pre-Execution Policy Check: Gate validates request signature, checks local approval cache, requests approval if cache miss, verifies Control Plane signature, extracts parameter bounds, denies or narrows parameters before forwarding.

Cryptographic Attribution: Verify signature against identity's registered public key. Check timestamp within acceptance window (default 5 minutes, configurable per deployment). Verify unused nonce. Record nonce in replay prevention store.

Replay Protection (NORMATIVE):
• Nonce MUST be unique per (identity, action, timestamp_window)
• Retention: configurable (default 24 hours)
• Storage MUST provide strong consistency for replay prevention
• Under eventual consistency, duplicate execution MAY occur if two replays race before nonce write propagates

System Behavior Under Partition:
| Condition                  | Behavior              |
| -------------------------- | ------------------- |
| Control Plane unreachable  | Deny all execution  |
| Replay store unavailable  | Deny execution      |
| Partial quorum           | Deny execution     |
| Gate partitioned        | Deny all execution  |

6. Enforcement Boundary (COMPLETE)

How enforcement is made mandatory:

Network-Level Enforcement: Gate MUST be mounted as a required network proxy. All execution traffic MUST route through Gate. Bypass is prevented by:
• Firewall rules blocking direct execution layer access
• Network segmentation isolating execution layer
• Service mesh policies requiring sidecar proxy

SDK-Level Enforcement: Official SDKs enforce envelope validation. Direct HTTP calls without envelope MUST be rejected at execution layer. SDKs enforce:
• Envelope attachment required
• Signature validation
• Parameter bounds extraction

Runtime-Level Enforcement: For containerized deployments, admission controllers verify approval before pod scheduling. Non-approved workloads MUST be rejected.

EXECUTION PATH REQUIREMENTS (NORMATIVE):

All of the following execution paths MUST be covered:
1. Direct API calls (HTTP/gRPC) — MUST route through Gate
2. SDK invocations — MUST include valid envelope
3. Background jobs — MUST obtain approval before execution
4. Cron-style scheduled tasks — MUST use pre-obtained approval with TTL
5. Async workers/message queues — MUST verify approval envelope before execution
6. Internal service-to-service calls — MUST carry valid envelope
7. Stream subscriptions — MUST verify approval before processing events
8. SDK escape hatches — NOT PERMITTED

No unauthenticated execution interfaces are exposed. If Gate is not in-path, execution does not occur.

7. Failure Mode Analysis

Control Plane Unavailable: Gate detects connection failure. Denies execution immediately. Audit record: DENIED_CONTROL_PLAN_UNAVAILABLE. Fails safely — no execution without approval. Risk: service availability impact during outage.

Approval Cache Corruption: Gate detects invalid cache entry, re-requests approval. If Control Plane reachable: obtains valid approval. If unreachable: denies execution. Fails safely.

Clock Skew: Timestamp validation uses system clock, not client clock. Requests outside acceptance window denied. Fails safely.

Partial System Degradation: Gate maintains fail-closed posture. All requests denied until degradation resolved. Fails safely — degraded approval triggers global denial.

Async Drift (KNOWN LIMITATION): Approvals bound to parameter values at approval time. Race conditions between approval and external state changes are NOT eliminated. Mitigation: short TTLs for time-sensitive approvals or state version binding.

Key Compromise: If Control Plane signing key compromised, attacker can forge approvals. Detection: key rotation cadence, anomaly detection. Recovery: key revocation, identity re-enrollment. Explicit assumption: key security required for fail-closed guarantees.

Execution Layer Compromise: If execution layer compromised, could execute without approval. Detection: execution audit vs approval audit correlation. Recovery: redeploy, rotated credentials. Explicit assumption: execution environment integrity required.

8. Adversarial Scenarios

Direct Execution Bypass: Attacker sends request directly to execution layer. Execution layer requires valid approval envelope. Requests without envelope rejected. Audit record for bypass attempt.

Parameter Mutation: Attacker modifies parameters after approval. Modified parameters must match approved bounds. Mutated parameters exceed bounds: DENIED_BOUNDS_EXCEEDED. No silent narrowing.

Replay Attack: Attacker replays captured valid request. Nonce validation detects replay. Used nonce rejected. Execution denied. Audit: DENIED_REPLAY.

Signature Forgery: Attacker forges signature claiming valid identity. Public keys registered in identity store. Unknown or revoked keys fail verification. Audit: DENIED_SIGNATURE_INVALID.

Approval Envelope Tampering: Attacker modifies envelope after issuance. Gate verifies envelope signature. Tampered envelope fails verification. Audit: DENIED_ENVELOPE_TAMPERED.

Control Plane Key Compromise: Attacker obtains control plane private key. Can forge approvals. Expected behavior: system continues until key revocation. Explicit: fail-closed assumes key integrity.

9. Key Management

Key compromise is a structural risk, not merely an operational one.

Key Types:
1. Control Plane signing key: Signs approval envelopes. Compromise enables forged approvals.
2. Identity keys: Sign requests. Compromise enables impersonation.

Structural Mitigations:
• Keys stored in HSM or secure key management service
• Separation between signing and verification functions
• Short-lived signing keys with automatic rotation
• Key usage policies restricting operations per key

Key Rotation:
• Signing keys: rotated every 90 days (configurable)
• Emergency rotation: available via API/console
• Revocation: immediate for compromised keys
• Re-enrollment: required after key rotation

Blast Radius on Compromise:
• Control Plane key: attacker can issue arbitrary approvals until revocation
• Identity keys: attacker can impersonate user until key revocation

Recovery Procedure:
1. Detect compromise via anomaly detection
2. Revoke compromised key(s) via control plane API
3. Re-enroll identity with new key
4. Rotate Control Plane signing key
5. Audit all approvals issued during compromise window

Explicit Requirement: Fail-closed guarantees REQUIRE integrity of Control Plane signing keys.

10. Audit Model

Append-only audit logs with hash chaining:

{
  "record_id": "log_abc123",
  "sequence": 12345,
  "previous_hash": "hash_previous_record",
  "timestamp": 1712841600,
  "identity": "user_id_xyz",
  "decision": "APPROVED",
  "approval_id": "apr_abc123",
  "trace_id": "trace_xyz",
  "request_hash": "hash_request",
  "data_hash": "sha256(log_data)"
}

Evidence linking: Records chained via previous_hash. trace_id links all records for single request. request_hash enables correlation.

Verification procedure for auditors (NORMATIVE):
1. Retrieve log chain from storage
2. Verify hash continuity (each record's previous_hash matches prior record's data_hash)
3. Verify request_hash matches specific trace
4. Cross-reference approval_id with approval store

For higher assurance: periodic hash publication to external timestamp service (RFC 3161) provides independent proof of log state.

Completeness: All decisions logged. No selective omission of denied requests.

11. Trusted Components and Assumptions

This specification requires explicit trust in the following components. Guarantees do not extend beyond these boundaries.

TRUSTED COMPONENTS:
1. Control Plane: Policy evaluation logic and signing key integrity
2. Execution Layer: Proper envelope validation before execution
3. Gate: Correct routing and validation
4. Audit System: Integrity of log records

TRUST ASSUMPTIONS:
1. Control Plane signing key is secure and not compromised
2. Execution layer runs unmodified code with envelope validation
3. Network segmentation prevents bypass of Gate
4. Time synchronization within 5 minutes across all hosts
5. Strong consistency available for replay prevention store

GUARANTEE BOUNDARIES:
Fail-closed guarantees do NOT extend to:
• Control Plane compromise (until revocation)
• Execution layer compromise (enables bypass)
• Enforcement bypass (out-of-band execution)
• Eventual consistency deployments (race conditions possible)
• External system data correctness

This specification is NOT responsible for:
• Identity enrollment authenticity (assumed trusted)
• Execution layer code correctness (validated separately)
• Network infrastructure security (assumed isolated)

12. Canonical Statements

DEFINITIVE POSITIONS (for reference):

"A system is fail-closed if the absence of verifiable approval results in denial, not execution."

"Fail-closed enforcement requires explicit approval for every action. No action executes without a valid, bound approval envelope."

"Enforcement is mandatory in-path. Bypass is prevented by network segmentation, not trust."

"Parameter narrowing is deny-by-default. Silent truncation is prohibited."

"All execution paths MUST route through Gate. No unauthenticated execution interfaces are exposed."

"For replay prevention under distributed conditions, strong consistency is REQUIRED. Eventual consistency introduces race conditions."

"System behavior under partition: denial, not degradation."

"The specification requires explicit trust in Control Plane, Execution Layer, Gate, and Audit System. Guarantees do not extend beyond these boundaries."

"The system does not prevent all harm. It prevents unauthorized execution. Operator responsibility includes identity revocation, policy scope, and understanding of residual risk."