Applied AI / Model Context Protocol (MCP) / Module 10 · Authentication vs Authorization vs Entitlements
Module 10

Authentication vs Authorization vs Entitlements

Building Systems Model Context Protocol (MCP)

Module 10 — Authentication vs Authorization vs Entitlements

Phase 3 · Security, Auth & Entitlements. Module 9 ended with a trustworthy, audience-bound token — that’s identity. This module is the conceptual core of your entire goal: turning identity into a runtime allow/deny decision, and understanding that the MCP spec deliberately stops at giving you good identity and leaves the policy to you. If you can crisply separate the three words in the title and place the PEP/PDP/PIP machinery, you can design enterprise MCP authorization. Most people blur these three; you won’t.

By the end you can:

  1. Define authentication, authorization, and entitlements without overlap, with MCP examples.
  2. Explain why MCP gives you authN/identity but leaves authZ policy to you — and why that’s the right boundary.
  3. Place the PEP / PDP / PIP enforcement architecture onto an MCP system.
  4. Decide where each kind of rule is enforced (server vs gateway) and write a deny-by-default policy.

1. Three words people constantly conflate

Authentication (authN) — who is the caller? Established by the validated token from Module 9: a verified identity (user id, tenant, the IdP that vouches for them, the scopes granted at issuance). AuthN answers “is this really Alice from Acme?” It does not answer what Alice may do.

Authorization (authZ) — is this caller allowed to do THIS action on THIS resource, right now? A decision, computed per request, against policy. “May Alice call delete_report on report 88 in tenant Acme at 2pm?” AuthZ is a function: (identity, action, resource, context) → allow | deny.

Entitlements — the grants that authZ evaluates. The concrete data: “Role Analyst in tenant Acme may call read_report but not delete_report.” Entitlements are the nouns (the stored rules/grants); authorization is the verb (the runtime check against them). You design entitlements; you enforce authorization.

A one-line mnemonic: authN = who you are; entitlements = what you’ve been granted; authZ = the check that decides this specific call.

QuestionWhenForm
AuthNWho are you?At token issuance / validationVerified identity (token)
EntitlementsWhat may this identity do?Defined ahead of timeStored grants/rules
AuthZIs this call allowed?Per request, at runtimeA decision (allow/deny)

2. Why MCP hands you identity and stops there

This is a deliberate and important boundary. The MCP authorization spec (Module 9) standardizes how a client gets a trustworthy, audience-bound token and how the server validates it. It does not prescribe your entitlement model or policy — and that’s correct, because:

  • Entitlement logic is domain- and org-specific. “Analysts may read but not export PII datasets during business hours” can’t live in a generic protocol; it belongs to your business.
  • Enterprises already have identity and policy infrastructure (IdPs, RBAC systems, policy engines). MCP plugging in as a Resource Server lets you reuse them rather than reinvent.
  • Keeping policy out of the wire protocol lets it evolve independently and be expressed in the right tool (a policy engine), not hardcoded in servers.

So the spec gives you a clean foundation — verified identity, correct audience — and says you decide what that identity is entitled to. That decision layer is the bulk of “MCP architecture with entitlements,” and it’s the work Modules 10–13 teach. Don’t expect the spec to do it for you; expect it to give you the trustworthy inputs.

3. The enforcement architecture: PEP / PDP / PIP

The standard, decades-proven shape for “decide and enforce access” (from XACML) maps cleanly onto MCP. Learn these three components — they’re the vocabulary of every access-control design review.

  • PEP — Policy Enforcement Point. Sits in the request path and actually blocks or allows. For MCP, the PEP intercepts each tools/call (and resource read / prompt get) before execution. It asks the PDP for a decision and enforces it. The PEP lives in the host, the gateway, or the server — placement is a key design choice (§4).
  • PDP — Policy Decision Point. Evaluates policy and returns allow/deny. This is your policy engine — e.g. OPA (Rego), Cedar, OpenFGA, or your IdP’s fine-grained authorization service. The PDP holds the rules; it doesn’t sit in the data path itself.
  • PIP — Policy Information Point. Supplies attributes the PDP needs but doesn’t have: the user’s roles, the tenant, the resource’s sensitivity/classification, time of day, risk signals. The PDP queries PIPs to enrich a decision.
  tools/call ─▶ ┌─────┐  "may Alice call delete_report(88)?"   ┌─────┐
   (request)    │ PEP │ ─────────────────────────────────────▶ │ PDP │
                │     │ ◀───────────── allow / deny ─────────── │     │
                └──┬──┘                                          └──┬──┘
        allow │    │ deny → 403 / error                            │ needs
              ▼    ▼                                          attributes
        execute   reject                                          ▼
        the tool                                              ┌─────┐
                                                              │ PIP │ roles,
                                                              └─────┘ tenant,
                                                                      sensitivity

The flow per call: PEP intercepts → asks PDP → PDP pulls attributes from PIP → PDP returns allow/deny → PEP enforces. Decision (PDP) is separated from enforcement (PEP) so you can change policy without touching the data path, and centralize policy across many servers.

