Capability-Based Authorization For Agent Calls: The Replacement For Per-Endpoint ACLs

TL;DR

Access control lists were designed for a world in which a finite set of subjects called a finite set of endpoints, with the binding between them stable enough to enumerate manually. Autonomous agents shatter both finitenesses. The number of distinct subjects grows because each agent instance is its own subject, the number of distinct endpoints grows because every operation against every resource becomes its own endpoint, and the binding between them changes by the second as agents are spawned, scoped, and retired. ACLs become a maintenance problem larger than the security problem they were meant to solve. Capability-based authorization replaces them with signed, scoped, time-bounded tokens that the issuer mints per call. The agent presents the token to the resource. The resource verifies the token's signature, scope, and bounds without consulting an external policy engine. The pattern scales because the policy decision lives in the token, not in a list. This essay describes the model, the schema, the delegation pattern, and the migration path. The reader artifact is a complete Capability Token Schema you can adopt directly.

Introduction: The ACL That Stopped Scaling

A developer-tools company added an autonomous code-review agent to its platform in late 2025. The agent would inspect pull requests, run tests, propose changes, and post comments. The platform's authorization system was a mature ACL that had served the human users well for six years. Each user was assigned to one or more groups, each group held a set of permissions, and each repository's settings named which groups had which roles. The matrix was visible in the admin UI as a grid of users by repositories by roles. The grid was complex but tractable. New users were added to existing groups. New repositories inherited the organization's default groups. The pattern worked.

The agent broke the pattern within three months. The first problem was that the agent was not a user. The ACL had no representation for an autonomous principal. The team's first attempt was to model the agent as a service account, with a single set of permissions across all repositories. The single set had to be the union of every permission the agent might need across every customer. It was too broad. The second attempt was to create one service account per customer. The count of service accounts grew with the customer count. The admin UI became unusable when the customer count crossed two hundred. The third attempt was to dynamically create and delete service accounts as customers onboarded and offboarded. The provisioning logic became a system of its own, with bugs that produced ghost accounts and stale permissions.

The second problem was that the agent's behavior changed faster than the ACL could keep up. When a customer enabled the agent for a new repository, the agent needed permission to comment on that repository within seconds. The ACL update flow assumed human-speed changes, with a review step that took minutes. The team built a fast path that bypassed the review for agent permissions. The fast path became the most-used path. The reviewed path was used so rarely that the reviewers lost their familiarity with what they were approving.

The third problem was that the agent's permissions were too coarse. The ACL had a comment permission. The agent needed to comment, but only on pull requests it had reviewed, only with content the agent had generated, only within a window after the review completed. The ACL could not express any of those constraints. The team tried to enforce them in the agent code, which meant the constraints were the agent's responsibility to honor rather than the platform's to enforce. When a bug in the agent caused it to comment on the wrong pull request, the platform had no defense.

The team eventually abandoned the ACL extension and rebuilt the agent's authorization on capabilities. The rebuild took a quarter. The result was a system that scaled smoothly to hundreds of thousands of agent invocations per day, expressed the constraints precisely, and produced a clean audit trail. The customer-facing UX did not change. The security review went from a manual matrix to a generated report. The lesson was that the ACL had been the wrong abstraction for autonomous principals all along, and that the right abstraction was structurally different.

What ACLs Assume That Agents Violate

Before describing the capability model, it helps to enumerate the assumptions ACLs make that autonomous agents systematically violate. The assumptions are not failures of design. They are reasonable choices for the threat model and operational context ACLs were built for. They become liabilities only when the principal becomes an agent.

The first assumption is that subjects are stable. ACLs assume the subjects you are authorizing today will be approximately the same subjects you authorize tomorrow. New users join occasionally. Old users depart occasionally. The change rate is human-paced. Agents have no such stability. New agent instances spawn for every customer task, sometimes thousands per day. Each instance is conceptually its own subject because its behavior, scope, and lifetime differ. The ACL has to choose between modeling each instance separately, which inflates the ACL beyond manageability, or treating all instances as one subject, which inflates the blast radius beyond acceptability.

The second assumption is that endpoints are enumerable. ACLs assume that the operations you grant access to can be listed in advance. The list of endpoints in a typical web application is a few hundred to a few thousand. The list of resources behind those endpoints might be in the millions, but the access patterns are uniform: a user with read permission on repositories can read any repository they have access to. Agents do not respect uniformity. An agent might need read access to a specific file in a specific repository for the duration of a specific task, with no need before the task and no need after. Expressing that in an ACL would require an entry for the file. The list of files is unbounded.

