AI accountability is an authority chain, not an owner field.

An accountable owner cannot explain an AI action the architecture cannot trace. That becomes a serious problem when AI moves from generating content to changing enterprise state. Consider a customer-service agent that receives a refund request. It reads the account, checks policy, calculates an amount and calls the payment system.

The AI registry may clearly identify the business owner. That tells us who is accountable for the system.

It does not tell us why this specific agent was permitted to issue this specific refund for this specific customer. To answer that, the organization needs to trace something different:

At each step, the architecture needs to preserve identity, delegated authority, permissions, enforcement and evidence.

From ownership to authority

Organizations already know how to assign ownership. Applications have owners. Processes have owners. Data has stewards. Risks have accountable executives. Those concepts still matter.

But ownership and authority are not the same thing. An owner may be accountable for an AI system while the system itself operates through multiple agents, services, APIs and enterprise platforms. The action may be several technical steps removed from the person ultimately accountable for it.

That creates a different governance problem. The organization needs to preserve the relationship between who granted authority and what action was ultimately performed.

The model is no longer the most important unit of governance once the system can act.

Authority becomes one of the things architecture has to govern.

Six architecture decisions

1. Preserve the identity of every actor

The first requirement is traceability. When an employee asks an agent to perform a task, the resulting activity should not simply appear as though the employee performed every downstream action manually. The architecture should preserve both the initiating principal and the executing actor.

This becomes more important when agents call other agents. The relevant execution path may include:

• initiating user
• orchestrator
• specialist agent
• service identity
• tool
• target application

They do not necessarily need separate human-style accounts in every platform. But they do need to remain distinguishable in the execution record.

Those are not equivalent accountability stories.

2. Authorize actions, not just systems

Traditional enterprise permissions are often broad. Can this user access the CRM? Can this service connect to the finance platform? Can this agent use the HR API?

For agentic systems, that level of authorization is often too coarse. A single enterprise platform may allow an agent to:

• read a customer record
• change contact information
• update a case
• issue a refund
• cancel a service
• export information
• trigger another workflow

Those actions do not carry the same consequence. The more useful architecture question is: What action may this agent perform, under which authority and under which conditions?

An agent may be permitted to read a customer account and calculate a refund recommendation. It may be allowed to issue refunds below a defined threshold. A larger amount may require another authorization step. Exporting customer information may be prohibited entirely. The permission model should reflect business consequences, not simply technical connectivity.

3. Bound delegated authority

Agentic systems will increasingly delegate work. A coordinating agent may ask another agent to retrieve information, interpret a document or execute a specialized task. Delegation itself is not the problem. Implicit privilege expansion is. Suppose Agent A may read customer information but cannot modify records. It delegates work to Agent B. If Agent B has broader standing permissions, the system should not automatically allow Agent A to achieve indirectly what it was prohibited from doing directly.

If the user delegated read access, the agent is technically capable of writing, and policy permits writing only with additional approval, the result should still be read-only authority. The architecture should enforce the intersection, not the broadest permission available anywhere in the chain.

4. Escalate at the point of consequence

In Issue 03 of The Governed Stack, I argued that human oversight should be designed as a control loop rather than treated as a generic approval requirement. Agentic systems add another architectural question: Where in the authority chain should that control activate? Requiring a person to approve every agent step removes much of the value of automation. Allowing every action automatically creates the opposite problem.

The useful boundary is usually the consequence. An agent may autonomously retrieve information, compare options, prepare a recommendation, validate required fields and populate a draft. But the next action may change an enterprise record, commit money, communicate externally or create another material consequence. At that point, the authority requirement may change.

The approval is not there because AI was involved. It is there because the authority required for the next action exceeds what was delegated to the system. That distinction produces controls that can survive changes in models, vendors and agent platforms.

5. Preserve decision evidence, not only logs

Most enterprise platforms already generate technical logs. That does not mean they can explain an AI-mediated action. A log may tell you an API was called, a token was issued, a model responded or a record changed. Useful.

But accountability requires more context. For a consequential action, the organization may need to reconstruct:

• who initiated the task
• which agent executed it
• what authority was delegated
• what tool was invoked
• which policy decision applied
• what relevant context was used
• whether additional approval occurred
• what action was taken
• what outcome followed

The objective is not unlimited logging. It is decision reconstruction.

Those records should be linked through a common correlation or trace context. That gives operations one execution path and governance one evidence chain.

Observability tells us what happened. Governance evidence helps explain why it was allowed to happen.

6. Treat changes in authority as governance events

AI systems can change materially without changing models. Give an agent another tool. Allow it to write where it could previously only read. Increase its financial threshold. Connect another data source. Remove a human approval. Allow it to invoke another agent.

None of these changes necessarily looks dramatic in a conventional release process. From an accountability perspective, they may fundamentally change the system. The governance process should therefore define authority-change triggers.

• new application or tool access
• read permission becoming write permission
• higher transaction limits
• access to new categories of data
• removal of a human authorization point
• additional downstream agents
• longer autonomous execution windows
• permission to communicate externally
• permission to initiate irreversible actions

Those changes should trigger reassessment when they materially alter what the system is permitted to do. The model may be unchanged. The authority boundary is not.

What this looks like in architecture

The authority chain should not exist only in a governance diagram. It needs to survive execution.

These capabilities may already exist across identity systems, API gateways, orchestration platforms, policy engines, enterprise applications and observability tooling. The architectural requirement is more important than the product choice: the governance decision has to reach the execution path.

A practical example: issuing a refund

Return to the refund agent.

The agent can investigate the case, calculate the amount and prepare the transaction. But its effective authority does not permit execution. The workflow escalates. A supervisor authorizes the $180 refund. The payment tool receives the stronger authorization and executes the action.

The accountability-chain worksheet

Use one row for every consequential action an AI system can perform.

This does not need to become another large governance document. For many systems, mapping one consequential action end to end will expose more than another ten pages of policy.

Governance is moving into the execution path

The first generation of AI governance focused heavily on documents. Policies. Principles. Inventories. Assessments. Those remain necessary.

Systems that can act create an additional requirement. Governance increasingly has to reach the point where the action occurs. Identity has to connect to authority. Authority has to connect to permissions. Permissions have to remain bounded through delegation. Consequential actions need the right level of authorization. And the execution path needs to produce evidence.

That does not mean governance teams need to become runtime engineers. It means governance and architecture need shared objects they can reason about.

For agentic systems, the authority chain is one of them. Because once software can act on behalf of the organization, knowing who owns the system is only the beginning.

Accountability has to follow the action.

If a consequential action cannot be traced from authority to evidence, the AI Decision Review can expose that gap before production.

Scope

This article provides practical architecture and governance guidance. Appropriate identity, authorization, evidence and oversight controls depend on the action, its consequences and the organization's obligations.