Veriticity for developers

Veriticity is the trust layer between an AI agent and the money it wants to spend. Give agents spending rules, approval thresholds and budgets, and get an explained decision on every purchase.

Veriticity is the trust layer between an AI agent and the money it wants to spend. An agent asks whether a purchase is allowed; spending rules a person wrote decide; and every answer comes back explained and recorded.

The problem it solves is narrow and real. An autonomous agent that can spend is either given a credential with no limits, or given none at all and made useless. Neither is a position anybody is comfortable defending to a finance team. Veriticity is the third option: the agent gets a credential, and the credential is governed.

What a call looks like#

One endpoint carries the whole product. You submit a purchase, and you get a decision.

curl -X POST https://app.veriticity.com/v1/purchase-requests \
  -H "Authorization: Bearer cmp_live_9f2a1c4b7e30.<secret>" \
  -H "Content-Type: application/json" \
  -d '{
    "merchant": "Acme Cloud",
    "amountMinor": "7500",
    "currency": "GBP",
    "reason": "Renew the build pipeline compute credits"
  }'

{
  "purchaseRequest": { "id": "0199a3f1-…", "status": "APPROVED" },
  "decision": {
    "outcome": "APPROVED",
    "reasonCodes": ["WITHIN_POLICY"],
    "explanation": "Acme Cloud is on the allow list. GBP 75.00 is within the GBP 500.00 single-purchase maximum, and the daily budget has GBP 420.00 remaining."
  },
  "approval": { "required": false, "expiresAt": null },
  "replayed": false
}

Three outcomes are possible — APPROVED, REJECTED and REQUIRES_APPROVAL — and all three are successful calls. A refusal is an answer, not an error.

The mental model#

Five things, in a line. Getting this right makes the rest of the documentation obvious, and getting it wrong makes all of it confusing.

Human
  │  creates an account and writes the spending rules
  ▼
Organisation
  │  contains the identities that are allowed to spend
  ▼
Agent                       ← an identity. Holds no credential.
  │
  ├── API key bound to it   ← your own software authenticates with this
  └── OAuth connection      ← an AI assistant acts through this, by a person's grant
        │
        ▼
   Trust Engine             ← evaluates the purchase against the rules in force
        │
        ▼
    Decision                ← approved, refused, or escalated to a person

The line that matters most: an agent never authenticates. An agent is an identity, like a role. A credential authenticates, and it acts as the agent. So there is an “API key bound to an agent” and an “OAuth connection acting as an agent”, and never an agent that logs in.

Connecting an AI assistant#

Claude, ChatGPT and other assistants connect to an agent that already exists, through an OAuth connection a person authorises. The assistant does not become a Veriticity user, does not create an agent, and gains no authority of its own — it receives a revocable grant over authority that was already there, and the grant can be withdrawn without touching the agent.

Once connected, the assistant reaches Veriticity over MCP, where it can ask what it is allowed to spend, request a purchase, and find out what a person decided. It cannot approve its own escalations, cannot change the rules it is judged against, and cannot see the organisation’s other agents.

What Veriticity does not do#

Veriticity does not move money. It governs, checks, records and explains purchase decisions; settlement happens wherever it already happens for you. An APPROVED decision means the purchase is permitted under your rules, not that a payment has been made.

There is also no sandbox mode and there are no published rate limits today. Both are noted here because their absence is easy to assume the other way round.

Where to go next#