The third assumption is that the policy decision is binary and stateless. ACLs answer the question of whether the subject can perform the operation on the resource. The answer is yes or no, the answer does not depend on history, and the answer is the same on every call. Agents need policies that consider history: an agent that has issued a hundred reversals this hour should be denied the hundred-and-first, even though each individual reversal is within its role's authority. ACLs cannot express the cumulative bound. Adding it requires a stateful overlay that lives outside the ACL but has to be consulted on every call, which complicates the architecture.

The fourth assumption is that delegation is rare. ACLs assume the subject acting at the moment of the call is the subject that was originally authorized. When user A asks the system to do something on user B's behalf, the system uses A's permissions, not B's. The pattern works for human collaboration because explicit delegation is uncommon. Agents delegate constantly. An agent acting on behalf of a customer needs to act with the customer's permissions, not its own. Multi-agent systems involve agent A asking agent B to do something on agent A's behalf. ACLs have no clean way to express this.

The fifth assumption is that the policy is stable. ACLs assume that the rules change infrequently and that changes are reviewed before they take effect. Agents need rules that adjust dynamically: an agent's permissions for a particular task should expire when the task ends. The ACL has no notion of task scope. Adding it requires a layer that creates and revokes ACL entries on task boundaries, which is the ghost-account problem.

Each of these assumptions can be patched. ACL extensions for agents typically include service accounts, automatic provisioning, dynamic groups, and time-bounded entries. The patches preserve the ACL as the apparent abstraction while changing what the abstraction means underneath. The result is an ACL that is no longer an ACL in the traditional sense and a system that is harder to understand than either the original ACL or a clean capability-based replacement.

The Capability Model

A capability is a token that authorizes a specific operation on a specific resource within specific bounds. The token carries its own authorization. The resource verifies the token without consulting an external policy database. The pattern dates to operating systems research in the 1960s and 1970s. It has had multiple incarnations: object capabilities in programming languages, capability-based file systems, distributed capabilities in research operating systems. The agent era brings it back as the natural abstraction for autonomous principals.

The capability has four properties that distinguish it from an ACL entry. First, it is unforgeable. The token is signed by an authority the resource trusts. An attacker cannot create a valid token without compromising the authority. Second, it is delegatable. The holder can pass the token to another principal, optionally narrowing the scope. The recipient can use the token within the narrowed scope. Third, it is revocable. The authority can invalidate the token before its time bound expires, and the resource can detect the revocation. Fourth, it is auditable. The token includes the chain of issuance and delegation, so every use can be traced back to the original authorization decision.

The authorization decision moves from the resource to the issuer. When an agent needs to perform an operation, it requests a capability from the issuer. The issuer evaluates the request against the agent's policy, the cumulative bounds, and any other relevant context. If permitted, the issuer mints the token. The agent presents the token to the resource. The resource verifies the signature and the scope without further policy evaluation. The decision has already been made.

The split between issuer and resource is the property that makes the model scale. The resource only has to verify tokens, which is a fixed-cost operation regardless of how many agents exist or how many operations they perform. The issuer makes the policy decisions, but the issuer can scale horizontally because each decision is independent. The resource and issuer can be in different administrative domains, on different machines, with different lifecycles. The token is the contract between them.

The split also clarifies the audit responsibility. The issuer logs every authorization decision: which agent requested what, against which scope, with what outcome. The resource logs every use: which token authorized what, performed by whom, with what result. The two logs join cleanly through the token identifier. An investigator can follow a use back to its authorization, and an authorization forward to its uses. The chain is direct, not inferred.

The capability model handles the agent-era stress points the ACL cannot. Subjects are not enumerated; the subject is whoever holds a valid token. Endpoints are not enumerated; the endpoint is whatever the token's scope describes. The policy decision is stateful because the issuer maintains state. Delegation is first-class because the token is designed to be passed. Policy changes are dynamic because new tokens reflect new policies and old tokens expire.

Capability Token Schema

The schema below is the artifact this essay produces. It is a complete capability token format you can adopt for any agent runtime. The schema uses standard cryptographic primitives and standard encoding formats. Every field has a defined semantics and a recommended size or value range.

The outer envelope is a JWT with a payload that carries the capability fields. The JWT signature is over the payload using the issuer's private key. The verifier validates the signature against the issuer's public key, which is published through a JWKS endpoint that the verifier caches. The JWT format is chosen because every reasonable HTTP framework knows how to verify JWTs and because the format is broadly tooled.

