Your AI Agent Is an Unlisted Signer

The missing entry in the authority framework

Finance organizations usually have established rules for who may approve a journal entry, create or modify a supplier, authorize expenditure, or release a payment. Those rules may be documented through a delegation-of-authority matrix, bank mandates, ERP roles, approval workflows, and segregation-of-duties controls.

An AI agent introduces a new operating actor. It may act continuously, process transactions at scale, and invoke systems through connectors or service accounts. If the agent uses a manager’s broad permissions, the system may record the manager’s identity even when the agent performed the action.

The important question becomes: Can finance distinguish the authority given to a person from the authority exercised by an automated agent acting on that person’s behalf?

CoE | AI Cost & Governance recommends recording agents with consequential write or transaction capabilities in an AI Agent Authority & Control Register, linked to the organization’s established authority and access-control structures. In some organizations the register can be an extension of the delegation-of-authority matrix; in others a separate register with cross-references will be easier to maintain.

This is a recommended governance design, not a universal legal requirement that agents be named as signatories.

Instruction, authorization and evidence are different controls

Return to the fictional AP agent. The intended operating model is reasonable: the agent checks invoices against purchase orders, flags discrepancies, and prepares approved invoices for payment. A human treasury approver releases payments above a specified threshold.

But the actual configuration gives the agent write access to the vendor master, payment instructions, and the payment-submission interface. It authenticates through a service account with permissions broader than those required for invoice matching.

Even if the instruction says do not alter bank details, the system has not technically prevented the agent from doing so.

Consider the difference between three layers of control:

A prompt is useful guidance. A downstream permission check is a stronger preventive control. Independently retained transaction records make it possible to determine what happened. Compare the approved purpose with effective access: an unexplained difference is a control gap even when the agent has followed its instructions so far.

Authority has legal consequences, with limits

US federal electronic-signature law addresses electronic agents directly. Under 15 U.S.C. §7001(h), a contract or other record relating to a transaction in or affecting interstate or foreign commerce may not be denied legal effect, validity, or enforceability solely because its formation, creation, or delivery involved the action of one or more electronic agents, so long as the action of any such electronic agent is legally attributable to the person to be bound. The Act defines an electronic agent as a computer program or other automated means used independently to initiate an action or respond to electronic records or performances, in whole or in part, without review or action by an individual at the time. That qualification matters. The statute does not mean every action by every AI agent automatically binds its organization. Questions of attribution, actual authority, contract terms, and applicable law remain relevant. [2]

A different example comes from Moffatt v. Air Canada, a 2024 small-claims decision of the British Columbia Civil Resolution Tribunal. The tribunal found Air Canada liable for negligent misrepresentation over inaccurate bereavement-fare information delivered through its website chatbot, and rejected the airline’s suggestion that the chatbot was a separate legal entity responsible for its own actions. That was a consumer misrepresentation dispute, not an autonomous payment or business-to-business agency case. [3]

Together, these sources make organizational accountability a serious consideration. Neither decides how liability would be allocated if a finance agent initiated a transaction outside its configured limits. The article’s control recommendations should therefore be treated as operational risk management, not legal conclusions about every future dispute. The narrower recommendation is this: treat consequential AI actions as delegated organizational authority, document that authority, enforce it in the systems of execution, and retain records that make the activity independently examinable.

What to put in the register

For each agent that can change financial records, initiate an economically consequential transaction, modify master data, or accept commercial terms, record:

1. Identity and purpose. Agent name, platform, version or configuration, business use case, and environment.
2. Accountable owner. The business owner responsible for approving its purpose, permissions, and continued operation.
3. Permitted actions. Specific transactions, systems, entities, accounts, counterparties, and amount or volume thresholds.
4. Technical enforcement. Where permissions and thresholds are actually checked: ERP, bank portal, API gateway, identity system, or other downstream control.
5. Required approvals. Which actions need human approval before execution and how the approval is verified.
6. Independent records. Where authoritative activity, configuration-change, approval, and transaction logs are retained.
7. Change and suspension controls. Who can alter the agent’s access, how changes are approved, and how access can be revoked promptly.

Register aggregate limits, not only per-item amounts.

