Verify AI Agent Traffic in the Support Queue: A Triage Table for Customer Agents, Bots and Humans

Two chat sessions open at 10:14. Both write in full sentences, both name a real order number, both answer in under two seconds.

One is a customer’s personal agent, set up last week to chase a late refund. The other is the fortieth session this hour from the same proxy range, cycling through account emails from a breach list. Your queue treats them identically, because until this month it never had to tell them apart.

To verify AI agent traffic at the support desk, you need two answers per contact, not one score: who operates this automation, and what, if anything, the account holder allowed it to do. This playbook gives you a support-queue agent triage table that turns those answers into four classes, each with a route, an action limit, a challenge rule, an escalation path and an evidence line. It ends with the signal list and a kill switch you can pull for one agent platform or for all of them.

Decagon’s Personal Agent Gateway, Oct 1: what it does and what it does not claim

On Oct 1, 2026, at its Dialogues event, Decagon announced the Personal Agent Gateway, one of four launches alongside Voice 3, Agent Modules and Duet Apprentice. It is a product, not a protocol. Per Decagon’s announcement post, it detects likely personal agents in live chat and voice, including ones that don’t announce themselves; routes self-identifying agents into a dedicated channel that sits beside chat, email and voice with its own procedures; and holds each agent to scopes the customer grants.

Screenshot: Decagon, “Personal agents are here. Meet them on your terms.” (Oct 1, 2026), captured Oct 7, 2026.

The detection signals Decagon names come from two places: from the business, “device fingerprints” and “account history”; from the CX platform, “conversational patterns” and “request cadence”. Decagon says detection “will keep improving”. The Business Wire release adds that the gateway authenticates the agent, restricts its actions and requires the human owner’s approval for sensitive actions, declining if the owner cannot be reached.

Verification runs on PACT, Decagon’s protocol open-sourced on Oct 6, not on the Personal Agent Protocol Meta and Sierra announced that day; the gateway post does not mention PAP. Under the PACT spec, the agent signs each request with a short-lived JWT checked against the platform’s published keys, and acts on an account only under a delegation token the customer granted by signing in with the business. That signature proves which platform is calling. It does not prove who owns the account; the customer’s own login does that.

Screenshot: Decagon, “Personal agents are here. Meet them on your terms.” (Oct 1, 2026, closing section), captured Oct 7, 2026.

What Decagon has not published matters as much for your planning. There are no detection accuracy or false-positive numbers, no general-availability or beta label, and no claim that the gateway rate-limits agents, and none had appeared as of Oct 8. Any rate limit in the table below is your own control.

The standards layer is younger than the launch copy around it. HTTP Message Signatures is a published RFC, RFC 9421, published February 2024. Web Bot Auth, the profile that uses those signatures to identify bots and agents, is not: the IETF webbotauth working group adopted draft-ietf-webbotauth-httpsig-protocol-00 on Sep 1, 2026, per the IETF Datatracker, still at -00 on Oct 8, and header names and key-directory formats have shifted between revisions.

At the edge, Cloudflare’s docs say “Signed agents are now Verified” and now classify them by “Direct” versus “Intermediary” access. We found no comparable personal-agent detection feature from Intercom, Zendesk, Salesforce, Genesys or NiCE as of Oct 8, though Meta lists Genesys and NiCE as Personal Agent Protocol partners; that is a search negative, not a confirmed absence.

Why a bot score cannot answer the support-queue question

Classic bot management asks one question, human or not, and blocks the “not”. That worked while every legitimate contact was a person. A customer’s personal agent is automation by design, so a strict bot score wrongly blocks it and a permissive one waves the credential stuffer through with it.

The fix is to split the question along the two layers the protocols already separate. Transport-level signing, the Web Bot Auth model, tells you who operates the bot. Application-level delegation, the PACT or PAP model, tells you what the customer allowed. Neither alone proves both, and the triage table needs both columns.

Which surfaces agents may use and which scopes exist is a front-door decision covered in the personal agent front-door register; this playbook assumes those answers exist and sorts live traffic against them.

The runbook: build and run the support-queue agent triage table

Six steps: collect signals, fill the table, verify in order, set limits, run the week’s numbers, and wire the kill switch.

