Agent Identity and Verification: Knowing the Sender Is a Legitimate AI

A refund request lands at 3:47 a.m. It cites the order number, quotes the correct clause of your returns policy, and asks for £89.40 back to the original card. It is polite, well-formed, and written by software acting for someone who may or may not own that account.

Three questions wearing one costume

Most support teams ask a single question about inbound agent mail: is this legitimate? That question is doing far too much work. It's actually three, and they fail independently.

• Authentication. Is the sender the agent it claims to be, or something wearing its name?
• Delegation. Does that agent genuinely act for the account holder whose order it's asking about?
• Authorisation. Even granting both of the above, is it allowed to request this specific action?

An agent can pass the first and fail the second. A perfectly authenticated, properly delegated agent can still be asking for something well outside its remit. Collapsing the three into one gate is how you end up refunding a stranger.

What SPF, DKIM and DMARC actually prove

Start with what you already have, because it's more than nothing and less than people assume.

DKIM proves the message left a server holding the private key for a domain, and that the signed headers and body weren't altered in transit. SPF proves the sending IP was on that domain's permitted list. DMARC ties both back to the domain a human sees in the From field and tells receivers what to do when alignment fails.

All three operate on domains. None of them operate on people.

An agent sending from assistant.example-ai.com passes DMARC identically whether it's acting on a customer's explicit instruction or trawling a mailbox it shouldn't have access to. Worse, when agents run on a shared platform, a DMARC pass on the platform domain tells you the platform sent the mail. It says nothing about which tenant, which end user, or whether that tenant is in good standing.

Email authentication is the floor. Treat a DMARC failure as disqualifying and a DMARC pass as the beginning of the conversation.

Signed agent cards, and what a signature buys you

A2A reached v1.0 in April 2026 with signed Agent Cards as part of the spec, and by mid-year the protocol had over 150 production organisations behind it. The Agent Card is a JSON descriptor published at a well-known path: who the agent is, who operates it, which endpoint it speaks on, which authentication schemes it supports, and which skills it claims. Our explainer on A2A and MCP for support leaders covers the wider protocol picture.

Signing wraps that descriptor in a JWS. Verification is four checks:

1. Signature validity against a key published at the issuer's JWKS endpoint, fetched over TLS and cached with a sane TTL
2. Domain alignment between the card's issuer and the domain that just passed DMARC on the email itself
3. Freshness: the card hasn't expired, and you're not serving a six-month-old cached copy
4. Capability match: the skills the card declares actually cover what this message is asking for

What you get from that is continuity. This is the same agent that emailed you last Tuesday, so reputation can attach to it: resolution rates, escalation rates, injection attempts, refund reversal rates. That's genuinely valuable, and it's the foundation for treating known agents differently from unknown ones.

What you don't get is honesty. A signature proves origin, not intent. A well-signed agent operated by a fraud ring is a well-signed agent. If you're on the other side of this problem and publishing a card of your own, designing an agent card for your support organisation goes through what to declare and what to withhold.

Delegation is the part that actually matters

The claim you care about isn't that this is Agent X. It's that Priya Nair authorised Agent X to act on her account, for these actions, until this time.

That's a delegation problem, and OAuth already has the shape of an answer. RFC 8693 token exchange defines an act claim precisely for this: a token that names both a subject and an actor operating on the subject's behalf. A usable delegation token for support email carries:

• Subject: the account holder, expressed as an identifier you can resolve against your own customer records
• Actor: the agent identity, matching the agent card you just verified
• Scope: narrow and action-specific. Read order status is not initiate refund
• Audience: your support endpoint, so a token minted for someone else's helpdesk doesn't work on yours
• Expiry: minutes and hours, not months
• A JWT ID for replay detection

The subject field is where teams get sloppy. If the token says the account holder is priya@example.com and you accept that as identity, you've delegated your identity resolution to whoever minted the token. The subject has to map to a customer record you control, through a binding the account holder established while authenticated to you. Anything less and the agent is simply telling you who its user is, which is not verification.

Email is a poor place to put a credential

Here's the genuinely awkward bit. Email is forwardable, archived indefinitely, frequently plaintext at rest, and copied into ticket systems, analytics pipelines and Slack channels. A bearer token in a message body is a bearer token in a hundred mailboxes, and it stays valid until it expires.

A credential you can copy-paste out of an inbox is not really a credential.

The pattern that holds up better: the email carries a short, single-use reference, and your system resolves it out of band. You call the agent's declared endpoint, or a token introspection endpoint, over TLS, and get back the delegation claims. The email becomes a pointer rather than a bearer instrument. It costs you a round trip and buys you a credential that can't be replayed by anyone who later reads the thread.

A verification ladder you can build this quarter

Rather than a binary trusted or untrusted flag, tier the trust and attach automation privileges to each tier. This is the design we'd argue for, and it has the practical advantage that you can ship tier one on a Tuesday and add the rest over months.

