Agents should not hold unrestricted wallet authority.
A payment-capable agent needs room to act, but full wallet access turns every prompt, integration, and dependency into a signing risk.
Gateway Console
Pre-signing policy enforcement for AI-agent payments.
Anagate sits between agent intent and signed Stellar payment. It checks policy before a relayer signs, so autonomous payments stay inside explicit operating limits.
agent intent Payment intent recipient, amount, reason
policy gateway 
ALLOW / BLOCK / REQUIRE_APPROVAL
ALLOW / BLOCK / REQUIRE_APPROVAL signed payment Stellar payment signed by relayer
Payment safety has to happen before execution.
Agent payments need a narrow signing path: enough autonomy to move, with policy checks before money can leave the wallet.
Monitoring after execution is too late.
Alerts and dashboards can explain what happened. Anagate is designed to make the decision before the signature exists.
What goes wrong without a gate
Compromised authority still looks valid
If a key, session, or agent credential is abused, the payment can still look technically legitimate unless policy checks challenge the request before signing.
Language can become payment intent
A manipulated prompt, tool output, or workflow instruction can become a structured transfer request when nothing verifies the intent between the agent and the wallet.
Late observability cannot stop a signature
Dashboards can explain a bad payment after it lands. The safer control point is the moment before a relayer receives something signable.
Intent becomes a signature only after policy passes.
- agent intent
Agent proposes payment intent
The agent sends recipient, asset, amount, memo, and reason as a structured request.
- policy gateway
Anagate evaluates policy
Rules check status, recipient allowlist, maximum amount, and daily spending limit.
- signed payment
Relayer signs only allowed requests
The relayer receives a signable request only when the gateway returns ALLOW.
A concrete request, checked line by line.
The gateway turns each payment intent into a decision record with visible inputs, thresholds, and reasons.
Payment request 42 XLM to stellar.tools
Reason: settle compute usage for an agent task.
Agent status
Agent can request payment intents from this policy set.
Recipient allowlist
Recipient matches the approved builder-services group.
Maximum amount
Request is inside the policy cap, but close enough to require approval.
Daily spending limit
Remaining daily capacity can cover the proposed transaction.
Every request exits through one explicit state.
ALLOW
Policy passed. The relayer can sign and submit the Stellar payment.
BLOCK
Policy failed. The request stops before a signature can be produced.
REQUIRE_APPROVAL
Policy is valid but sensitive. A human reviewer must approve before signing.
Decision records make the gate inspectable.
| Time | Agent | Recipient | Amount | Decision | Reason | Hash |
|---|---|---|---|---|---|---|
| 14:03:18 | invoice-agent | stellar.tools | 42 XLM | REQUIRE_APPROVAL | Near maximum amount | 9f3a...c18b |
| 14:05:44 | ops-agent | node-host | 8 XLM | ALLOW | Allowlisted recipient | 31ad...77e2 |
| 14:09:02 | research-agent | unknown-payee | 17 XLM | BLOCK | Recipient not allowlisted | not signed |
Stellar-native controls for agent payment surfaces.
The concept is early, but the operating model is specific: structured payment requests, a policy decision, and a relayer that signs only when allowed.
- Stellar flow Built for Stellar payment flows, including native XLM.
- Agent pattern Designed for x402 and MPP-style agent payment patterns.
- Integration path Surfaces can include a TypeScript client and a policy-aware relayer.
Join the waitlist
Get updates as Anagate develops the pre-signing policy gateway for Stellar agent payments.