The Autonomous Treasury Index 2027: Can AI Agents Safely Manage Company Money?

The Signal: Treasury Is Becoming Programmable

Corporate treasury used to be dominated by bank accounts, approval chains, spreadsheets and enterprise software.

That model is changing.

Stablecoins create programmable bearer-like digital money that can move continuously across networks.

Wallet infrastructure can now enforce transaction policies, destination restrictions and spending limits programmatically.

Agent systems can monitor balances, evaluate invoices, compare routes, initiate payments and interact with APIs without waiting for a human to click through every step.

Privy now explicitly markets wallet infrastructure for autonomous and delegated agents, including programmable policies, approvals and spending limits.

Coinbase Developer Platform similarly documents policy controls that can restrict destinations and transaction values.

Safe smart accounts support thresholds, modules and transaction guards capable of adding pre-transaction and post-transaction logic around execution.

The building blocks for machine-controlled treasury therefore already exist.

Moving Money Is the Easy Part

Sending a transaction is not treasury management.

Treasury involves balancing several objectives at once:

• liquidity;
• capital preservation;
• counterparty risk;
• yield;
• operational continuity;
• payment obligations;
• currency exposure;
• fraud prevention;
• compliance;
• accounting and reconciliation.

An autonomous system must therefore do more than identify an attractive transaction.

It needs to understand whether that transaction is authorized, liquid, affordable, compliant and consistent with treasury policy.

The DN Autonomous Treasury Index 2027

DN-ATI scores treasury-agent infrastructure across eight dimensions.

Calculate Treasury Agent Readiness

DN Treasury Autonomy Tiers

The Most Important Distinction: Prompt Policy vs Enforced Policy

A prompt can tell an agent:

That is a behavioral instruction.

It is not the same as a wallet or policy engine refusing to sign every transaction above $5,000.

Treasury systems should distinguish four layers of control:

What an Autonomous Treasury Agent Could Actually Do

Treasury autonomy is likely to arrive incrementally rather than as a single system suddenly controlling every corporate account.

Low-risk workflows are the logical starting point.

The Treasury Agent Should Not Control Its Own Constitution

This is one of the most important design rules in agentic finance.

An autonomous system should be able to act inside policy.

It should not be able to rewrite the policy that constrains it.

A treasury agent that can:

• raise its own transaction limits;
• add new counterparties;
• approve new assets;
• disable monitoring;
• change approval thresholds;
• rotate its own unrestricted credentials;

effectively possesses governance authority over its own financial constraints.

Privy Shows What Scoped Agent Wallet Access Can Look Like

Current wallet infrastructure is beginning to expose the primitives required for controlled autonomous finance.

Privy's wallet documentation describes programmable policies capable of restricting transfer sizes, recipients, smart contracts and even calldata.

Its agent-specific wallet offering also describes programmable approvals, spending limits and human-in-the-loop workflows.

Privy announced in June 2026 that agents could receive wallet access through an authorization flow without directly handling users' private keys or credentials.

These features do not prove that every Privy-based treasury implementation is secure.

They demonstrate that agent authorization can be separated from unrestricted private-key custody.

Coinbase CDP Demonstrates Another Policy Model

Coinbase Developer Platform documents server-wallet policies that can control transaction behavior based on destination address and transaction value.

Examples include:

• blocking restricted destinations;
• restricting smart-contract interactions;
• limiting transaction values;
• preventing certain signatures;
• applying USD-denominated spending limits.

Again, the important architectural principle is not which provider is used.

It is that the model should not be the only thing standing between an agent and an unrestricted financial transaction.

Safe Adds Threshold and Guard Architecture

Smart-account architecture offers a different control model.

Safe accounts support owner thresholds, modules and transaction guards.

A guard can perform checks around a transaction while thresholds can require multiple approvals before a transaction is valid.

This allows treasury systems to separate routine autonomous activity from actions requiring independent authorization.

The architecture can therefore resemble a corporate treasury approval matrix rather than a single wallet private key.

The Treasury Permission Graph

Treasury risk is often hidden in combinations of capabilities.

A balance-reading permission is relatively low risk.

A payment permission is higher risk.

A contract-interaction permission can be significantly broader.

Combine wallet access, arbitrary contract interaction, unrestricted routing and the ability to modify policy, and the system's effective authority becomes dramatically larger.

DN therefore proposes mapping a Treasury Permission Graph.

The DN Treasury Blast-Radius Budget

The Blast-Radius Budget introduced in the DN AI Agent Blast Radius Index becomes particularly important for treasury.

