SilvectorDocs
Silvector docsBy jobUpdated 2026-11-07

Job · Rung 2

Let AI shopping agents buy safely

Admit agents that can show who they are and who they act for, and step up before money moves.

For Head of growth and e-commerce, AI agent builders. Works at Rung 2 · Operational.

The situation

Business
A retailer or marketplace.
Use case
Customers send AI assistants to compare, fill carts and check out.
Risk
Blocking a real customer's agent loses the sale; admitting a hostile one invites abuse.
Today's failure
Bot defenses treat every agent as hostile, so the channel is blocked by default.
Silvector
Web Bot Auth verification of the agent, a delegation chain to the customer, and step_up before payment.
Evidence
A receipt with the verification verdict and the delegation, for each request.
Judged on
Agent-driven conversion and revenue admitted.

Steps

  1. Ask agents to sign their requests

    Agents that sign with Web Bot Auth publish their keys in a directory. Silvector checks the signature and records one of four verdicts: verified, verification_failed, not_verifiable or not_identified.

  2. Bind the agent to the customer

    An on-behalf-of chain such as seat:ada > agent:meridian names who the agent acts for. A chain that does not bind the agent to the seat is denied with rule deny.delegation_chain.

  3. Step up before payment

    A delegation to browse is not a delegation to pay. The public check endpoint's default policy allows a checkout with no agent claim (try it in the playground). On the identity path, rule stepup.assurance asks the person for a fresh second factor when the session is below the route's assurance; it runs only when the policy turns rel.identity_stepup on.

    sh
    curl -s https://api.silvector.com/v1/check \
  -H 'content-type: application/json' \
  -d '{"method":"POST","path":"/checkout"}'

  4. Check the receipt

    The receipt's verification and delegation fields say what was verified. Verify the signature with any of the quickstarts.

Guardrails

  • not_identified means no claim was made. It is not evidence of abuse; treat it with your default policy.
  • A User-Agent string is a claim, not an identity. Only a verified signature moves an agent to verified.

What works today

Signature verification, delegation-chain denial and receipts work today. The public check endpoint ignores signature fields in its JSON body; real verification runs on signed HTTP requests at the edge.

Every receipt this job produces carries this grade:

Evidence grade Rung 2 · Operational
Covers
Which rule decided this request and that the record was not changed after signing. Not whether the sender was an AI agent.
Confidence
None stated. No calibrated confidence applies to this record.
Calibration
Uncalibrated
Known error rates
None measured. Silvector publishes no detection error rate yet.
Basis
  • Deterministic decide() rule allow.default
  • Ed25519 signature over the canonical receipt body, checked against the published JWKS
Bias risks
  • The decision is only as good as the facts it was given. A request with no signature claim is not_identified, which is not a finding that a person or an agent sent it.
Next step
To ask who was behind a series of requests, keep the receipts and escalate to rung 3 with at least two independent signal families. How escalation works
Assigned by
These docs, from the rung definitions. The grade is not a signed field of the receipt.

Next

AgentDelegationNode quickstart