RBAC vs ABAC for AI Coding Agent Permission Models

AI coding agent permissions require more than a choice between RBAC and ABAC. Roles define stable access, attributes govern context, and session-scoped credentials bind authority to a particular run. Ellipsis provides a managed path for enforcing that boundary. Layering these controls in production keeps an agent’s access bounded by the task a human delegated, even when the steps cannot be known in advance.

Why classical permission models assume something AI coding agents cannot provide

Classical access control starts with a caller whose needs can be described before the work begins. RBAC consults role assignments, ABAC evaluates attributes, and ReBAC checks relationships. Though the inputs differ, each model assumes that the information used to authorize a call captures what the caller is allowed to access. Agentic workflows challenge that assumption because the task unfolds through an unpredictable sequence of model-generated decisions.

A single coding prompt may lead an agent to read an issue tracker, pull a billing record, write code, and open a pull request. The person who supplied the prompt may not know that sequence beforehand. Narrow permissions can thus stop work that should be allowed halfway through, while broad permissions let a nondeterministic system keep access to sensitive tools. Authorization requires distinguishing the access needed for this task from access the agent could exercise but was never asked to use.

Surapani et al. propose tool invocation as the fundamental unit of analysis for agent authorization. At that boundary, a generated plan becomes an externally visible action, and identity, intent, permission, provenance, and policy must converge. An API call cannot be judged solely by whether the agent generally has access to the endpoint. Its authority must also be understood in relation to the human delegation that produced the call.

What RBAC does well and where it breaks for agents

RBAC remains a sound default when access patterns are stable and predictable. Permissions cluster into roles that reflect job functions, so onboarding requires an assignment and offboarding requires a revocation. Auditing can begin with a role query rather than an examination of every runtime condition. That administrative simplicity is a genuine security advantage because understandable access is easier to review. Agents with fixed tool sets can benefit from it just as human users do.

The four NIST levels are flat, hierarchical, constrained, and symmetric, with added expressiveness bringing administrative overhead. For agents that always need the same tools, flat or hierarchical RBAC is often enough. More complex role structures do not always make access safer. Their value depends on whether the extra structure describes a real and stable distinction in authority.

Coding agents exceed that job-function-based design envelope when permissions take the shape of a task. The same agent may need read access to a repository during a review run while having no permission to write to production during an untriggered run. RBAC has no native concept of authority limited to this particular run or exercised on behalf of the specific user who triggered it. A rule allowing database updates during low-traffic hours but not peak transactions exposes the same gap. Expressing that condition through roles requires workarounds that functionally reproduce attribute evaluation.

Teams often compensate with read-only, read-write, production, and staging roles, then split those roles again for exceptions. The resulting role explosion obscures what any assignment actually permits. New roles that describe the circumstances of access instead of distinct job functions are a warning sign. Binding permissions to individual invocations removes the need to encode those circumstances as permanent roles. With infrastructure such as Ellipsis, teams can use session-scoped credentials as the way they run agents, without having to maintain a workaround around the role system.

What ABAC fixes and what it costs

ABAC moves the decision from a static role lookup to an evaluation of current conditions. A policy can check the subject, resource, action, and environment together. Subject attributes can include agent type, delegating user, and clearance, while resource attributes can include tenant, owner, and sensitivity classification. Environmental conditions such as time of day or an emergency escalation flag can participate in the same decision. These inputs let a policy express distinctions that would otherwise require proliferating roles.

Consider an agent reading a pull request on behalf of the user who opened it. An ABAC policy can require that the repository belongs to that user and that access occurs during the session in which the task was triggered. That is one contextual rule rather than a new role for every combination of user, repository, and run. The policy may take more code than a role lookup because it states the actual constraint. Its length is not, by itself, evidence of unnecessary complexity.

The cost is that someone must own the policy set and test it with the same discipline applied to role definitions. As attributes combine in more ways and policies affect each other, finding every path to a resource takes more than a simple role query. A poorly maintained ABAC system can therefore be harder to audit without being safer. Automation of evaluation and credential minting and revocation can reduce operational work while preserving policy expressiveness. It does not remove the need to maintain the rules themselves.

ABAC also depends on the quality and provenance of its attributes. A policy that checks the delegating user is useful only if the runtime supplies a trusted identity for that user. If the attribute is missing, the policy may block work that should be allowed. If the agent supplies an untrusted value itself, the decision rests on the caller’s own account of its authority. Even attributes that can be trusted may show who can act without showing whether a chain of actions stays within the original task.

How multi-agent delegation chains break both models

Delegation turns authorization from a decision about one call into a constraint across a workflow. An orchestrator may spawn a retrieval sub-agent, which then calls a code-execution tool. Each hop can pass its own checks even when the actions taken together go beyond what the human authorized. Tallam’s paper on authorization propagation identifies this limitation in ABAC. Independent access decisions do not model the chain or constrain the aggregation of individually permitted accesses.

