The question every governance framework must answer
When a human employee modifies a billing system, the chain of authority is traceable. The employee has an identity. Their access was granted through a role assignment approved by a manager. The change was (in well-governed organisations) documented in a change request. If the modification causes a problem, the organisation can answer a simple question: who authorised this?
When an AI agent modifies that same billing system, the question becomes harder. The agent has an identity of sorts, typically a service account. The service account was provisioned by an engineer, perhaps months ago, with permissions that seemed reasonable at the time. The specific modification was not individually authorised by any human. The agent decided to make it, based on its programming, its inputs, and whatever reasoning process its underlying model applied.
Who authorised this?
The engineer who provisioned the service account? They authorised the agent's existence and its general capabilities. This specific action was never on that list. The team lead who approved the agent's deployment? They approved the agent for a category of work. This particular modification was never reviewed. The human who triggered the workflow that led to the agent acting? They initiated a process, possibly without knowing that this specific modification would be a consequence.
The honest answer, in most agent deployments, is that no one specifically authorised this action. The permissions allowed it. The workflow triggered it. The agent performed it. The authority is ambient, distributed across provisioning decisions, deployment approvals, and permission configurations that no single person can fully reconstruct.
This is the accountability gap.
What does "authority" mean in an agent context?
Authority, in the context of agent governance, is the explicit, verifiable delegation of permission to perform a specific category of actions, granted by an identifiable human or system, with defined scope and duration.
Each word in that definition does work. "Explicit" means the delegation is recorded, not inferred from permission configurations. "Verifiable" means a third party can confirm the delegation chain without relying on the organisation's self-reporting. "Specific category" means the authority is scoped, not blanket. "Identifiable human or system" means the root of the delegation chain terminates at an accountable entity. "Defined scope and duration" means the authority has boundaries in both capability and time.
By this definition, most agent deployments operate without authority. They operate with permissions, which is a different thing. Permissions describe what the system allows. Authority describes what a human decided to allow, for this purpose, for this duration, with these constraints. Permissions are a property of the infrastructure. Authority is a property of the governance model.
Why ambient permissions are insufficient
The standard model for agent permissions follows the same pattern as application service accounts. An agent is assigned a role. The role includes permissions for the resources the agent needs to access. The permissions persist until someone modifies the role or decommissions the account.
This model has a specific failure mode: permission drift. Over time, the agent's actual behaviour diverges from the original intent of its permission assignment. The agent was given write access to the billing system for a specific integration. Six months later, the agent's logic has evolved through several iterations, and it is now using that write access for purposes that the original provisioner did not anticipate and might not have approved.
No one violated any policy. The permissions were correctly assigned. The agent operated within its technical permissions at all times. The governance failure is that the agent's authority, in the meaningful sense of what a human decided to allow, was never updated to reflect the agent's evolving behaviour. The permissions persisted. The authority, such as it was, became stale.
This is why the rule book abstraction exists in Covia's model. Permissions define the technical ceiling. The rule book defines the governance constraints within that ceiling. And the delegation chain, expressed through verifiable tokens, connects every action back to a human decision with defined scope.
How delegation chains close the gap
A delegation chain is a verifiable sequence of authority grants connecting an agent's action to a human decision. The human grants authority to an agent for a specific purpose, with specific constraints. The agent may delegate a subset of that authority to a sub-agent. The sub-agent may delegate further. At each step, the scope can only narrow, never widen.
When the billing system is modified, the delegation chain provides a complete answer to "on whose authority?" The chain shows: this human (identified by their DID) granted this agent permission to modify billing records for this account, for this time period, under these constraints. The agent delegated a subset of that authority to a sub-agent to execute the specific modification. The sub-agent acted within the delegated scope.
Every link in the chain is cryptographically signed. Every scope reduction is verifiable. The complete chain can be audited at any time, by any party, without relying on the organisation's own records. The authority is not ambient. It is not inferred from permission configurations. It is explicit, scoped, and traceable.
This changes the accountability model fundamentally. The question "who authorised this?" has a concrete answer. The human at the root of the delegation chain authorised it, within the scope they defined. If the action was within scope, the authority chain is valid. If the action exceeded scope, the chain shows exactly where the violation occurred: which agent delegated authority it did not hold, or which agent acted beyond its delegated scope.
What enterprise organisations need to evaluate
The accountability question is not abstract. It manifests in specific scenarios that enterprise governance teams should be evaluating now, before they arise in production.
When an agent modifies customer data incorrectly, can the organisation identify which human authorised the agent to modify that category of data? When an agent makes an API call that incurs unexpected costs, can the organisation trace the authority for that API access back to a budget-holding decision-maker? When an agent's action triggers a data protection inquiry, can the organisation demonstrate to the regulator that the agent operated under explicit, scoped authority from an accountable individual?
If the answer to any of these questions is "we would need to investigate," the organisation has an accountability gap. Investigation reconstructs. Governance proves. The difference between the two determines whether the organisation can respond to an incident with evidence or with a narrative.
The accountability question that remains
Scoped authority, delegation chains, and the rule book provide the mechanisms to close the accountability gap. They make it possible to answer "on whose authority?" with a verifiable chain rather than an inference from permission configurations.
The mechanisms do not answer a harder question: what should the scope of delegation be? How much authority should a human grant to an agent? How narrow is too narrow (rendering the agent ineffective) and how broad is too broad (creating unacceptable risk)?
This is a governance design question. It requires organisations to articulate, in precise terms, what categories of actions they are willing to delegate to agents, under what constraints, with what oversight mechanisms. The tooling can enforce whatever boundaries the organisation defines. The tooling cannot define the boundaries.
Every organisation deploying agents into production is making these decisions, whether explicitly through governance design or implicitly through permission provisioning. The organisations making them implicitly will discover what they decided only when an agent acts in a way they did not expect. The authority was never defined, so it was never exceeded, so the system worked exactly as designed. The outcome was simply one that no one intended.