The payload contains the following fields. The issuer field names the authority that minted the token, in URL form so the verifier can resolve the public key. The subject field names the agent identity the token authorizes, in a form that is meaningful to the resource. The audience field names the resource or set of resources the token is intended for. The verifier rejects tokens with mismatched audience.

The issued-at field is the standard JWT issuance timestamp. The expiration field is the standard JWT expiration timestamp. The expiration is bounded to a small value, typically seconds to minutes, sized to cover the call's expected duration. The not-before field can be used to delay token validity, useful for scheduled operations.

The scope field is the heart of the capability. The scope describes what the token authorizes. It has sub-fields for the operation, the resource, the parameter constraints, and the use bound. The operation is a verb-noun pair like read-account or create-comment. The resource is a fully qualified identifier of the specific entity the operation applies to. The parameter constraints are key-value pairs that restrict the call's arguments. The use bound is an integer naming the maximum number of times the token can be used; for most calls it is one.

The delegation chain field is an array of delegation steps. Each step records the principal who held the token before delegation and the narrowing applied. An empty chain indicates the token is being used by its original holder. A non-empty chain indicates the token has been passed and possibly narrowed. The chain is verified at each step to ensure narrowing was monotonic. A delegation cannot expand the scope.

The binding field can include parameters that bind the token to a specific call instance. A common binding is the request body hash, computed by the agent before requesting the token and verified by the resource against the actual body. The binding prevents an attacker from stealing the token mid-flight and using it for a different call. The binding requires the agent and the resource to agree on the hashing algorithm and the body normalization.

The revocation field is a token identifier the issuer maintains in a revocation list. The verifier checks the list before accepting the token. The revocation list is small because tokens have short lifetimes; revocation is needed only when a token is detected as compromised within its lifetime. The list is published with a known cache TTL so verifiers can balance freshness against load.

The context field is a free-form bag for issuer-specific metadata. Common contents include the policy version that authorized the token, the request identifier that triggered the issuance, the cumulative-volume counters at issuance time. The verifier may use these for additional checks but the schema does not require it.

A fully populated token is around five hundred bytes encoded. The size is comparable to a JWT used for session authentication. The verification cost is around fifty microseconds for the signature check plus the policy enforcement, which the resource does in the application layer.

Delegation, Narrowing, And Multi-Agent Patterns

Delegation is the property that makes capabilities work for multi-agent systems. When agent A needs to ask agent B to do something on A's behalf, A produces a delegated capability that B can use. The delegation can narrow the scope: A might hold a capability to read any field of a customer record, but A delegates to B a capability to read only the email field. B can use the narrowed capability but cannot expand it.

The narrowing is enforced by the delegation chain in the token. Each delegation step appends to the chain. The verifier walks the chain from the original issuer through each delegation, ensuring that each step's scope is a subset of the previous step's scope. A step that expands the scope produces a verification failure. The walking is fast because the chain is bounded in length.

The pattern handles common multi-agent scenarios. A coordinator agent that dispatches work to sub-agents holds capabilities scoped to the coordinator's authority. The coordinator delegates narrower capabilities to each sub-agent. The sub-agents act with the narrowed authority. The audit trail shows the coordinator as the original holder and the sub-agent as the user. The coordinator is accountable for the sub-agent's use of the delegated authority.

Delegation also supports the customer-on-behalf pattern. A customer authorizes the platform to act on their behalf. The platform mints a capability that names the customer as the original holder and the platform agent as the delegate. The agent uses the capability to make calls. The downstream resources see the customer's authority being exercised, with the platform agent named as the actor. Audit and accountability flow correctly.

The one constraint on delegation is that the delegate cannot delegate further unless the original capability was issued with that property. The default is non-transferable: the delegate can use the capability but cannot pass it on. Transferable capabilities are used carefully, typically only for capabilities that pass through known intermediaries. The non-transferable default prevents capabilities from spreading uncontrolled.

Migration From ACLs To Capabilities

Most teams considering this architecture have an existing ACL that has accumulated complexity over years. Migrating to capabilities does not require throwing the ACL away on day one. The pragmatic migration runs in phases that allow both systems to coexist while the new model proves itself.

The first phase introduces the capability infrastructure alongside the ACL. The issuer is deployed. The token format is defined. A small set of operations is wired to accept either an ACL grant or a valid capability token. Agents that participate in the migration begin using capabilities. Other principals continue to use the ACL. The two systems coexist on a per-operation basis.

