From role gates to policy bound to data. How RBAC (role-based), ABAC (attribute-based), and RuBAC (rule-based) access control actually relate; why role-based perimeters — WordPress roles, AWS IAM, Azure RBAC — stop at the door; and how the entitlement plane extends the same discipline to a subject the incumbents were never designed for: the AI agent.
Every mainstream permission system answers one question: who may open the door? The questions that decide real-world outcomes are different: what does this specific subject hold, right now, on this specific object, under which terms — and how do we take it back? The entitlement plane answers those. Policy is data (purchase-granted roles carrying scoped capability caps), enforcement is at the data plane (per-asset envelope encryption; possession of bytes is worthless without a grant), revocation is an operation (rotate one key, every outstanding copy dies), and every decision leaves evidence (a hash-chained ledger, verifiable against a published key at /.well-known/jwks.json by anyone, with no account and no trust in the platform).
| WordPress roles | AWS IAM | Azure RBAC / Entra | |
|---|---|---|---|
| Model | Roles = flat bundles of global capabilities (edit_posts = all posts) | Identity policies over control-plane APIs; ABAC via tags exists but governs resources, not app users | Role assignments at scopes (subscription → resource); ABAC conditions narrow (e.g. blob storage) |
| Granularity stops at | Site / post-type; per-object requires plugins enforcing in PHP at render time | The AWS resource boundary; your application's users and objects are "your problem" — hence Cedar | The Azure resource boundary; app roles are coarse claims stamped into a token |
| The naked file | wp-content/uploads = public URL, zero policy | S3 presigned URL = bearer access, irrevocable until expiry | SAS tokens = same bearer pattern |
| Revocation semantics | Role change ≠ recall of anything already served | Policy change ≠ recall of presigned URLs | Assignment change ≠ recall of issued SAS/tokens mid-lifetime |
The common structure: all three are perimeter authorization over containers. None bind policy to the data itself; all three have weak revocation. The industry has already conceded the gap — AWS shipped Cedar / Verified Permissions, Google published Zanzibar (now OpenFGA), and OPA exists, all because role gates do not compose into application-level authorization. Each of those is a policy-as-data engine. The entitlement plane is the same conclusion, plus the step none of them take: cryptographic enforcement at the asset.
A role gate at the door with attribute rules underneath is the architecture the standards bodies recommend:
Where RuBAC fits. Rule-based access control (RuBAC) evaluates condition rules — time windows, network, object state — against a request. In NIST’s framing it is not a rival model but the policy half of ABAC: attributes describe the subject, object, and context; rules decide. A mature stack therefore layers all three: an RBAC gate at the door, RuBAC condition rules in the policy engine, and attributes carrying the per-subject, per-object facts those rules consume.
Role systems assume a human who logs in occasionally and holds standing permissions. An AI agent is the opposite subject: it acts continuously, delegates, and cannot safely hold a role-wide grant — an agent with "Editor everywhere, forever" is an incident report with a timestamp. Agent authorization requires exactly the properties the entitlement plane already has:
caps.a2a), granted and revoked like any entitlement.create_mandate → agentic_checkout). The mandate is the ceiling; caps constrain within it — the Kuhn hybrid applied to machines.The deeper split is not which acronym a stack implements but where its enforcement lives. WordPress, the cloud IAMs, and the modern Next.js stack (Sanity for content, Better Auth or Clerk for identity) all enforce inside the file system or application scope — the app is the guard. The entitlement plane's modules live outside both: policy as data at the edge, enforcement cryptographic at the asset. When the application is compromised, only one of these designs still holds.
| WordPress | AWS IAM / Azure RBAC | Next.js + Sanity + Better Auth / Clerk | Entitlement modules — outside file-system & application scope | |
|---|---|---|---|---|
| Where policy lives | App code + DB, inside the install | Cloud control plane (infra scope) | App middleware + role claims in the vendor's token | Policy-as-data at the edge, independent of any app deployment |
| Enforcement point | Template/render code | Cloud API perimeter | Route guards & server components — whatever code remembers to check | Every request at the edge, plus cryptographically at the asset |
| Object granularity | Role → site-wide capabilities | Resource / container | Org & role claims; per-object = custom app code | Per-subject × per-object × per-request entitlement |
| Re-delegation | Files & links forwardable | Presigned URL / SAS = bearer access | Token holder asserts role; sessions replayable in scope | Non-discretionary: no holder can extend access |
| Revocation | Role edit ≠ recall of anything served | Policy edit ≠ recall of issued URLs | Session revoke stops future logins; served data is gone | Key rotation kills every outstanding copy at once |
| App compromised — then what? | Game over: the app was the guard | Infra intact; data within granted scope exposed | Game over: enforcement was compiled into the app | Modules unaffected; the attacker holds ciphertext |
| AI agents | No model | Service principals with standing power | API keys with standing power | Mandates + caps.a2a: time-boxed, consent-anchored, ledgered |
| Evidence | Logs, if configured | Control-plane trails only | Vendor dashboards | Hash-chained ledger; public JWKS verification |
To be fair to the incumbents: Sanity, Better Auth, and Clerk solve authentication and role assertion well. The gap is that everything after the door — object authorization, delegation, revocation, evidence — remains application code, in application scope, sharing the application's fate.
| Layer | Question it answers | Mechanism |
|---|---|---|
| RBAC gate (door) | Who may enter at all? | Roles — including the incumbents' (WP/IAM/Azure), which coexist |
| Capability caps (ABAC) | What can this subject do here, now? | Purchase-granted, scoped caps evaluated per request (NIST 800-162 / Kuhn hybrid) |
| Agent mandates | What may this machine do, for whom, until when? | AP2 mandates + caps.a2a + JWE-resolved principal + consent snapshot |
| Data-plane crypto | What happens if every layer above fails? | Envelope encryption; leak yields ciphertext; rotation = revocation |
| Evidence | Can anyone prove what happened? | Hash-chained ledger; Ed25519 certificates; public JWKS verification |