The permissions problem no one designed for
Every AI agent acting in a production environment needs permissions. It needs access to tools, APIs, databases, and external services. The standard approach is familiar: assign the agent a service account, attach a role with the necessary permissions, and manage those permissions through the same identity and access management (IAM) infrastructure used for human users and application services.
This works until it does not. The failure mode is specific: IAM was designed for relatively static permission assignments. A human user gets a role when they join a team and keeps it until they leave. A service account gets permissions when it is provisioned and keeps them until it is decommissioned. The permissions are coarse-grained by necessity, because managing fine-grained permissions for every possible action is administratively untenable at scale.
AI agents break this model in three ways. First, agents act dynamically. An agent coordinating a multi-step workflow may need different permissions at each step, and the specific permissions needed may depend on decisions made during earlier steps. Second, agents delegate. An agent may invoke sub-agents, each of which needs its own scoped permissions derived from the parent agent's authority. Third, agents operate at machine speed. The time between granting a permission and exercising it may be milliseconds, making manual approval workflows impractical.
The result is that most agent deployments either over-provision permissions (granting broad access to avoid runtime failures) or under-provision them (restricting access so tightly that the agent cannot complete legitimate tasks). Neither outcome is acceptable in a production environment where the agent is modifying real systems on behalf of real users.
What are UCAN tokens?
A UCAN (User Controlled Authorisation Network) token is a self-certifying, delegatable authorisation token based on signed JSON Web Tokens (JWTs). Unlike traditional access tokens issued by a central authority, UCANs are created and signed by the entity that holds the authority, enabling decentralised delegation without requiring a round-trip to an authorisation server.
The issuer is the entity granting the authority. This is identified by a decentralised identifier (DID) and authenticated by a cryptographic signature. The audience is the entity receiving the authority. The capabilities define what the recipient is authorised to do, expressed as resource-action pairs with optional caveats that further constrain the scope. The expiry sets a time boundary on the authority. The proof chain links the token to its parent authorisation, creating a verifiable delegation chain back to the root authority.
What makes UCANs particularly relevant for agent systems is the delegation model. A human user can create a UCAN that grants an agent permission to perform specific actions on specific resources for a specific duration. That agent can then create a child UCAN that delegates a subset of its authority to a sub-agent. At no point can any entity in the chain grant more authority than it holds. The permissions can only narrow as they flow through the delegation chain, never widen.
This is a structural guarantee enforced by cryptography. The cryptographic signatures and the proof chain make it mathematically verifiable that no entity exceeded its authority. An auditor can inspect any UCAN token and trace the complete chain of delegation back to the human who initiated it.
How does scoped authority differ from access control?
Access control answers the question "is this identity allowed to access this resource?" Scoped authority answers a different and more specific question: "is this identity allowed to perform this action on this resource, under this delegation, with these constraints, until this time?"
The distinction matters because access control is binary (allowed or denied) while scoped authority is dimensional. A UCAN token does not simply grant access to a billing API. It might grant permission to read invoices from a specific account, created within a specific date range, for the purpose of generating a quarterly summary, with the authority expiring in fifteen minutes. Every dimension of the scope is encoded in the token itself, verifiable without consulting an external authority.
Traditional access control systems can approximate this level of granularity through attribute-based access control (ABAC) policies, but the policy evaluation happens at a central policy decision point. The agent presents its credentials, the policy engine evaluates the rules, and the decision is made at runtime. If the policy engine is unavailable, the decision cannot be made. If the policy is misconfigured, the agent gets the wrong permissions.
The authority lives in the policy engine. With UCANs, the authority lives in the token. The token is self-certifying: any party can verify its validity, its scope, and its delegation chain without contacting a central authority. This is what makes it practical for distributed agent systems where agents may be executing across organisational boundaries, on different infrastructure, through different tool providers.
Delegation chains: from human to agent to sub-agent
Consider a concrete scenario. A financial controller authorises an AI agent to reconcile accounts payable for Q1 2026. The agent needs to read invoice data from the ERP system, cross-reference it with payment records from the banking API, identify discrepancies, and generate a reconciliation report. To handle the volume, the agent delegates the invoice retrieval to a specialised sub-agent and the payment record retrieval to another.
In a traditional IAM model, each of these agents needs its own service account with its own role assignments. The financial controller's authorisation is implicit: someone approved the role assignments at provisioning time, perhaps weeks or months ago, with no direct connection to this specific task.
With UCAN delegation, the chain is explicit and verifiable. The financial controller creates a root UCAN granting the reconciliation agent permission to read accounts payable data for Q1 2026 and to generate reconciliation reports. The reconciliation agent creates a child UCAN for the invoice sub-agent, scoping it to read-only access on invoice data for Q1 2026, with no write permissions and no access to payment records. It creates another child UCAN for the payment sub-agent, scoped to read-only access on payment records for Q1 2026.
Each token in this chain is cryptographically signed by its issuer. Each token's capabilities are provably a subset of its parent's capabilities. The complete chain is auditable: from the financial controller's root authorisation, through the reconciliation agent's delegation decisions, to the specific permissions each sub-agent held when it accessed the underlying systems.
The delegation is a scoped, time-boxed UCAN the venue verifies on every call:
from covia import Grid, UCANAttenuation
venue = Grid.connect("https://venue.covia.ai")
# A controller issues a scoped, time-boxed UCAN to an agent: read-only access
# to one namespace. Authority can only narrow as it is re-delegated.
token = venue.ucan.issue(
"did:key:zReconciliationAgent",
[UCANAttenuation(with_="did:key:zController/w/invoices/2026-Q1", can="crud/read")],
expiry=2_000_000_000,
).token
# The agent presents the token; the venue checks scope before it acts.
result = venue.run(
"v/ops/covia/read",
{"path": "did:key:zController/w/invoices/2026-Q1"},
ucans=[token],
)Revocation semantics: withdrawing trust at runtime
Revocation in hierarchical systems is straightforward in principle and difficult in practice. The principle is clear: when trust is withdrawn from any point in the delegation chain, all authority derived from that point must cease to be valid. The difficulty lies in propagation. How quickly does the revocation take effect? What happens to actions that were authorised before the revocation but have not yet completed?
UCAN revocation operates through a combination of expiry and explicit revocation lists. Short-lived tokens (with expiries measured in minutes rather than hours or days) limit the window of exposure. When a token expires, it simply stops being valid. No propagation delay, no race condition, no stale permissions.
For cases where immediate revocation is necessary, Covia maintains a revocation registry within the Grid's lattice data structure. When a UCAN is revoked, the revocation is recorded in the lattice and propagated to all venues participating in the execution. Any venue that receives an action authorised by a revoked UCAN will reject it, even if the token has not yet expired.
How scoped authority connects to the rule book
The rule book is Covia's abstraction for encoding governance policies as executable rules that are evaluated at runtime. Scoped authority through UCAN tokens and rule book enforcement are complementary mechanisms that operate at different layers of the same problem.
UCAN tokens define what an agent is authorised to do. The rule book defines the conditions under which that authority may be exercised. An agent might hold a UCAN granting it permission to modify customer records, but the rule book might specify that customer record modifications require a human approval step when the modification affects billing data, or that modifications are only permitted during business hours, or that no more than fifty records may be modified in a single execution.
The UCAN provides the capability ceiling. The rule book provides the runtime constraints within that ceiling. Together, they create a governance model where authority is delegated with precision and exercised under supervision, without requiring a human in the loop for every action.
What does this mean for enterprise agent deployments?
Enterprise organisations evaluating agent platforms should ask a specific set of questions about authority and permissions. Can you trace the authority for any agent action back to a human decision? Can you verify that no agent exceeded its delegated scope? Can you revoke authority at any point in the delegation chain and have the revocation take effect within a bounded time? Can you prove all of this to an auditor without reconstructing it from logs?
These questions expose the gap between traditional IAM (which was designed for a world of static role assignments and human-speed operations) and the requirements of production agent systems (which operate at machine speed, delegate dynamically, and act across organisational boundaries).
UCAN tokens are one answer. They are one of several approaches to scoped authority for agents. Their structural advantage is that the authority is self-certifying and verifiable without a central authority, which makes them practical for distributed systems where the agents, the tools, and the governance infrastructure may all be operated by different organisations.
The deeper question is whether organisations will adopt scoped authority models before or after an agent exceeds its intended permissions and modifies something it should not have. The technical mechanisms exist. The compliance requirements are arriving. The agents are already acting. The question of whether their authority is properly scoped is one that each organisation will answer on its own timeline, and will be held accountable for on someone else's.