Permissions for AI, in plain terms — capability, not perimeter

For: BAs, growth marketers, CISOs/DPOs, and the Next.js/Tailwind devs who handle permissions the "senior-dev" way. See it live: prosthetics demo · building-inspection demo.

Watch the 2-minute explainer above. Then claim a discount — this link applies it automatically at checkout: crm-sync.dev/r/du2qxzd.

Role-based access control is the right answer to a question we no longer only ask. RBAC answers "is this person allowed in?" But the actor is now often an AI agent, and an agent is inside the perimeter by definition. Here it is in plain terms.

1 · The problem, in three steps

You secured the app the standard way — roles behind a locked-down route (RBAC). That is the right answer for a human.
Your customer is now an AI agent, acting on their behalf — and an agent is inside the wall by design. A wall can't scope something already inside.
So you lock everything down. But that same wall blocks your customer's consented AI from finishing the purchase. Security just killed the sale.

2 · The words, one line each

RBAC (Role-Based) — access by your role. Coarse and static: a role unlocks a whole surface.
ABAC (Attribute-Based) — access by attributes (user, resource, context) checked by a policy. More granular, but the policy lives centrally.
RuBAC (Rule-Based) — access by rules/conditions (time of day, network), authored ahead of time, usually on top of RBAC.
OAuth — lets an app act on your behalf without your password, via a scoped token. "Sign in with Google," "Connect Shopify."
OIDC — a thin identity layer on top of OAuth that proves who you are.
Capability / claim (what CRM Sync uses) — a signed grant for one action on one record, carrying its own consent + ISO timestamp, checked just-in-time, revocable by deletion. Attribute- and rule-aware and portable, verifiable, auditable.

3 · How CRM Sync does it, in three steps

Claim, not role. A small key for one action — not a big key for the whole building. Scope the action, not the room.
The mint IS the grant. A link or QR is a scoped grant; every use is a signed row in a ledger anyone can verify against a public key. A file behind a login is shared once, shared forever. A grant is a receipt.
Three principals, not one. Agent (a scoped, expiring mandate — not a login) · Peer (a human teammate) · View (read-only). The verbs: Grant = insert, Revoke = delete, Audit = read.

AI is the security partner — and the compliance and mandate checks. Rules-based functions run at request time: AI verifies the mandate and runs the compliance checks; the agent manages the running ledger — every transaction recording the exact device, agent, screen, and application behind it, per request. A CSV file throws all of that away the moment it is exported: no device, no agent, no screen, no record — just a row. And no one has to cry over a 50,000-row CSV file — the ledger already knows.

Permissions for AI — five real-world proofs

The theory is one thing; here is what minting actually does across five settings — the same model against five problems people feel every day. This is the selling point.

Streaming, for a household. Stop sharing one password (a key to everything, un-revocable, un-auditable). Mint five scoped grants — one per member/device. Kick one person off = delete one grant; the other four keep working.
Remote 3D printing of a medical device (HIPAA). A print file, once sent, is shared forever with no record. Instead, the master stays encrypted and you mint a per-print grant — single-use (idempotency key), bound to that printer's device session. Every print is a signed ledger row: chain of custody as a side effect. (This is the prosthetics demo — the model behind charities like e-NABLE, whose volunteers 3D-print free prosthetic hands for children.)
Qualifying for a mortgage, privately. Don't hand the lender your SSN, statements, and tax returns. Mint a verification grant that proves the predicates — income ≥ X ✓, DTI ≤ Y ✓, identity ✓ — without surrendering the documents. The lender verifies the proof, not a copy. Prove the predicate; keep the data.
The dark warehouse — robots read the QR (GS1 Sunrise 2027). It isn't only agents who shop; it's robots who inventory stock and run deliveries in a lights-out warehouse. Each robot reads the GS1 Digital Link QR on the item and acts on a scoped, expiring mandate — pick, count, move, ship — verified against the running ledger, with device, screen, and application recorded per scan. This is a new capability a CPG company can build on the QR Sunrise 2027 rollout: the same QR that carries the product's identity to a shopper carries the instruction to a machine. You don't share a password with a robot — you grant it a mandate, and revoke it the moment the shift ends. The QR Sunrise 2027 migration isn't a single feature — it's a whole category of startups this model can stand up.
A geo-verified building inspection (BIM), for the architect. An inspector shouldn't walk away with a permanent copy of the whole building model. Mint a grant bound to the site — geo-verified to the device standing in the building — that opens the relevant BIM layer for the visit and closes after. Every inspection is a signed, located ledger row: who, where, when, and which model version. (This is the BIM inspection demo.)

