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. Bring your agent or run one natively. Orangepill governs what it can do to money and runs approved intents through the same financial execution 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
Bring your agent or run one natively. Orangepill governs what it can do to money.
The intelligence does not have to run inside Orangepill. External agents, application backends and native Orangepill agents cross the same financial boundary: actor context, authority, economic intent and governed execution.
External-agent first
An external agent can reason in its own runtime and call Orangepill through governed API, SDK or MCP surfaces. Orangepill remains authoritative for financial permission, state and execution.
Native-agent complete
Flows can also use bounded native agents where adding another runtime would be unnecessary. Native agents enter the same financial execution path rather than receiving a lighter path.
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.
Governed access surfaces
Agents reach financial operations through API, SDK or MCP surfaces that enter the same authority and execution semantics, 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
Intelligence can live elsewhere. Financial authority stays here.
External intelligence
Kortix, model runtimes, custom agents and application backends can originate an economic request.
Native intelligence
Orangepill flows can use bounded native agents for financial reasoning inside a deterministic journey.
- Actor / Principal Who is acting, for whom
- Financial Authority Policy, scope, limits, approvals
- Economic Intent What should happen
- Financial Execution Governed movement and state
- Evidence / Verification What actually happened
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. Native agents can act through governed tools and economic intents, and external agents can integrate through existing application or MCP boundaries. 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 budgets, approval patterns and external-agent bindings 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.