A financial agent should have measurable ceilings.

Cash, Stablecoins and Tokens Should Not Share One Risk Policy

Treasury assets have different operational characteristics.

Bank deposits, tokenized deposits, stablecoins, money-market funds, government securities and DeFi positions are not interchangeable.

Their risks differ across:

• issuer exposure;
• custody;
• redemption;
• settlement;
• smart contracts;
• liquidity;
• jurisdiction;
• counterparty concentration;
• operational recoverability.

An autonomous treasury should therefore have asset-specific authority.

Stablecoins Make 24/7 Treasury Possible

Stablecoins introduce treasury capabilities that traditional banking infrastructure does not always provide continuously.

They can enable:

• continuous settlement;
• programmable transfers;
• global counterparties;
• machine-readable balances;
• API-based execution;
• on-chain reconciliation;
• integration with smart contracts.

This makes stablecoins particularly compatible with autonomous systems.

But availability does not eliminate financial risk.

Stablecoin issuer risk, chain risk, wallet compromise, sanctions exposure, bridge risk and smart-contract interactions all remain relevant.

Tokenized Deposits May Expand the Treasury Design Space

Stablecoins are not the only programmable form of money developing.

In September 2026, UK banks reported completing interbank transactions using tokenized deposits under the Great British Tokenised Deposit project.

Tokenized deposits preserve a legal relationship to bank deposits while adding programmable settlement capabilities.

If these systems become broadly accessible through APIs, future treasury agents may operate across both bank-native tokenized money and stablecoin rails rather than treating crypto and banking as separate environments.

The Treasury Agent Routing Problem

Once several money rails exist, an agent must decide not only whether to pay but how.

A payment could potentially move through:

• bank transfer;
• card;
• stablecoin;
• tokenized deposit;
• on-chain settlement;
• internal ledger transfer;
• cross-border payment provider.

Choosing the cheapest route alone would be insufficient.

A treasury route selector should also consider:

• settlement certainty;
• recipient compatibility;
• FX cost;
• network fees;
• slippage;
• liquidity;
• compliance;
• reversibility;
• counterparty risk;
• accounting treatment.

The DN Treasury Execution Stack

Simulation Should Precede Irreversible Execution

An agent that can preview a transaction's effect before signing it has another opportunity to identify unexpected behavior.

Simulation is particularly valuable for smart-contract interactions.

It can help detect:

• unexpected token movement;
• wrong destination;
• incorrect contract calls;
• excessive approvals;
• unexpected value transfer;
• failed execution;
• policy violations.

Simulation does not eliminate risk, but it can reduce the number of surprises reaching execution.

Agent Treasury Should Separate Trading From Withdrawal

A trading agent does not automatically need unrestricted custody authority.

Where infrastructure permits, different roles should be separated.

Human Approval Should Be Risk-Weighted

Requiring approval for every payment defeats much of the value of autonomy.

Requiring approval for nothing creates unnecessary exposure.

The better architecture uses thresholds.

Treasury Agents Need Stop Conditions

Autonomous systems should know not only what to do but when execution must stop.

Automatic stop conditions could include:

• balance mismatch;
• unexpected destination;
• asset depeg;
• abnormal fee spike;
• simulation discrepancy;
• duplicate invoice;
• policy-engine failure;
• unavailable price feed;
• counterparty status change;
• transaction failure cluster;
• network instability;
• unexpected treasury drawdown.

The Autonomous Treasury Kill Switch

Every treasury-agent architecture should answer a simple question:

A genuine kill mechanism may require more than shutting down an application.

It may need to revoke:

• API keys;
• delegated wallet authority;
• session signers;
• smart-account modules;
• exchange permissions;
• payment credentials;
• MCP tool authorization;
• persistent automation schedules.

If the agent retains an independent signing path after the application is stopped, the kill switch is incomplete.

MCP Adds Another Treasury Authorization Layer

MCP increasingly connects agents with external tools and business systems.

The 2026-07-28 specification includes substantial authorization work, including credential isolation and scope handling.

MCP Apps can also require authorization globally or for particular tools.

This matters for treasury because a single MCP server might expose both harmless read functions and consequential financial actions.

The ideal architecture should distinguish them.

A balance lookup should not necessarily require the same authorization path as an irreversible payment.

Agentic Treasury Requires Machine Identity

Human credentials are a poor long-term foundation for machine-controlled finance.

Agents should increasingly operate through identifiable machine identities with:

• defined owners;
• explicit delegated authority;
• expiration;
• scope;
• transaction limits;
• audit history;
• revocation mechanisms.

