Four worked agent scenarios linked to one verified credential.

Worked examples

The five questions of Know Your Agent are easy to state and easy to fudge in the abstract. This page grounds them in five end-to-end scenarios, each traced through the canonical flow: the principal issues a scoped delegation, the agent presents a verifiable credential, the service verifies identity and authorisation at the point of action, the action is logged, and the delegation can be revoked.

Every scenario uses the same frame — the five questions KYA answers:

  1. Identity — what is this agent, technically?
  2. Principal — who is accountable for its actions?
  3. Authority — what may it do, for how long, up to what limits?
  4. Evidence — can it prove it is what it claims, and can actions be traced?
  5. Lifecycle — how is it onboarded, monitored and revoked?

The technical mechanics referenced below are detailed in the sibling guides: How to verify an agent, How to scope an agent’s permissions, Audit trails for agents, The agent identity lifecycle and Defending against agent spoofing.

1. Travel-booking agent

A personal travel assistant books a flight on the user’s behalf.

  • Principal: the traveller (a natural person with a loyalty account).
  • Delegated scope: create a booking on one account; HEL–BCN; economy; departure window 12–14 Nov; ≤ €1,200; single task; audience = the airline’s booking service.
  • Credential: a short-lived delegated OAuth token carrying actor = the travel agent, subject = the traveller, plus the scope. Bound to the agent’s key with DPoP, so the token alone is not enough.
  • Verification at point of action: the booking service checks signature, issuer, audience and expiry; verifies the DPoP proof against the token’s key; then checks this request (route, fare class, price) against the delegated scope. Price above €1,200 is refused, not silently truncated.
  • Audit record: agent identity, principal, mandate reference, action `bookings:create`, decision + reason, the flight and price, correlation ID for the whole trip-planning session, credential reference.
  • Revocation: the traveller cancels the mandate; the token is revoked at the authorisation server and, being short-lived, would expire anyway. The very next booking attempt is refused.

2. Procurement / invoice agent

A finance agent processes supplier invoices and, within limits, approves payment.

  • Principal: the company (a legal entity — this is where KYB still applies to the principal).
  • Delegated scope: read invoices; match to purchase orders; approve payments only where the invoice matches a PO and is ≤ €5,000; above that, request human approval. Audience = the ERP and the payment provider, separately scoped.
  • Credential: per-integration scoped tokens minted just-in-time; the ERP token cannot pay, and the payment token cannot read the full supplier master. Proof of possession for the payment leg.
  • Verification at point of action: the ERP checks the match; the payment service re-checks the amount, counterparty and approval state against the mandate. A payment just under €5,000 to a new counterparty trips an approval gate and a detection signal.
  • Audit record: actor (finance agent), principal (company), mandate, action `payments:approve`, matched PO reference, approval identity if gated, outcome, trace ID tying the invoice → match → approval → payment chain together.
  • Revocation: disabling the payment token stops the payment leg immediately; the read-only ERP token remains, so the agent degrades rather than losing all function.

3. Customer support agent

A support agent answers tickets and, where needed, issues refunds or changes account settings.

  • Principal: the platform (the deployer), acting for its own customers.
  • Delegated scope: read ticket and order data for the requesting customer only; issue refunds ≤ €100; cannot change payment methods, export data, or view other customers’ records. This is the confused-deputy boundary: the agent must act with the customer’s authority, not the support platform’s ambient rights.
  • Credential: short-lived token scoped per session and per customer; audience = the support backend. No standing token that spans customers.
  • Verification at point of action: the backend enforces that the resource belongs to the customer in the mandate — an object-ID from a message is treated as attacker-controlled until ownership is checked. Refunds above the threshold escalate to a human.
  • Audit record: actor, principal, the customer on whose behalf it acted, action, decision, and the ticket correlation ID. Because the agent reads untrusted text (the ticket), any ingested instructions are logged as data, not obeyed.
  • Revocation: a suspected prompt-injection incident disables the session identity; the next action is refused and the trace is reviewed.

4. Coding agent with CI access

