Skip to content

Financial control infrastructure for autonomous agents

Give your AI agents autonomy. Keep them on a financial leash.

WAYLOCK is the economic authorization layer for AI agents.

WAYLOCK is designed to evaluate scoped agent requests before routing authorized actions to supported financial rails. Each request receives ALLOW, DENY or APPROVAL_REQUIRED against the permissions, policies and approval thresholds a person sets.

Get startedFor developers

The problem

Instructions are not a financial control.

An agent with direct access to money can spend beyond what anyone intended. A prompt can be misread, a tool can be misused, and a key can be copied. Authority needs a boundary the agent cannot move.

Direct access

The agent holds the authority

Whatever the agent can reach, it can spend. Limits live in instructions.

Through WAYLOCK

A person holds the authority

The agent requests. WAYLOCK evaluates each request against the bounds a person set.

The authority layer

One layer between agents and money.

External agents sit above. Financial rails sit below. WAYLOCK sits between them and decides whether a request may proceed.

In this design, a rail is an adapter: it would receive only already-authorized instructions and never grant authority itself. Execution through a rail is not available yet.

How it works

Every request receives exactly one outcome.

The agent requests. WAYLOCK evaluates identity, permission, policy and limits deterministically. A language model can add context, but it cannot authorize money movement.

Agent

The agent requests

An external agent submits a request through its WAYLOCK identity. It cannot grant itself authority.

POST /v1/authorization-requests

WAYLOCK

WAYLOCK evaluates

  • Agent identity and state
  • Permission version and scope
  • Policy and limits
  • Approval threshold
  • ALLOWWithin the permission ceiling and below the approval threshold.The request is authorized. It is eligible for execution only through a compatible rail; authorized is not paid.
  • APPROVAL_REQUIREDAbove the approval threshold.A person reviews the exact request. A changed amount, currency, payee or purpose needs a new approval.
  • DENYOutside the permission or its policy.No executable instruction is produced, so nothing reaches a rail.

Architectural illustration. No live customer, market or provider is shown.

Control

Bounded authority you can inspect and revoke.

A person sets the bounds once. WAYLOCK applies them to every request, and every change is versioned.

What a person controls

Permission
An Agent Financial Permission states what an agent may request and against which source.
Limits
A ceiling and a time window bound each permission. Requests outside them are denied.
Source
A registered source records where authority would apply. Registered is not funded.
Approval threshold
Above the threshold, a person reviews the exact request before it can proceed.
Revocation
Pause or revoke an agent, a verification or a credential. WAYLOCK enforces it, not only the screen.
Audit
Each decision is recorded with the permission and policy versions that applied.

Pairing and trust

Connect an external agent without handing it the keys.

A short-lived, single-use pairing code binds a compatible integration to one WAYLOCK Agent. The code only pairs. It is not a credential and grants no spending authority.

  1. Code issuedWAYLOCK shows a single-use pairing code once.
  2. Waiting for the integrationThe code is given to the external agent’s integration before it expires.
  3. Proof on the integration sideThe integration redeems the code with a fresh proof of its key.
  4. ConnectedThe integration submits requests as that WAYLOCK Agent.

Enterprise

The same control model for every team.

Organizations use the same agent identity and authorization model as everyone else. Operations review requests, approvals and audit evidence in one workspace; there is no separate authority system for enterprise agents.

  1. 01External agent
  2. 02Financial identity
  3. 03Bounded permission
  4. 04Policy and risk
  5. 05Human approval when required
  6. 06Authorization
  7. 07Compatible execution rail

Permission, policy, approval, authorization and execution are separate steps. Rails do not grant authority, and human approval does not establish settlement.

Developers

Build against the control layer.

Every interface converges on the same WAYLOCK Agent identity, permissions, policies and authorization. None of them is a shortcut around it.

  • APIRegister identity, define permission, request authorization.
  • SDKA convenience layer over the same contract; the server still enforces every check. Internal, not yet published.
  • ConnectorRedeems a pairing code and submits requests for one external agent. Internal, not yet published.
  • MCPAn interface to the same financial controls, not a separate authority.

One control core

The same checks, whichever interface sends the request

  1. Agent identity
  2. Permission and limits
  3. Policy
  4. Human approval when required
  5. Authorization
For developersRead the quickstart

Security

Authority that can be inspected.

Authorization fails closed when identity, permission or authority cannot be verified. Agents and their tool arguments are treated as untrusted.

  • Least privilegeBound identity, permission, scope and current versions.
  • Human reviewBind approval to the exact request.
  • Execution certaintyUncertain outcomes enter reconciliation.
  • Audit evidencePreserve decisions and consequential actions.

Start with one bounded agent.

Sign in, register an agent, set its permission and approval threshold, then connect its external integration.

Get startedFor developersReview security