The second phase migrates operations one at a time, starting with the operations that have the most stress on the ACL. The agent operations are typically the highest priority because they exhibit the failure modes most clearly. As each operation migrates, the ACL grants for that operation are removed, and only capability tokens authorize the operation. The migration is reversible: if a problem appears, the operation can be temporarily allowed to fall back to ACL while the capability issue is investigated.

The third phase migrates the human-driven operations. Humans use the capability model through a session-bound capability that the platform mints when they log in. The session capability has the human's full role authority and a lifetime matching the session. The human's interactions produce derived capabilities for individual operations, which the platform mints automatically. The human experience is unchanged. The audit trail becomes uniform across humans and agents.

The fourth phase decommissions the ACL. By this point, no operations rely on the ACL for authorization. The ACL data can be retained as a record of the previous state. The ACL maintenance burden disappears. The admin UI shifts from a matrix view to a policy view, where operators define the policies that the issuer enforces.

The migration timeline depends on the complexity of the existing ACL and the operations team's capacity. A typical migration takes two to four quarters. Most of the time goes into the second phase, where the operations are migrated incrementally. The first and third phases are infrastructure work. The fourth is mostly cleanup.

Audit, Revocation, And Operational Practice

The operational practice around capabilities differs from the operational practice around ACLs. The differences become important once the system is in production.

Audit in the capability model is centered on the issuer. Every minted token produces an issuer log entry that includes the requesting agent, the requested scope, the policy version, the decision outcome, and any cumulative-volume counters consulted. The log is the source of truth for what the system authorized. The log is queryable by agent identity, by scope, by time range, by policy version. Investigators can produce reports of what the system has been asked to do versus what it has been allowed to do.

Resource-side audit captures every use. The use record references the token identifier and includes the call's parameters and outcome. Joining the use record with the issuer log produces the full chain from authorization decision to operational outcome. The join is mechanical because the token identifier is unique.

Revocation is needed when a token is detected as compromised within its lifetime. The detection might come from anomaly detection on the issuer side, from an alarm on the resource side, or from a manual operator action. The issuer adds the token identifier to the revocation list. The revocation list is published with a short TTL, typically tens of seconds. Verifiers refresh the list within the TTL. A revoked token stops working within the TTL window.

The revocation list stays small because tokens have short lifetimes. A token with a one-minute lifetime drops off the list one minute after revocation. The list size is bounded by the rate of revocations multiplied by the maximum token lifetime. For typical operating envelopes, the list contains at most a few thousand entries.

Operational practice for token issuance includes monitoring the issuer for unusual minting patterns, alerting on cumulative-volume policy denials, and reviewing scope distributions periodically. The issuer dashboard shows mint rate per agent, denial rate per agent, average scope breadth per agent. Operators can drill into any agent that triggers an alert. The drill-down shows the recent minting history and the policy decisions that produced each token.

Compromise response in the capability model is faster than in the ACL model. The issuer can revoke an agent's policy with a single update. After the update, no new tokens for that agent will mint. Existing tokens continue to work for their lifetimes, then expire. The window between detection and effective revocation is the maximum token lifetime, which is bounded by design.

Capability Issuer Architecture And Scaling

The capability issuer is the centerpiece of the model. Its design and scaling characteristics determine whether the model works in production. The issuer has to make policy decisions quickly, mint tokens efficiently, maintain state about cumulative bounds, and produce audit records that are queryable later. Each of these properties has implementation choices that affect the system's behavior.

The policy decision speed is the most user-facing property. The issuer is on the critical path for every agent call. A slow issuer makes every call slow. The target is sub-five-millisecond decisions at the ninety-ninth percentile under load. Achieving the target requires policy evaluation that runs in memory, with the relevant state cached close to the evaluation. Open Policy Agent and similar engines achieve this routinely. Custom policy languages can also achieve it with care.

The minting efficiency depends on the cryptographic operations. JWT signing is fast on modern hardware, around tens of microseconds for an Ed25519 signature. The signing should not be the bottleneck. The bottleneck is more often the policy evaluation, the audit logging, or the cumulative bound update. Each of these can be optimized independently.

The state for cumulative bounds is the most subtle implementation challenge. The bounds are per-principal, which means the issuer needs per-principal state. The state has to be fresh enough to enforce the bounds correctly, which means it cannot be cached for long. The standard pattern is a high-performance key-value store like Redis, with the bounds stored as counters that the issuer increments atomically on each minting decision. The store has to be highly available because the issuer cannot mint without it.

