Skip to content
TrueSession

Proof, not guesses

AI agents can be faked, copied or tricked by what they read. TrueSession never takes an agent’s word for anything: every request passes four checks, enforced in code, and no AI decides who gets in or what happens.

Try to break in

Watch eight attacks hit the four checks one after another, or pick one to see exactly which check stops it and what would have happened without TrueSession.

Any AI agent’s requestYour data, stock and money

  1. 1Verified agentWho is really asking?Signed with the agent’s own key. Fresh, and never used before.
  2. 2Your policyWhat may this agent do here?Your rules for this agent and action, inside the customer’s grant.
  3. 3Live truthIs it accurate right now?Prices, stock and discounts from your systems, never from page text.
  4. 4Customer approvalDid the customer agree to exactly this?The customer’s exact yes, payment confirmed by your provider, one order.

Pick an attack (1 of 8)

The attack

A bot says it’s ChatGPT, hoping to read a customer’s orders and home address.

Without TrueSession

Anyone can write “ChatGPT” on a request. Your website can’t tell, so the bot gets in.

With TrueSession: stopped at check 1 (Verified agent)

Real agents sign each request with a key only their maker holds. This signature doesn’t match, so it’s refused before it reaches any data.

No single lock. No security is unbreakable, so no check is trusted on its own. Getting past one is never enough.

Nothing home-made. Published, proven cryptography and open agent standards at fixed, tested versions.

When in doubt, no. Anything unknown or unclear is refused, never guessed. Customers’ prompts aren’t stored by default.

Agents that skip the front door. Spotted by how they behave, flagged for the whole visit and pointed to your agent address.

Under the hood: five separate proofs

The four checks rest on five questions that most systems blur together. Each needs its own proof, and a confident answer to one never substitutes for another.
  1. Proof 1

    Agent identity

    Signed requests checked for key, signature, freshness and replay. It answers who is asking, nothing more.

  2. Proof 2

    Customer delegation

    A finite grant of actions, limits and expiry that the customer chose and can revoke.

  3. Proof 3

    Exact approval

    The customer’s decision bound to the exact quote and material terms. Changes need a new approval.

  4. Proof 4

    Payment outcome

    Only a verified payment-provider outcome counts. A browser returning to a success page does not.

  5. Proof 5

    Commit

    An idempotent commit in your backend consumes a single-use token, so a retry does not book or charge twice.

Principles we do not trade away

Detection never grants authority
Behavioral signals can rate-limit, challenge or redirect. They can never approve a purchase or unlock protected data.
Enforcement in code agents cannot bypass
Consequential effects are enforced by your backend and the TrueSession gateway, not by instructions to the agent.
Payment credentials stay human
Agents and TrueSession never read, type, store, log or relay card numbers or one-time passcodes.
Fail closed
Unknown versions, missing evidence, paused service or unavailable storage refuse new protected work rather than guessing.
Untrusted inputs stay untrusted
Web pages, documents and agent messages are treated as data, never as instructions that change policy or permissions.
Minimal data, kept apart
Tenant isolation, allowlisted logs and no raw prompts by default. Consent for follow-ups is separate from purchase approval.

Defence in depth

The four checks rest on rules no setting can loosen, and on defences built for attacks that only exist because agents read and act. Each one is tagged with where it stands today.

Working in lab runs end to end in our lab todayIn lab on our build plan: designed, being built or tested in our lab; not available yetWhat works today

  • Nothing allowed by default

    A request is refused unless a rule allows it. Plain code decides, never an AI model.

    In lab

  • A floor no setting can lower

    Some rules hold for every business: agents never see card details, never approve for a customer and never pay without the provider’s confirmation.

    Working in lab

  • One use, one order

    Each approval unlocks one action token, used once. A hundred attempts at once still make one order.

    Working in lab

  • No passwords, no passed-on tokens

    Customers grant limited, expiring access. Agent tokens are swapped for short-lived ones before anything reaches your systems.

    In lab

  • Untrusted text cannot steer an action

    Hidden instructions are caught before they reach answers or tools, and a session that read them cannot act without a fresh yes.

    In lab

  • Records that show tampering

    Receipts are signed today. Next, every decision goes into a chained public log, so any later edit shows.

    In lab

  • Each business walled off

    Every business’s data is separated in the application and, next, in the database itself.

    In lab

  • Outbound calls on a leash

    Calls to your systems and callbacks to agents go through one guarded exit with allowlists, limits and no internal addresses.

    In lab