Step 1: Collect the signals for every contact

Each signal lands on the contact record before any routing decision. The list below is grouped by what it can prove; nothing in the behavioural group proves identity on its own.

DECLARED IDENTITY (claims, cheap to fake alone)
  - agent self-declaration in the first message or voice greeting
  - agent card or User-Agent string naming a platform
  - platform name in a callback URL or reply-to address

SIGNED REQUESTS (proof of who operates it)
  - per-request agent JWT verified against the platform's published JWKS (PACT)
  - HTTP Message Signatures on the request, key from the operator's directory
    (Web Bot Auth draft; header names vary by revision)
  - delegation token on the request, issued by you after the customer signed in

BEHAVIOURAL TELLS (probability, never proof)
  - request cadence per session and across accounts from one network
  - conversational patterns: templated phrasing, zero hesitation, instant tool-like replies
  - device fingerprint vs the account's history
  - credential failures and account enumeration across sessions

The last line matters most. A personal agent works one account at a time, for one customer, and mostly succeeds; an attack works many accounts and mostly fails. Cross-account behaviour from one source is the sharpest tell you have, and it is yours to compute; no protocol hands it to you.

Voice is the hard channel. A phone call carries no request signature, so a voice agent’s declaration (“I’m an assistant calling for Dana”) is a claim and nothing more until something out of band confirms it. The workable pattern is to treat every declared voice agent as unverified, then let it reach the verified row only through a delegation the customer completes elsewhere: a sign-in link sent to the contact details already on the account, never to a number or address the caller supplies. Until that link is used, the call gets public answers and an offer to continue in writing.

Step 2: Fill the triage table, one row per class

Every contact lands in exactly one row. The thresholds and limits here are illustrative starting points, labelled as such; tune them against a month of your own traffic.

Class	How detected	Route	Allowed actions	Rate or challenge	Escalation	Evidence logged
Declared and verified agent	Signed request verifies against the platform’s keys, and a customer-granted delegation token is present and in date	Agent channel with its own procedures	Only the scopes in the delegation token; sensitive actions need the customer’s fresh approval	Illustrative: 30 requests per minute per grant; no challenge	Scope or signature failure to the agent-ops on-call; owner unreachable means decline	Platform, key ID, grant ID, scopes used, action, verifier result; receipt to the receipt ledger
Declared but unverified	Self-declares or names a platform, but sends no signature or no delegation token	Agent channel, guest mode	Public information only: policies, store hours, order-status lookup by order number without personal data; send the customer a consent link	Illustrative: 10 requests per minute per session; challenge after 3 account-action attempts	Repeated account-action attempts to trust and safety	Claimed platform, failure reason (no signature, no grant), actions refused
Undeclared automation, including hostile traffic	No declaration and behavioural tells cross your threshold (cadence, phrasing, fingerprint mismatch, cross-account pattern), or a signature that fails verification	Challenge, then human queue if passed	None on any account until challenge passes and the customer signs in	Failed signature: block and alert at once. Otherwise challenge on detection; block the source after illustrative 5 failed challenges or 3 accounts touched in an hour	Cross-account pattern pages trust and safety immediately	Signals that fired and their values, challenge outcome, accounts touched, source network
Human	No declaration, no signature, behavioural tells under threshold	Normal chat, voice or email queue	Your existing human policy	None by default; never challenge on speed alone	Existing escalation	Your existing contact record plus the classifier’s score, so misclassifications can be audited

Read the rows as a ladder of evidence. The top row has cryptographic proof of both operator and permission, and the second has a claim, or proof of the operator but not of permission. The third has only probabilities. The fourth is the default, and it stays the default: a fast typist, a screen-reader user or someone pasting from notes should never need to prove they are human to get help.

“Its own procedures” in the top row is worth taking literally. An agent channel does not need greetings, empathy scripts or satisfaction surveys; it needs structured answers, explicit refusals with a reason code, and a hard timeout when an owner approval does not come back. Write those procedures down separately from the human playbook, because the failure you are guarding against is different: a human gets frustrated and leaves, an agent retries forever. The consent link offered in the second row hands off to the grant flow your front door already defines; the queue only sends it.

Step 3: Verify in a fixed order, and record where it stopped