1. Tier 0, unverified. No agent signals at all, or DMARC fails. Handle exactly as you'd handle any anonymous inbound email. No account data disclosed, no actions taken.
2. Tier 1, domain authenticated. DMARC passes and the domain is known. You can safely answer generic policy questions. You cannot disclose anything account-specific.
3. Tier 2, agent identified. A signed agent card resolves and aligns with the sending domain. Now reputation applies, rate limits can be per-agent rather than global, and you can hold a structured conversation about what the agent needs.
4. Tier 3, delegation verified. A valid, unexpired token binds this agent to an account holder you can resolve internally. Read access to that account's data unlocks: order status, invoice history, shipment tracking.
5. Tier 4, action authorised. The delegation scope explicitly covers the requested action, and the action falls inside your own policy limits for autonomous handling. Refunds, address changes, plan modifications and cancellations live here and nowhere lower.

The value of the ladder is that failure degrades instead of collapsing. An agent that can't produce a delegation token doesn't get rejected. It gets a tier 1 response explaining what's needed, which is a far better customer experience than silence or a bounce.

Most agents won't have a token, and you still have to answer them

The ladder above describes where this ends up. Today, the overwhelming majority of agent email arriving in support queues carries no delegation token at all, because the customer set up an assistant with mailbox access and never touched an authorisation flow. Refusing all of it is not a policy, it's an outage.

The fallback that holds up is out-of-band confirmation, and it's older than any of this protocol work. When an unverified agent requests something account-specific, you don't reply to the agent with the answer. You send a confirmation to the channel the account holder has already verified with you, and you make it cheap to approve.

The shape that works in practice:

• Read requests on low-sensitivity data: answer in the thread, because the blast radius of getting it wrong is a shipping date
• Read requests on sensitive data: answer to the account holder's verified address, not to the sender, with the agent copied only if that address is the same mailbox
• Any write action: a one-tap confirmation to the account holder's app or verified address, with the specific action and amount spelled out, expiring in an hour
• Anything irreversible: a human on your side, regardless of what confirmation came back

This is slower than a token exchange and considerably better than guessing. It also gives you a migration path: as customers do establish formal delegation, those accounts move up the ladder and stop hitting the confirmation step, so the friction decays over time rather than becoming permanent.

One design detail is easy to get wrong. The confirmation must go to a channel the agent doesn't control. If the assistant has full read access to the mailbox you're confirming into, you've built a loop that confirms itself. Push notification, SMS to a verified number, or an in-product approval queue all break the loop. A confirmation email into the same inbox does not.

Where the answer should just be no

Some requests shouldn't be automated for an agent sender at any tier. Account closure, changes to the recovery email or phone number, anything that alters who controls the account, and any payout to a destination that wasn't already on file. These are the actions an attacker wants, and the cost of being wrong is not a refund, it's an account takeover. Route them to a person and say so plainly in the reply, so the agent stops retrying. The wider question of when to resolve and when to route to a human applies here with a heavier thumb on the scale.

The ways this breaks

Prompt injection is now the fastest-growing attack class against LLM systems and sits at the top of the OWASP 2026 risk list, up roughly 340% year over year. An email agent is the textbook case: untrusted content arriving from outside, private customer data in reach, and an outbound channel to send it anywhere. The specific failures worth designing against:

• The confused deputy. Your agent trusts the sender's agent, then executes with your system privileges. The attacker never needed access to your CRM. They needed access to something that had it.
• Delegation-shaped injection. A block of text in the body formatted to look like a token, or an instruction claiming the account holder has pre-authorised this refund. Text in a body is input, not credential. If your verification path can be satisfied by something the sender typed, it isn't verification.
• Replay. The same signed, validly delegated refund request submitted forty times over an afternoon. Idempotency keys and JTI tracking, or you'll find out the expensive way.
• Silent scope drift. An agent card gets updated to declare broader skills. If you cache cards without re-verifying, you're authorising against yesterday's claims.
• Failing open. Your introspection endpoint times out during a traffic spike and the code path defaults to trust. This is the one that actually causes incidents, because it only triggers under load.

None of this is exotic. It's ordinary authorisation engineering applied to a channel that historically had none, which is why the security questions enterprise buyers should be asking increasingly include agent-to-agent handling.

Log the decision, not just the outcome

When a verification decision is questioned six weeks later, a log line saying the agent was verified is useless. Record the inputs: DMARC result and authenticated domain, agent card issuer and fingerprint, which JWKS key verified the signature, delegation subject and scope, the tier assigned, and the specific rule that granted or denied the action. Retain the raw signed card alongside the decision so a later key rotation doesn't make old records unverifiable. Our guide to audit trails for AI email support covers retention and access patterns in more depth.

Where Robylon fits

Robylon's email agents treat inbound agent traffic as a distinct sender class rather than folding it into the general queue. Verification tier drives what the agent is permitted to do, so a read-only status query and a refund request follow different paths even when they arrive in the same thread. Anything that fails delegation, or requests an action outside its granted scope, routes to a human with the verification trace attached rather than being silently dropped. Across 60+ write-access integrations, the authorisation check sits in front of the action, not after it.

Ready to handle agent traffic without widening your attack surface? Robylon AI resolves 60–80% of customer emails autonomously with agents that take action across Zendesk, Gmail, Shopify, Stripe and 60+ other integrations. Start free at robylon.ai