This makes it possible to determine which autonomous actor initiated a transaction and under whose authority.

Treasury Autonomy Should Be Earned

Organizations should not begin by granting the largest authority envelope.

DN proposes a progressive model.

The Treasury Reliability Problem

An autonomous treasury system may be safe from theft and still fail operationally.

Examples include:

• double payments;
• missed payroll;
• wrong network selection;
• stuck transactions;
• duplicate retries;
• stale FX rates;
• unreconciled balances;
• incorrect payment references;
• failed offramps;
• broken accounting sync.

Treasury reliability therefore needs its own benchmark.

The DN Treasury Agent Stress Test

A strong Treasury Agent Readiness Score should eventually require controlled failure testing.

Yield Optimization Is Not the First Treasury Use Case

The most visible crypto treasury discussions often focus on earning yield.

That may be the wrong place to begin autonomous treasury.

The highest-value early applications may instead be operational:

• cash visibility;
• payment scheduling;
• invoice verification;
• currency routing;
• liquidity forecasting;
• balance reconciliation;
• exposure monitoring.

These workflows can create value without requiring the agent to take significant investment risk.

The Cash Preservation Constraint

A treasury is not an investment fund.

Its primary purpose is normally to ensure the organization can meet obligations.

A treasury agent that maximizes yield while increasing the probability of missing payroll is failing its job.

DN therefore proposes a priority hierarchy:

1. meet known obligations;
2. preserve operating liquidity;
3. maintain approved counterparty exposure;
4. control currency and settlement risk;
5. optimize execution cost;
6. only then optimize return on excess liquidity.

Treasury Agent Economics

Autonomous treasury only makes sense if it creates net value.

Potential value comes from:

• lower payment fees;
• better FX execution;
• reduced idle balances;
• faster reconciliation;
• lower operational labor;
• fewer missed-payment penalties;
• continuous liquidity monitoring;
• improved cash forecasting.

But these savings must be compared against:

• infrastructure cost;
• security controls;
• compliance;
• human review;
• software integration;
• failure losses;
• insurance or audit costs.

The Treasury Agent ROI Equation

This is a better measure than counting how many treasury actions an agent automates.

Autonomous Treasury and Stripe's Stablecoin Direction

Payment infrastructure is also moving toward programmable treasury primitives.

Stripe's 2026 product roadmap included stablecoin-related financial-account functionality, local-currency onramps and offramps, stablecoin-backed account expansion and 24/7 movement of money through stablecoin rails.

Not all announced features were generally available at the time of this article, so roadmap items should not be treated as universal production capabilities.

The strategic direction is nevertheless important: stablecoin functionality is increasingly being absorbed into mainstream payment and treasury infrastructure.

The Ideal Autonomous Treasury Architecture

Beginner, Business and Institutional Paths

Ten Questions Before an Agent Controls Company Money

1. Can the agent increase its own spending limit?
2. Can it add a new payment destination?
3. Can it transfer funds to arbitrary wallets?
4. Can it interact with arbitrary smart contracts?
5. Can it change the treasury policy that constrains it?
6. Can high-value actions require independent authorization?
7. Can all activity be reconstructed from logs?
8. Can its authority be revoked immediately?
9. Does the system fail closed when policy infrastructure breaks?
10. Has the organization tested duplicate, failed and adversarial transaction scenarios?

A negative answer to the first five is generally desirable.

A positive answer to the final five is generally desirable.

Proposed DN Autonomous Treasury Leaderboard

DN will not manufacture platform scores from marketing documentation. The first public leaderboard should distinguish documented capability from controlled testing and should remain unranked until sufficient reproducible evidence is collected.

DN Methodology

Limitations

The DN Autonomous Treasury Index does not certify financial safety, regulatory compliance or solvency.

A technically strong treasury architecture can still fail because of:

• fraudulent data;
• bad treasury policy;
• compromised counterparties;
• issuer failure;
• smart-contract vulnerabilities;
• market risk;
• banking restrictions;
• human governance failures.

Scoring should therefore be treated as one layer of treasury due diligence rather than a substitute for professional financial, legal, security or compliance review.

Primary Evidence and Reference Frameworks

Frequently Asked Questions

Disclosure

Decentralised News develops independent indices, benchmarks, research frameworks and decision tools covering AI, crypto and agentic finance. Some Decentralised News pages may contain affiliate or commercial relationships. These relationships do not determine benchmark inclusion, methodology, scores or editorial conclusions. DN-ATI is an original analytical framework and does not constitute financial, cybersecurity, legal or investment advice.