Authorization for AI agents
Know which agents act for your customers.
Behest tells you which AI agent is acting, for which customer, and checks everything it asks for against your policy before your systems act.
Decides on structured actions. Never reads prompts.
{
"agent": "Instinct",
"connection_id": "cnx_8f21",
"action": "wire_transfer",
"amount": 5000,
"decision": "block",
"reason": "over_ceiling",
"reason_text": "Over the bank's ceiling for agents"
}
How it works
Your policy decides. Behest applies it to every request.
Define your policy
List the actions an agent may ever be given and a ceiling on each. Some actions are never done for an agent, like adding a payee. Anything not listed is blocked. You can change the policy at any time.
# Actions not listed here are blocked.
actions:
get_balance: {}
dispute_charge:
ceiling: 500
wire_transfer:
ceiling: 1000
never_delegable:
- add_payee
- change_address
- close_account
Customer connects an agent
The customer connects the agent from inside your app, picks what it may do within your ceilings, and approves with the agent provider. The agent never gets the customer's password, and Behest never learns who the customer is.
The agent arrives with a key
Before it contacts you, the agent states its purpose and gets a key from Behest: signed, single use, valid for two minutes and bound to that agent, that customer's connection and your bank. You check it and know exactly who is acting for whom. No key means no verification, so you use your normal checks.
# the agent asks for a key
POST /v1/calls/intent
{ "connection_id": "cnx_8f21", "purpose": { "action": "wire_transfer", "amount": 800 } }
200 OK
{ "key": "eyJhbGciOiJFUzI1NiIs...", "expires_in": 120 }
# the bank checks it
POST /v1/calls/verify
200 OK
{ "status": "verified", "agent_name": "Instinct", "customer_ref": "cust_41c9" }
Every request gets a decision
When the agent asks for something, you ask Behest before acting. Behest checks that the agent is still connected, that the customer granted this action, and that the amount fits both their limit and your ceiling. It returns allow or block with a reason, and logs every decision. If the customer removes the agent, its next request is blocked.
# verification_id omitted
POST /v1/calls/authorize
{ "action": "wire_transfer", "amount": 800 }
200 OK
{ "decision": "allow", "reason": "within_limit" }
POST /v1/calls/authorize
{ "action": "add_payee" }
200 OK
{ "decision": "block", "reason": "never_delegable" }
Built for both sides
For businesses
- You own the policy. Behest enforces it and never changes it.
- Every agent request is checked before you act on it, and logged with its reason.
- Customers choose what each agent may do, and can remove it at any time.
For agent providers
- Integrate once. Work with every business on Behest.
- No custom integration for each bank.
- One key proves which agent is calling and for whom.
How Behest compares
API keys and OAuth scopes say who may call an API. They don't decide on each action.
| API keys | OAuth scopes | Behest |
|---|
Questions
Do you read the agent’s prompts or conversations?
No. Behest only sees structured actions, like wire_transfer with an amount. It never sees prompts, chats or model output.
Who decides what an agent is allowed to do?
The business, through its policy. Behest enforces that policy and does not change it.
What happens when a request is blocked?
The business gets a block with a reason and doesn’t act, so it can tell the agent why. The decision is logged.
What if an agent shows up without a key?
It isn’t verified, so the business treats it like any other caller and uses its normal security checks.
Does this work for humans acting on someone’s behalf?
Not yet. It’s on the roadmap: a caregiver, assistant or accountant would go through the same connect flow and the same policy checks.