A finance team asks an AI agent to pull job costs, reconcile a vendor statement, and draft a cash forecast. It does the work in minutes. The next request sounds just as routine: “Clean up the open items and take care of anything overdue.”
That is where automation becomes an authority problem. Reading an invoice, drafting a proposed payment, adding a bank beneficiary, and releasing funds are not degrees of the same permission. They are different responsibilities, with different consequences, approvals, and evidence requirements.
The critical question is no longer whether an agent can complete a task. It is whether the business can prove the agent was authorized to complete that particular task, under those conditions, at that moment.
What changed in October
Several October 2026 developments point in the same direction. On October 27, NIST published ten proposed design tenets for agent identity management, including distinct agent identities, short-lived authorization, narrower downstream delegation, separation of policy from AI reasoning, and independent evidence. These are proposed design principles, not regulations or a completed industry standard.
The day before, IBM announced general availability of its Agent Identity offering, describing enterprise controls for agent ownership, delegation, runtime policy, and credential management. On October 22, 1Password announced an approval-mediated approach intended to help supported agents sign in without receiving the underlying stored password. Both are vendor announcements whose practical reach and performance require evaluation.
The commercial stakes are becoming clearer in payments as well. Proof announced its x401 identity and signed-authorization protocol on October 15. The OpenID Foundation's October 8 response to EMVCo's draft agentic-payments framework emphasized verifiable intent, delegation lineage, and the need to distinguish an agent from the principal it represents. Neither announcement establishes a universally adopted payment authorization regime.
The common signal is important: access, identity, custody of credentials, and authority to bind a person or business are separate problems.
In finance, having the credentials has never meant having unlimited authority. AI should not quietly reverse that principle.
The control problem is familiar to any CFO
A healthy finance function separates preparation from approval, approval from release, and release from reconciliation. It does not let a persuasive narrative override a bank signer's authority limit. It does not make the person who creates a vendor the sole approver of payments to that vendor. Those boundaries exist because money and obligations can move faster than mistakes can be recovered.
Consider a contractor with an agent connected to its project management system, general ledger, email, and banking portal. The agent may be able to identify a disputed subcontractor invoice and prepare an explanation for the controller. That does not mean it should be able to change the payee, approve its own resolution, and send funds.
An appropriate operating mandate could let the agent retrieve approved documents, match cost codes, flag exceptions, draft responses, and recommend which invoices are ready for review. A separate human or deterministic authorization service should approve consequential changes. Payment release should remain bounded by authorized signers, amount limits, segregation of duties, and confirmation of the recipient.
That is the practical meaning of delegated authority: the principal defines the outcome and grants only the capability needed to reach it. The agent does not create new authority for itself because it believes a step would be useful.
Six questions an executive should ask before deploying an agent
- Who owns the agent? Give it a distinct identity and a named business owner. Do not hide agent activity inside a shared human login.
- What is its mandate? Define purpose, allowed systems and actions, dollar thresholds, recipient restrictions, duration, and forbidden operations.
- Who controls the credentials? Prefer task-scoped access and credential brokers over broadly reusable secrets or raw bank passwords exposed to the model.
- What requires approval? Separate drafts and recommendations from commitments, changes to beneficiaries, publishing, contracting, and movement of money.
- Can it be stopped? Revocation must reach downstream tools and agents. An expired instruction is not enough if a usable token or queued transaction remains active.
- What evidence survives? Keep the originating instruction, authorizations, tool actions, exceptions, final decision, and transaction outcome in records the agent cannot freely rewrite.
None of those questions requires an executive to understand every model parameter. All require the executive to know where operational authority begins and ends.
A signed approval is not the same as a settled transaction
In a payment workflow, a cryptographic approval may establish that someone consented to specific terms: the merchant, amount, currency, account, or recipient. That is useful evidence. It does not prove funds settled, eliminate fraud, correct an erroneous vendor record, or resolve a dispute.
Finance needs separate states for a transaction that was proposed, authorized, submitted, settled, and reconciled. It also needs to distinguish stopping future agent actions from unwinding something already completed. Those distinctions belong in the ledger, approvals, bank controls, and incident procedures, not in an AI-generated summary after the fact.
Where does the authority go when the agent or vendor disappears?
There is a longer-term governance risk beneath today's product announcements. What happens when an agent provider fails, a senior employee leaves, an account changes ownership, or a business is acquired? Who can identify and terminate all outstanding delegations? Who keeps the signed approvals and execution record when the original software is gone?
That is the continuity question explored by MoonVault, a concept-stage Curate Holdings venture researching identity, bounded authority, credential custody, revocation, and recovery. It is not a live identity, banking, or authorization service. Related hands-on technical work is examined through the independent BlackBoxx.ai Systems Lab.
To my mind, the opportunity is not a future in which every decision requires a person to click “Approve.” The opportunity is letting capable software do more useful work while keeping important boundaries outside the model. Routine work should move; exceptions should surface; consequential commitments should remain attributable to the right authority.
When a CFO says an agent is working for the company, the next question should be precise: Under whose authority, within which limits, with what record, and with what ability to stop?
Primary sources
- NIST, Design Tenets for Agent Identity Management Systems, October 27, 2026 (proposed nonbinding design principles).
- IBM, Agent Identity general availability, October 26, 2026 (vendor announcement).
- 1Password for Agents, October 22, 2026 (vendor announcement, integration availability varies).
- Proof, x401 launch, October 15, 2026 (vendor-described transaction authorization).
- OpenID Foundation response to EMVCo agentic-payments draft, October 8, 2026 (standards consultation, not a final framework).
This article is independent founder-operator and financial-governance analysis, not legal or financial advice. Vendor descriptions are not independent attestations of security, adoption, or regulatory compliance.