Skip to main content
AI SYNDICATE

AI SYNDICATE

Review enforcement evidence for regulated AI execution.

Product
ProductsPricingTrust CenterFinancial Services
Governance
AI Execution GovernanceAI Agent GovernancePre-Execution GovernanceAI Agent Audit TrailAI Approval WorkflowsRegulated Enterprise
Learn
All GuidesAssessmentsAI Workflow Risk AssessmentGoverned Agentic SystemsIncident ReconstructionCase StudiesCompareBlog
Company
AboutMarketplacePartners
Book Boundary Review
← Back to Docs

Auditor Checklist for Fail-Closed AI Controls

This page defines the third-party audit workflow required to assess compliance with INV-1 through INV-6.

INV-1INV-2INV-3INV-4INV-5INV-6

Spec Drift Warning

Changes to implementation that violate invariant mappings invalidate compliance with v1.0. Implementations MUST preserve invariant-to-component, invariant-to-artifact, and invariant-to-verification-step mapping.

Compliance Assertion

  • • Defines an auditor-executable review path from invariant to artifact to verification outcome.

Non-Compliance Results In

  • • Any failed checklist item invalidates compliance with v1.0 until remediated and re-verified.

Audit Preconditions

Invariant Mapping: ALL INVARIANTS

Each item tests whether the execution path can demonstrate approval before execution and whether that approval was bound to the parameters that actually ran.

  • • Auditor MUST have access to the v1.0 specification.
  • • Auditor MUST have access to the implementation contract under /docs.
  • • Auditor MUST have access to the verification kit or implementation-equivalent artifact set.
  • • Auditor MUST evaluate both successful and denied execution paths.

Approval Before Execution

Invariant Mapping: INV-1, INV-2

Approval before execution is the minimum evidence standard for governed AI actions. The reviewer must verify that approval existed before the action ran and that the executed parameters stayed inside the approved scope.

  • • The approval envelope MUST exist before the side-effecting action executes.
  • • The approval envelope MUST identify the requester, approver, policy version, target action, and approved parameter bounds.
  • • Execution MUST be denied when approval is missing, expired, unverifiable, or mismatched to the requested parameters.

Invariant Checklist

Invariant Mapping: ALL INVARIANTS

InvariantRequirementArtifactAudit TestFailure Condition
INV-1Execution occurs only after a valid approval envelope exists.approval-001.jsonVerify Control Plane signature and envelope presence before execution.Missing or unverifiable approval envelope.
INV-2Executed parameters match approved bounds.approval-001.json + audit-chain-001.jsonCompare approved bounds with executed parameters; confirm no silent truncation.Executed parameters exceed bounds or were silently altered.
INV-3Identity, timestamp, and nonce are cryptographically attributable.request-001.json + identity-keys.jsonVerify request signature, timestamp window, and replay controls.Invalid signature, expired timestamp, or replay not denied.
INV-4Failure behavior is denial, not degraded execution.verification walkthrough + failure testsReview outage and partition outcomes; confirm denial path.Any failure mode produces execution instead of denial.
INV-5Every request produces attributable audit evidence, including denials.audit-chain-001.jsonVerify audit record presence, hash continuity, request_hash, and trace_id linkage.Missing denial records, broken hash chain, or missing linkage.
INV-6All execution paths route through Gate. No unauthenticated interfaces exist.boundary controls + audit-chain-001.json + bypass testsValidate network/runtime boundary closure and direct bypass rejection.Any bypassable execution path or direct execution interface.

Audit Decision Rules

Invariant Mapping: ALL INVARIANTS

  • • If any invariant fails, the implementation SHALL be classified as non-compliant.
  • • If any artifact required for verification is missing, the implementation SHALL be classified as non-compliant.
  • • If observed behavior conflicts with the implementation contract, the implementation SHALL be classified as non-compliant.
  • • Compliance MAY be re-established only after remediation and repeated verification.

Required Outputs

Invariant Mapping: ALL INVARIANTS

  • • Auditor MUST record pass or fail per invariant.
  • • Auditor MUST record the artifact reviewed for each invariant.
  • • Auditor MUST record the exact failed check for every non-compliant result.
  • • Auditor MUST record whether spec drift was observed.

Verification Linkage

INV-1

Artifact: approval-001.json

Check: Approval envelope present and valid before execution

Verification step: verify.sh: INV-1

INV-2

Artifact: approval-001.json + audit-chain-001.json

Check: Executed parameters remain within approved bounds

Verification step: verify.sh: INV-2

INV-3

Artifact: request-001.json + identity-keys.json

Check: Signature, timestamp, and nonce verification succeed

Verification step: verify.sh: INV-3

INV-4

Artifact: verification walkthrough

Check: Failure scenarios deny execution

Verification step: Adversarial scenarios 4 and 5

INV-5

Artifact: audit-chain-001.json

Check: Audit chain continuity and attribution hold

Verification step: verify.sh: INV-5

INV-6

Artifact: audit-chain-001.json + boundary controls

Check: Gate-only execution boundary remains closed

Verification step: verify.sh: INV-6

Use This Checklist In A Technical Review

Invariant Mapping: ALL INVARIANTS

If your current AI deployment cannot map each side-effecting action to authorization, parameter bounds, denial behavior, and evidence continuity, the gap should be reviewed before production expansion.