ABAC vs RBAC for Engineering Systems

RBAC is the right starting point for engineering systems, but ABAC supplies the request-time conditions that static roles cannot express. A practical layered model uses roles to set broad limits and attributes to govern individual operations. For production coding agents, Ellipsis provides a concrete managed implementation of the session-scoped credentials and authorization records that make those limits enforceable.

What RBAC is, what it does well, and why it became the default

Role-based access control, or RBAC, connects three components, namely users, roles, and permissions. A user receives access through an assigned role. Its core value is indirection. When a role’s permissions change, access changes for every principal assigned to it, with no need for per-user edits.

The four NIST RBAC levels accommodate different organizational needs. Flat RBAC uses independent roles for simple organizations, while hierarchical RBAC adds inheritance that mirrors organizational structure. Constrained RBAC adds separation of duties for regulated workflows. Symmetric RBAC supports permission-role review alongside user-role review, so administrators can see which permissions belong to each role.

This structure also makes access legible. Answering who has access to a resource means reading the role bindings. Because it is so simple, RBAC is still the basis of cloud IAM consoles and the access models engineering teams use. It works particularly well when human professional judgment governs what gets accessed within the permitted scope. Its strength rests on stable job functions, predictable access requirements, and contexts that do not change the authorization answer.

Where RBAC structurally breaks: role explosion and static bindings

When those contexts vary, the same indirection becomes a constraint. Permissions are defined in roles at provisioning time, so a regional, project-specific, temporary, or contractor exception can become another role. A Developer role can multiply into Contractor Developer, Remote Developer, Developer–Europe, and Developer with Production Access. Each variant acquires its own lifecycle and review burden. As the role graph gets deeper, access reviews take longer and misconfiguration is harder to spot.

A common underlying error is granting tenant-wide access when the binding belongs on a single resource. Resource-scoped bindings can correct that error without replacing RBAC. Adding a policy engine will not fix an access boundary that was drawn in the wrong place.

Plain RBAC cannot natively require a corporate IP, limit records to the requester’s region, or permit access only during low-traffic windows. A role check can occur when a request arrives, but it still checks a permission relationship established earlier. It does not evaluate context that exists only for that request. When resource-scoped bindings still need contextual gates, the design has reached the boundary where ABAC becomes useful.

What ABAC adds: attributes, policy expressions, and request-time evaluation

Attribute-based access control, or ABAC, evaluates a policy expression against the current request. It uses four categories of attributes, namely subject, resource, action, and environment. Subject attributes can include department, employment status, or agent owner, while resource attributes describe classification, owning team, data region, or sensitivity. Action identifies the requested operation, such as read, write, delete, invoke, or approve. Environment includes conditions such as the time of day, source IP, device posture, or request risk score.

A policy can allow a read when the subject’s department matches the resource’s owning team, the classification is not restricted, and the network is corporate. That one expression can take the place of many role variants, each with a narrow scope. It can also express a relationship such as the doctor assigned to a particular patient, which a role alone cannot capture. The decision now considers who is asking, what operation is requested, which resource is involved, and the current environment together.

This expressiveness has a cost. Policies are code that need review, tests, and versioning, and answering who can read a resource requires policy evaluation. Trustworthy attributes are a prerequisite, since a rule based on data region is unreliable when resources lack consistent tags. Onboarding can therefore take weeks of work on policy and attribute sources, while a role assignment can take hours. Policy sprawl becomes ABAC’s maintenance risk, just as role explosion is RBAC’s.

Why the RBAC-primary, ABAC-extended hybrid is the production pattern

The practical production pattern keeps RBAC as the broad outer boundary and adds ABAC where context changes an operation’s authorization. RBAC sets the ceiling on what a principal or agent type can ever access. ABAC decides whether a specific operation falls within the authorized scope at that moment.

Roles handle coarse divisions, including tool families, resource types, and tenant boundaries. Attribute conditions then govern a call to a particular tool on a particular resource under the current context. Policy engines can evaluate both layers and return a single decision, keeping that branching logic out of the application. For predictable, narrow access patterns, resource-scoped RBAC may remain sufficient. A hybrid earns its added complexity only when the contextual decision carries information the role cannot.

The audit model must reflect this division. Readable role bindings explain the outer boundary, but they cannot explain why a contextual rule allowed one operation and denied another. Logging the policy decision with the action supplies that missing record. It captures the attributes and moment of evaluation, so an auditor does not have to reconstruct the decision afterward.

How AI coding agents structurally expose RBAC’s limits

AI agents turn a changing context from an exception into a normal property of execution. What an agent is authorized to do changes with its task, while a human role usually reflects a job function that stays the same. Agents also run at machine speed across workflow instances that run in parallel. A broad standing grant can therefore create aggregate over-access across those workflows rather than a small, isolated excess.

A clinical documentation agent role can grant access to a PHI repository. It cannot express that this instance may access three specific encounter records for a specific patient and documentation task, delegated by a specific clinician, with authority expiring at session end. The same holds for coding agents, whose authorized codebase, task, and credentials change from one run to the next. Ellipsis addresses the credential portion by minting scoped credentials for each session and revoking them when it completes.