Every one of these makes the solution more relatable — to the tradesman on the warehouse floor and, just as much, to the tech lead who loves Next.js and Tailwind. For that tech lead the lesson is blunt: a beautiful perimeter — however well-built — is simply not enough. The moment a robot, an agent, or a consented user needs to act, a wall that only knows how to say no can't grant, can't scope, can't revoke, can't record. Capability can.

Is Tailwind or Next.js enough for AI? (short answer: no)

Is Tailwind enough for AI? Is Next.js RBAC enough for agentic checkout? No — Tailwind and Next.js build a beautiful front end and a tidy perimeter, but a perimeter only knows how to say no. AI agents, robots, and consented users need to act: grant, scope, revoke, record. That is a capability model, not a wall. For AI, a great Tailwind / Next.js build is simply not enough — the framework renders the door; it does not decide who may open it, for how long, or leave a signed record that they did.

Where a mandate comes from — four definitions, each as a challenge and its answer

The words below get used interchangeably and are not interchangeable. Each is stated as the problem it exists to solve, because a definition without its problem is a term nobody can apply.

System of record

Challenge. Authority accumulates in the surfaces that need it. Who may grant what ends up expressed in a theme conditional, an app's middleware, a spreadsheet of roles and somebody's memory. Asked who was allowed to do this, the estate answers by reading four places and guessing at the fifth.

Solution. One row per subject, holding permissions, state and a version, in a store that can be queried and audited — here, Xano. It is not in the request path for rendering and it is not a cache. It is the thing that gets asked, and the only thing entitled to answer. Its job is to be correct and revocable, not fast.

Mandate

Challenge. An agent needs to act for a person — place an order, book a slot, pull a record. A standing API key cannot express for whom, how much, or until when, and it cannot be withdrawn from one agent without breaking every other holder.

Solution. A signed, scoped, time-boxed artifact naming the subject it acts for, the permission it carries, the limits that bound it and the moment it stops being true. It is evidence, not configuration: a verifier needs the signature and the published key, not an account on your platform.

How the two combine to produce one

Challenge. Minting a mandate needs two things that must not live together — the authority to issue one, and the key that makes it verifiable. Put the key where the authority lives and a database compromise mints mandates. Put the authority where the key lives and revocation stops being possible.

Solution. They stay apart and both are consulted:

The system of record answers whether this subject may delegate this scope right now. It never sees a signing key.
The worker mints and signs, in a runtime whose only secret is a signing key it cannot export. It holds no entitlement data of its own.
The published key set lets any party verify without asking either of them — the property that makes a mandate portable rather than a session.
Edge rules bound the traffic carrying it: rate limits on the mint route, header discipline on the response, origin routing so the mint path is not the same surface as the storefront.

Nothing in that list is the boundary on its own. The boundary is step 1 and 2 together — authority consulted, signature applied, neither able to do the other's job.

Compile-time placement is not a runtime permission

Challenge. Modern frameworks make a developer feel they have drawn a security line when they have drawn a packaging line. "use client" and "use server" decide where code is bundled. Nothing checks them at runtime, nothing refuses at them, and — as the serialisation problem elsewhere in this estate shows — crossing one is a disclosure event, not an authorisation one. A compiler decides placement. A compiler cannot refuse a request.

Solution. Treat framework directives as what they are: a statement about transport. Then put the actual permission where something can say no at the moment of asking.

The contrast worth holding is Deno's model, because it is the same idea done at the layer where it works. A Deno process starts with nothing and receives only what it was granted: --allow-net for named hosts, --allow-read for named paths, --allow-env for named variables. Deny by default, declared before the code runs, enforced by the runtime rather than by convention. Xano runs Lambda steps on Deno, which is where this becomes practical rather than theoretical — an untrusted transformation can be given the ability to compute and nothing else.

The difference in one line: a compile-time boundary tells you where code runs; a runtime permission decides what it may do. Only the second one is a control.

Transport encryption and row-level encryption answer different questions

Challenge. TLS is treated as the encryption story, and it ends at the socket. Once a request terminates, the value is plaintext in the process, in the query result, in the log line and in whatever the backup captured. A query returns what it matches; a compromised credential returns rows. Neither is a transport problem, so transport security does nothing about them.

Solution. Encrypt the value to the subject entitled to it, not merely the pipe it travels down. A row read without the corresponding entitlement yields ciphertext — to an over-broad query, to a misconfigured export, to a stolen credential, and to an operator.

	Protects	Ends when	A breach yields
