The Trust API for AI Agents: Oracles and Proof of Reserve

A human portfolio manager can read an issuer's quarterly letter, call the sponsor and form a judgment. A software agent cannot. It can query an endpoint, check a signature and compare a number against a threshold. In 2023 the Bank for International Settlements argued that adding trusted data providers to blockchain systems creates a tension that may confine decentralised finance to crypto-native assets. That tension now applies to a newer class of market participant. As agents start to hold and move balance-sheet cash, the useful question is no longer whether an asset is on-chain. It is whether anything about the asset can be verified by a machine.

A claim is not a fact a machine can use

Most of what an allocator needs to know about a real-world asset still arrives as a document: an audited financial statement, a vault bar list, an appraisal, a registry screenshot, a servicer report. These documents are fine for people. A credit analyst knows how to discount a sponsor's adjectives, notice a footnote and ask a follow-up question.

An agent has no equivalent instinct, and giving it one would be the wrong design. An agent that "reads" a press release and decides it sounds credible is doing the very thing institutional risk frameworks exist to prevent. The sound pattern is narrower and stricter: the agent acts only on data that arrives from a source independent of the issuer, carries a timestamp and a signature, and can be checked against a policy the agent's human principal wrote in advance.

That makes the oracle layer, together with proof-of-reserve attestations, the trust API for AI agents. It is the interface that turns an issuer's claim ("the token is backed one-for-one", "NAV is $102.40", "the credit was retired") into a fact a machine can test before acting. Our explainer on the oracle layer for RWA tokenization covers the mechanics. The agent-specific point is that this layer stops being a convenience and becomes the gate. If an asset has no verifiable data surface, an agent operating under a sensible mandate cannot hold it.

What an agent actually queries before it allocates

Across asset classes, the questions an agent needs answered are similar, though the data behind them is not.

Does the asset exist, and in the stated quantity? For a gold-backed instrument, that means a reserve attestation reconciled against the outstanding token supply. For a carbon credit, it means registry status: issued, held in a named account, not yet retired. For a tokenized loan pool, it means a loan tape whose principal balance matches what holders are told. This is the job of proof of reserve, which our guide to proof of reserve for RWAs treats in full.

What is it worth, and as of when? NAV for a commercial property or a private credit fund is not a live market price. It is an appraisal or model mark struck monthly or quarterly. An agent that confuses "last updated four seconds ago" with "valued four seconds ago" will misprice risk. A useful feed carries two timestamps: when the data was published, and the valuation date it refers to.

Has anything happened? Distributions, missed payments, covenant breaches, redemptions, corporate actions and credit retirements are events, not states. Agents need them as structured event streams, not as an email to investors that someone may or may not forward.

Who said so? Every data point needs provenance: which auditor, custodian, administrator or registry produced it, and whether it was relayed by an independent network or posted by the issuer. A NAV the issuer posts about itself is still a claim. A NAV relayed from an independent administrator through a decentralized oracle network is much closer to a fact.

The Financial Stability Board's 2024 report on tokenisation identified exactly this dependency. It noted that tokens referencing existing assets may need oracles to bring data onto ledgers, and warned that reliance on unregulated or non-compliant oracles can hinder an accurate picture of asset price and quality. For a human investor, that is a disclosure risk. For an agent, it decides whether the agent can hold the asset at all.

Policy, not judgment: how agents use attestations

The practical value of a trust API is that it lets a human principal express risk appetite as rules a machine can follow without improvising. The patterns emerging in the market are straightforward.

A staleness rule blocks allocation if the most recent reserve attestation is older than a set window, say 24 hours for a commodity-backed token or one valuation cycle for a property fund. A reconciliation rule halts activity if attested reserves fall below outstanding supply by more than a tolerance. A source rule accepts NAV only from a named administrator via an independent relay, never from the issuer's own contract. An event rule triggers a review, or a forced exit, when a payment-default or covenant-breach event is published.

None of this requires the agent to be clever. It requires the data to be dependable. The same discipline is already visible at the issuance end of the stack. Chainlink Proof of Reserve, for example, can gate minting so new tokens cannot be created unless attested reserves support them. The check runs in code before supply changes, not in a quarterly review afterward. An agent applying the same logic on the buy side is simply the other half of that loop.

There is also a real benefit for issuers here, and it is not only defensive. An asset with a clean, continuously attested data surface becomes legible to a new category of buyer that cannot hold anything else. Liquidity follows legibility. Two otherwise identical tokenized warehouse interests will not trade the same way if only one exposes verifiable NAV, rent-collection events and title status to machines.

Where the trust API is still weak

It would be a mistake to treat attestations as a solved problem. The BIS analysis is a useful corrective: introducing trusted parties to make oracles efficient also reintroduces trust. Moving a number on-chain does not make the number true. A reserve attestation is only as good as the custodian and auditor behind it. A NAV feed faithfully relays whatever the valuation model produced.

Three gaps matter most for agents today.

Valuation cadence. Real assets are valued slowly. A property appraised quarterly cannot produce a meaningful price every block, and a feed that pretends otherwise invites agents to trade on stale marks. The honest design exposes the valuation date clearly and lets the agent's policy decide what age is acceptable.

Coverage. Proof of reserve is mature for assets held in custody, such as bullion, cash and treasuries. It is thinner for assets whose "reserve" is a legal right: a mineral royalty, a lease, a carbon removal offtake. For those, the attestable facts are cash receipts, registry entries and contract status, and the standards for attesting them are still forming.

Accountability. When an agent acts on an attested fact that turns out to be wrong, someone must be responsible. Market participants increasingly expect data providers to state their methodology, their update triggers and their liability in plain terms, as index providers and benchmark administrators already do in traditional markets.

Why this matters for institutional capital

The agentic-finance discussion often centers on model capability. The more consequential constraint is upstream. Agents will allocate only to assets whose existence, value and status they can verify without a human reading a PDF. Our earlier piece on what AI agent treasuries need from capital markets made the case for machine-readable markets in general. Oracles and proof of reserve are the specific layer where that case is either met or failed.

For commercial real estate, private credit, energy royalties and commodities, the implication is concrete. The assets that build an independent, timestamped and signed data surface now will be the ones machine allocators can see. Commertize's view is that verifiable data, more than any single chain or wrapper, is what will separate the real assets that attract this capital from the ones that don't.

Prefer email? Send the offering memo or a short asset summary to deals@commertize.com. We reply within one business day, with no obligation to engage us.