A coding agent opens pull requests, runs CI and (sometimes) deploys.

  • Principal: the engineering organisation; the specific developer on whose behalf it works.
  • Delegated scope: read/write to one repository; trigger CI; no deploy without an approval gate; no access to production secrets; audience = the code host and the CI system.
  • Credential: workload identity for the agent (attested, short-lived, auto-rotated) rather than a static personal access token; the CI token is separate from the repository token.
  • Verification at point of action: the code host checks the workload identity and the repository scope; the CI system checks its own token’s audience; the deploy step is gated on human approval and on the merge having passed required checks.
  • Audit record: actor, principal (developer), mandate, tool calls (branch, commit, CI run), decision for the deploy gate, and the trace ID linking PR → CI → deploy. Provenance of any dependency the agent pulls is checked where it triggers a build.
  • Revocation: revoking the workload identity stops new CI runs and PR pushes; the deploy token, being separately scoped and short-lived, expires on its own.

5. Supervisory agent spawning a sub-agent

A research supervisor agent decomposes a task and spawns child agents for web retrieval.

  • Principal: the organisation running the supervisor.
  • Delegated scope: the supervisor may spawn children, but a child inherits a subset of the supervisor’s scope, never more, and each child expires with the task. Children get no authority to spend money or write to internal systems.
  • Credential: each child gets its own short-lived identity and a delegated token whose authority is a strict subset of the parent’s. Recursive delegation is carried in the token (actor chain), so the origin principal remains visible.
  • Verification at point of action: the tool server checks the child’s identity, its own audience, and that the requested action is within the inherited subset — not the supervisor’s full rights. This is where recursive delegation chains are supposed to be constrained.
  • Audit record: every child action logs the full actor chain (child → supervisor → principal) and a shared trace ID, so a retrieved-and-acted-on instruction can be attributed to the exact child that read it.
  • Revocation: revoking the supervisor invalidates the ability to spawn children; in-flight children die at credential expiry, and any child identity can be revoked individually.

Summary

ScenarioPrincipalKey scope limitPoint-of-action checkRevocation target
Travel bookingTraveller≤ €1,200, one route, one taskPrice vs mandateDelegation / token
ProcurementCompany≤ €5,000 + PO match, else approvalPO match + gatePayment token
SupportPlatform / customerOwn customer only; refunds ≤ €100Resource ownershipSession identity
Coding + CIDeveloper / orgRepo + CI, no deploy without gateWorkload ID + approvalWorkload identity
Sub-agentsOrganisationChild scope ⊆ parent scopeInherited subsetChild or supervisor ID

The pattern across all five: identity proves who the agent is; scope constrains what it can do; the point-of-action check enforces the scope; the audit record makes it explicable; revocation and short lifetimes bound the damage. Answer all five questions for a scenario and you have done KYA for it.

FAQ

Why do the examples always separate the actor from the principal?

Because that separation is what makes the action answerable. Delegation semantics (actor = agent, subject = principal) let a downstream service see both who acted and on whose behalf, and let an audit record be read from either direction. Impersonation erases the agent’s identity, and with it the ability to hold the specific agent to account.

Where do these scenarios differ from simple API integration?

The agent chooses its own calls at runtime, so you cannot rely on a fixed code path to limit what it does. That is why the examples lean on scope, per-action enforcement and approval gates rather than on “the integration only calls these endpoints”. The controls move from the edges of the system to the point of action.

Do the amounts and thresholds matter?

The numbers are illustrative, not advice. The point is that a scope should have explicit limits and a gate above them; pick values that reflect your risk appetite and any scheme rules that apply to the transaction type.

Not legal advice. Several scenarios touch regulated activity — payments, support and data access, employment-adjacent coding agent — where obligations (KYC/KYB, payment-scheme rules, data protection, human oversight of high-risk systems) apply to the principal or deployer. Treat these examples as technical references and confirm your obligations with qualified counsel.

Primary sources

Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.

Try the interactive demo: an agent books and pays for a train ticket — watch the delegation, the credential check, the audit log and the revocation.