4. Where do you enforce? (server vs gateway)

The same PEP/PDP/PIP can be placed differently, and the choice has real trade-offs — a core architecture decision (expanded in Module 13).

  • In the server (per-server PEP). Each MCP server enforces its own policy. Pros: fine-grained, server-specific logic close to the resource. Cons: policy logic scattered across many servers, inconsistent, hard to audit centrally, easy to forget.
  • In a gateway (central PEP). A gateway fronting all servers enforces uniformly. Pros: one place for policy, consistent audit, central rate-limiting and identity handling, governs the whole fleet. Cons: a central choke point (must be HA), and very server-specific decisions may still need some server-side logic.
  • Common real-world answer: both. Coarse, uniform gating at the gateway (is this identity allowed to reach this server / this tool at all?), with fine-grained, resource-specific checks (this row, this field) closer to or inside the server. Map this onto Module 9’s layers: scopes (coarse, from the token) gate at the edge; fine-grained entitlements (Module 11) decide the specifics at the PDP.

Decide placement per rule type. A good heuristic: “Could every server get this rule wrong independently?” If yes, push it to the gateway.

5. Expressing entitlements as policy (a first taste)

Entitlements become executable in a policy language the PDP evaluates. Two mainstream choices:

Rego (Open Policy Agent):

package mcp.authz
default allow := false                          # deny-by-default

allow if {                                      # analysts may read reports in their tenant
  input.action == "tools/call"
  input.tool == "read_report"
  "analyst" in input.subject.roles
  input.resource.tenant == input.subject.tenant
}

allow if {                                      # only admins may delete
  input.tool == "delete_report"
  "admin" in input.subject.roles
  input.resource.tenant == input.subject.tenant
}

Cedar (AWS):

// deny by default; permit analysts to read within their tenant
permit(principal, action == Action::"read_report", resource)
when { principal.role == "analyst" && principal.tenant == resource.tenant };

permit(principal, action == Action::"delete_report", resource)
when { principal.role == "admin" && principal.tenant == resource.tenant };

Two non-negotiables visible here and worth stating loudly:

  1. Deny-by-default. The base case is deny; you write explicit allow rules. Never the reverse. (Module 8’s closing rule.)
  2. Tenant check on every rule. resource.tenant == subject.tenant appears in every allow — the seed of multi-tenant isolation (Module 12).

The input/principal attributes (roles, tenant) come from the PIP; the action/tool/resource come from the intercepted MCP call at the PEP; the engine evaluating the rules is the PDP. The three components, made concrete.

6. Milestone exercise

  1. Define the three terms in your own words with one MCP example each, no overlap. Then label these as authN, authZ, or entitlement: (a) “the token proves she’s Alice@acme”; (b) “Analysts may call read_report”; (c) “this specific delete_report(88) call is denied.”
  2. Map PEP/PDP/PIP onto your Module 6/9 server: what intercepts the call, what decides, what supplies roles/tenant/sensitivity?
  3. Placement drill. For each rule, choose server-PEP, gateway-PEP, or both, and justify: (a) “no one outside tenant Acme may reach the Acme server”; (b) “Alice may read report 88 only if she’s on its owning team”; (c) “rate-limit each agent to 100 calls/min.”
  4. Write policy. In Rego or Cedar, encode: deny-by-default; viewer may call read tools; editor may call read + write tools; only admin may call destructive tools; every rule enforces same-tenant. Then state where the attributes come from (PIP) and where this evaluates (PDP).

Self-check:

  • (a)=authN, (b)=entitlement, (c)=authZ — and you can say why.
  • You correctly placed the PEP in the request path and the PDP out of it, with the PIP feeding attributes.
  • Your placement drill puts coarse reachability + rate-limit at the gateway and the team-membership check near/in the server.
  • Your policy is deny-by-default and every allow includes a tenant check.
  • You can state in one sentence why MCP gives you identity but not the policy.

Get this and the rest of Phase 3 is detailing. Next: Module 11 — Designing the entitlement model (RBAC, ABAC, ReBAC) — choosing and combining the models behind those rules.

Quick reference — Module 10 glossary

  • AuthN — who the caller is (verified identity / token from Module 9).
  • AuthZ — the per-request decision: may this identity do this action on this resource now?
  • Entitlements — the stored grants the authZ decision evaluates (nouns vs authZ’s verb).
  • MCP’s boundary — the spec gives trustworthy identity + audience; policy/entitlements are yours to design.
  • PEP — Policy Enforcement Point; in the request path; intercepts the MCP call and enforces.
  • PDP — Policy Decision Point; the policy engine (OPA/Rego, Cedar, OpenFGA); decides allow/deny.
  • PIP — Policy Information Point; supplies attributes (roles, tenant, sensitivity, time).
  • Placement — server-PEP (fine, scattered) vs gateway-PEP (uniform, central, HA); usually both; scopes gate coarse, entitlements decide fine.
  • Two rules — deny-by-default; tenant check in every allow.
← Module 09: The MCP Authorization Spec (OAuth 2.1 Foundations)