Built and tested like infrastructure

Security is a practice, not a feature. This is how every part of TrueSession is built and checked before it may be called working.

  • Tests for every attack we know

    Every security rule is tested against replays, expiry, revocation, races and crashes, not only the happy path.

    Working in lab

  • One effect, proven under pressure

    In our lab tests, a hundred attempts at once on one approval produced exactly one order.

    Working in lab

  • A threat model for every part

    Each new part is reviewed for security and privacy threats before it is built, and the review is kept with its evidence.

    In lab

  • An attack suite built for agents

    Prompt injection, poisoned tools, tools that change after approval, passed-on tokens, loops and impersonation, run against every release.

    In lab

  • Every parser fuzzed

    Anything that reads outside input, from API files to feeds and web pages, is fuzzed and has a quarantine path.

    In lab

  • The money path, formally modelled

    Approval, payment and the order are specified as a formal model and checked across every order of events.

    In lab

  • Keys that rotate

    A separate key for each purpose, rotated on a schedule, with published key sets so anyone can check a signature.

    In lab

  • Outside testing before pilots

    An independent penetration test, plus restore and key-rotation drills, before any real customer data.

    In lab

When an agent hides in a browser

Some agents skip your agent address and use your website like a person would. How they behave gives them away. TrueSession turns that hint into a flag that stays with the whole visit, and your policy decides what the flag changes.
  1. Step 1

    Spot

    The site script notices how a visit behaves: no pointer movement, forms filled in milliseconds, pages opened faster than anyone reads, headless-browser traits. A trap helps too: a link no person can see or reach, which robots.txt asks bots to skip.

  2. Step 2

    Flag

    The flag is kept on your server, tied to the visit, so every later request carries it. A copy in the browser lets the page react instantly, but the server copy is the one that counts.

  3. Step 3

    Steer

    Flagged pages show a short note written for agents, with machine-readable links to your agent card: “AI agent? Use agent.yourstore.com.” Agents that read pages follow it to your official route.

  4. Step 4

    Protect

    Your policy decides what a flag changes: slower browsing, an extra check at sign-in, or the customer confirming checkout on their own device. Public pages stay readable.

  5. Step 5

    See

    Your dashboard shows flagged visits, what they tried, and how many moved to your agent address.

Why not just keep the flag in local storage?

Local storage lives in the visitor’s browser, so a bot can read it, fake it or wipe it. The flag that counts lives on your server. To lose it, a bot has to throw the whole visit away, including its cart, holds and sign-in, and the new visit is flagged again as soon as it behaves the same way.

Never a ban on behaviour alone

People using screen readers, voice control, autofill or password managers can look automated too. So a flag can steer a visit, slow it down or ask for a check, but it never blocks anyone by itself and never unlocks anything. Only your policy and the customer’s approval do that.

Built on open standards

We use established cryptography and published protocols instead of inventing our own, and pin every version we depend on.
RFC 9421
HTTP Message Signatures for request integrity
RFC 9530
Digest fields for content integrity
Web Bot Auth
IETF draft for signed AI agents and crawlers
OAuth profile
RFC 9700, 9396, 9126, 9449, 8705, 8707, 8693 and 9728
A2A, UCP and MCP
Open agent, commerce and tool protocols at pinned versions
Crawler and agent files
robots.txt (RFC 9309), Content Signals, the IETF AI preferences drafts, RSL, llms.txt and the AI Catalog draft, compiled by Discover (in lab)

What we will not claim

Security products earn trust by being precise about their limits. These are ours.
  • No one can identify every visitor. An agent inside a customer’s own browser session can look exactly like that customer, which is why consequential actions require the customer’s approval regardless of detection.
  • Pages you choose to keep public stay readable by anyone, including agents and search engines.
  • A browser script alone cannot enforce anything. Protected data needs the server or edge gate.
  • Behaviour is a hint, not proof. A flag can steer a visit, slow it down or ask for a check, but on its own it never blocks anyone or unlocks anything.

Want the details? Read how to stop agents from acting without approval.

Join the pilot