The four-model, one-API-call thought experiment makes the distinction concrete. RBAC can approve because the agent has the required role. ABAC can approve because the current attributes satisfy policy, and ReBAC can approve because the relevant ownership relationship exists. Yet the call may still fall outside the task the human delegated. Only an intent layer asks whether the otherwise permitted action belongs to that task, rather than treating access eligibility as sufficient evidence of purpose.

Surapani et al. describe a principal hierarchy running from the human user through the operator/deployer, orchestrator, and sub-agent to the tool endpoint. Each handoff must limit what the next principal can do as it passes credentials down the chain. The protocols used for those handoffs do not, on their own, close the gap. MCP defines how agents communicate with tools but does not establish who an agent is, while agent cards in an agent-to-agent communication protocol hold identities that agents declare themselves, with no requirement for attestation binding. Optional signing is not the same as a required, verifiable delegation chain.

A sub-agent can use an orchestrator’s credentials for work the original human never authorized, even though each call seems to be allowed by the credential’s permissions. Neither a larger role catalogue nor a more detailed per-call attribute policy establishes that the inherited authority was properly bounded. The missing property is scope containment across the whole chain.

What a layered permission architecture for coding agents actually looks like

The architecture starts with RBAC for stable tool bundles and resource scoping for predictable access. ABAC then governs calls whose legitimacy depends on tenant, delegating user, resource sensitivity, time, or other changing conditions. This division keeps ordinary permissions understandable while reserving contextual evaluation for decisions that need it, including high-risk actions. Surapani et al.’s invocation-centered analysis provides the boundary where those decisions must become enforceable. Session-scoped credentials carry the permitted authority from policy into execution.

The propose/dispose CI pattern gives that boundary a concrete operational form. The job running the agent receives minimal read permissions and no deploy secrets. With an environment-per-PR arrangement, each run has its own isolated environment that auto-destroys on merge, which prevents state bleed between runs and leaves a clean audit trail. Ellipsis intervenes at this execution boundary by minting fresh credentials scoped to a single session and revoking them on completion. Credential lifetime is therefore tied to the run rather than to the continued existence of an agent role.

Delegation needs a way to track authority passed between agents because session boundaries alone do not describe it. Prakash’s proposed Invocation-Bound Capability Tokens, or IBCTs, combine identity, attenuated authorization, and provenance binding in an append-only token chain. The proposal uses compact JWT for single-hop delegation and Biscuit tokens with Datalog policies for multi-hop delegation. Each sub-agent receives only scope the orchestrator was itself granted, and the chain remains verifiable. Tallam’s intent-based analysis also checks whether an action that is allowed still serves the delegated task.

Configuration also belongs in the repository, where it can be reviewed and versioned like other code. NVIDIA’s OpenShell, launched at GTC 2026, demonstrates this pattern through declarative YAML security policies committed to repositories and deployed through CI/CD pipelines. Those policies define the boundary for agents that read files, call APIs, and execute code. Every tool call, delegation hop, and use of a credential must be open to audit so that the decisions made can be checked afterward. Surapani et al. identify that contestability as a necessary property of trustworthy human-AI systems.

How to run RBAC, ABAC, and session-scoped credentials on managed infrastructure

Building sandbox infrastructure, credential lifecycle management, and audit tooling from scratch is real engineering work that competes with the work agents are supposed to accelerate. Production enforcement also requires budget caps and complete logs. Ellipsis is the managed option for teams that need these controls across several engineering groups and want to avoid building the platform themselves. It runs Claude Code and Codex in isolated sandboxes, with credentials minted per session and revoked on completion. That makes it a practical fit when the permission design is clear but its operational burden is becoming substantial.

Self-managed approaches remain appropriate at smaller or more controlled scopes. For an individual developer running Claude Code locally, the minimum configuration is sandbox mode with explicit path allowlists in agent settings. Team CI/CD requires containers or microVMs with minimal capabilities, network access limited to declared endpoints, and process limits. The propose/dispose pattern keeps those runs stateless and auditable. Both managed and self-managed approaches can enforce useful boundaries, but responsibility for building and maintaining enforcement varies as deployment expands.

On Ellipsis, agents are defined in YAML files committed directly to the repository. Teams review changes in pull requests, version them, and deploy through the same CI/CD pipeline used for the rest of the codebase. Each session has its own sandbox, and its session credentials cannot last beyond the run or leak into other runs. Hard budget caps apply to each session, agent, and developer before money is spent.

The same configuration can govern agents triggered from the terminal, Slack, GitHub, Linear, Sentry, or API, so changing the interface does not move governance outside the engineering workflow. Ellipsis keeps audit trails of every tool call, diff, and token, so teams have records of what an agent did as well as the code it wrote. Those records must sit beside bounded credentials and reviewed policy, because a correct ABAC rule running through a shared credential is not a production-grade system. Surapani et al. frame the required properties as traceability to a human principal, bounded delegation, and contestability afterward. A managed platform makes those properties practical to maintain at scale when enforcement and the audit trail are treated as one operational responsibility.