Run the checks in the same order every time so the evidence line tells you exactly where a contact fell out.

One path for every contact. The log records where verification stopped, which is what makes misclassifications auditable.

An illustrative classifier policy:

triage_policy: support-queue-v1   # illustrative
order:
  - step: transport_signature
    check: verify request signature or agent JWT against operator keys
    on_fail: class=undeclared_automation, reason=bad_signature, action=block_and_alert
    on_absent: continue
  - step: delegation
    check: delegation token issued by us, unexpired, for this account
    on_fail: class=declared_unverified, reason=no_grant
    on_pass: class=declared_verified
  - step: behaviour
    signals: [cadence, phrasing, fingerprint_vs_history, cross_account]
    threshold: 0.7              # illustrative score
    on_over: class=undeclared_automation
    on_under: class=human
log_fields: [contact_id, channel, class, stopped_at, reason, key_id, grant_id, signals]

Two rules keep the order honest. A valid signature never skips the delegation check, because a verified operator acting with no customer grant is still a stranger on that account. And a passed behavioural check never upgrades anyone to the top row; only signatures and grants do that.

Your own agents already pass a stricter version of this test as named principals, the pattern in agent identity through service principals and SSO. Inbound agents earn the same treatment only when they bring the same proof.

Step 4: Set the limits as your own controls

The gateway announcement makes no rate-limiting claim, and the draft protocols do not set one, so every number in the “rate or challenge” column is yours. Set them per grant for verified agents, per session for unverified ones and per source network for undeclared automation, so a single compromised grant cannot drain a queue and a single proxy range cannot rotate through accounts. On voice, the equivalent limit is concurrent calls per declared platform, since one platform placing fifty simultaneous calls can tie up a phone queue faster than any chat flood.

Keep challenges out of the human row. A challenge is a cost you impose on suspected automation; imposed on a person, it is a support failure. Give every challenge a no-challenge fallback, such as a callback or an email thread, so a misclassified human still gets an answer.

Step 5: Run the week’s numbers before you trust the table

Worked scenario (illustrative numbers). A mid-size retailer’s support desk takes 10,000 contacts in one week after turning on classification. A review at the end of the week sorts the log by what each contact actually was: 8,600 humans, 450 declared and verified agents, 300 declared but unverified agents and 650 undeclared automation sessions. The chart shows how each class was handled, mistakes included.

Illustrative week of 10,000 contacts: share of each class by response. Modeled numbers, not vendor data.

Read it class by class.

Of the 450 verified agent contacts, 396 were served in the agent channel, 36 hit a limit and 18 escalated, mostly owner approvals that timed out. Of the 300 unverified, 90 got public answers, 135 were held to guest limits, 60 were challenged after repeated account attempts and 15 escalated.

Of the 650 undeclared, 65 cleared the challenge and reached the human queue as ordinary contacts, 163 were rate-limited, 357 were challenged and failed or abandoned, and 65 tripped the cross-account rule and paged trust and safety. Of the 8,600 humans, 86 were challenged, which is 86 too many: each one is a person the classifier mistook for a script, and each one gets reviewed.

The numbers to watch weekly are three: the share of contacts per class, the human challenge rate, and the count of unverified agents attempting account actions. A rising unverified share usually means a popular agent platform has not adopted signing yet; send its customers the consent link rather than tightening the screws.

Pair the meter with a hand review. Each week, pull 25 random contacts per class and have someone who did not tune the classifier read the transcripts and evidence lines. Every human found in the automation row and every script found in the human row becomes a labelled example for the next threshold change. Without that loop, thresholds drift toward whatever produced the fewest complaints last week, which is rarely the same as whatever stopped the most attacks.

Step 6: Wire the kill switch at two levels

You need two switches, both testable in minutes:

KILL SWITCH 1: block one agent platform
  1. add the platform's key IDs to the verifier deny list (signed requests now fail)
  2. its contacts fall to declared_unverified: public info only
  3. revoke open delegation grants for that platform; record revocation time
  4. notify affected customers through your own channel, not through the agent

KILL SWITCH 2: fall back to human-only
  1. close the agent channel; every contact routes to the human queue
  2. account actions require a signed-in human session
  3. undeclared-automation challenges stay on
  4. post a status note; reopen per platform after review