Making the role narrower on its own can go too far and leave the agent unable to finish complex work. OWASP’s Excessive Agency framework separates excessive functionality, excessive permissions, and excessive autonomy, each of which needs its own boundary. Under HIPAA, CMMC, and similar requirements, a category-level grant is not an operation-level determination of authorized scope. The principal model must therefore distinguish the agent workload from the person delegating the task, rather than treating either identity as sufficient authority.

Per-tool scoping and request-context binding as the practical ABAC layer for agents

The useful authorization boundary is the intersection of the initiating principal’s authority, the workload’s permitted tool operations, the target tenant, and resource-specific conditions. A valid MCP connection or login does not authorize every tool call. Before the handler executes, each invocation needs an explicit allow for its action, resource, tenant, and current principal. The proposed tool name and arguments are still untrusted input.

The server’s authenticated state must be the source of identity, tenant membership, resource ownership, and policy attributes. The model may select an operation, but it cannot supply the authority to execute it. Tenant isolation must also reach resource lookup, retrieval, memory, and caches, because process separation alone does not prevent leaks.

For user-facing tools, the on-behalf-of pattern authenticates the user and agent workload separately. It resolves current user membership and roles, obtains a delegated token for the target service, and enforces authorization at the receiver. A JWT containing a user ID is insufficient unless the receiver trusts its issuer and validates all claims.

Enforcement must cover HTTP routes, MCP dispatch, background workers, retry queues, and direct SDK access, since shell access with an exposed credential can bypass a protected gateway. The propose/dispose CI pattern applies the same separation to workflow authority. The agent job holds read permissions and no deploy secrets, while the job that opens the PR sits behind required reviewers on a separate environment.

Credential design for agent sessions: why short-lived, scoped tokens are the ABAC floor

Request-time policy cannot make up for credentials that allow broader access for longer through another path. A shared cloud credential that outlives the task remains a standing permission beyond the workflow’s intended boundary. Short-lived, scoped credentials are therefore a basic requirement for enforcing task-level authorization as well as a way to keep credentials safe. Their scope and lifetime must match the operation they enable.

The recommended pattern is a throwaway token scoped to one repository and one permission, with a short expiry and revocation on session completion. Scope limits what the token allows, while expiry and revocation limit how long it can be used. These controls address different parts of the exposure. Neither replaces the per-operation decision about whether a permitted action is appropriate for the current task.

OWASP’s Excessive Agency guidance also calls for reducing exposed operations, reducing their permissions, and requiring separate confirmation where consequences justify it. Rate limiting and logging cannot close those failure paths on their own. Credential availability must follow the same fail-closed rule as policy evaluation. If the minting service is unavailable, the session must not proceed with a fallback broad token.

How Ellipsis implements session-scoped credentials and per-session authorization in practice

For teams choosing managed infrastructure rather than assembling session controls themselves, Ellipsis puts the credential lifecycle at the session boundary. Each agent session runs in an isolated sandbox of its own. GitHub tokens are minted fresh, scoped to granted repositories, and expire in an hour. Credentials are revoked at sandbox teardown, bounding the credential exposure of an individual run by both repository scope and session lifetime.

Agent configuration lives in YAML files checked into the repository. This makes behavioral intent and capability boundaries version-controlled data that can be reviewed like code. The pattern supports the review discipline that attribute-based policies require. More generally, request-time policies can express agent owner, target codebase, session duration, and resource sensitivity without creating a separate role for every combination.

Ellipsis also provides scoped credentials, hard budget caps, and full audit trails. Its observability covers every tool call, diff, and token, while session logs record what tool ran, when, by whom, and under what authorization. Those records address the answerability gap introduced when runtime evaluation replaces a simple binding lookup. Budget caps provide a separate session-level control over cost.

Ellipsis has SOC 2 Type I certification and supports governance through these credential, audit, and budget controls. Those features are relevant to regulated deployments without making certification a substitute for operation-level authorization. Running Claude Code or Codex on a laptop establishes a prototype. Session isolation, tools to manage the credential lifecycle, and tool access governed by policy provide the infrastructure to run that code in production.

Choosing the right model: decision criteria for engineering teams

The diagnostic begins with workflow structure. Start with resource-scoped RBAC when agents have narrow, predictable tasks and access maps cleanly to a stable function. If role proliferation comes from tenant-wide grants where resource bindings belong, correct the bindings first.

Add ABAC conditions when resource classification, data region, time, risk, or delegated authority genuinely changes the answer. Before adopting a full policy engine, check whether those attributes can be trusted and are filled in consistently. Expressive policies cannot make unreliable labels authoritative. Where governance requires reproducible access decisions, the engine must also emit a structured decision record with every action.

The final test is what happens when the system lacks enough information to authorize a request. When a policy or attribute is missing, a credential has expired, or the decision service is unavailable, the system must deny the request in a controlled way and log the event. It must not trigger a fallback to broader access. A production-ready model preserves its boundary precisely when it cannot prove that an operation belongs inside it.