Identity
Each agent is a distinct actor, not a shared API key. Its actions are attributable to it and to the party it acts for.
Agent Runtime Private Preview
Agents need authority, not raw credentials.
Software that initiates financial actions needs bounded authority and verifiable execution. Agent Runtime gives an agent an identity, a scope and a budget, and runs what it asks for through the same governed lifecycle as every other operation.
Problem
An API key is all-or-nothing authority.
The quickest way to let an agent move money is to hand it the same credentials a backend service uses. That gives it every permission the service has, no spending limit, and no record of which decisions were the agent's. When something goes wrong, nobody can say what the agent was allowed to do, only what it did.
- A retry loop sends the same payout repeatedly because nothing bounds total spend.
- An agent built for refunds can also initiate payouts, because the key allows both.
- Audit logs show a service account, not the agent, the user it acted for, or the policy that applied.
Principle
Agents express intent. The runtime decides whether it is allowed, and executes it.
Bounded authority
Provider credentials stay on the server, inside provider configuration. An agent submits a financial intent using an Orangepill credential. Identity, scope, policy and budget determine whether that intent may proceed.
Verifiable execution
Approved intents run through the same execution, ledger and verification path as any operation. There is no separate, lighter path for automation.
How it works
Controls that sit between an agent and value movement.
Scopes and permissions
Which operations, wallets and counterparties an agent may touch. Anything outside scope is refused, not attempted.
Policy
Rules evaluated before execution: amount limits, allowed routes, balance constraints, time windows.
Budgets
Spending bounded over time, so a loop or a bad decision cannot drain a wallet.
Approvals
Intents above a threshold or outside normal patterns wait for a person before they run.
Tool access via MCP
Agents reach financial operations through defined tools (Model Context Protocol), not through raw provider credentials.
Audit attribution
Every action records which agent, under which delegation and which policy, requested it.
Proof of Record
Agent-initiated operations produce the same evidence as any other operation.
Architecture
Authority is checked before intent becomes execution.
- Agent
- Identity Who is acting, for whom
- Policy / Scope / Budget Is this allowed?
- Financial Intent What should happen
- Runtime Governed execution
- Proof of Record Attributed evidence
The runtime does not trust the agent's description of what happened. Outcomes come from execution and the ledger, and are verified against provider reality like any other operation. If an agent-initiated payout ends in an uncertain state, it goes to Resolve, not back to the agent to try again.
Example
A procurement agent reaches its budget.
An agent pays approved suppliers from an operating wallet. It is scoped to known counterparties and a weekly budget. Late in the week it requests a payment that would exceed the remaining budget.
- Supplier payment intent Submitted by agent
- Policy check Counterparty in scope; budget exceeded
- Within bounds Executes, Proof of Record attributed to agent
- Outside bounds Held for human approval
Nothing is attempted with the provider until a person approves. The approval itself becomes part of the operation's proof, alongside the agent's request.
Status Private Preview
What exists, and what is being extended.
Working in the platform; enabled with selected customers. Agents act through MCP tools and economic intents, and agent-initiated intents use the same execution path and ledger as every other operation. Per-agent policy is applied where it has been configured for the agent. Coverage of the other controls on this page (budgets, approval patterns and the set of MCP tools) is being extended. We confirm exactly what is available for your use case during technical evaluation rather than listing it as finished here.
For why software-initiated finance changes infrastructure requirements at all, see Autonomous Finance.
For developers
Inspect how to integrate it.
The v4 API is described by an OpenAPI contract. Start with the quickstart, then the parts that matter in production: errors, webhooks and the sandbox.
- Quickstart Authenticate, choose an environment, create a payout.
- API reference Representative v4 routes, objects and lifecycle statuses.
- Errors Errors versus unknown outcomes, and when retrying is safe.
- Webhooks Signatures, at-least-once delivery, retries and ordering.
- Sandbox Deterministic test provider, including failure outcomes.
- Integrations Providers, rails and channels in the catalog.
Describe one financial action you want an agent to take.
We will map the identity, scope, budget and approvals it would need, and what is available today.