Time both in a drill each quarter. If blocking one platform takes longer than a coffee, it is a ticket, not a switch.

Name who may pull each switch before you need it. Switch 1 belongs to the trust and safety on-call, with an illustrative trigger of verified contacts from one platform doubling inside an hour while delegation failures rise; switch 2 belongs to the support director, because closing the agent channel moves real customers back into a human queue that may not have the staff for them. Write the trigger, the owner and the reopen condition into the same runbook page as the table, and log every pull with the evidence that justified it, so the platform conversation afterwards starts from data rather than from a complaint.

How the support-queue triage table misroutes

What breaks	Signal you would see	First action
A verified agent platform’s signing key leaks	Declared-verified contacts from one platform spike across many accounts, with failed delegation checks	Pull kill switch 1 for that platform; rotate trust only after the platform confirms the new key
A draft revision renames headers and your verifier stops matching	One platform’s verified share drops to near zero overnight while its volume holds	Accept both header versions for a transition window; check the working-group draft revision
Humans are misclassified as automation	Human challenge rate rises; abandonment after challenge; accessibility complaints	Lower the weight on speed and phrasing; widen the no-challenge fallback; review a sample by hand
Unverified agents act as if signed in	Account-action attempts from the declared-unverified class	Hard-deny account actions without a delegation token; send the consent link
Undeclared automation learns your thresholds	Cadence clusters just under your limit across many sessions	Score cross-account behaviour per network, not per session; rotate thresholds
The agent channel becomes a backdoor to human agents	Escalations from the agent channel ask humans to do what scopes refused	Escalation inherits the agent’s scopes; human overrides need the customer, not the agent

The last row is the one that hurts quietly. An escalation path that lets a refused agent ask a person to do the same thing turns your best-behaved human agents into the weakest control in the system.

Inbound agents get the same test as your own fleet

The identity, scope and evidence test you run on your own agents, the discipline behind treating agents as privileged users, is the same test that decides whether an inbound agent is a customer or an attack. The difference is only who issued the identity. Your own agents get theirs from you; a customer’s agent brings one from its platform and earns scope from the customer, and the table records both.

That symmetry is why the triage view belongs in the same place you watch your own fleet, the argument of the multi-agent command center: one screen for which agents are acting, under whose authority, with what evidence. The direction has also flipped since agents started classifying your product for buyers; now you are the one classifying them. Consent mechanics for the verified row stay where they live, in the fail-closed consent test matrix.

FAQ

How do you tell a customer’s AI agent from a bot attack in support?

Ask two questions per contact: does a signed request prove which platform operates the agent, and does a customer-granted delegation token prove what it may do? Both yes means serve within scope. Behavioural tells such as cross-account cadence flag undeclared automation; they suggest, but never prove, identity on their own.

Is Web Bot Auth an official standard?

Not yet. Web Bot Auth is an IETF working-group draft; the group adopted its protocol draft on September 1, 2026, and header names have changed between revisions. The signature mechanism underneath, HTTP Message Signatures, is a published RFC, RFC 9421. Build verifiers that tolerate revisions until the draft becomes an RFC.

Does Decagon’s Personal Agent Gateway rate-limit AI agents?

Decagon has not said so. Its Oct 1 announcement and release describe detection in chat and voice, a dedicated agent channel, customer-granted scopes, owner approval for sensitive actions and PACT verification. No rate-limiting, accuracy or availability claims are published, so any limits in your triage table are your own controls.

Sources

• Decagon: Personal agents are here. Meet them on your terms. (Oct 1, 2026)
• Decagon: Dialogues 2026 launches (Oct 1, 2026)
• Business Wire release via Webull: Decagon unveils AI for the era of personal agents (Oct 1, 2026)
• PACT: Specification (PACT 1.0, read Oct 7, 2026)
• Cloudflare Docs: Signed agents (updated Jul 1, 2026)
• IETF Datatracker: webbotauth documents (working-group documents; draft-ietf-webbotauth-httpsig-protocol-00, Sep 1, 2026)
• RFC Editor: RFC 9421, HTTP Message Signatures (Standards Track, February 2024)