RBAC vs ABAC vs PBAC in Cloud Infrastructure
Three models work as layers, not alternatives, to prevent access creep.
RBAC, ABAC, and PBAC serve different purposes in cloud infrastructure. RBAC establishes baseline access, ABAC refines it with runtime conditions, and PBAC governs their enforcement across services. The practical choice is how much of each layer a system needs. For teams running coding agents, Ellipsis offers a managed approach to the session isolation, credential scoping, and audit trails that make this architecture operable.
Why access control becomes an architectural problem as cloud systems grow
An ex-regional director still has transaction access across four states, months after moving to a new role. Authentication may work perfectly, but authorization still gives the person access for work they no longer do. The access was never reviewed or revoked, so an ordinary organizational change left behind unnecessary permissions. This is what happens when access control is treated as an implementation detail rather than a structure that must change with the organization.
Distributed systems make that harder because APIs, services, jobs, and frontends can each enforce access on their own. Without a common policy baseline, changing a permission in one place does not establish what happens elsewhere. Roles multiply, attributes acquire inconsistent meanings, and policies contradict one another. Authorization encodes how an organization distributes trust, but that encoding becomes a liability when it cannot change safely. The choice of model thus shapes how requests are allowed today and whether people can still explain who has access as the system grows.
What RBAC does well and exactly where it breaks
Role-based access control is the right foundation when job responsibilities map cleanly to resource permissions. Users receive roles, and roles carry permissions, so administrators do not have to manage every permission for every person. A financial services trading platform can give a “Senior Financial Analyst” market data and trade execution while giving a “Compliance Officer” audit logs and monitoring without direct trading. These are stable distinctions based on job function. The resulting checks are deterministic, inexpensive database lookups that are easy to cache.
The limitation appears when a job title no longer contains enough information to decide a request. A physician role can establish baseline access to patient records, but it cannot by itself express case ownership, shift hours, or device trust. Encoding those conditions as specialized roles produces role explosion as a structural outcome. Governed platforms instead keep the assignment layer separate from the runtime constraints. For example, Ellipsis supports role-based access to agent definitions while using fresh session-scoped credentials, budget caps, and sandbox isolation to constrain execution without multiplying roles for every condition.
What ABAC adds and what it costs
Attribute-based access control matches attributes of the principal and resource with environmental context at request time. A doctor may access patient records only when assigned to the case, during their shift, and on a secure device. Similarly, a cardiologist can access cardiology records but not oncology records without requiring a new role for every specialty combination.
That flexibility shifts complexity from roles to attributes. Request-time evaluation uses data from more than one source and costs more than a role lookup, though the right attribute infrastructure keeps that extra cost manageable. The harder requirement is clean identity data and clear ownership of attribute meanings. When mappings are in application code, each service can read the same condition in a different way, which makes changes hard to audit and test. Diagnosing an incorrect decision then requires tracing which attributes were evaluated, in what order, and against which logic. ABAC therefore needs governance over the evaluation rules themselves as well as the attributes they use.
What PBAC actually is and how it relates to RBAC and ABAC
Policy-based access control supplies that governance layer over role and attribute logic. It separates policy definition from enforcement, moving authorization rules out of scattered middleware and application conditionals. A dedicated policy engine evaluates the roles, attributes, and context that a request presents. The declarative rule can remain legible, such as “Physicians may access patient records only during active care episodes on managed devices”. Attributes are resolved at evaluation time, but the governing requirement is explicit.
The PBAC/XACML architecture distinguishes a Policy Administration Point where policies are authored and versioned, a Policy Decision Point that evaluates requests, and a Policy Enforcement Point that applies decisions. Human-readable rules help compliance teams compare the stated control with the rule the system enforces. However, centralization alone does not prevent redundant or contradictory policies. Versioning, review, and testing are necessary because PBAC can accumulate policy sprawl just as RBAC accumulates roles and ABAC accumulates attributes.
How the three models operate as layers, not alternatives
Consider a physician requesting a patient record. RBAC first gives the physician the broad access that comes with the job, including the types of records that role may access. ABAC then refines that entitlement using the circumstances of this request, including case assignment, a managed device, and shift hours. PBAC evaluates those inputs against the system’s explicit policy and provides the decision that the enforcement point applies.
This is an RBAC-primary, ABAC-extended architecture with a policy engine enforcing both. RBAC preserves a stable vocabulary for broad responsibilities, while ABAC avoids turning every contextual distinction into another role. PBAC gives services a common interpretation of how those responsibilities and conditions combine. By distributing complexity according to what each model handles well, the layers contain the risks of role, attribute, and policy sprawl, but they do not remove the need to manage any of them.
Where each model breaks down when used alone, and what that costs
Used alone in a complex system, each model eventually carries work it was not designed to handle. RBAC turns fine-grained conditions into an expanding role list that becomes difficult to audit. With ABAC, the number of attribute sources and sets of evaluation logic can grow without a shared meaning across them. PBAC without structured roles and precise attributes must compensate with increasingly complex rules.
More harm comes from failures between systems that use different models without a shared policy layer. A user can lose an RBAC role yet still get access elsewhere through a matching ABAC attribute. Neither local decision necessarily appears erroneous, even though the combined result is broken access control. Auditors must then reconcile separate authorization logs to explain who can reach sensitive data and why. For systems containing ePHI, HIPAA Technical Safeguards require evidence that controls operated.
Why AI coding agents make the access control layering problem urgent
AI coding agents inherit the permissions and weaknesses of their host infrastructure. Stale access that remains a latent risk for a human becomes active exposure when an agent operates across tools at machine speed. A documented 2026 case involving a production database illustrates the consequence. An agent wiped the database in 9 seconds through a combination of guessing instead of verifying, overprivileged tokens, and missing per-tool blast radius controls. The authority available when the incorrect decision occurred was an architectural issue.
The correct boundary starts with the intersection of the originating user’s permissions and the tool’s legitimate needs. ABAC adds context such as data classification, environment, time, and risk score, while PBAC evaluates every tool call. A capability token narrows the task to specific tools, resources, and tenants, with a short TTL and no refresh. Additional capabilities require a return to the authorization server. Delegated agents receive scopes equal to or narrower than their parent’s, so delegation cannot expand authority.
Policy-as-code as the mechanism that makes PBAC governable in practice
Policy-as-code makes these boundaries reviewable and testable before agents exercise them. Ellipsis keeps agent definitions and permission fields in version-controlled YAML files checked into the repository, so configuration goes through the same review as application code. Repository access itself remains governed through GitHub App installation settings, so YAML is not the sole access authority. More broadly, configuration files do not establish PBAC merely by existing. Rules given to a model through a prompt or enforced through scattered inline conditionals still have no shared way to reach a decision.
A dedicated policy engine places that mechanism in front of tool calls, where the agent runtime does not decide whether its own action is permitted. OPA with Rego provides this pattern through a declarative language for context-aware policies. Netflix, Goldman Sachs, Google Cloud, Pinterest, Capital One, Intuit, and T-Mobile are documented production adopters of OPA-based authorization. The same pattern can set the rules for Kubernetes admission requests, API calls, Terraform compliance, and agent actions. Its value is the development discipline around policy, including version control, unit tests, peer review, and continuous deployment. Those practices also let teams trace the attribute evaluation logic and keep each service from reading it in its own way.
How to choose the right combination for a given system
The progression begins with the conditions the organization actually has. A small engineering organization with stable responsibilities and predictable permission needs may need only RBAC. Adding attribute infrastructure and a policy engine at that stage costs money to run and may not solve a problem the organization has. ABAC becomes useful when access starts depending on location, device trust, tenant boundaries, data classification, or time. Role proliferation is another sign that the system is trying to encode conditions at the wrong layer.
PBAC is needed when services handle authorization in different ways or compliance reviews cannot clearly explain who has access and why. Regulated environments need it sooner because they must show that rules were enforced as well as say what the rules were meant to do. Automated agents also change when it is needed because they use permissions across tool calls without the pauses a human would take. Those systems need at least per-session credential scoping, per-tool blast radius controls, and policy enforcement that works the same way across them. The progression remains additive, but agent adoption can make the need for the later layers immediate.
Running governed agents in production with RBAC, ABAC, and PBAC in place
Once the policy model is defined, it still needs to be enforced from start to finish in every agent session. Credentials need narrow scopes and a controlled lifecycle, tool activity needs attribution, and budgets need limits before execution begins. For teams that want that governance without building the infrastructure themselves, Ellipsis is a managed cloud platform for coding agents including Claude Code and Codex. Its repository-based agent definitions connect the review process to the environment in which agents run. This makes it a strong fit when the operational requirement is consistent governance across an engineering organization.
Each session runs in an isolated sandbox with credentials minted fresh and revoked when the session ends. Every tool call, diff, and token is logged and attributable to a person or trigger. Hard budget caps apply at the session, agent, and account level, with trailing daily, weekly, and monthly limits per account, per agent, and per developer. Agents can start through the terminal, Slack, GitHub, Linear, API, events, or schedules, so governance can cover existing workflows. Ellipsis is SOC 2 Type I certified and backed by Y Combinator.
Self-hosted runners with a dedicated policy engine remain a valid approach for teams that want to operate the infrastructure themselves. The architecture is the same, but managing sandboxes, credential lifecycles, audit pipelines, and budget enforcement falls on the team. Either approach must distinguish logging obligations from access enforcement requirements. The EU AI Act (Article 12) requires automatic event logging throughout the life of high-risk AI systems so events can be traced, but it does not specifically require evidence of enforcement at the level of each access attempt. The practical decision is therefore not managed versus self-hosted policy in isolation, but who will maintain the infrastructure that makes every governed decision effective.
