Granular access control: per-verb permissions, denials, and the _acl block

[coodos]

Records in an eVault now carry their own access rules: who may read, add, change, or delete them, held inside the record so the policy travels with the data when it syncs.

This implements the list half of the access control design — grants, denials, and the decision order. The Resource Link Ontology half (resolving a platform's score and comparing it) is left as an injected seam, since the scoring side already exists elsewhere.

The problem

Platforms have no access controls between them. Any platform holding a valid Registry-issued token can reach anything that syncs to it, and the legacy acl array is all-or-nothing — there is no read-without-write except ["*"], which is what essentially every record in the system is written with today.

What is here

A policy engine (infrastructure/evault-core/src/core/acl/) — pure, no I/O:

• Permissions as a bitmask: 0x01 READ, 0x02 CREATE, 0x04 UPDATE, 0x08 DELETE. 0x03 expresses add-only access. Reserved bits 4-7 are rejected on write and stripped on read; 0x00 counts as no grant rather than an empty one.
• Most-specific-wins: a user grant beats a platform grant beats a group grant, with no union across specificity. Grants tied at the same specificity are unioned, so the outcome does not depend on storage order.
• Denials always win, by eName (matching the party, the platform carrying its request, or a group it belongs to) or by a failing condition.
• Decision order: denials, then the single most specific grant, then the require groups against default_perms. A named party never falls through from a grant to default_perms.

Persistence — the block is stored as an aclBlock JSON property on :MetaEnvelope, carried through every read site, both store paths, the update path, and the cross-eVault migration copy. An update that omits _acl preserves the stored policy rather than clearing it.

Enforcement — VaultAccessGuard now takes the permission each operation needs; all 21 resolvers are mapped. The consequential change:

A record carrying an _acl block is decided by that block for every caller, including a platform holding a valid Registry token. Closing that bypass is the point of the model.

Delegated identity — a platform's token proves the platform, not which of its users a request is for. X-ON-BEHALF-OF: @<ename> carries that: the named user becomes the party, with the carrying platform recorded alongside it, so a user grant applies at user specificity while a platform grant still applies at its own.

It is the platform's assertion, not a proof — the eVault cannot verify it, so a platform can reach what a user was granted, including more than its own grant. That is the deliberate reading of the design's specificity rule, and a platform that can write to a vault can already act as its users in other ways. What it cannot do is escape a denial: denials match the carrying platform too.

Only @-prefixed eNames are accepted as parties. This also fixes a real trap: currentUser is derived from the JWT kid, which for a Registry platform token is the literal string entropy-key-1 — a signing-key id, not a party. It is no longer treated as an identity.

Reading the policy back — MetaEnvelope._acl is exposed to anyone permitted to read the record, as typed output (AclBlock/AclGrant/AclDenials/AclCondition). It always reports the policy in force: a record carrying only a legacy array reports the block that array maps to, so clients see one shape regardless of how the record was written. The legacy array itself is still never returned.

Note this means a denial list is visible to permitted readers — it names the parties an owner excluded.

GraphQL input — AclBlockInput and friends, with _acl on MetaEnvelopeInput, BulkMetaEnvelopeInput, and UploadFileInput.

Nothing narrows until an owner sets a policy

Every platform writes acl: ["*"] today, so back-compat mattered more than purity here. Records with no _acl keep their exact current behaviour, token bypass included. Legacy arrays are read as: ["*"] → default_perms 0x0F behind an always-passing group; ["@ename"] → a 0x0F grant to that eName. Binding documents (acl: [subject]) are unaffected.

Docs

• W3DS Protocol/Access-Control.md — the protocol model, wire format, decision order, the delegation header, and reading policies back.
• Post Platform Guide/access-control.md — the implementation guide: worked policy shapes, the perms table, header usage, and the failure modes most likely to bite (a grant is final; 0 means no grant, not "denied"; a platform token will not open a policied record; policies replace rather than merge).
• Infrastructure/eVault.md rewritten — it previously documented the old model as a limitation with granular permissions "planned for future versions".
• The bundled skills/w3ds reference carried the same stale claim and is corrected; it is symlinked into installed agent skills.

Deliberately not in scope

• Group membership is not resolved. A grant or denial naming a group matches nobody. Fail-closed for grants, but fail-open for group denials — so group denials are not usable until a membership lookup is wired into principalFor.
• No condition evaluator is connected. Conditions currently fail closed: a require group containing conditions cannot pass, and a deny condition always fires. Policies should use grants, denials.enames, and empty-group require until one lands.
• eVault only. The Web3 Adapter hardcodes acl: ["*"] with no _acl parameter and does not send X-ON-BEHALF-OF, so records written through handleChange cannot carry a policy or a delegated identity yet — a direct GraphQL call is needed. Platforms do not evaluate policies themselves.
• The binary wire format from §9 of the design has no consumer in this layer.

Deploying

No migration. Neo4j is schemaless and aclBlock is a new optional property, so existing nodes take the legacy path untouched. Nothing can write a policy through the adapter yet, so the change is inert on deploy.

One caution: treat this as forward-only once policies start being written. Rolling back means old code ignoring aclBlock and reading the acl array, which platforms set to ["*"] — a locked-down record would become world-open again.

Testing

30 engine tests written from the design's normative examples, plus 19 guard integration tests against real Neo4j covering the token-bypass closure, specificity, deny-over-grant, default_perms, fail-closed conditions, delegated identity and its denial escape-hatch, rejection of non-eName identities, and legacy records staying unchanged. Full suite: 213/213 across 18 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 43fef62c-f09c-48a9-ae99-74e38cd7f1dc

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Records in an eVault now carry their own access rules: who may read, add, change, or delete them, held inside the record so the policy travels with the data when it syncs.

This implements the list half of the access control design — grants, denials, and the decision order. The Resource Link Ontology half (resolving a platform's score and comparing it) is left as an injected seam, since the scoring side already exists elsewhere.

The problem

Platforms have no access controls between them. Any platform holding a valid Registry-issued token can reach anything that syncs to it, and the legacy acl array is all-or-nothing — there is no read-without-write except ["*"], which is what essentially every record in the system is written with today.

What is here

A policy engine (infrastructure/evault-core/src/core/acl/) — pure, no I/O:

• Permissions as a bitmask: 0x01 READ, 0x02 CREATE, 0x04 UPDATE, 0x08 DELETE. 0x03 expresses add-only access. Reserved bits 4-7 are rejected on write and stripped on read; 0x00 counts as no grant rather than an empty one.
• Most-specific-wins: a user grant beats a platform grant beats a group grant, with no union across specificity. Grants tied at the same specificity are unioned, so the outcome does not depend on storage order.
• Denials always win, by eName (matching the party, the platform carrying its request, or a group it belongs to) or by a failing condition.
• Decision order: denials, then the single most specific grant, then the require groups against default_perms. A named party never falls through from a grant to default_perms.

Persistence — the block is stored as an aclBlock JSON property on :MetaEnvelope, carried through every read site, both store paths, the update path, and the cross-eVault migration copy. An update that omits _acl preserves the stored policy rather than clearing it.

Enforcement — VaultAccessGuard now takes the permission each operation needs; all 21 resolvers are mapped. The consequential change:

A record carrying an _acl block is decided by that block for every caller, including a platform holding a valid Registry token. Closing that bypass is the point of the model.

Delegated identity — a platform's token proves the platform, not which of its users a request is for. X-ON-BEHALF-OF: @<ename> carries that: the named user becomes the party, with the carrying platform recorded alongside it, so a user grant applies at user specificity while a platform grant still applies at its own.

It is the platform's assertion, not a proof — the eVault cannot verify it, so a platform can reach what a user was granted, including more than its own grant. That is the deliberate reading of the design's specificity rule, and a platform that can write to a vault can already act as its users in other ways. What it cannot do is escape a denial: denials match the carrying platform too.

Only @-prefixed eNames are accepted as parties. This also fixes a real trap: currentUser is derived from the JWT kid, which for a Registry platform token is the literal string entropy-key-1 — a signing-key id, not a party. It is no longer treated as an identity.

Reading the policy back — MetaEnvelope._acl is exposed to anyone permitted to read the record, as typed output (AclBlock/AclGrant/AclDenials/AclCondition). It always reports the policy in force: a record carrying only a legacy array reports the block that array maps to, so clients see one shape regardless of how the record was written. The legacy array itself is still never returned.

Note this means a denial list is visible to permitted readers — it names the parties an owner excluded.

GraphQL input — AclBlockInput and friends, with _acl on MetaEnvelopeInput, BulkMetaEnvelopeInput, and UploadFileInput.

Nothing narrows until an owner sets a policy

Every platform writes acl: ["*"] today, so back-compat mattered more than purity here. Records with no _acl keep their exact current behaviour, token bypass included. Legacy arrays are read as: ["*"] → default_perms 0x0F behind an always-passing group; ["@ename"] → a 0x0F grant to that eName. Binding documents (acl: [subject]) are unaffected.

Docs

• W3DS Protocol/Access-Control.md — the protocol model, wire format, decision order, the delegation header, and reading policies back.
• Post Platform Guide/access-control.md — the implementation guide: worked policy shapes, the perms table, header usage, and the failure modes most likely to bite (a grant is final; 0 means no grant, not "denied"; a platform token will not open a policied record; policies replace rather than merge).
• Infrastructure/eVault.md rewritten — it previously documented the old model as a limitation with granular permissions "planned for future versions".
• The bundled skills/w3ds reference carried the same stale claim and is corrected; it is symlinked into installed agent skills.

Deliberately not in scope

• Group membership is not resolved. A grant or denial naming a group matches nobody. Fail-closed for grants, but fail-open for group denials — so group denials are not usable until a membership lookup is wired into principalFor.
• No condition evaluator is connected. Conditions currently fail closed: a require group containing conditions cannot pass, and a deny condition always fires. Policies should use grants, denials.enames, and empty-group require until one lands.
• eVault only. The Web3 Adapter hardcodes acl: ["*"] with no _acl parameter and does not send X-ON-BEHALF-OF, so records written through handleChange cannot carry a policy or a delegated identity yet — a direct GraphQL call is needed. Platforms do not evaluate policies themselves.
• The binary wire format from §9 of the design has no consumer in this layer.

Deploying

No migration. Neo4j is schemaless and aclBlock is a new optional property, so existing nodes take the legacy path untouched. Nothing can write a policy through the adapter yet, so the change is inert on deploy.

One caution: treat this as forward-only once policies start being written. Rolling back means old code ignoring aclBlock and reading the acl array, which platforms set to ["*"] — a locked-down record would become world-open again.

Testing

30 engine tests written from the design's normative examples, plus 19 guard integration tests against real Neo4j covering the token-bypass closure, specificity, deny-over-grant, default_perms, fail-closed conditions, delegated identity and its denial escape-hatch, rejection of non-eName identities, and legacy records staying unchanged. Full suite: 213/213 across 18 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 43fef62c-f09c-48a9-ae99-74e38cd7f1dc

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Records in an eVault now carry their own access rules: who may read, add, change, or delete them, held inside the record so the policy travels with the data when it syncs.

This implements the list half of the access control design — grants, denials, and the decision order. The Resource Link Ontology half (resolving a platform's score and comparing it) is left as an injected seam, since the scoring side already exists elsewhere.

The problem

Platforms have no access controls between them. Any platform holding a valid Registry-issued token can reach anything that syncs to it, and the legacy acl array is all-or-nothing — there is no read-without-write except ["*"], which is what essentially every record in the system is written with today.

What is here

A policy engine (infrastructure/evault-core/src/core/acl/) — pure, no I/O:

• Permissions as a bitmask: 0x01 READ, 0x02 CREATE, 0x04 UPDATE, 0x08 DELETE. 0x03 expresses add-only access. Reserved bits 4-7 are rejected on write and stripped on read; 0x00 counts as no grant rather than an empty one.
• Most-specific-wins: a user grant beats a platform grant beats a group grant, with no union across specificity. Grants tied at the same specificity are unioned, so the outcome does not depend on storage order.
• Denials always win, by eName (matching the party, the platform carrying its request, or a group it belongs to) or by a failing condition.
• Decision order: denials, then the single most specific grant, then the require groups against default_perms. A named party never falls through from a grant to default_perms.

Persistence — the block is stored as an aclBlock JSON property on :MetaEnvelope, carried through every read site, both store paths, the update path, and the cross-eVault migration copy. An update that omits _acl preserves the stored policy rather than clearing it.

Enforcement — VaultAccessGuard now takes the permission each operation needs; all 21 resolvers are mapped. The consequential change:

A record carrying an _acl block is decided by that block for every caller, including a platform holding a valid Registry token. Closing that bypass is the point of the model.

Delegated identity — a platform's token proves the platform, not which of its users a request is for. X-ON-BEHALF-OF: @<ename> carries that: the named user becomes the party, with the carrying platform recorded alongside it, so a user grant applies at user specificity while a platform grant still applies at its own.

It is the platform's assertion, not a proof — the eVault cannot verify it, so a platform can reach what a user was granted, including more than its own grant. That is the deliberate reading of the design's specificity rule, and a platform that can write to a vault can already act as its users in other ways. What it cannot do is escape a denial: denials match the carrying platform too.

Only @-prefixed eNames are accepted as parties. This also fixes a real trap: currentUser is derived from the JWT kid, which for a Registry platform token is the literal string entropy-key-1 — a signing-key id, not a party. It is no longer treated as an identity.

Reading the policy back — MetaEnvelope._acl is exposed to anyone permitted to read the record, as typed output (AclBlock/AclGrant/AclDenials/AclCondition). It always reports the policy in force: a record carrying only a legacy array reports the block that array maps to, so clients see one shape regardless of how the record was written. The legacy array itself is still never returned.

Note this means a denial list is visible to permitted readers — it names the parties an owner excluded.

GraphQL input — AclBlockInput and friends, with _acl on MetaEnvelopeInput, BulkMetaEnvelopeInput, and UploadFileInput.

Nothing narrows until an owner sets a policy

Every platform writes acl: ["*"] today, so back-compat mattered more than purity here. Records with no _acl keep their exact current behaviour, token bypass included. Legacy arrays are read as: ["*"] → default_perms 0x0F behind an always-passing group; ["@ename"] → a 0x0F grant to that eName. Binding documents (acl: [subject]) are unaffected.

Docs

• W3DS Protocol/Access-Control.md — the protocol model, wire format, decision order, the delegation header, and reading policies back.
• Post Platform Guide/access-control.md — the implementation guide: worked policy shapes, the perms table, header usage, and the failure modes most likely to bite (a grant is final; 0 means no grant, not "denied"; a platform token will not open a policied record; policies replace rather than merge).
• Infrastructure/eVault.md rewritten — it previously documented the old model as a limitation with granular permissions "planned for future versions".
• The bundled skills/w3ds reference carried the same stale claim and is corrected; it is symlinked into installed agent skills.

Deliberately not in scope

• Group membership is not resolved. A grant or denial naming a group matches nobody. Fail-closed for grants, but fail-open for group denials — so group denials are not usable until a membership lookup is wired into principalFor.
• No condition evaluator is connected. Conditions currently fail closed: a require group containing conditions cannot pass, and a deny condition always fires. Policies should use grants, denials.enames, and empty-group require until one lands.
• eVault only. The Web3 Adapter hardcodes acl: ["*"] with no _acl parameter and does not send X-ON-BEHALF-OF, so records written through handleChange cannot carry a policy or a delegated identity yet — a direct GraphQL call is needed. Platforms do not evaluate policies themselves.
• The binary wire format from §9 of the design has no consumer in this layer.

Deploying

No migration. Neo4j is schemaless and aclBlock is a new optional property, so existing nodes take the legacy path untouched. Nothing can write a policy through the adapter yet, so the change is inert on deploy.

One caution: treat this as forward-only once policies start being written. Rolling back means old code ignoring aclBlock and reading the acl array, which platforms set to ["*"] — a locked-down record would become world-open again.

Testing

30 engine tests written from the design's normative examples, plus 19 guard integration tests against real Neo4j covering the token-bypass closure, specificity, deny-over-grant, default_perms, fail-closed conditions, delegated identity and its denial escape-hatch, rejection of non-eName identities, and legacy records staying unchanged. Full suite: 213/213 across 18 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 43fef62c-f09c-48a9-ae99-74e38cd7f1dc

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Records in an eVault now carry their own access rules: who may read, add, change, or delete them, held inside the record so the policy travels with the data when it syncs.

This implements the list half of the access control design — grants, denials, and the decision order. The Resource Link Ontology half (resolving a platform's score and comparing it) is left as an injected seam, since the scoring side already exists elsewhere.

The problem

Platforms have no access controls between them. Any platform holding a valid Registry-issued token can reach anything that syncs to it, and the legacy acl array is all-or-nothing — there is no read-without-write except ["*"], which is what essentially every record in the system is written with today.

What is here

A policy engine (infrastructure/evault-core/src/core/acl/) — pure, no I/O:

• Permissions as a bitmask: 0x01 READ, 0x02 CREATE, 0x04 UPDATE, 0x08 DELETE. 0x03 expresses add-only access. Reserved bits 4-7 are rejected on write and stripped on read; 0x00 counts as no grant rather than an empty one.
• Most-specific-wins: a user grant beats a platform grant beats a group grant, with no union across specificity. Grants tied at the same specificity are unioned, so the outcome does not depend on storage order.
• Denials always win, by eName (matching the party, the platform carrying its request, or a group it belongs to) or by a failing condition.
• Decision order: denials, then the single most specific grant, then the require groups against default_perms. A named party never falls through from a grant to default_perms.

Persistence — the block is stored as an aclBlock JSON property on :MetaEnvelope, carried through every read site, both store paths, the update path, and the cross-eVault migration copy. An update that omits _acl preserves the stored policy rather than clearing it.

Enforcement — VaultAccessGuard now takes the permission each operation needs; all 21 resolvers are mapped. The consequential change:

A record carrying an _acl block is decided by that block for every caller, including a platform holding a valid Registry token. Closing that bypass is the point of the model.

Delegated identity — a platform's token proves the platform, not which of its users a request is for. X-ON-BEHALF-OF: @<ename> carries that: the named user becomes the party, with the carrying platform recorded alongside it, so a user grant applies at user specificity while a platform grant still applies at its own.

It is the platform's assertion, not a proof — the eVault cannot verify it, so a platform can reach what a user was granted, including more than its own grant. That is the deliberate reading of the design's specificity rule, and a platform that can write to a vault can already act as its users in other ways. What it cannot do is escape a denial: denials match the carrying platform too.

Only @-prefixed eNames are accepted as parties. This also fixes a real trap: currentUser is derived from the JWT kid, which for a Registry platform token is the literal string entropy-key-1 — a signing-key id, not a party. It is no longer treated as an identity.

Reading the policy back — MetaEnvelope._acl is exposed to anyone permitted to read the record, as typed output (AclBlock/AclGrant/AclDenials/AclCondition). It always reports the policy in force: a record carrying only a legacy array reports the block that array maps to, so clients see one shape regardless of how the record was written. The legacy array itself is still never returned.

Note this means a denial list is visible to permitted readers — it names the parties an owner excluded.

GraphQL input — AclBlockInput and friends, with _acl on MetaEnvelopeInput, BulkMetaEnvelopeInput, and UploadFileInput.

Nothing narrows until an owner sets a policy

Every platform writes acl: ["*"] today, so back-compat mattered more than purity here. Records with no _acl keep their exact current behaviour, token bypass included. Legacy arrays are read as: ["*"] → default_perms 0x0F behind an always-passing group; ["@ename"] → a 0x0F grant to that eName. Binding documents (acl: [subject]) are unaffected.

Docs

• W3DS Protocol/Access-Control.md — the protocol model, wire format, decision order, the delegation header, and reading policies back.
• Post Platform Guide/access-control.md — the implementation guide: worked policy shapes, the perms table, header usage, and the failure modes most likely to bite (a grant is final; 0 means no grant, not "denied"; a platform token will not open a policied record; policies replace rather than merge).
• Infrastructure/eVault.md rewritten — it previously documented the old model as a limitation with granular permissions "planned for future versions".
• The bundled skills/w3ds reference carried the same stale claim and is corrected; it is symlinked into installed agent skills.

Deliberately not in scope

• Group membership is not resolved. A grant or denial naming a group matches nobody. Fail-closed for grants, but fail-open for group denials — so group denials are not usable until a membership lookup is wired into principalFor.
• No condition evaluator is connected. Conditions currently fail closed: a require group containing conditions cannot pass, and a deny condition always fires. Policies should use grants, denials.enames, and empty-group require until one lands.
• eVault only. The Web3 Adapter hardcodes acl: ["*"] with no _acl parameter and does not send X-ON-BEHALF-OF, so records written through handleChange cannot carry a policy or a delegated identity yet — a direct GraphQL call is needed. Platforms do not evaluate policies themselves.
• The binary wire format from §9 of the design has no consumer in this layer.

Deploying

No migration. Neo4j is schemaless and aclBlock is a new optional property, so existing nodes take the legacy path untouched. Nothing can write a policy through the adapter yet, so the change is inert on deploy.

One caution: treat this as forward-only once policies start being written. Rolling back means old code ignoring aclBlock and reading the acl array, which platforms set to ["*"] — a locked-down record would become world-open again.

Testing

30 engine tests written from the design's normative examples, plus 19 guard integration tests against real Neo4j covering the token-bypass closure, specificity, deny-over-grant, default_perms, fail-closed conditions, delegated identity and its denial escape-hatch, rejection of non-eName identities, and legacy records staying unchanged. Full suite: 213/213 across 18 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 43fef62c-f09c-48a9-ae99-74e38cd7f1dc

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Records in an eVault now carry their own access rules: who may read, add, change, or delete them, held inside the record so the policy travels with the data when it syncs.

This implements the list half of the access control design — grants, denials, and the decision order. The Resource Link Ontology half (resolving a platform's score and comparing it) is left as an injected seam, since the scoring side already exists elsewhere.

The problem

Platforms have no access controls between them. Any platform holding a valid Registry-issued token can reach anything that syncs to it, and the legacy acl array is all-or-nothing — there is no read-without-write except ["*"], which is what essentially every record in the system is written with today.

What is here

A policy engine (infrastructure/evault-core/src/core/acl/) — pure, no I/O:

• Permissions as a bitmask: 0x01 READ, 0x02 CREATE, 0x04 UPDATE, 0x08 DELETE. 0x03 expresses add-only access. Reserved bits 4-7 are rejected on write and stripped on read; 0x00 counts as no grant rather than an empty one.
• Most-specific-wins: a user grant beats a platform grant beats a group grant, with no union across specificity. Grants tied at the same specificity are unioned, so the outcome does not depend on storage order.
• Denials always win, by eName (matching the party, the platform carrying its request, or a group it belongs to) or by a failing condition.
• Decision order: denials, then the single most specific grant, then the require groups against default_perms. A named party never falls through from a grant to default_perms.

Persistence — the block is stored as an aclBlock JSON property on :MetaEnvelope, carried through every read site, both store paths, the update path, and the cross-eVault migration copy. An update that omits _acl preserves the stored policy rather than clearing it.

Enforcement — VaultAccessGuard now takes the permission each operation needs; all 21 resolvers are mapped. The consequential change:

A record carrying an _acl block is decided by that block for every caller, including a platform holding a valid Registry token. Closing that bypass is the point of the model.

Delegated identity — a platform's token proves the platform, not which of its users a request is for. X-ON-BEHALF-OF: @<ename> carries that: the named user becomes the party, with the carrying platform recorded alongside it, so a user grant applies at user specificity while a platform grant still applies at its own.

It is the platform's assertion, not a proof — the eVault cannot verify it, so a platform can reach what a user was granted, including more than its own grant. That is the deliberate reading of the design's specificity rule, and a platform that can write to a vault can already act as its users in other ways. What it cannot do is escape a denial: denials match the carrying platform too.

Only @-prefixed eNames are accepted as parties. This also fixes a real trap: currentUser is derived from the JWT kid, which for a Registry platform token is the literal string entropy-key-1 — a signing-key id, not a party. It is no longer treated as an identity.

Reading the policy back — MetaEnvelope._acl is exposed to anyone permitted to read the record, as typed output (AclBlock/AclGrant/AclDenials/AclCondition). It always reports the policy in force: a record carrying only a legacy array reports the block that array maps to, so clients see one shape regardless of how the record was written. The legacy array itself is still never returned.

Note this means a denial list is visible to permitted readers — it names the parties an owner excluded.

GraphQL input — AclBlockInput and friends, with _acl on MetaEnvelopeInput, BulkMetaEnvelopeInput, and UploadFileInput.

Nothing narrows until an owner sets a policy

Every platform writes acl: ["*"] today, so back-compat mattered more than purity here. Records with no _acl keep their exact current behaviour, token bypass included. Legacy arrays are read as: ["*"] → default_perms 0x0F behind an always-passing group; ["@ename"] → a 0x0F grant to that eName. Binding documents (acl: [subject]) are unaffected.

Docs

• W3DS Protocol/Access-Control.md — the protocol model, wire format, decision order, the delegation header, and reading policies back.
• Post Platform Guide/access-control.md — the implementation guide: worked policy shapes, the perms table, header usage, and the failure modes most likely to bite (a grant is final; 0 means no grant, not "denied"; a platform token will not open a policied record; policies replace rather than merge).
• Infrastructure/eVault.md rewritten — it previously documented the old model as a limitation with granular permissions "planned for future versions".
• The bundled skills/w3ds reference carried the same stale claim and is corrected; it is symlinked into installed agent skills.

Deliberately not in scope

• Group membership is not resolved. A grant or denial naming a group matches nobody. Fail-closed for grants, but fail-open for group denials — so group denials are not usable until a membership lookup is wired into principalFor.
• No condition evaluator is connected. Conditions currently fail closed: a require group containing conditions cannot pass, and a deny condition always fires. Policies should use grants, denials.enames, and empty-group require until one lands.
• eVault only. The Web3 Adapter hardcodes acl: ["*"] with no _acl parameter and does not send X-ON-BEHALF-OF, so records written through handleChange cannot carry a policy or a delegated identity yet — a direct GraphQL call is needed. Platforms do not evaluate policies themselves.
• The binary wire format from §9 of the design has no consumer in this layer.

Deploying

No migration. Neo4j is schemaless and aclBlock is a new optional property, so existing nodes take the legacy path untouched. Nothing can write a policy through the adapter yet, so the change is inert on deploy.

One caution: treat this as forward-only once policies start being written. Rolling back means old code ignoring aclBlock and reading the acl array, which platforms set to ["*"] — a locked-down record would become world-open again.

Testing

30 engine tests written from the design's normative examples, plus 19 guard integration tests against real Neo4j covering the token-bypass closure, specificity, deny-over-grant, default_perms, fail-closed conditions, delegated identity and its denial escape-hatch, rejection of non-eName identities, and legacy records staying unchanged. Full suite: 213/213 across 18 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 43fef62c-f09c-48a9-ae99-74e38cd7f1dc

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Records in an eVault now carry their own access rules: who may read, add, change, or delete them, held inside the record so the policy travels with the data when it syncs.

This implements the list half of the access control design — grants, denials, and the decision order. The Resource Link Ontology half (resolving a platform's score and comparing it) is left as an injected seam, since the scoring side already exists elsewhere.

The problem

Platforms have no access controls between them. Any platform holding a valid Registry-issued token can reach anything that syncs to it, and the legacy acl array is all-or-nothing — there is no read-without-write except ["*"], which is what essentially every record in the system is written with today.

What is here

A policy engine (infrastructure/evault-core/src/core/acl/) — pure, no I/O:

• Permissions as a bitmask: 0x01 READ, 0x02 CREATE, 0x04 UPDATE, 0x08 DELETE. 0x03 expresses add-only access. Reserved bits 4-7 are rejected on write and stripped on read; 0x00 counts as no grant rather than an empty one.
• Most-specific-wins: a user grant beats a platform grant beats a group grant, with no union across specificity. Grants tied at the same specificity are unioned, so the outcome does not depend on storage order.
• Denials always win, by eName (matching the party, the platform carrying its request, or a group it belongs to) or by a failing condition.
• Decision order: denials, then the single most specific grant, then the require groups against default_perms. A named party never falls through from a grant to default_perms.

Persistence — the block is stored as an aclBlock JSON property on :MetaEnvelope, carried through every read site, both store paths, the update path, and the cross-eVault migration copy. An update that omits _acl preserves the stored policy rather than clearing it.

Enforcement — VaultAccessGuard now takes the permission each operation needs; all 21 resolvers are mapped. The consequential change:

A record carrying an _acl block is decided by that block for every caller, including a platform holding a valid Registry token. Closing that bypass is the point of the model.

Delegated identity — a platform's token proves the platform, not which of its users a request is for. X-ON-BEHALF-OF: @<ename> carries that: the named user becomes the party, with the carrying platform recorded alongside it, so a user grant applies at user specificity while a platform grant still applies at its own.

It is the platform's assertion, not a proof — the eVault cannot verify it, so a platform can reach what a user was granted, including more than its own grant. That is the deliberate reading of the design's specificity rule, and a platform that can write to a vault can already act as its users in other ways. What it cannot do is escape a denial: denials match the carrying platform too.

Only @-prefixed eNames are accepted as parties. This also fixes a real trap: currentUser is derived from the JWT kid, which for a Registry platform token is the literal string entropy-key-1 — a signing-key id, not a party. It is no longer treated as an identity.

Reading the policy back — MetaEnvelope._acl is exposed to anyone permitted to read the record, as typed output (AclBlock/AclGrant/AclDenials/AclCondition). It always reports the policy in force: a record carrying only a legacy array reports the block that array maps to, so clients see one shape regardless of how the record was written. The legacy array itself is still never returned.

Note this means a denial list is visible to permitted readers — it names the parties an owner excluded.

GraphQL input — AclBlockInput and friends, with _acl on MetaEnvelopeInput, BulkMetaEnvelopeInput, and UploadFileInput.

Nothing narrows until an owner sets a policy

Every platform writes acl: ["*"] today, so back-compat mattered more than purity here. Records with no _acl keep their exact current behaviour, token bypass included. Legacy arrays are read as: ["*"] → default_perms 0x0F behind an always-passing group; ["@ename"] → a 0x0F grant to that eName. Binding documents (acl: [subject]) are unaffected.

Docs

• W3DS Protocol/Access-Control.md — the protocol model, wire format, decision order, the delegation header, and reading policies back.
• Post Platform Guide/access-control.md — the implementation guide: worked policy shapes, the perms table, header usage, and the failure modes most likely to bite (a grant is final; 0 means no grant, not "denied"; a platform token will not open a policied record; policies replace rather than merge).
• Infrastructure/eVault.md rewritten — it previously documented the old model as a limitation with granular permissions "planned for future versions".
• The bundled skills/w3ds reference carried the same stale claim and is corrected; it is symlinked into installed agent skills.

Deliberately not in scope

• Group membership is not resolved. A grant or denial naming a group matches nobody. Fail-closed for grants, but fail-open for group denials — so group denials are not usable until a membership lookup is wired into principalFor.
• No condition evaluator is connected. Conditions currently fail closed: a require group containing conditions cannot pass, and a deny condition always fires. Policies should use grants, denials.enames, and empty-group require until one lands.
• eVault only. The Web3 Adapter hardcodes acl: ["*"] with no _acl parameter and does not send X-ON-BEHALF-OF, so records written through handleChange cannot carry a policy or a delegated identity yet — a direct GraphQL call is needed. Platforms do not evaluate policies themselves.
• The binary wire format from §9 of the design has no consumer in this layer.

Deploying

No migration. Neo4j is schemaless and aclBlock is a new optional property, so existing nodes take the legacy path untouched. Nothing can write a policy through the adapter yet, so the change is inert on deploy.

One caution: treat this as forward-only once policies start being written. Rolling back means old code ignoring aclBlock and reading the acl array, which platforms set to ["*"] — a locked-down record would become world-open again.

Testing

30 engine tests written from the design's normative examples, plus 19 guard integration tests against real Neo4j covering the token-bypass closure, specificity, deny-over-grant, default_perms, fail-closed conditions, delegated identity and its denial escape-hatch, rejection of non-eName identities, and legacy records staying unchanged. Full suite: 213/213 across 18 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 43fef62c-f09c-48a9-ae99-74e38cd7f1dc

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Records in an eVault now carry their own access rules: who may read, add, change, or delete them, held inside the record so the policy travels with the data when it syncs.

This implements the list half of the access control design — grants, denials, and the decision order. The Resource Link Ontology half (resolving a platform's score and comparing it) is left as an injected seam, since the scoring side already exists elsewhere.

The problem

Platforms have no access controls between them. Any platform holding a valid Registry-issued token can reach anything that syncs to it, and the legacy acl array is all-or-nothing — there is no read-without-write except ["*"], which is what essentially every record in the system is written with today.

What is here

A policy engine (infrastructure/evault-core/src/core/acl/) — pure, no I/O:

• Permissions as a bitmask: 0x01 READ, 0x02 CREATE, 0x04 UPDATE, 0x08 DELETE. 0x03 expresses add-only access. Reserved bits 4-7 are rejected on write and stripped on read; 0x00 counts as no grant rather than an empty one.
• Most-specific-wins: a user grant beats a platform grant beats a group grant, with no union across specificity. Grants tied at the same specificity are unioned, so the outcome does not depend on storage order.
• Denials always win, by eName (matching the party, the platform carrying its request, or a group it belongs to) or by a failing condition.
• Decision order: denials, then the single most specific grant, then the require groups against default_perms. A named party never falls through from a grant to default_perms.

Persistence — the block is stored as an aclBlock JSON property on :MetaEnvelope, carried through every read site, both store paths, the update path, and the cross-eVault migration copy. An update that omits _acl preserves the stored policy rather than clearing it.

Enforcement — VaultAccessGuard now takes the permission each operation needs; all 21 resolvers are mapped. The consequential change:

A record carrying an _acl block is decided by that block for every caller, including a platform holding a valid Registry token. Closing that bypass is the point of the model.

Delegated identity — a platform's token proves the platform, not which of its users a request is for. X-ON-BEHALF-OF: @<ename> carries that: the named user becomes the party, with the carrying platform recorded alongside it, so a user grant applies at user specificity while a platform grant still applies at its own.

It is the platform's assertion, not a proof — the eVault cannot verify it, so a platform can reach what a user was granted, including more than its own grant. That is the deliberate reading of the design's specificity rule, and a platform that can write to a vault can already act as its users in other ways. What it cannot do is escape a denial: denials match the carrying platform too.

Only @-prefixed eNames are accepted as parties. This also fixes a real trap: currentUser is derived from the JWT kid, which for a Registry platform token is the literal string entropy-key-1 — a signing-key id, not a party. It is no longer treated as an identity.

Reading the policy back — MetaEnvelope._acl is exposed to anyone permitted to read the record, as typed output (AclBlock/AclGrant/AclDenials/AclCondition). It always reports the policy in force: a record carrying only a legacy array reports the block that array maps to, so clients see one shape regardless of how the record was written. The legacy array itself is still never returned.

Note this means a denial list is visible to permitted readers — it names the parties an owner excluded.

GraphQL input — AclBlockInput and friends, with _acl on MetaEnvelopeInput, BulkMetaEnvelopeInput, and UploadFileInput.

Nothing narrows until an owner sets a policy

Every platform writes acl: ["*"] today, so back-compat mattered more than purity here. Records with no _acl keep their exact current behaviour, token bypass included. Legacy arrays are read as: ["*"] → default_perms 0x0F behind an always-passing group; ["@ename"] → a 0x0F grant to that eName. Binding documents (acl: [subject]) are unaffected.

Docs

• W3DS Protocol/Access-Control.md — the protocol model, wire format, decision order, the delegation header, and reading policies back.
• Post Platform Guide/access-control.md — the implementation guide: worked policy shapes, the perms table, header usage, and the failure modes most likely to bite (a grant is final; 0 means no grant, not "denied"; a platform token will not open a policied record; policies replace rather than merge).
• Infrastructure/eVault.md rewritten — it previously documented the old model as a limitation with granular permissions "planned for future versions".
• The bundled skills/w3ds reference carried the same stale claim and is corrected; it is symlinked into installed agent skills.

Deliberately not in scope

• Group membership is not resolved. A grant or denial naming a group matches nobody. Fail-closed for grants, but fail-open for group denials — so group denials are not usable until a membership lookup is wired into principalFor.
• No condition evaluator is connected. Conditions currently fail closed: a require group containing conditions cannot pass, and a deny condition always fires. Policies should use grants, denials.enames, and empty-group require until one lands.
• eVault only. The Web3 Adapter hardcodes acl: ["*"] with no _acl parameter and does not send X-ON-BEHALF-OF, so records written through handleChange cannot carry a policy or a delegated identity yet — a direct GraphQL call is needed. Platforms do not evaluate policies themselves.
• The binary wire format from §9 of the design has no consumer in this layer.

Deploying

No migration. Neo4j is schemaless and aclBlock is a new optional property, so existing nodes take the legacy path untouched. Nothing can write a policy through the adapter yet, so the change is inert on deploy.

One caution: treat this as forward-only once policies start being written. Rolling back means old code ignoring aclBlock and reading the acl array, which platforms set to ["*"] — a locked-down record would become world-open again.

Testing

30 engine tests written from the design's normative examples, plus 19 guard integration tests against real Neo4j covering the token-bypass closure, specificity, deny-over-grant, default_perms, fail-closed conditions, delegated identity and its denial escape-hatch, rejection of non-eName identities, and legacy records staying unchanged. Full suite: 213/213 across 18 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 43fef62c-f09c-48a9-ae99-74e38cd7f1dc

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Records in an eVault now carry their own access rules: who may read, add, change, or delete them, held inside the record so the policy travels with the data when it syncs.

This implements the list half of the access control design — grants, denials, and the decision order. The Resource Link Ontology half (resolving a platform's score and comparing it) is left as an injected seam, since the scoring side already exists elsewhere.

The problem

Platforms have no access controls between them. Any platform holding a valid Registry-issued token can reach anything that syncs to it, and the legacy acl array is all-or-nothing — there is no read-without-write except ["*"], which is what essentially every record in the system is written with today.

What is here

A policy engine (infrastructure/evault-core/src/core/acl/) — pure, no I/O:

• Permissions as a bitmask: 0x01 READ, 0x02 CREATE, 0x04 UPDATE, 0x08 DELETE. 0x03 expresses add-only access. Reserved bits 4-7 are rejected on write and stripped on read; 0x00 counts as no grant rather than an empty one.
• Most-specific-wins: a user grant beats a platform grant beats a group grant, with no union across specificity. Grants tied at the same specificity are unioned, so the outcome does not depend on storage order.
• Denials always win, by eName (matching the party, the platform carrying its request, or a group it belongs to) or by a failing condition.
• Decision order: denials, then the single most specific grant, then the require groups against default_perms. A named party never falls through from a grant to default_perms.

Persistence — the block is stored as an aclBlock JSON property on :MetaEnvelope, carried through every read site, both store paths, the update path, and the cross-eVault migration copy. An update that omits _acl preserves the stored policy rather than clearing it.

Enforcement — VaultAccessGuard now takes the permission each operation needs; all 21 resolvers are mapped. The consequential change:

A record carrying an _acl block is decided by that block for every caller, including a platform holding a valid Registry token. Closing that bypass is the point of the model.

Delegated identity — a platform's token proves the platform, not which of its users a request is for. X-ON-BEHALF-OF: @<ename> carries that: the named user becomes the party, with the carrying platform recorded alongside it, so a user grant applies at user specificity while a platform grant still applies at its own.

It is the platform's assertion, not a proof — the eVault cannot verify it, so a platform can reach what a user was granted, including more than its own grant. That is the deliberate reading of the design's specificity rule, and a platform that can write to a vault can already act as its users in other ways. What it cannot do is escape a denial: denials match the carrying platform too.

Only @-prefixed eNames are accepted as parties. This also fixes a real trap: currentUser is derived from the JWT kid, which for a Registry platform token is the literal string entropy-key-1 — a signing-key id, not a party. It is no longer treated as an identity.

Reading the policy back — MetaEnvelope._acl is exposed to anyone permitted to read the record, as typed output (AclBlock/AclGrant/AclDenials/AclCondition). It always reports the policy in force: a record carrying only a legacy array reports the block that array maps to, so clients see one shape regardless of how the record was written. The legacy array itself is still never returned.

Note this means a denial list is visible to permitted readers — it names the parties an owner excluded.

GraphQL input — AclBlockInput and friends, with _acl on MetaEnvelopeInput, BulkMetaEnvelopeInput, and UploadFileInput.

Nothing narrows until an owner sets a policy

Every platform writes acl: ["*"] today, so back-compat mattered more than purity here. Records with no _acl keep their exact current behaviour, token bypass included. Legacy arrays are read as: ["*"] → default_perms 0x0F behind an always-passing group; ["@ename"] → a 0x0F grant to that eName. Binding documents (acl: [subject]) are unaffected.

Docs

• W3DS Protocol/Access-Control.md — the protocol model, wire format, decision order, the delegation header, and reading policies back.
• Post Platform Guide/access-control.md — the implementation guide: worked policy shapes, the perms table, header usage, and the failure modes most likely to bite (a grant is final; 0 means no grant, not "denied"; a platform token will not open a policied record; policies replace rather than merge).
• Infrastructure/eVault.md rewritten — it previously documented the old model as a limitation with granular permissions "planned for future versions".
• The bundled skills/w3ds reference carried the same stale claim and is corrected; it is symlinked into installed agent skills.

Deliberately not in scope

• Group membership is not resolved. A grant or denial naming a group matches nobody. Fail-closed for grants, but fail-open for group denials — so group denials are not usable until a membership lookup is wired into principalFor.
• No condition evaluator is connected. Conditions currently fail closed: a require group containing conditions cannot pass, and a deny condition always fires. Policies should use grants, denials.enames, and empty-group require until one lands.
• eVault only. The Web3 Adapter hardcodes acl: ["*"] with no _acl parameter and does not send X-ON-BEHALF-OF, so records written through handleChange cannot carry a policy or a delegated identity yet — a direct GraphQL call is needed. Platforms do not evaluate policies themselves.
• The binary wire format from §9 of the design has no consumer in this layer.

Deploying

No migration. Neo4j is schemaless and aclBlock is a new optional property, so existing nodes take the legacy path untouched. Nothing can write a policy through the adapter yet, so the change is inert on deploy.

One caution: treat this as forward-only once policies start being written. Rolling back means old code ignoring aclBlock and reading the acl array, which platforms set to ["*"] — a locked-down record would become world-open again.

Testing

30 engine tests written from the design's normative examples, plus 19 guard integration tests against real Neo4j covering the token-bypass closure, specificity, deny-over-grant, default_perms, fail-closed conditions, delegated identity and its denial escape-hatch, rejection of non-eName identities, and legacy records staying unchanged. Full suite: 213/213 across 18 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 43fef62c-f09c-48a9-ae99-74e38cd7f1dc

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}