RBAC governed software.
AI requires governance attached to data.

Systems today govern applications. NoData governs the data itself.

The future permission system is not roles. It is continuous classification attached to content.

Trust is temporary. Governance must be continuous.

Everything below is one of these three sentences, expanded.

For 30 years, we secured data by securing where it lived. Walls around databases. Perimeters around networks. ACLs around files. Audit logs that recorded who walked through which door.

The assumption was simple: if you can guard the building, you control what is inside it.

Then we sent the data outside the building.

By email. By Slack. By Drive sync. By DocuSign envelope. By WhatsApp screenshot. By API integration. By contractor's laptop. By customer's phone. By AI agent reading the entire CRM in one prompt.

Every wall we built still stands. And every wall is now irrelevant.

Underneath every perimeter that fell, there is a deeper failure that almost no one names directly.

Role-Based Access Control was sufficient until the world changed.

For 30 years, the enterprise software industry assumed that the right way to model “who can see what” was to assign each person a role — admin, manager, member, viewer — and write rules against those roles. Salesforce built its empire on it. SharePoint did. Workday did. Every IAM vendor did.

And it worked, because the world being modelled was simple: people had stable jobs, data lived in one place, and access decisions could be made in advance and cached for years.

That world is gone.

The breakage is everywhere you look:

• Salesforce permissions — multi-thousand-line spaghetti debugged in production by exception.
• SharePoint hell — every site, library, folder, item carrying its own ACL until no human knows who can read what.
• Google Drive ACL sprawl — “anyone with the link” because the alternative was too painful.
• IAM explosion — Okta groups, Azure AD groups, AWS IAM, Kubernetes RBAC, each drifting from the others.
• AI agents with over-permissioning — the agent is given a service account with broad access because nobody can express “let it see summaries but not the underlying PII”.

These are not implementation failures. They are the abstraction failing.

Consider what the real world looks like and what RBAC cannot express:

• A person is an auditor without being a manager.
• A person is a north-region manager only this week.
• An assistant sees PII redacted but salaries in full.
• An AI agent sees summaries but not raw data.
• A contractor sees one section of one document, for 48 hours, from one device.

Roles are a crude approximation of reality. Reality is a graph of attributes — geography, time, workflow state, sensitivity tier, relationship to the data, identity proof level, AI exposure, jurisdiction. Roles flatten this graph and lose almost everything.

A new layer of infrastructure that does not exist anywhere else in your stack.

Not authentication. Not authorisation. Not encryption-at-rest. Not key management. Not policy engines. Not audit pipelines. Those are tools. They sit inside applications, inside perimeters, inside trusted environments.

This layer sits underneath the data itself.

Computable governance attached to the data itself.

What that means in practice is the inversion of every permission system you have ever shipped:

• The data is tagged with classifications — not assigned to roles.
• The viewer carries a set of classification claims (a JWT, signed, time-bound) — not a role.
• The access decision is a set intersection, computed at the moment of access. There is no policy engine to consult. The data and the claim either intersect or they do not.
• Rules are enforced by cryptography, not policy enforcement points. If your claim does not authorise the classification, the key is not released; the bytes on your disk are mathematically inert.
• Revocation is a mathematical act, not a notification. Zeroing the wrapped key turns every copy into noise.
• Audit is inherent. Every access decision writes a hash-chained receipt. The chain is independently verifiable without trusting the operator.

We call this continuous policy computation.

Not configured once and cached. Not assigned during onboarding. Not maintained in a policy file that drifts from reality. Computed live, at every access, against the data itself, with cryptographic enforcement.

If you are a CISO or a security architect, this section is for you. The vocabulary will be familiar; the architecture will not.

The server holds no plaintext. Data is encrypted at the section level with per-section keys (AES-256-GCM). Section keys are derived deterministically from a master secret via HKDF. The master secret is wrapped with an environment KEK. The server can unwrap when authorised, but the plaintext never sits at rest on the server.

The recipient's browser holds no keys longer than the moment of decryption.Section keys live in WebCrypto memory for the render, then drop out of scope. No client-side key storage to steal.

Every access leaves a cryptographic receipt.A monotonic chain of HMAC-linked receipts records every access decision, every revocation, every classification change. Each receipt references the previous one's hash. Tampering breaks the chain.

Burn is mathematics, not policy.When access is revoked, the server zeroes the wrapped key. The ciphertext becomes mathematically unrecoverable. Not “deleted.” Not “marked inaccessible.” Unrecoverable.

Access decisions compose. Tags can encode geography (region:north), time (window:q2), workflow state (stage:pre-signature), AI exposure (agent:gpt-readable), legal hold, or any other dimension. This is not RBAC. It is composable governance state.

Post-quantum readiness is engineered in. The crypto envelope supports ML-KEM hybrid mode. When NIST PQC finalises, the wrap layer rotates with no recipient action.

No client install required.The viewer is a browser. WebCrypto handles decryption. Works on a phone, in a hotel, on a contractor's laptop.

Most security products are a bag of features held together by a marketing deck. Continuous Governance is the opposite. There is one thesis — computable governance attached to data — and every capability below is the same thesis viewed from a different angle.

