Inside the Front Door: Agent Identification vs Intent Intelligence

Knowing what is at the door is now table stakes. Knowing why it came in, and what it is trying to do once inside, is where banks and retailers will win or lose the agentic era.

AI agents now log in, browse, compare, fill carts, move money and talk to support on behalf of people. Some say who they are. Many do not. Security teams have spent the past two years learning to tell a good bot from a bad one. That work matters, but it only answers one question: who or what is this?

The harder question is: what is this session trying to achieve, and does that match what the account owner actually wants? A verified, well-behaved agent from a trusted platform can still be used to drain an account, launder funds, abuse a promotion or scrape a price book. A real human with a perfect device can still be a money mule or a scam victim being coached on the phone.

This blog post explains the difference between agent identification and intent intelligence, why you need both, and how CISOs can join threat and fraud signals into one continuous view of identity, authority and intent, for agents and humans alike.

Two different questions

Agent identification tells you what is acting and for whom. Intent intelligence tells you why it is acting and whether that purpose is safe.

Agent identification answers: Is this a human, an automated script, or an AI agent? If an agent, which one, who runs it, and is it allowed here? It covers two groups:

• Declared agents announce themselves. They send a signed identity, a known user-agent, or a token from a platform you trust (for example an AI assistant, a shopping agent or a bank-approved aggregator).
• Undeclared agents hide. They look like a normal browser, run headless or through automation frameworks, rotate residential IPs, or drive a real browser through computer-use tools.

Intent intelligence answers: Given everything this actor has done so far, what is it trying to do, does that match the account owner's normal goals, and does it fit within the authority it was given? It applies to every session, human or agent, declared or not.

The two are not rivals. Identification narrows the field. Intent decides what happens next.

Identification: the front door check

Identification is still the first filter. It removes the noise so intent models can focus on the sessions that matter.

Declared agents

Declared agents are becoming easier to verify. The main building block is Web Bot Auth, which uses HTTP Message Signatures (RFC 9421). The agent signs each request with a private key. The site checks the signature against a public key the agent publishes in a known directory.

Card networks have built on this. Visa's Trusted Agent Protocol and Mastercard Agent Pay both use Web Bot Auth as the agent authentication layer, as Cloudflare explains. A tag in the signature says what the agent is there to do: browsing (agent-browser-auth) or paying (agent-payer-auth). The merchant checks the key, the time window, a one-time nonce, and that the tag fits the action.

This gives you a strong answer to which agent is this, and is it registered? It does not tell you whether the human behind it is the real account owner, whether that human is being scammed, or whether the agent is staying inside its brief.

Undeclared agents

Most risky automation will never sign anything. You find it through evidence:

• Network: data-center or residential proxy IPs, IP and ASN reputation, TLS and HTTP/2 fingerprints (JA4 and similar) that do not match the claimed browser.
• Runtime: headless browser traces, automation frameworks (Playwright, Puppeteer, Selenium), injected scripts, missing or faked browser APIs, virtual machines and emulators.
• Interaction: no real pointer movement, perfect timing, instant form fill, copy-paste of every field, pages read at machine speed, computer-use agents clicking pixel-perfect centers.
• Navigation: direct hits on deep URLs or APIs without the normal page path, unusual request order, high page coverage per session.
• Threat intelligence: known bot-net infrastructure, credential stuffing lists, fraud-as-a-service tooling, phishing kits and stolen-session markets.

What identification is good at

Identification is the right tool to block obvious bad actors at the edge: credential stuffing, card testing, scalping, fake account farms, and scraping by unknown bots. It should also sort traffic into clear lanes: verified agent, likely agent, likely human, and unknown. Each lane then gets its own intent model and its own limits.

The mistake is treating a pass at the door as a pass for the whole visit.

The real challenge: inside the front door

Once an agent is identified and authorized, the risk moves from who it is to what it does with the access it was given. That is where most losses will come from.