TLS	The connection	The socket closes	Plaintext rows
Row-level encryption	The value	The entitled party decrypts	Ciphertext

They compose rather than compete — TLS for everything in flight, row-level for the fields whose disclosure is the actual harm. The cost is key management, and it is worth paying exactly where the data is regulated and the store is shared, replicated or somebody else's.

Summary — opportunity, against the baseline risk

Stated last, because the definitions have to be settled before the trade means anything.

	With the four in place	Baseline, without them
Answering "who allowed this"	A query against one row, with a version and a time	A code read across surfaces, under deadline
Withdrawing an agent's authority	Revoke the row; outstanding mandates expire on their own clock	Rotate a shared key and break every other holder
A third party verifying a claim	Signature plus the published key set — no account needed	They must trust your assertion, or integrate with you
A database compromise	Ciphertext for the fields that matter	Plaintext rows, and disclosure measured in records
An untrusted transformation	A runtime that grants compute and nothing else	Whatever the process could already reach
A framework boundary crossed	A disclosure decision, made deliberately	A packaging decision, mistaken for a control

The opportunity is not that this is more secure in the abstract. It is that each row above turns a question that currently takes an investigation into one that takes a query — and every one of those questions is asked at the worst possible moment, by a regulator, a customer's lawyer or an incident channel.

The baseline risk is not a breach. It is arriving at that moment with no answer, and discovering that the controls you had were placement, transport and convention: three things that look like security in a diagram and refuse nothing in production.

Why it's money AND privacy gated (the unique part)

Every principal — a Peer, a Household member, or an AI agent — is gated on both dimensions at once:

Money — the entitlement: what was purchased/converted grants which capabilities.
Privacy — the consent: the grant only fires if consent for this purpose exists, right now, with a timestamp.

No role model does both. RBAC has no money dimension and no consent dimension. The moment the search runs, if a consented, ISO-timestamped grant exists → conversion + a value-weighted (pLTV) audience is enabled — for free. Behind a fortress RBAC perimeter, the dynamic AI function is never enabled at all, so the sale never happens. Security that sells, not security that only blocks.

<figure style="margin:1.5rem 0;max-width:900px"> <img src="https://crm-sync.dev/kb/media/docs/aug18-revenue-comparison.svg" alt="August 18, 2026 — CSV/PMax by app vs Permissions/Consent: same cohort, $0 captured vs $670 value-weighted" style="width:100%;display:block;border:1px solid #B8B0A4;background:#EDE8E0" loading="lazy"> <figcaption style="font-size:0.9rem;color:#555;margin-top:0.5rem">August 18: the same consented cohort earns <strong>$0</strong> through a CSV/PMax app (emails only, rails rejected) vs a value-weighted <strong>$670</strong> ($223 avg) through consented, timestamped permissions. Demo cohort, sanitized.</figcaption> </figure>

A date makes it accessible — it isn't a doomsday. August 18 isn't a disaster to absorb, and it isn't "your agency should have done this." It's a legible deadline with an immediate fix: you don't need a post-mortem or someone to blame — you need a grant, and you can issue it today. A date you can act on beats a threat you can't.

Why the stakes are enterprise, not startup — the single dev vs. the compliance team

The single dev. A Turbopack/Tailwind developer builds you a fast, responsive e-commerce theme; the agency invoices for it; everyone moves on. A theme is a look. A theme is not a system of record.
The compliance team. A real e-commerce operation must keep running documents — geo-stamped and timestamped on the server (not the client, where anyone can forge them): Omnibus 30-day price history, Consent Mode v2 state per purpose, the SBOM / CRA evidence chain — all producible on demand, in real time. In the EU the stakes run to the billions.
The gap that's left behind. Those records have to exist long after the Turbopack/Tailwind dev has left the room and the agency has taken the money for a responsive-only theme. The theme can't produce them; the operator is still liable. A capability model backed by a hash-chained, server-side, geo- and time-stamped ledger produces the evidence as a side effect of normal operation — it is the shape of the system, and it stays after everyone leaves.

Rebuild the whole thing again. Every new developer, every new theme, every agency re-implements consent capture, price-history logging, and audit records from scratch — and it breaks the moment they leave.
Consent flags built into a utility. The consent and entitlement logic lives once, as a reusable utility nested inside your frameworks — remotely updatable without breaking live code. Swap the theme, swap the developer; the consent flags and the ledger stay. You never rebuild compliance — you inherit it.