Read this section asking: “is this a feature, or is this what the thesis required?”

• Per-section encryption with classification-gated key release. The data must be cryptographically partitioned by classification.
• Cryptographic burn. Revocation must be mathematical, not policy.
• Chained, HMAC-linked receipts. Trust is replaced by verifiability.
• Hardware-bound recipient identity. Identity becomes part of policy.
• Per-recipient rendering and watermarking. The same data produces different documents per viewer.
• Word add-ins, Outlook integration, DocuSign envelope handling. Governance survives outside the application.
• SLA boards and continuous monitoring. Governance is continuous, not point-in-time.
• Post-quantum cryptographic readiness. The architecture survives cryptographic generations.

None of these features are independent. They are the same architecture, applied to nine surfaces. Remove any one and the thesis is incomplete.

This is what differentiates an architecture doctrine from a product.

What becomes possible under this architecture is not “the same things, more secure.” It is a different set of things.

Start small. Each of the following is a real-world access need that RBAC literally cannot express — and is a single classification combination in a continuous-governance system.

• “Auditor without being a manager.” Claim set: {audit_read}.
• “North-region manager only this week.” Claim set: {region:north, window:2026-W22}.
• “Assistant sees PII redacted.” PII fields carry a classification the assistant lacks.
• “AI agent sees summary, not raw.” Agent JWT: {summary_read}.
• “Contractor sees one section, 48 hours, one laptop.” Claim set: {doc-x:section-3, window:next-48h, device:fp-a7c9}.

Each is a one-line classification config. Each, in your current systems, is either impossible, a six-month engineering project, or a “we trust the contractor.”

Now scale up. The bigger patterns that become available:

• AI agents on sensitive data. Give the agent a JWT carrying classification tags. Every retrieval goes through the same primitive. Every quote is receipted. For most organisations, this is the only path that lets them deploy production AI on regulated data in 2027.
• One dashboard for the entire organisation. Five portals collapse into one. Adding a new role takes zero engineering.
• Customer self-service from the same dataset. The customer's portal is the same record with a customer-scoped classification set.
• Cross-organisation collaboration without VPN, federation, or SSO bridges. The data knows.
• Geographic and temporal access in configuration. Compliance officers configure this in seconds.
• Workflow with state-bound access. The classification is the workflow state.
• Legal hold and preserve orders follow the data. Spoliation defence is automatic.

There is no organisation that handles information and does not benefit. The pattern is sector-agnostic.

• Banking. Wealth advisor sees their book. Compliance sees AML-tagged. Customer sees only theirs.
• Hospitals. Physician sees clinical. Billing sees codes. Family sees discharge summary. Patient sees their full record.
• Law firms. Every matter carries client-confidentiality classification. Conflicts checking is automatic.
• Insurance. Underwriters see risk. Claim handlers see incidents. Agents see commission. Customers see benefits. We have shipped this. It runs in production today.
• Government. Classified material carries its distribution list cryptographically.
• Universities. Student records, faculty research, donor data, athletic compliance — different lenses on the same student.
• Defence contractors. ITAR-controlled components enforce cleared-personnel-only access by refusing to decrypt for an uncleared identity.
• Media. Source protection, embargoes, redaction states encoded as classifications.
• Pharma. Trial data classified by phase. IP follows the data across CROs and academic collaborators.
• Consulting firms. Client confidentiality enforced across engagements.
• Energy / critical infrastructure. Operational telemetry visible per role to control room, regulator, public.
• Family offices. Each family member sees their slice. Estate plan enforced by data, not paper.
• HR systems. Salaries, reviews, medical accommodations — employee sees own, manager sees team, HR sees org.

The list is not exhaustive. It cannot be. Any organisation that handles information sees the same shape of problem the moment data moves between people with different need-to-know.

Information is information. The rules for who sees what travel with it, or they don't. Today, in 99% of organisations, they don't.

The operational promise is simple and verifiable. Adding a new governance rule no longer requires engineering.

• Onboarding a new role: configuration.
• Adding a geographic scope: configuration.
• Adding a temporal window: configuration.
• Adding a workflow state: configuration.
• Adding a compliance hold: configuration.
• Adding an AI agent with limited access: configuration.
• Auditing a contractor's access for the last 90 days: query.
• Revoking everything that ever touched a project: one SQL.

The CTO is no longer the bottleneck for governance change. Compliance, legal, and operations execute these changes directly — through the same primitive, with the same guarantees, against the same data, with the same receipts.

This document is for organisations that have hit one or more of the following walls:

• Your AI deployment is blocked by governance review.
• Your portals are multiplying.
• Your audits cost six figures and take months.
• Your data leaves your perimeter daily and you have no enforcement once it leaves.
• You are building governance into every product separately, and every product gets it slightly wrong.

If any of these are familiar, the conversation is short.

This is the new layer. It is not a feature added to your existing stack. It is the layer your existing stack will eventually sit on top of, the way your current stack sits on top of TLS, on top of PKI, on top of the file system.

We built it because no one else was building it for the world we now live in.