Several of these fields correspond to controls in existing finance-control guidance. In its fraud-risk discussion, the COSO-commissioned 2026 publication on generative AI says AI agents can introduce authorization risks, excessive agency and insecure interfaces. Its illustrative controls for automated transaction processing include defining posting authority by role, separating configuration permissions from review responsibilities, and keeping full audit trails for unattended postings. [4]

Why human approval is not enough

A human approval step can be necessary for higher-risk actions, but it cannot compensate for unrestricted access.

An approver may become overloaded with repetitive requests, overlook a changed bank account, or approve an action without inspecting its underlying evidence. NIST’s Generative AI Profile names automation bias among the risks of human-AI configurations and describes it as excessive deference to automated systems. [5]

OWASP’s guidance on Excessive Agency identifies three typical root causes: excessive functionality, excessive permissions, and excessive autonomy. Its recommendations include minimizing permissions, requiring approval for high-impact actions, and enforcing authorization in downstream systems instead of relying on the language model to decide which actions are allowed. [6]

The appropriate design is layered:

• Before action: restrict the agent to the minimum necessary capabilities and enforce approval or transaction limits.
• During action: apply relevant approval gates, transaction checks, monitoring, and exception handling.
• After action: preserve authoritative records so activity can be reconciled, reviewed, and investigated.

The control goal is not to eliminate human judgment. It is to ensure that an agent cannot bypass a boundary merely because a reviewer failed to notice a request.

Should an agent use its own identity or a user’s permissions?

There is no single identity pattern appropriate to every deployment. An agent may operate within an authenticated user’s context with narrowly delegated scopes, or it may use a distinct service or workload identity for defined automation. The correct design depends on the workflow, systems, and identity capabilities.

What matters is that the permission granted is no broader than necessary, and the records allow investigators to distinguish who authorized the action, which agent executed it, and what the target system actually did.

Shared human credentials that confer unrestricted access and obscure the agent’s activity are particularly difficult to defend as a control design. Agent-specific credentials may improve traceability, but a distinct username alone is not sufficient if its permissions are excessive or its actions are not logged.

Payment networks have also announced agent-identity and transaction-control mechanisms. Mastercard described registration and verification of trusted agents in its April 2025 Agent Pay announcement. [7] Visa has described tokenization, spending controls, and pilot activity in agentic commerce, including a business bill-payment pilot. [8] These are provider descriptions of capabilities and pilots, not independent evidence that such programs reduce fraud or errors. In the UK, HM Treasury’s July 2026 consultation on modernising payment services regulation asked whether the rules on authentication, consent and liability for unauthorized payments need updating for agentic payments; it closed on October 6, 2026, and the outcome is pending. [9]

What finance leaders should do next

Start with the systems in which an unintended action would have material consequences: the general ledger, accounts payable, bank and payment platforms, vendor master, payroll, and contract execution.

First, inventory the agents with write or execution access. Include embedded AI features and orchestrated workflows, not only systems labeled “AI agents.” Identify what each can actually do through its credentials and integrations.

Second, compare intended and effective authority. For each agent, document the transactions it should perform, the permissions it actually has, and where limits are technically enforced. Treat unexplained differences as control gaps requiring remediation.

Third, test the boundaries. In a safe non-production environment, confirm that the agent cannot exceed its transaction limits, modify restricted fields, circumvent required approvals, or act after access has been revoked. Preserve test evidence. Include repeated requests that each stay under the per-item limit, and a misleading instruction placed in a harmless test invoice: the permission, not the assistant, has to block the action. When access is revoked, confirm that queued and scheduled work stops as well as new requests, and establish what had already completed before access is restored; closing the chat does not stop a scheduled job.

Fourth, verify the audit trail. Confirm that independently retained records identify the initiating agent or execution identity, the authorizing person, the affected records, approvals, and the final system result. Do not rely only on the agent’s own narration.

Finally, assign ongoing ownership. Changes to models, connectors, system roles, or workflows can change what an agent is able to do. Incorporate these changes into access review and change-management routines.

Make delegated authority visible

An agent does not need a signature line to create a financial consequence. It needs access to a system that can move money, change a record, or commit the organization.

The central governance question is whether finance has made that authority explicit and verifiable. Instructions describe what an agent should do. Permissions determine what it can do. Independent records establish what it did.

That distinction should become part of how finance controls AI-enabled operations.