Module 11 — Designing the Entitlement Model: RBAC, ABAC, ReBAC

Phase 3 · Security, Auth & Entitlements. Module 10 gave you the machinery (PEP/PDP/PIP) and the rule that policy is yours to design. This module is how to design that policy: the three access-control models, when each fits, how they combine, and how OAuth scopes relate to fine-grained entitlements. This is the design skill at the center of “MCP architecture with entitlements.” By the end you can choose the right model per decision and defend it.

By the end you can:

Define RBAC, ABAC, and ReBAC and pick the right one per decision.
Combine them in one system without it becoming a mess.
Map coarse OAuth scopes onto fine-grained entitlements.
Use the read/write tool split (Module 4) as the backbone of tool-level permissions.

1. RBAC — Role-Based Access Control

Idea: permissions attach to roles; users get roles. You never grant a permission to a person directly — you grant it to a role and assign the role.

 user ──has──▶ role(s) ──grants──▶ permissions ──over──▶ tools/resources
 Alice         Analyst             read_report           reports server

Strengths: simple, auditable (“what can Analysts do?” is one lookup), maps perfectly to tool-level permissions (“which roles may call which tools”), and matches how orgs already think (job functions). It’s the default for MCP tool gating and what most gateways implement first.
Limits: struggles with context (“…but only during business hours”, “…only for non-PII data”) and with per-object rules (“…only reports she owns”) — that’s where ABAC and ReBAC come in.
MCP shape: roles → allowed tools, with the read/write split as the spine: viewer = read tools; editor = read + write; admin = read + write + destructive. Add per-tenant role scoping (Module 12).

RBAC is your starting skeleton. Most systems are “RBAC + a bit of ABAC/ReBAC for the hard cases.”

2. ABAC — Attribute-Based Access Control

Idea: decisions are computed from attributes of the subject, resource, action, and environment/context — not just role membership. ABAC is “it depends” made executable.

Subject attributes: department, clearance, employment type, risk score.
Resource attributes: data classification (PII / public / secret), owner, environment (prod/dev).
Action attributes: read vs write vs export.
Environment/context: time of day, location, device posture, current threat level.

Example entitlements ABAC expresses that RBAC can’t cleanly:

“Allow export_dataset only when the dataset’s classification != PII and it’s business hours.”
“Allow run_query against prod only from managed devices.”
Strengths: fine-grained, context-aware, scales to nuanced policy without role explosion. Pairs naturally with data classification, which is your main defense against the exfiltration threat (Module 8 T7).
Limits: harder to audit (“who can do X?” requires evaluating attribute combinations, not a lookup); policy can sprawl; needs good, trustworthy attribute sources (PIPs from Module 10).

ABAC is how you handle conditions. Reach for it when a permission depends on something other than who the user is.

3. ReBAC — Relationship-Based Access Control

Idea: access derives from relationships in a graph between subjects and resources — the Google Zanzibar model, implemented by OpenFGA, SpiceDB, etc. “Alice can read doc 88 because she’s a member of the team that owns the folder that contains it.”

 Alice ──member──▶ Team-X ──owner──▶ Folder-7 ──contains──▶ Doc-88
        (so Alice inherits read on Doc-88 through the relationship chain)

Strengths: ideal for fine-grained, hierarchical, per-object authorization at scale — documents, folders, orgs, nested resources, sharing. Handles “ownership”, “membership”, “parent inherits to child” elegantly, which RBAC/ABAC do awkwardly. The model of choice when resources form a graph and sharing matters.
Limits: new infrastructure (a relationship store / authorization service); modeling discipline required; can be overkill for simple tool gating.

ReBAC is how you handle resource graphs and sharing. Reach for it when “can X access Y?” depends on the relationship path between them.

4. Choosing and combining (the practical synthesis)

You rarely pick one. Mature systems layer them, each handling what it’s best at:

Decision type	Model	MCP example
Which roles may call which tools	RBAC	`editor` may call write tools
Conditional on context/data sensitivity	ABAC	`export` only for non-PII in business hours
Per-object, ownership, sharing, hierarchy	ReBAC	read this record only if on its owning team