Authorization is usually granted once and broadly: "let my assistant manage my bills", "let this agent buy groceries under $200". The agent then acts many times, at machine speed, across many sessions. Five problems follow:

1. The human behind the agent may not be the owner. A fraudster with stolen credentials can connect a perfectly legitimate agent to a victim's account. The agent is real. The intent is theft.
2. The owner may be acting under pressure. In an authorized push payment (APP) scam, the victim really does instruct their agent to pay. The agent signature is valid. The payee is a mule.
3. The agent may drift from its brief. Prompt injection from a web page, a product review or an email can redirect an agent. It may add a payee, change a delivery address or share data it was never asked to share.
4. Scale changes the economics of abuse. One person exploiting a promo code is a nuisance. One agent template doing it across 50,000 accounts is a loss event. The same applies to returns abuse, refund claims and loyalty points.
5. Legitimate actions can be steps in a bad plan. Checking a balance, adding a payee, raising a limit and making a transfer are each normal. In that order, in ten minutes, from a new agent connection, they tell a different story.

None of these show up in a bot score. A verified agent with a valid token, clean IP and correct signature will pass every identification check. Only intent intelligence, built from behavior, identity, transactions and the agent's own tool calls, can see them.

Online banking use cases

In banking, the cost of getting intent wrong is money that cannot be recalled. Each case below shows what identification sees and what only intent sees.

The pattern is the same each time. The door check passes. The sequence and the purpose are what give it away.

Ecommerce use cases

In ecommerce, agents are welcome customers. The goal is to say yes to good agent traffic and still stop abuse that hides inside it.

A useful rule for retailers: rate limits and offers should apply to the linked identity behind the agents, not to each agent session. That is only possible if identity and intent signals are joined.

The signals that reveal intent

Intent is never one signal. It is a pattern across five families, read together and over time. No single family is enough; the value is in how they agree or disagree.

1. Behavior signals: how the actor moves

Behavior shows the how of a session. For humans it shows hesitation, coaching and familiarity. For agents it shows whether the agent behaves like itself.

• Interaction rhythm: typing cadence, pauses, pointer paths, scroll depth, touch pressure and angle on mobile.
• Familiarity: does the actor know where things are? Owners go straight to known pages. Takeover actors explore settings first.
• Hesitation and coaching: long pauses before a payment, switching apps, an active phone call, reading out numbers. These are classic signs of a scam victim being guided.
• Journey shape: the order of pages and actions. Login, balance, add payee, raise limit, transfer is a known takeover pattern.
• Speed and coverage: how many items, accounts or pages are touched per minute compared with the norm for that actor type.
• Agent consistency: a given agent should act the same way each time. A sudden change in its tool use, timing or path suggests a new operator, a new prompt or an injection.

2. Identity signals: who is really behind it

Identity links the session to people, devices and accounts. It answers whether the human principal is the true owner.

• Device and environment: device ID, OS and browser integrity, emulators, remote access tools, jailbroken or rooted phones.
• Network and location: IP reputation, proxy and VPN use, distance from usual locations, impossible travel.
• Account history: account age, recent changes to email, phone, password or MFA, recent new devices or agent links.
• Linkage: devices, cards, addresses, emails and phones shared across many accounts. This is how you see mule rings, synthetic identities and promo abuse farms.
• Agent-to-principal binding: which human authorized this agent, when, from what device, and with what proof. A new agent connection made from a risky session is itself a strong signal.
• Consortium and threat intel: whether the device, email, phone, payee or IP has been seen in fraud elsewhere.

3. Transaction signals: what the money is doing

Transactions show the outcome the actor is driving toward.

• Amount and frequency against the customer's own history and their peer group.
• Payee and merchant risk: first-time payee, payee account age, mule-linked accounts, high-risk merchant categories, crypto off-ramps.
• Velocity and structuring: many small payments, splitting just under limits, fast in-and-out flows.
• Basket content: high-resale goods, gift cards, mismatched quantities, items unrelated to past orders.
• Fulfilment: new or reshipping addresses, click-and-collect by a different person, digital goods to a new email.
• Post-transaction behavior: refund claims, disputes, chargebacks and returns linked back to the same identity cluster.