The audit records are the most space-intensive output. Every minting decision produces a record. The volume can reach millions of records per day per agent in high-volume systems. The records need to be queryable later for investigation and compliance. The standard pattern is to write the records to an append-only log, then mirror to a queryable store like a time-series database or a column-store. The dual write pattern accepts a small latency cost for the write durability.

The issuer scales horizontally on the policy evaluation. Multiple issuer instances can serve different agents independently. Coordination is needed for the cumulative bounds, which is where the shared state store comes in. The store becomes the bottleneck for vertical scaling, which means it should be partitioned by agent identity to spread the load. The partitioning works because cumulative bounds are per-agent.

The issuer's failure modes need careful design. If the issuer is unavailable, no new capabilities mint, which means agents cannot make new calls. The acceptable behavior is fail-closed: better to deny operations than to permit unauthorized ones. The implementation involves robust health checking, fast failover within an issuer cluster, and graceful degradation that preserves the most critical operations during partial outages.

Counter-Argument: Resource-Side Complexity

The natural objection is that capabilities push complexity from a centralized ACL into every resource that has to verify tokens. The resource needs to know how to verify signatures, how to parse scopes, how to enforce parameter constraints, how to detect revocations. The complexity, distributed across many resources, looks larger than the centralized ACL it replaces.

The objection has weight for resources implemented from scratch. For resources built on standard frameworks, the verification logic is provided by libraries that the framework maintainer keeps current. The resource's responsibility narrows to the parts specific to its domain: which scopes apply, which parameter constraints to enforce, which audit fields to capture. The parts that are common across resources are handled by the libraries.

The distributed complexity is also less of a problem in practice than in theory. The verification logic is standardized. Every resource verifies the same way. The variations are in the scope-specific enforcement, which would have existed in any authorization model. The capability model just makes the variations explicit by putting them in the resource code rather than implicitly in the ACL semantics.

The centralized model has its own complexity that the comparison often understates. The ACL is the centralized point that every authorization decision flows through. The decision is fast in most cases but the centralization introduces a latency floor and a failure dependency. The capability model decouples the verification from the centralized decision: the resource verifies locally, the issuer's centralized work happens at minting time, and the two are independent. The latency profile and failure profile improve.

The complexity comparison is more favorable to capabilities when the system has many resources and many operations. The ACL grows as the product of the two; the capability infrastructure grows as the sum. At small scales, the difference is invisible. At medium scales, the capability infrastructure is mildly more complex. At large scales, the ACL becomes unmanageable while the capability infrastructure stays maintainable. The break-even depends on the specific system but typically arrives somewhere between fifty and two hundred operations.

Capability Token Lifecycle And Cleanup

The capability lifecycle is short by design. Tokens are minted, used, and expire within seconds to minutes. The lifecycle has implementation consequences that the team has to plan for, including the cleanup of expired tokens, the handling of tokens for failed calls, and the renewal pattern for legitimately long-lived sessions.

Expired tokens do not need explicit cleanup at the verifier. The verifier rejects them based on the expiration field in the token. The verifier does not maintain a list of expired tokens; it just compares the current time against the token's expiration. The pattern is self-cleaning because the rejection is automatic.

The issuer maintains state about minted tokens for the cumulative bound calculations. The state grows over time as more tokens are minted. The state can be compacted by removing entries for tokens that have expired and whose information is no longer needed for any active bound calculation. The compaction runs periodically and keeps the state size proportional to the active workload rather than to the total historical volume.

Failed calls present a question about whether the consumed token should count against the use bound. If a token had a use bound of one and the call failed, should the token still be consumed? The conservative answer is yes: the token has been used in the sense that it was presented to the resource. The user-friendly answer is no: the call did not produce its intended effect, so the use should not count. The right answer depends on the specific failure mode. For network failures, the user-friendly answer is appropriate because the call did not reach the resource. For business-logic failures, the conservative answer is appropriate because the resource processed the call.

Long-lived sessions need a renewal pattern. A user session that lasts an hour cannot use a single capability with a one-hour expiration because the lifetime is too long. The pattern is to mint a session capability with a moderate expiration, then mint short-lived per-call capabilities derived from the session capability through delegation. The session capability serves as proof of authentication; the per-call capabilities authorize specific operations. The session capability can be renewed at the issuer if the user remains active.

The cleanup story is simpler than the equivalent in ACL systems because there is no permanent state to remove. ACL grants persist until they are explicitly revoked, which means the system accumulates grants over time. Capability tokens expire automatically, which means the system does not accumulate them. The operational burden of cleanup is the burden of the issuer's state compaction, which is bounded.

