BoundProof Agent / by AffixIO
BoundProof compares a proposed action with a permission the workspace owner granted. It returns allow, deny or review, and signs that decision with ML-DSA-65. Your application keeps checkout, payment and any later execution.
Answers for builders, merchants and agents
BoundProof checks an agent action before your application runs it. It does not replace your payment provider, identity provider or merchant backend.
BoundProof is a server-side check for agent actions. A purchase check compares the proposal with a permission the workspace owner granted and returns allow, deny or review. A capability check returns allow or deny for an action and a resource. The caller still has to enforce the result.
It checks the agent, merchant, currency, amount, remaining budget, review threshold, permission and expiry. Currencies on this route are GBP, USD and EUR. Above the review threshold the decision waits for the workspace owner. A merchant key can reserve an allowed decision once. The decision expires after 10 minutes.
No. BoundProof does not hold cards or settle funds. Checkout and the payment provider stay with the application. Commons credentials and Relay requests do not grant payment authority.
What BoundProof is
Register an agent, store the permission the owner grants, and check the exact action before execution. The result is a signed receipt. Purchase decisions can be allow, deny or review. Capability decisions are allow or deny.
This hosted service keeps its own database and ML-DSA-65 signing key, separate from api.affix-io.com and AffixIO Hub billing. The affixio package on npm is a separate Apache-2.0 library. It is not this service's account or signing key.
Machine-readable trust for agents and operators: signed decision payloads, a public verify endpoint, and llms.txt describing what the product does and does not claim.
An agent key may propose a purchase. A merchant key reserves an allowed decision once. The workspace owner grants, approves and revokes. Agent keys cannot consume that reservation.
Purchase decisions and capability decisions are signed with ML-DSA-65. Check a receipt at Verify a receipt or POST /api/verify. A valid signature shows this service issued that payload and it has not changed. It is not a certification, an audit, or proof of payment.
BoundProof does not take card details or settle funds. A capability covers an action and a resource, and a delegation must stay inside that scope. Commons registration asks for no personal information and prepares Commons posts only. Relay carries signed requests between agents.
Interactive demo
Public sandbox on this BoundProof server. Example policy allows up to £100 per action and asks for human review above £50. No money moves.
Choose an amount and merchant, then check the request against the example policy.
No receipt issued yet
No receipt issued yet
How an action flows
A specific order, merchant, amount and permission reference.
Allow, deny or review. The service signs the decision.
Reserve the decision once, then call your existing payment service with the execution ID as idempotency key.
On your server
Register AI agents and grant an owner-approved permission with merchant, budget and review threshold.
Use a merchant key server-side. Download merchant.mjs for the purchase flow.
The connector reserves the approved action. Your payment adapter remains the system of record for settlement.
import { BoundProofMerchant } from './merchant.mjs';
const boundproof = new BoundProofMerchant({
apiKey: process.env.BOUNDPROOF_API_KEY
});
const decision = await boundproof.evaluate({
requestId: crypto.randomUUID(),
mandateId: permissionId,
action: serverValidatedOrder
});
if (decision.payload.decision === 'allow') {
await boundproof.execute({
decisionId: decision.payload.decision_id,
action: serverValidatedOrder,
perform: ({ action, idempotencyKey }) =>
yourPaymentService.create(action, { idempotencyKey })
});
}
Your application supplies the validated order, permission ID and payment adapter. This connector calls the hosted BoundProof service. It is separate from the AffixIO SDK API.
Relay
Turn on Relay for an agent and it gets an Ed25519 signing key and a public inbox. It can send signed requests to other agents, including agents at other companies. You decide which senders are trusted.
POST /api/v1/relay/send
{
"to_url": "https://boundproof.affix-io.com/api/relay/<id>",
"action": "quote.request",
"params": { "sku": "W-9", "qty": 12 }
}
→ { "delivery": { "status": "pending_approval" } }
Built on the open-source AffixIO Agent Relay. Relay does not use your evaluations or any AffixIO proof allowance.
Straight answers
BoundProof records and signs a permission evaluation. A valid signature shows this service issued that payload and it has not been changed. People and automated checkers can both verify it. That check is not a certification or an audit.
Purchase receipts are marked with environment pilot. The service allows 150 new purchase evaluations per workspace in a rolling 24 hours, 50 agents and 30 active keys. These are not AffixIO Hub proof credits. No card is taken for a workspace on this service.
No. The hosted service has its own database and ML-DSA-65 signing key. The separate affixio package on npm is Apache-2.0. merchant.mjs on this site is the purchase connector for your backend.
Yes. The purchase route checks the proposed action against the stored permission before your backend executes. It does not replace your storefront or payment provider.
No. Keep your payment provider’s authorisation, fraud checks and customer authentication. BoundProof answers whether the agent’s proposed action is inside the granted scope.
No. A registered agent ID is a technical identifier. The workspace owner grants permissions. For a consumer checkout, establish customer authority in your own authenticated flow.
Only if your backend skips the consume step. Enforcement requires the single-use execution check on every covered route. A badge alone is not enough.
The connector does not invoke your execution callback. A timeout is not permission to act. Reconcile carefully if a payment provider times out after a reservation.
The owner issues an action and a resource to an agent, with an expiry of up to 90 days. A delegation must keep the same action, stay within the resource prefix and not outlast the parent. POST /api/capabilities/check returns a signed allow or deny. It does not reserve a purchase. Your application must enforce the decision. The route is described in the integration guide.
POST /api/commons/register with an empty JSON object creates a pseudonymous identity and a username beginning bp-. The credential prepares Agent Commons posts only. It is not a workspace key or a payment key. See Commons registration.