Banks and fintechs
Distinguish an authenticated agent from a delegated one. Explore how an explicit, customer-defined grant could be checked at your own transaction boundary, with your controls keeping final say.
Financial authorityDelegated authority for AI agents
Your AI agent has access. But was that action authorized?
Banks and organizations can authenticate an AI agent without necessarily knowing what a person authorized it to do. Standard Bearer is building infrastructure to define, evaluate, and verify delegated agent authority.
A valid login isn't permission to do everything.
Signing in proves who, or which agent, is connecting. It does not say what the person behind it agreed the agent may do: which payee, how much, until when.
What authentication answers
Is this the customer's credential, token or session? Is the connection allowed onto the platform? Most agent activity that passes these checks is legitimate and intended.
What it leaves open
Did the customer delegate this action, to this recipient, for this amount, right now? Today that answer is usually pieced together from credentials, platform permissions and logs, often only after something has gone wrong.
Capability does not imply authority. An agent that is able to act still needs a record of what it was permitted to do.
Define authority. Check the action. Preserve the evidence.
Three steps, each one explicit, bounded and revocable.
- Demonstrated in local simulation
Define the delegation
The person states which agent may act, what action, which recipient, the limit and when it expires. The permission can be revoked at any time.
- Design direction
Check the action at the boundary
A deterministic check runs where a participating institution executes the action, before it happens. The same request always gets the same answer. Today this check runs only in the local simulation.
- Design direction
Keep evidence others can verify
Each decision leaves a replayable record. Independently verifiable evidence is the goal where the architecture supports it. Today's records are self-attested by the simulator.
A $500 permission. A $2,000 request. A clear decision.
A customer lets a personal assistant agent pay one approved electricity utility, up to $500 per billing cycle. Here is what the local simulation decides.
Case A
Agent pays a $184.32 bill
Permitted in local simulation
Within the $500 limit, to the approved utility. $315.68 remains for the cycle. No money moves.
Case B
Agent requests $2,000
Denied
$2,000 exceeds the customer's $500 limit by $1,500. Nothing is reserved and the full $500 remains.
Revocation. If the customer withdraws permission after a payment has been reserved but before it executes, the reservation is released and execution is blocked.
- Every screen is labeled as a local simulation with no real funds.
- The customer's permission: $500 per billing cycle, one approved utility, one assistant agent, fixed dates.
- The agent's request: a $2,000 payment to the same utility.
- The decision and the reason: $2,000 exceeds the $500 limit by $1,500. Nothing was reserved.
Screenshot of the Example 03 browser demo running on a local machine. It is not a hosted or live service: the demo binds to 127.0.0.1, moves no money, connects to no bank and stores no personal data.
Built for the people accountable when agents act.
Insurers and brokers
When an agent causes a loss, what was it authorized to do? Explore what delegation records and evidence would matter for coverage, claims and underwriting questions.
InsuranceAgent platforms and developers
See the effective authority an agent actually holds across its configuration, and where it exceeds what was intended.
DevelopersIndependent where consequences demand it.
Not every action needs the same assurance. The more an action can cost, the less its evidence should depend on the agent or the platform that ran it.
Authority the agent can't rewrite
The permission is defined by the person and held outside the agent, so the agent cannot widen its own limits.
Enforcement where the action executes
The check belongs at a trusted execution point, such as a bank's payment system, rather than inside the agent.
Evidence others can verify
For the highest-consequence actions, records should be verifiable by someone other than the party that produced them.
These are design principles, not product tiers or ratings. The local financial simulation today provides self-attested records only.
What works today - and what we're building next.
Demonstrated today
- A local, deterministic financial-authority simulation: 15 scenarios, including permitted, denied and revoked payments
- Event replay that rebuilds the simulation's state from its record and checks it matches
- An OpenClaw observer that replays agent configurations and reports effective authority and the Authority Exposure Gap
Under development or awaiting partner validation
- Integration with a bank or payment provider
- Real enforcement at an execution boundary
- Independently witnessed evidence
- Institutional pilots
Questions institutions ask first
Does Standard Bearer move money?
No. Standard Bearer is not a bank, payment processor or money transmitter. The financial example is a local simulation: it connects to no bank or payment rail and moves no funds.
Does it replace a bank's fraud controls?
No. Standard Bearer is not a fraud-detection engine. It is concerned with a different question: whether a specific action falls within what a customer explicitly delegated to an agent. A bank's existing fraud, risk and authentication controls stay in place and keep final control.
Can it block every agent that uses bank credentials?
No. A delegation check can only affect actions that pass through an execution point that participates in it, such as an integrated bank system. Without an enforcement integration, Standard Bearer cannot stop an agent that uses valid credentials elsewhere.
Is the evidence independently witnessed today?
No, not for the local financial demonstration. Its records are produced and self-attested by the simulator itself. Independently verifiable evidence is a design goal, not a current capability.
What is a pilot?
Exploratory design and sandbox work with a partner institution to test whether delegated authority fits its environment. Scope, data handling and any commitments are subject to a written agreement. A pilot is not a production deployment.
Explore whether delegated authority fits your environment.
Pilots are exploratory design and sandbox work with partners, subject to agreement. Tell us what you are evaluating.