CerbaSeal Security Summary

Security posture summary

Not yet third-party reviewed

status: not_yet_third_party_reviewed

CerbaSeal is currently a deterministic enforcement library and demo with no external API calls, no database, and no authentication layer. Security review should focus on enforcement integrity, bypass resistance, evidence integrity, replay correctness, and deployment assumptions. The in-memory audit log, caller-supplied fields, and absence of cryptographic signing are known limitations documented below.

Implemented controls

Control	Invariant / Fix	Tested
AI non-authority invariant — AI actor + AI proposal → always REJECT	INV-05	✓ yes
Approval artifact binding — forRequestId must match request.requestId exactly	INV-03 / Fix 1	✓ yes
Workflow-level approval enforcement — fraud_triage always requires approval	Fix 2	✓ yes
Gate issuance registry — WeakSet prevents forged GateResults entering evidence layer	INV-06 / Fix 3	✓ yes
Fail-closed catch-all — all unexpected exceptions produce controlled REJECT	Fix 6	✓ yes
Known action class validation — proposedActionClass must be a valid member	INV-11	✓ yes
Proposal/request action match — proposedActionClass must equal requestedActionClass	INV-12	✓ yes
Policy pack required — no execution without policyPackRef	INV-01	✓ yes
Provenance required — modelVersion, ruleSetVersion, sourceHash all non-empty	INV-02	✓ yes
Logging readiness required — loggingReady must be true	INV-04	✓ yes
Trust state required — trustState.trusted must be true	INV-09	✓ yes
Stale controls block sensitive release — criticalControlsValid + not stale	INV-08	✓ yes
Prohibited use immediate reject — prohibitedUse:true → REJECT before other checks	INV-10	✓ yes
Immutable decision envelope — immutable literal true on every code path	INV-07	✓ yes
Evidence bundle deep cloning — no shared mutable references in bundles	EvidenceBundleService	✓ yes
Append-only audit log with SHA-256 hash chaining (entryHash over previousHash)	AppendOnlyLogService	✓ yes
Export hash verification by index — not just count	Fix 5	✓ yes
requestId non-empty validation	INV-11 / Fix 7	✓ yes

Threats covered

Threat	Control	Tested
AI attempts to authorize its own action	INV-05	✓ yes
Caller bypasses gate by constructing GateResult directly	INV-06 WeakSet	✓ yes
Caller reuses approval artifact from another request	INV-03 forRequestId binding	✓ yes
Caller omits approvalRequired flag for gated workflow	Fix 2	✓ yes
Caller supplies forged GateResult to evidence layer	assertIsGateIssued	✓ yes
Caller mutates evidence bundle after creation	deep clone	✓ yes
Caller omits provenance	INV-02	✓ yes
Caller provides stale controls on sensitive request	INV-08	✓ yes
Caller provides malformed or unknown action class	INV-11	✓ yes
Caller mismatches proposed and requested action class	INV-12	✓ yes
Caller attempts prohibited use	INV-10	✓ yes
Unexpected exception produces silent ALLOW	Fix 6	✓ yes

Known limitations — clearly stated

Audit log is in-memory — not persisted across process restarts
No cryptographic signing — evidence is hash-linked, not key-signed or attested
No identity provider — actor identity is caller-supplied with no independent attestation
No persistent storage — all state exists per process instance
No production deployment hardening
No third-party security review completed yet
loggingReady is caller-declared — gate does not verify actual log system health
immutableSignature content is not cryptographically verified — any non-empty string passes
SHA-256 hash chain proves consistency, not origin — fabricated chain with recomputed hashes passes verifyChain()

Known Limitations / Not Yet Solved

Listed without softening. These are real boundaries of the current build.

No cryptographic signing of evidence artifacts
No identity verification (actor is caller-supplied)
Audit log is in-memory (not persistent)
No external system health verification (loggingReady is declared, not checked)
No deployment hardening for production environments
No third-party security review completed
Hash chain proves consistency, not origin authenticity
No multi-tenant isolation model
No access control layer

What Would Need To Change For Production

These items are required before production deployment with real client data.

persistent storage layer
cryptographic signing / attestation
identity provider integration
deployment hardening
monitoring + alerting
external security review

Claim discipline

Claim	Status
AI cannot produce authority-bearing actions	Code Tests
Approval artifacts are request-bound	Code Tests
All errors fail closed	Code Tests
Evidence bundles are immutable after creation	Code Tests
Replay matches original outcomes	Code Tests
Evidence is cryptographically signed	Not implemented
Identity of callers is independently verified	Not implemented
Third-party security review complete	Requires review
Production-ready for client deployment	Future deployment requirement