Authorize the action and the data.
Activity-data authorization decides not just whether a caller may perform an operation, but whether they may perform it on this record and these fields — convention-derived, data-aware, and fully overridable. The 2026 edge externalizes the decision to a policy engine only for the operations where relationships or rich attributes demand it, while ADA stays the default everywhere else.
1. Why role checks are not enough
The most common API breaches are not broken authentication — they are broken authorization: a properly logged-in user reaching an object that is not theirs (BOLA) or invoking a function they should not (BFLA). Role checks answer “is this caller an admin?” They do not answer “may this caller read this account’s balance and this field?” The gap between the two is where record-scraping and privilege abuse live.
B5 Secure closes it by authorizing the action together with the data it touches, down to the record and the field, as a pipeline concern rather than a per-handler convention that drifts.
2. Today: activity-data authorization
ADA is activity-based, data-aware, and convention-driven. Permission codes are derived by convention from the operation and entity, so authorization cannot silently fall out of step with the code as the surface grows. Sensitive fields are flagged automatically and gated, and implied permissions let a higher grant subsume lower ones without redundant declarations. The result is least privilege scoped to the action and the record — with explicit overrides where business logic genuinely needs them.
Convention-derived permits are the quiet strength here: because codes come from the operation and entity, a new endpoint is authorized by the same rules as every existing one. There is no “we forgot to add an authorization check” failure mode.
3. The 2026 edge: a PEP to an external PDP
Some decisions are genuinely relational (“may this user act because they manage the owner’s team?”) or richly attribute-driven, and those are better expressed in a dedicated policy language than in code. The 2026 extension adds a standards-based Policy Enforcement Point aligned to OpenID AuthZEN 1.0 — the emerging interop standard for the PEP↔PDP authorization API. The pipeline becomes the PEP; the decision can be delegated to an external Policy Decision Point for exactly the operations that warrant it.
Crucially, this is additive and surgical. ADA remains the default for the overwhelming majority of operations; you route to the external PDP only where relationship or attribute complexity earns it. The application code calls the same authorization surface either way.
4. ReBAC, PBAC, and where each fits
- OpenFGA (ReBAC) — relationship-based access control, Zanzibar-style. The right tool when authorization follows a graph: ownership, team membership, delegation, hierarchical sharing.
- Cedar / Cerbos (PBAC) — policy-based access control over rich attributes and conditions, with human-readable, testable, versioned policies.
- ADA — the default for the convention-driven, data-aware case that covers most endpoints with the least ceremony.
Because the PEP speaks AuthZEN, the PDP is a deployment choice, not a code rewrite — you can change engines behind the same enforcement point.
5. The calling convention
ADA is declarative and convention-driven; the external PDP is opt-in per operation through the same attribute surface.
// ADA by default — permit derived by convention, data-aware
[Permission("account.read")] // scoped to the operation AND the record it touches
public async Task<AccountView> GetAccount(AccountId id) => ...;
// Route the genuinely relational decision to an AuthZEN PDP
[Authorize(Pdp.AuthZen, relation: "can_manage")]
[Permission("team.payouts.approve")]
public async Task ApproveTeamPayout(TeamId t, PayoutId p) => ...;6. What an attacker actually gets
An authenticated caller who tampers with an object id to reach another tenant’s record is stopped: ADA authorizes the data, not just the action, so the foreign record is not in scope for their permit. A caller probing for hidden functions finds none they are not permitted, because feature exposure and authorization share the same permit model. And because permits are convention-derived, an attacker cannot find the one endpoint a developer forgot to guard — there is no such endpoint.
7. Where this lands in an audit
This is the evidence for least-privilege and logical access controls (SOC 2 CC6.1–CC6.3; ISO 27001 A.5.15, A.8.3) and the direct mitigation for OWASP API Security Top 10 BOLA/BFLA. Externalized policies, when used, give auditors human-readable, versioned, independently testable authorization logic — and AuthZEN alignment lets you describe it against a published standard.