Most systems are permissive by default and add restrictions later. You create a resource, and unless you remember to lock it down, it's reachable. The security model is a list of exceptions to "yes." This is how data leaks: not through dramatic breaches, but through the one share someone forgot to scope.

NAOMS inverts it. The base state is no. Nothing is readable, shareable, or reachable by another being unless a specific, signed, logged grant says otherwise. The Unified Consent Engine and the Consent Audit Trail are how that inversion is implemented, and both shipped and were signed off this week. The interesting part isn't the slogan "deny by default." It's that the engine makes access pass through four independent layers, each able to refuse on its own, and writes every decision to an append-only trail you can audit afterward.

Why default-deny is a structure, not a policy

"Deny by default" is easy to say and hard to mean. The cheap version is a config flag that flips the default and trusts everyone to opt into restriction correctly. The honest version makes "yes" something you have to actively construct out of cryptographic facts, so that the absence of those facts is itself the denial.

That's the design choice in the consent engine: there is no ambient permission anywhere in the system. A being's data is sealed by default (the encryption layer guarantees even a compromised database reveals nothing), and reaching it requires assembling a positive case for access that the engine can verify. No case, no access — not because a rule blocked it, but because nothing granted it.

The four layers

The consent engine evaluates access through four independent gates. The word independent is load-bearing: any single layer can deny, and a denial at any layer ends the evaluation. Access requires all four to say yes; denial requires only one to say no.

flowchart LR
  A[request] --> B[identity] --> C[trust edge] --> D[consent rule] --> E[capability token] --> F[access granted]
  B -->|no| X[denied]
  C -->|no| X
  D -->|no| X
  E -->|no| X

1. Identity. Who is asking? The requester must present a DID — a self-owned cryptographic identifier — and prove control of it by signing the request. An unauthenticated request never reaches the later layers. This is the "are you who you claim to be" gate, and it's answered by signature verification, not by a session cookie someone could steal.

2. Trust edge. Does a relationship exist that could justify this access? The engine consults the trust graph for a directed, consented edge from the data owner toward the requester of the appropriate kind and sufficient weight. No edge, no standing. This is where the relational trust model earns its keep: access is scoped to relationships you actually formed, not to anyone who happens to hold a credential.

3. Consent rule. Has the owner expressed a rule that permits this access to this data? A trust edge means "I have a relationship with you"; it does not by itself mean "you may read my health journal." The consent-rule layer is where the owner's explicit grant lives — scoped to specific memories, domains, or operations. The default here, again, is deny: in the absence of a matching rule, this layer refuses.

4. Capability token. Finally, the request must carry a valid Biscuit capability token authorizing the specific operation. Biscuit tokens are attenuable — a broad capability can be narrowed, never widened, as it's passed along — which means a grant can be delegated downstream only in more restricted form. The engine is Biscuit-first: the token is the portable, verifiable proof of authority that travels with the request, and it's checked last because it's the most specific.

Stack them and the shape is clear:

request
  → identity      (signed DID? prove it)
  → trust edge    (is there a consented relationship?)
  → consent rule  (did the owner permit THIS access?)
  → capability    (valid Biscuit for THIS operation?)
  → GRANT
any layer says no → DENY (and the request stops there)

Four gates, four different kinds of "no." You can have a relationship without a rule. A rule without a token. A token whose authority was narrowed below what this operation needs. Each failure mode is distinct, and each is independently revocable: tear down the trust edge, delete the consent rule, or revoke the token, and access ends — without touching the other three layers or re-encrypting a byte of data.

Every decision is written down: the audit trail

A consent engine you can't audit is a consent engine you have to take on faith. The Consent Audit Trail removes the faith. Every access decision the engine makes is appended to a log, and the log is hash-chained with BLAKE3: each entry includes the hash of the previous entry, so the chain is tamper-evident. You cannot quietly delete or rewrite a past decision without breaking every hash that came after it.

The trail is append-only. Grants, denials, revocations — they accrete; they are never edited in place. This is the Honesty axiom expressed as a data structure: the system cannot silently change the record of what it decided. If you were granted access on Tuesday and revoked on Thursday, both facts are in the chain, in order, provably unaltered. "Who could read this, and when, and on whose authority?" is a query against an immutable log, not a reconstruction from memory.

The pairing of the engine and the trail is the whole point. The engine makes the decisions; the trail makes them accountable. A grant you can't audit is a liability. A grant that's cryptographically logged the moment it's made is a fact you can stand behind.

Why it's built this way

Deny-by-default with four independent layers and a hash-chained audit trail is more machinery than a permissive model with an exception list. The extra machinery buys properties the cheap model can't have:

• No accidental exposure. There is no "forgot to lock it down" failure mode, because nothing is reachable until a positive grant is constructed. The dangerous default — open — does not exist.
• Independent revocation. Four layers means four independent off-switches. You can revoke a relationship, a rule, or a token without disturbing the others, and access ends at the first "no."
• Least privilege by construction. Biscuit attenuation means delegated authority can only shrink as it travels, never grow.
• Accountability. The hash-chained trail makes every decision provable after the fact, which is what turns "we have a consent model" into "here is the log of every grant we ever made, and you can verify it wasn't tampered with."

Related: Proof You Said Yes: Consent as a Signed Receipt.

The reason it's default-deny isn't paranoia. It's that in a system whose entire premise is that you own your data, "open unless restricted" is the wrong default to ever ship — it makes the safe outcome depend on the owner remembering to be careful. NAOMS makes the safe outcome the default outcome: nothing leaves until you, provably and revocably, decide it should.

Written by AI agents from real project logs; owned and edited by Mujo.