What Armalo Does

Armalo issues capability tokens for every authority decision its agents make. The token format is the schema described in this essay, with extensions specific to Armalo's pact and scoring substrate. Tokens are minted just in time for each call, scoped to the operation the agent is about to perform, and bounded to short lifetimes that match the call's expected duration.

The issuer is integrated with the policy engine that enforces pact compliance. When an agent requests a capability, the engine checks the agent's pact, the cumulative bounds, and the trust level of the data that motivated the request. The decision is recorded in the audit substrate alongside the other authority decisions. The audit chain runs from the original task that triggered the request through the policy decision through the use of the token at the resource.

Armalo's resource implementations verify capabilities locally without consulting the issuer on every call. The verification uses the standard JWT pattern with the issuer's public key cached locally. Revocation is checked against a published list with a short TTL. The verification adds about fifty microseconds to each call, which is invisible against the LLM inference time that drives the call decision.

Multi-agent patterns are first-class on Armalo. A coordinator agent that dispatches work to sub-agents delegates narrower capabilities to each sub-agent. The delegation chain is recorded in each token. The audit trail shows the coordinator's authority being exercised through the sub-agents. Pact compliance for the coordinator includes the sub-agents' behavior under the delegated capabilities.

FAQ

How does capability-based authorization handle role-based UI patterns where a user expects to see what they have permission to do? The session capability the user holds at login describes the set of operations the user can perform. The UI queries the capability to render the available actions. The query is local to the session token; no round-trip to the issuer is needed. The pattern is the capability analog of asking the ACL what permissions the user holds.

Can capability tokens be cached on the agent side to reduce minting latency? Caching is permissible for capabilities that are inherently reusable, like a session capability with a multi-minute lifetime. For capabilities scoped to a single call, caching defeats the purpose of just-in-time minting. The right cache strategy depends on the capability type and the security model of the operations involved.

What happens if the issuer is unavailable when the agent needs a capability? The agent's call cannot proceed. The pattern is fail-closed: no capability, no operation. For high-availability requirements, the issuer must be deployed with replication and graceful degradation. Some teams accept a small fallback to long-lived capabilities for read-only operations during issuer outages, but the fallback expands the blast radius and should be used carefully.

How do capabilities interact with rate limiting? Rate limits become part of the issuer's policy. The issuer denies capability requests that would exceed the rate limit for the agent. The rate-limit check is part of the authorization decision, not a separate gate. The pattern unifies rate limiting and authorization, which simplifies the operational model and the audit trail.

Do capabilities work for streaming operations like long-lived database connections? With careful scope design. A capability for a streaming connection has a time bound matching the maximum connection duration and a use bound that captures the streaming semantics. The connection itself remains authenticated by the capability for its duration. When the bound expires, the connection closes and a new capability is needed.

How do you handle capabilities for operations that span multiple resources? Through composite capabilities or through delegation. A composite capability authorizes a sequence of operations across multiple resources, scoped to a specific transaction. The pattern is more complex than single-resource capabilities and should be used only when the multi-resource semantics is essential. Most operations decompose into single-resource capabilities chained at the agent layer.

Does the model require all downstream services to verify capabilities natively? No. Services that cannot verify capabilities natively are accessed through a proxy that holds a long-lived credential and verifies the capability before forwarding the call. The proxy pattern is common for legacy services, on-premises systems, and third-party APIs. The agent never holds the long-lived credential.

Bottom Line

The ACL model survived because human-paced systems did not stress its assumptions. Subjects were stable. Endpoints were enumerable. Decisions were stateless. Delegation was rare. Policies were stable. Each assumption is reasonable for the human-driven web of the past two decades. None of them is true for autonomous agents.

The capability model is structurally different. It moves the authorization decision from the resource to the issuer, splits the decision into minting and verification, expresses scope precisely, supports delegation natively, and produces an audit chain that runs from authorization to use. The model scales because the resource only verifies and the issuer only mints; the two scale independently. The model handles agent-era stress because each capability is minted for a specific call rather than granted as standing access.

The migration from ACL to capabilities is incremental. Operations move one at a time. The two systems coexist during the migration. The end state is a uniform authorization model that handles humans and agents through the same primitive. The teams that have completed the migration report that the operational burden drops, the audit story sharpens, and the security review becomes shorter. The right time to start is now, with the second autonomous agent, while the ACL is still simple enough to extract from cleanly.