A clean composite policy for an MCP system:

RBAC gates tool access (the coarse “may this role use this tool at all”).
ABAC adds conditions (data classification, time, environment) on top.
ReBAC decides per-resource access for tools that touch individual objects.
All of it deny-by-default and tenant-scoped (Modules 10, 12).

Keep it manageable: start with RBAC, introduce ABAC only where conditions genuinely vary, and ReBAC only where a real resource graph exists. Adding models speculatively creates audit and maintenance pain.

5. Scopes vs entitlements — coarse gate, fine cut

A crucial and frequently-muddled relationship that ties back to Module 9.

OAuth scopes are coarse and set at token issuance by the AS — e.g. reports:read, reports:write. They travel in the token. They’re great for a first, cheap gate (“does this token even carry reports:write?”) and for limiting blast radius if a token leaks.
Fine-grained entitlements are evaluated per call at the PDP using live attributes/relationships — “may Alice delete this report given her team membership and the report’s classification, right now?” Scopes can’t express that; they’re static and blunt.

The standard pattern: scopes gate coarse at the edge (often the gateway), the PDP makes the fine decision. Don’t try to encode per-object, per-condition rules as scopes — you’ll get scope explosion and stale tokens. Use scopes to narrow, entitlements to decide.

 token(scopes: reports:read) ──▶ gateway: has reports:write? NO ──▶ block write tools cheaply
                                         │ has reports:read? YES
                                         ▼
                                PDP (RBAC+ABAC+ReBAC): may read THIS report now? ──▶ allow/deny

6. The read/write split as backbone (callback to Module 4)

Everything rests on the per-tool read vs write/destructive classification you designed in Module 4:

Read tools → granted liberally (often to viewer+), light consent, still audited.
Write tools → granted to editor+, may need consent, fully audited.
Destructive tools → granted narrowly (admin/owner), explicit consent, strict audit, often ABAC conditions and ReBAC ownership checks stacked on.

This split is what lets you apply proportionate control — loose where it’s safe, strict where it’s dangerous — instead of one blunt policy for everything. It’s also why Module 4 insisted a tool be either read or write, never both.

7. Milestone exercise

Design the full entitlement model for a multi-team SaaS (“DocuFlow”: documents owned by teams, with viewers/editors/admins, some documents classified PII):

RBAC: define roles and the tools each may call (use the read/write/destructive split).
ABAC: add at least two conditional rules (one using data classification, one using environment or time).
ReBAC: model the resource graph (user → team → folder → document) and write the “can read this document” relationship rule.
Scopes vs entitlements: define 2–3 OAuth scopes and state exactly which decisions they gate vs which the PDP makes.
Compose: write the deny-by-default decision flow combining all three models for a delete_document(id) call, and state which model contributes each check.

Self-check:

Roles map to the read/write/destructive split; destructive is narrowest.
At least one ABAC rule keys off data classification (ties to exfiltration defense, T7).
Your ReBAC rule derives access through a relationship path, not a role.
Scopes are coarse/edge; per-object + conditional decisions are at the PDP — you did not encode per-document rules as scopes.
The delete_document flow is deny-by-default, tenant-scoped, and stacks RBAC (role) + ReBAC (ownership) + ABAC (e.g. classification/confirmation).

Nail this and you can design the policy layer of an enterprise MCP platform. Next: Module 12 — Identity propagation, multi-tenancy & isolation — carrying this identity and tenant context safely across every hop.

Quick reference — Module 11 glossary

RBAC — permissions via roles; simple, auditable; default for tool-level gating; backbone = read/write/destructive split.
ABAC — decisions from attributes (subject/resource/action/context); handles conditions (classification, time, environment).
ReBAC — access via relationships in a graph (Zanzibar/OpenFGA); handles per-object ownership/sharing/hierarchy.
Combine — RBAC gates tools, ABAC adds conditions, ReBAC decides per-resource; all deny-by-default + tenant-scoped.
Scopes vs entitlements — scopes = coarse, in-token, edge gate; entitlements = fine, per-call, PDP decision. Don’t encode fine rules as scopes.