Agent Vault review: mock tokens keep the card out of the agent
Self Labs launched Agent Vault so agents can pay and sign in with mock tokens instead of real cards or passwords. Worth a look if you already let assistants checkout—and you can name the caps and the kill switch owner.
Verdict: Agent Vault (Self Labs, October 15, 2026) is worth evaluating if your agents must pay or log in across sites and you will not put real card numbers or passwords in model context. Mock tokens plus a TEE/proxy swap beat single-use virtual cards that still hand the agent something chargeable—but spend caps are not purchase judgment, and CAPTCHA, 3DS, and OTP still hand to a human.
Who this is for
You're letting an agent book travel, reorder supplies, or sign into a vendor site—and someone just asked for the card number or the password in chat. Or you're about to wire a checkout agent and the only options on the table are pasting secrets into the prompt, granting a single-use virtual card the model can still see, or hoping the vendor's "agent payments" story is enough.
Self Labs launched Agent Vault on October 15, 2026. It is a payment and login layer so agents can fill checkouts and sign-in forms without ever holding a real card number or password. The agent gets mock tokens. Real values are swapped in only inside Agent Vault's browser and Trusted Execution Environment (TEE), after your rules pass.
This review is for business owners and builders who will search "Agent Vault," "Self Labs agent payments," or "agent checkout without sharing card." It is not a merchant-readiness note—that problem lives in Agent-ready by default is a trap. It is also not the general authority framework in Agent checkout needs an authority card, or the Chrome Always-allow session grant in Always-allow in Chrome is a session grant. Those stay useful. Agent Vault is a portable vault that tries to keep secrets out of every agent's context at once.
What Agent Vault actually does
The product story is simple when you strip the launch language. You store cards, logins, and addresses in a dashboard. Your agent receives mock tokens—strings in a pattern like av_card_1_number_u7x2k. Those tokens are hollow outside an authorized Agent Vault session. The agent drives a browser that runs through Agent Vault's proxy and fills fields with tokens. At each fill, the proxy checks your rules, swaps the token for the real value, and types it into the merchant page. Logins fill only on the site they were saved for.
Agent Vault does not move money. The merchant sees an ordinary card payment. The merchant and the card issuer keep the financial record. That matters: you are not adopting a new payment rail; you are changing who is allowed to see the digits.
Integrations are built for agents people already use. The launch and docs name Muse, OpenClaw, Hermes, Grok Bot, Claude, and Codex, among others. Connection options include a hosted MCP server at https://mcp.agentvault.io/mcp, a self-run MCP package, a Playwright SDK (@agentvault/playwright) that replaces Playwright's Chromium so every browser action runs in the proxy, and an HTTP API for token catalogs and recipes when you are not driving the browser yourself. Merchant setup is not required; beta use covered logins and checkouts across sites such as Booking.com, Instacart, Roblox, Figma, Dropbox, Asana, Amtrak, Reddit, Apple, eBay, and Etsy.
Controls sit with the account holder. Per agent card you can set spending caps (per transaction, per week, and per rolling 30 days; a daily cap on Plus and Enterprise), block named merchants (allowlists on Enterprise), require approval above an amount you choose, and hit a kill switch that pauses all agents from the dashboard. Sessions idle out after 15 minutes; proxy sessions end after 60 minutes total.
Self's earlier argument against single-use virtual cards still frames the product: a short-lived real number in the agent's hands still leaves room for redirects and exfiltration. The vault keeps the chargeable number out of model context entirely. Mock tokens can leak; they should not charge anything outside a short, proxied window.
How the work moves
What to verify before you widen Agent Vault access
- One agent, one job
Name a single checkout or login with a done state and a person who can approve.
- Separate agent card
Issue one card and API key per agent; set per-txn and weekly caps below a wrong-buy cost.
- Merchant rules
Block unused sites; on Enterprise, allowlist only the pilot merchant.
- Force a denial
Trip approval threshold or kill switch and watch the dashboard and the agent.
- Force a handoff
Confirm CAPTCHA / 3DS / OTP still reaches a human on call.
- Then widen
Add agents or merchants only after the run report and revoke path are clear.
Mock tokens can leak. A real card number in the model should not.
Pricing as published
Plans are Free, Plus, and Enterprise. Public plan tables on agentvault.io show Free with one agent card and five payments per rolling month; Plus with five agent cards, a hundred payments, daily spend limits, and webhooks; Enterprise with unlimited agent cards and payments, plus merchant allowlists and priority support. Kill switch coverage is listed on every tier. Credentials are listed as unlimited across plans.
The Business Wire launch note offers the first 1,000 sign-ups free Agent Vault Plus for three months. Confirm current eligibility and billing screens at signup—promotional windows move.
Treat plan quotas as account limits, separate from the per-card spend caps you set yourself. Docs also publish request-rate limits on the token catalog by plan. If you are building a high-volume agent loop, read those before you assume Free is enough for a pilot.
Where it falls short
Agent Vault is honest in its own docs about what it does not do. It does not solve CAPTCHAs, 3-D Secure checks, or one-time codes. Those hand to a human on the live page. If your checkout path always trips 3DS, budget for that interrupt—do not assume the agent finishes alone.
Limits bound spend, not purchase selection. A compromised or confused agent can still buy within the caps and merchant rules you allowed. Caps are a blast-radius tool, not a product picker. If the agent can spend $200 at a merchant you allowlisted, it can spend $200 on the wrong SKU.
The vault also does not invent your authority matrix. Who may connect an agent card, who may raise a weekly cap, who approves above-threshold buys, and who owns the kill switch after hours—that is still your operating design. Pair this product with the questions in the authority card note rather than treating the dashboard toggles as a finished policy.
Portability across Muse, Claude, Codex, Hermes, Grok Bot, and OpenClaw is the point of a single vault. It is also a governance surface: every new agent you plug in inherits the same cards unless you issue separate agent cards and keys. Issue one agent card per agent before you connect, as the docs recommend. A shared card across five assistants is how a kill switch becomes a company-wide outage—or how a loose agent inherits more spend than you meant.
Finally, Agent Vault is not a merchant product. Merchants still see a normal card charge. If your problem is other people's agents hitting your storefront, that is a different stack—rate limits, bot signals, and the readiness questions in the agent-ready trap note.
Decision guide
Single-use virtual card vs Agent Vault mock token
| Consideration | Single-use virtual card (typical) | Agent Vault mock token |
|---|---|---|
| What the agent holds | A real (short-lived) card number that can still be charged if stolen from context. | A hollow token that only resolves inside an authorized Agent Vault proxy session. |
| Prompt injection / exfil | Leaked digits are still a payment instrument for the window they live. | Leaked tokens should charge nothing outside the proxy and short session window. |
| Where the secret appears | In the agent, logs, or model retention if the number was in context. | Swapped in TEE/proxy at fill time; agent context keeps the mock string. |
| Merchant experience | Ordinary card payment (issuer-dependent). | Ordinary card payment; Agent Vault does not move money itself. |
| Still your job | Caps, revoke, and which agent may hold the instrument. | Caps, merchant rules, approval thresholds, kill switch, and one card per agent. |
How to evaluate it in a week
Skip the all-apps tour. Run one bounded pilot:
- One agent, one job. Example: reorder a known SKU from one merchant, or renew one subscription, with a hard per-transaction cap below what a wrong buy would cost you.
- Separate agent card and API key. Do not reuse the personal card you also connect to a second assistant.
- Merchant rules first. Block everything you do not need; on Enterprise, prefer an allowlist for the pilot merchant only.
- Force one denial. Trip the approval threshold or the kill switch on purpose and watch what the agent and the dashboard do.
- Force one human handoff. Pick a checkout that will show CAPTCHA or 3DS and confirm the handoff path works for the person on call.
- Read the run report before you believe money moved. The product's own rules of engagement say the same thing.
If that loop is unclear, do not widen to travel booking, multi-merchant shopping, or shared team agents yet.
For teams already arguing about Chrome computer-use grants on signed-in profiles, keep the problems separate. Always-allow is about standing permission to drive an origin where sessions already live. Agent Vault is about keeping payment and login secrets out of the model when an agent must fill a form. You may need both disciplines. They are not substitutes.
Verdict
Verdict (October 15, 2026): Agent Vault is worth a serious look if you already run agents that must pay or sign in across sites, and you refuse to put real card numbers or passwords in model context. The mock-token plus TEE/proxy design is a clearer answer to prompt-injection theft than single-use virtual cards that still hand the agent something chargeable. Start on Free or the Plus promo with one agent card, tight caps, and a forced denial. Do not treat spend limits as purchase judgment, and do not skip the human path for 3DS, OTP, and CAPTCHA.
Alternatives still on the table: keep agents read-only and let a person pay; use a bank or Stripe-style virtual card knowing the agent may still see a real number; or build a narrowly scoped internal checkout agent with your own vault and audit trail when portability across consumer assistants is not the job.
We design and build AI applications and agents with bounded tools, visible state, and a human at the consequential write. When the agent is buying, the same discipline shows up in ecommerce flows—permissions and recovery are part of the product, not a settings afterthought. If you want a second pair of eyes on an agent-payments pilot—talk to us.
Related work: Spin:Market (agents).
We build alongside the people doing the work.
Bring us the problem you’re thinking about.