That is the whole difference: a theme is thrown away and re-bought; a utility with the flags built in is written once and carried everywhere.

Log in with what you already have — extended to your peers and agents

<figure style="margin:1.25rem 0;max-width:760px"> <img src="https://crm-sync.dev/kb/media/docs/capability-login.png" alt="CRM Sync login modal — Sign In / Shopify tabs and Continue with Google" style="width:100%;border:1px solid #B8B0A4;display:block" loading="lazy"> <figcaption style="font-size:0.9rem;color:#555;margin-top:0.5rem">The login isn’t just for Shopify — it also works for Shopify Headless, Webflow, AEM, Drupal, WordPress, and Next / Nuxt / Svelte / Astro themes.</figcaption> </figure>

<figure style="margin:1.25rem 0;max-width:760px"> <img src="https://crm-sync.dev/kb/media/docs/capability-data-redaction.png" alt="Data Redaction · Privacy Center — sign in to manage privacy settings and entitlements" style="width:100%;border:1px solid #B8B0A4;display:block;margin-bottom:0.75rem" loading="lazy"> <img src="https://crm-sync.dev/kb/media/docs/capability-dashboard.png" alt="AI & Dashboard Entitlements — feature access by consent, tier, and linked services" style="width:100%;border:1px solid #B8B0A4;display:block" loading="lazy"> <figcaption style="font-size:0.9rem;color:#555;margin-top:0.5rem">Privacy, Permissions, Peer/Team, and Agent gating — updated in real time, with documentation minted as records.</figcaption> </figure>

No new account. Users sign in with the accounts they already have — Google OAuth and Shopify OAuth. auth/me resolves who this request is at the moment it happens; there's no password for you to store and no credential to leak. Own your auth, don't rent it.
One identity, extended to the network. The same authorization utility reaches past the individual to their peers (human teammates) and their agents (AI acting under a mandate). You don't provision a separate login for each — you invite a peer or grant an agent, and each is a scoped, revocable capability issued off that one identity.
Frictionless updating. Because authorization is a utility, not a rebuild, changing who can do what — add a peer, revoke an agent, widen or narrow a scope — is a data change that propagates instantly across every surface. No redeploy, no re-implementation, no waiting on the developer who left. Grant is an insert, revoke is a delete, and it's live everywhere the moment you make it.
No app bound to a desktop. Reset your password, invite team and household members — all self-service, with no native app to download and no install locked to one machine. Because the output is vanilla, the same login and grants work on TVs, IoT devices, game worlds, and the CRM/CMS systems you already have — not just a browser on a laptop.

Vanilla, everywhere — own your auth, don't rent it

CRM Sync owns its auth — Google OAuth + Shopify OAuth, resolved by auth/me — instead of renting a "buy-auth" vendor (Cognito, Clerk, permit.io, Okta, Better Auth) whose fees and egress grow with you. The output is vanilla: the same grant gates Shopify, Webflow, WordPress, Drupal, Sitecore, Adobe Experience Manager, Salesforce Experience Cloud, Azure, and AWS — including legacy stacks a framework runtime can't reach. It is described at the edge, per request — not compiled into one frontend bundle (one build = one point of failure).

See it — the video's last screen

Watch the 2-minute explainer to the end, then do exactly what the final screen shows:

Scan the QR, or visit crm-sync.dev/r/du2qxzd — your discount is applied automatically at checkout.

Verify any grant yourself against the public key at /.well-known/jwks.json. No account required — that is the point.

Also view — Better than PMax (the same architecture, for growth): reach the customer the minute they search. Scan the code on the last screen, or watch on YouTube.

<figure style="margin:1.25rem 0;max-width:720px"> <a href="https://youtu.be/70oetzntjzQ"><img src="https://crm-sync.dev/kb/media/docs/pltv-lastscreen.jpg" alt="Better than PMax — the video's last screen with a scan-to-try QR (50% off)" style="width:100%;display:block;border:1px solid #B8B0A4" loading="lazy"></a> <figcaption style="font-size:0.9rem;color:#555;margin-top:0.5rem">Also view — <a href="https://youtu.be/70oetzntjzQ">Better than PMax: reach the buyer the minute they search</a>. Scan the QR on the last screen, or watch on YouTube.</figcaption> </figure>

The one-line version: RBAC asks "are you inside?" A capability asks "may you do exactly this, right now — and can anyone verify it later?" The senior-dev answer for humans is the wrong answer for agents.