4. Agent-facing MCP and API patterns: what the agent asks for

When businesses expose services to agents through MCP servers or agent APIs, they get a new and very rich signal: the agent's own requests. This is the closest thing to reading the agent's plan.

• Tool selection: which tools the agent calls. A shopping agent that calls get_order_history, update_address and issue_refund but never search_products is not shopping.
• Call sequence: the order of tool calls is a journey, just like page views. Model it the same way.
• Scope versus need: does the agent ask for more data or wider permissions than the task needs? Over-asking is an early sign of drift or abuse.
• Parameter patterns: amounts close to limits, enumerated account IDs, many coupon codes tried, systematic changes to one field.
• Error and retry patterns: repeated authorization failures, probing for which tools exist, testing edge cases in inputs.
• Session and token use: one token used from many places, tokens reused after the stated task ended, many agents sharing one principal.
• Agent fingerprint over time: model, client and framework details, and how stable they are for that principal.

5. Agent-facing content: what the agent reads and says

Agents work in language. What they read, and the instructions they pass on, carry intent.

• Task and instruction text: where available, the natural-language task the agent states ("pay this invoice today, it is urgent"). Urgency, secrecy and changes of payee are classic scam language.
• Free-text fields: payment references, chat with support, review text and claim descriptions written by agents. Repeated templates across accounts point to automation at scale.
• Injected content: hidden instructions in product pages, reviews, emails or documents that the agent processed just before it changed behavior.
• Outbound content: what the agent tries to send out (data exports, summaries, screenshots). Unusual data leaving through an agent is both a fraud and a privacy risk.

Putting the families together

The strongest intent signal is disagreement between families. A clean device and a valid agent signature (identity) with a first-time payee and maximum amount (transaction) after the agent read an email with new bank details (content) is a far clearer risk than any one of those alone.

Intent intelligence is not an Intent Mandate

An Intent Mandate records what a user says they want an agent to do. Intent intelligence judges what an actor is actually trying to do. You need the first for authority and the second for risk.

Agentic commerce protocols use signed "mandates" to prove a user authorized an agent. In Google's Agent Payments Protocol (AP2), announced in September 2025, the first version described an Intent Mandate (the user's instructions and limits, such as "buy these shoes under $120 if they come back in stock"), a Cart Mandate (approval of a specific cart) and a Payment Mandate (shared with the payment ecosystem). The current site frames this as Checkout and Payment mandates, each with an open stage that captures the user's constraints and a closed stage that authorizes a final checkout. These are tamper-evident, cryptographically signed objects, and they support both human-present and human-not-present purchases.

Mandates are a big step forward. They create a clear, auditable record of consent and they help settle disputes. But they are a different thing:

Three gaps matter most:

1. Signed by the wrong person. If an attacker controls the account or device, they can create a valid mandate. The cryptography is fine. The intent is criminal.
2. Signed under deception. A scam victim can authorize a mandate to pay a fraudster. The mandate proves consent, not that the consent was informed.
3. Inside the lines, still wrong. An agent can stay within the mandate's limits and still be abused: many small purchases, a refund loop, or an injected change that fits the stated budget.

The best design uses both. The mandate is a strong input to intent intelligence: it tells you the declared purpose and limits. Intent intelligence then checks whether real behavior fits that purpose, and flags the cases where the mandate itself looks suspicious.

Risk-based authentication as a continuous process

Authentication should be a running assessment of trust, not a gate passed once at login. This is true for humans, and it is essential for agents that act for hours or days on one grant.

Traditional risk-based authentication (RBA) checks risk at a few fixed points: login, add payee, large payment. If the score is fine, the session is trusted until it ends. That model breaks for agents for three reasons:

• Long-lived authority. An agent token or mandate may last days or weeks, with no login event to re-check.
• No natural checkpoints. Agents chain many actions through APIs. There is no screen where a human pauses.
• Risk changes mid-session. A session that starts as a balance check can become a takeover in minutes.

How it works in practice

1. Start with a trust level, not a yes/no. Each session begins with a score built from identity and identification signals.
2. Update on every event. Each page view, tool call, field change and transaction moves the score up or down.
3. Match friction to the action. Reading a balance needs little trust. Adding a payee and sending the maximum needs a lot. The bar rises with the impact of the action.
4. Step up the right party. For an agent, the right challenge is often the human principal ("Your assistant is adding a new payee. Was that you?"), not a CAPTCHA for the agent.
5. Narrow, don't just block. Reduce the agent's scope or limits, or switch it to read-only, while the case is checked. This protects customers without breaking good automation.
6. Learn after the fact. Chargebacks, scam reports and confirmed fraud feed back into the models and into the threat picture.

The outcome is less friction for good customers and good agents, and earlier action on the small share of sessions where intent turns bad.

The CISO opportunity: one signal layer for every team

CISOs can turn two separate data streams, threat intelligence and fraud intelligence, into one shared layer of identification, authorization and intent signals. Fraud, risk and compliance teams can then act on the same view, faster.

Today these streams rarely meet. Security sees bots, IPs, malware and attack tools at the edge. Fraud sees devices, accounts, payees and chargebacks in the app. Each team builds its own rules on half the picture. Attackers move between the gaps.

fused signal layer · 2 sources, 3 signals, 3 teams

Threat and fraud data feed one layer that answers three questions for every session; each team reads the same answer and feeds its outcomes back.

What the single layer produces

• Identification signals: human, declared agent, undeclared agent or unknown; which agent and which operator; confidence level.
• Authorization signals: which human principal stands behind the agent, what scope and limits they granted, whether a mandate exists and whether it is fresh.
• Intent signals: a live score and reason codes such as likely takeover, likely scam victim, likely mule, promo abuse cluster or agent drift.

How a single layer approach helps each downstream team

What CISOs should rethink

1. Ownership. Treat agent identity and intent as a shared control, owned with fraud, not a bot-management feature at the edge.
2. Data flow. Pass identification and threat context from the edge into the app and fraud stack in real time, and send fraud outcomes back to security.
3. Common language. Agree on shared reason codes and actor types (human, declared agent, undeclared agent) so every team reads the same signal the same way.
4. Policy for agents. Define what each class of agent may do, at what limits, and what happens when intent changes mid-session.
5. Privacy by design. Intent can often be read from patterns without needing to know who the person is. That keeps the layer useful for many teams while limiting personal data spread.

Where to start

Start by sorting traffic, then watch what verified actors do inside, then share one signal layer across teams. A practical order:

1. Map your agent traffic. Measure how much is declared, likely-undeclared and human today, by channel (web, app, API, MCP).
2. Verify declared agents. Accept Web Bot Auth signatures and network agent programs where they fit, and record the agent and its principal on every session.
3. Build agent baselines. Track each agent's normal tool calls, timing and scope, so drift is visible.
4. Add intent models to high-impact journeys first: new payee, transfer, limit change, checkout, refund and loyalty redemption.
5. Make step-up continuous. Replace one-time checks with trust that updates on every action, and route challenges to the human principal.
6. Treat mandates as inputs. Read declared intent and limits from protocol mandates, and compare them with observed behavior.
7. Fuse and share. Join threat and fraud signals into one layer, with shared reason codes, feeding fraud, risk and compliance in real time.

Identifying agents keeps obvious attackers out. Intent intelligence protects what happens after the door opens. In a world where good and bad actors both arrive as polite, verified software, that second layer is where trust is won.

Sources

• Agent Payments Protocol (AP2)
• Visa Trusted Agent Protocol specifications
• Mastercard Agent Pay
• Cloudflare: Securing agentic commerce, helping AI agents transact with Visa and Mastercard