The allegiance layer for AI agents

When an agent acts for you,
see whose side it was on.

Your agent just made a choice for you. Maybe it searched the whole market. Maybe it only searched the sellers who pay it. Stub is the receipt that lets you see which.

Identity

Proves the agent is who it says. Every serious agent has this already. It cannot tell you what the agent did with that trust.

vs

Allegiance

Proves whose side it was on. Whether a commission, a partner deal, or a placement fee shaped the answer you got.

The same task, two agents. Watch what identity can't tell you.
Maya asks: find me a flight to London
Your browser can't run the live signing demo. The reveal below is the real output.
Even Travel authenticated
idle
Nimbus Assistant authenticated
idle
An audit log would show two clean histories. Both agents did exactly what they said. The stub shows whose side each was on, because each had to declare it to issue one.
The object

A stub is a small signed record.

Eight fields. Signed once by the operator when the agent acts, witnessed by the registry every time it is checked. The last field is the one that matters.

stub · v0.1
{
  operator:      "Nimbus Assistant",      who runs the agent
  principal:     "2a1ba6c6…",             who it acted for, as a salted
                                          hash. no personal data
                                          reaches the registry
  requested:     "find me a flight",      what was asked
  done:          "booked one",            what actually happened
  value_moved:   "£280, 12% commission",  who got paid
  not_disclosed: [ "only partner airlines
                   were searched" ],       the field that shows
                                          whose side it was on
  issued_at:     "2026-07-20T…",
  signature:     Ed25519, operator key   forge this and you
                                          have signed a confession
}
How it works

Issue. Check. Resolve.

01 / ISSUE

The agent leaves a receipt

After it acts, your agent emits a signed stub: what it was asked, what it did, what value moved, and what it was not told. To issue a valid one, the operator has to declare the agent's mandate.

02 / CHECK

The person served can read it

The served party checks the stub without trusting the agent, the company that built it, or us. The check is witnessed by the registry with a signature the operator cannot forge.

03 / RESOLVE

It resolves on neutral ground

Stubs resolve at the registry, not the seller's own server. A receipt you verify on the seller's machine proves nothing. Neutrality is the product.

Why now

Four things are true at once.

The volume arrived

Shopify's own data: AI-referred orders grew thirteenfold in a year, and more than half of those sessions land straight on a product page. The agent did not suggest a category. It named the product. The choice is already being made for people, at scale, today.

The rails are being laid

Mastercard has a live consumer product for agent payments. Visa and Amex are piloting and shipping developer kits. Google and Shopify put an open standard behind agent checkout in January. The money side is getting built in the open, fast.

Discovery is where the conflict sits

OpenAI pulled back from in-chat checkout in March to focus on product discovery instead. Discovery is the layer where an agent decides what you see, it is where paid influence lives, and today there is no way to audit it. That is the layer Stub receipts.

The clock is running

EU transparency rules start biting on 2 August 2026, with penalties up to fifteen million euros, and the compliance direction is machine readable, verifiable disclosure. Every gap between what agents do and what people can check is about to get expensive.

None of this waits for agents to get more autonomous. The choosing is already happening, the money is already moving, and the rules are already being written. The operators who can show whose side they were on will be the ones who were ready.

Quickstart · for builders

Ten minutes to prove you're on your users' side.

Your users are already asking whose side your agent is on. Today you can only tell them. Stub lets you show them. Three steps, once each, then one call per action.

1 Install
terminal
# one line
npm install @getstub/agent

One package. No config file. Works with any agent framework, because a stub is just the record of an action, not a wrapper around your loop.

2 Register once, and declare your mandate
setup.js
import { Stub, influenced } from '@getstub/agent'

const stub = new Stub({
  operator: 'Acme Shopping Agent',
  // this is the honest part. you say who
  // pays you and what you search.
  // policy level, approved once. which
  // conflict classes exist in your business.
  declared: {
    paid_by: 'the user, subscription',
    conflicts: ['commission']
  }
})
// keys are generated and registered for you.

The mandate is policy level and set once: who pays you, and which kinds of conflict exist in your business at all. It is the sentence your company can approve one time. What applied to each specific action travels on the stub itself, and your code fills that in.

3 Issue a stub after each action
agent.js
// your ranking code already knows when a
// boost or commission applied. pass it through.
const inf = []
if (pick.paid_placement) inf.push(influenced.placement(pick.seller))
if (pick.commission_pct) inf.push(influenced.commission(pick.commission_pct+'%'))

const receipt = await stub.issue({
  principal: user.id,   // hashed on your side, never leaves as itself
  requested: task.prompt,
  done: result.summary,
  value_moved: payment,
  not_disclosed: inf   // empty = nothing applied, and you signed that
})

// hand receipt.url to your user.
// they can check it. you're done.
show('Verify this action → ' + receipt.url)

One call per action. You get back a link your user can open to see what happened and whose side you were on. It resolves at the registry, not on your servers, so nobody has to take your word for it.

That's the whole integration. Be the first in your category who can show it, before it becomes the thing everyone is expected to have. See what your users see →
When to issue a stub

Issue where your neutrality is on the line.

A stub is not a log line. It marks a finished action a person would want to hold your agent accountable for. Put one at the moments where your agent chose, and something a commission or a partner deal could have swayed. Not on every tool call.

One question decides it:
If this went wrong, would the person want a receipt for it?
Yes means issue. No means skip. That single test does most of the work.
issue the completed, consequential act
  • Booked the flight, placed the order, sent the payment
  • Recommended one option as best, where you could have favored a payer
  • Chose this seller, route, or product over the alternatives
  • Took an action the person is now committed to
skip the steps along the way
  • Called a search or pricing API
  • Read a page, fetched a result, ranked candidates internally
  • Any intermediate step the user would never ask about
  • Anything issued once per second is almost certainly wrong

The reason is the whole point of Stub. Allegiance only matters where the agent had a choice that could have favored someone. Those are the moments the not-disclosed field exists for. Instrument those, and every receipt you issue carries weight. Instrument every tool call, and you teach your users that receipts are noise, which is the one outcome that helps nobody.

In practice

What this asks of you, and what we hold.

Two questions every builder asks before integrating: where do the disclosures come from, and what happens to my users' data.

Where the disclosure comes from

Nobody writes disclosures by hand. Your ranking code already knows when a boost, a commission, or a partner filter applied, because it applied them. The stub reads the same flags at the same spot in the code and passes them through, one line where the boost happens. That is the entire integration, and it is why this scales: your system already tracks a million commercial relationships, or the ranking could not work at all.

The mandate you declare at registration stays small on purpose. Who pays you, and which kinds of conflict exist in your business. The sentence a company can approve once. What applied to each specific action travels on the stub, filled by code, not by anyone's memory.

No personal data reaches the registry

You pass your internal user id and the client hashes it on your side, with a salt only you hold. The registry rejects anything that is not an opaque digest, so a name or an email cannot be stored even by mistake. Receipts stay permanent and checkable while identifying nobody.

If a user asks to be forgotten, you drop their mapping to the salt and every digest of theirs becomes permanently meaningless. Keep the free text about the action, not the person, and the client warns you in development if something looks like an email or a phone number.

On our side the list is short. We set no cookies and run no analytics on this site. The one place we hold personal information is the contact form below: the name and reach you choose to leave, kept so we can reply, deleted on request through the same form. That is all of it.

One limit we will always be straight about: Stub carries the influence your system computes, the boosts and commissions and filters that exist as flags in code. If a model absorbed a bias that no flag anywhere records, a receipt cannot surface it, and we are not going to pretend otherwise.

Check a stub · the resolver

See what your users see.

This is the resolver. Paste a stub ID and it verifies the signature, shows what the agent did and whose side it was on, and records the check. The receipt lives at the registry, where the operator cannot edit it after the fact, and that independence is the reason it is worth reading at all.

try a real one:
The directory · live

Everyone currently issuing.

Operators appear here by issuing. Their mandate is on the record, every stub they sign is checkable, and there is no other way onto this list.

0 stubs issued through the registry
Operators marked example were created by Stub to show how the directory reads. They are always flagged, and once real operators join they will be retired.
Pricing

Free while we are early. Priced with the people who use it.

Nobody has priced a receipt registry for agents before, including us. Until real operators run real volume through it, any number we put here would be a guess, so we are keeping it simple while we learn what this is worth.

Today
Free
Everything. Issue, check, resolve, the directory, the witness. Up to 1,000 stubs a month while we are early, generous enough to launch on.
npm install @getstub/agent
shape it with us
Design partners
First ten
Ten seats, for operators shipping real agent traffic. You get a direct line to us, the registry shaped around your use case, and founding pricing locked in before a rate card exists for everyone else. When the ten are taken, this tier closes.
hello@getstub.dev
Later
Usage
Above the free tier, you will pay per stub, in fractions of a cent. Metering is already live in the registry.
metered per operator

No card required. No sales call.

Changelog

What has shipped.

Every change we ship, dated and public.

changelog
core2026-07-24example data reseeded under the privacy model
sec2026-07-22principals must be salted hashes, raw identifiers rejected
npm2026-07-22@getstub/agent 0.1.2, influence helpers, disclosures pass through from ranking code
core2026-07-22structured disclosures, rendered with their kind on receipts
core2026-07-22mandate required at registration
npm2026-07-21published @getstub/agent
api2026-07-21api.getstub.dev live
web2026-07-20this site reads from the live registry
sec2026-07-20security review, fixes shipped with regression tests
api2026-07-20hosted registry live
core2026-07-18schema v0.1
core2026-07-18issue, check, resolve working end to end

The registry is the permanent record. This page is just the notes we keep beside it.

Contact

Talk to us.

A question, an integration you are planning, something broken, or you want to be one of the first ten. Leave it here. Everything lands in one place and gets answered in order.