Prompt Injection and Agent Impersonation: The Commerce Security Threats You Haven’t Locked Down Yet

The agentic web has created a security problem that looks nothing like the threats commerce teams spent the last decade defending against. Traditional fraud targets the human layer: stolen credentials, fake accounts, manipulated clicks. The new threat targets the agent layer — the growing population of AI systems that browse, compare, and transact on behalf of your customers.

Two attack vectors in particular are becoming the defining security challenge of 2026: prompt injection and agent impersonation. Neither is hypothetical. Both are operational at scale. And most commerce sites have no specific defense against either.

Why This Is a Different Problem from Bot Detection

It is tempting to fold agent security into existing bot detection frameworks. The problems are related but distinct, and conflating them leads to the wrong defenses.

QAIL’s analysis of 30M+ website visits found that AI bot traffic now represents 38–52% of all web traffic. That research is about traffic classification: telling legitimate crawlers from scrapers, and understanding what AI systems are doing when they visit your site. It is a volume and policy problem.

Prompt injection and agent impersonation are transaction and trust problems. They don’t show up clearly in traffic logs. They don’t trigger rate limits. In many cases, they arrive wearing the identity of agents you have explicitly decided to trust.

What Prompt Injection Actually Means for Commerce

Prompt injection is the mechanism by which malicious content — embedded in a web page, a product description, a customer review, or any data source an agent reads — overrides the agent’s instructions and redirects its behavior.

The attack works because AI agents process natural language from untrusted sources. When a shopping agent reads a product listing, it cannot distinguish between the merchant’s legitimate description and a hidden instruction embedded in that description. Both arrive as text. Both get processed.

A direct injection puts the malicious instruction explicitly in a source the agent reads: white text on a white background, CSS-suppressed copy, or content behind a display:none div. The agent’s scraper fetches the raw HTML, which includes the hidden instruction, and the agent follows it.

An indirect injection attack is more sophisticated and harder to detect. The compromised content is upstream: a supplier’s product feed, a review aggregator, a third-party data source your agents read to enrich their context. The Cloud Security Alliance documented operational indirect injection attacks in the wild in 2026, including cases where payloads delivered through poisoned data sources successfully corrupted agents’ decisions mid-session.

The commerce implications are significant. An injected instruction could redirect an agent to a competitor’s checkout instead of yours. It could manipulate comparison data so your products score worse in an agent’s evaluation. It could exfiltrate customer data the agent holds in session memory. It could commit a purchase the user never intended. OWASP’s researchers have described the pattern bluntly: an agent that combines access to private data, exposure to untrusted content, and the ability to communicate externally is an exfiltration tool waiting to be triggered. SecurityWeek documented a production case in which prompt injection attacks tricked AI agents into making unauthorized cryptocurrency payments. The agents were legitimate. The exploit was in the content they read.

Agent Impersonation: The Identity Crisis in Your Traffic Logs

While prompt injection attacks target agents directly, impersonation attacks target the trust relationship between you and the agents you have decided to treat as legitimate.

The mechanism is straightforward. Sites that want to serve AI agent traffic extend preferential treatment to recognized crawlers and agents: reduced friction, relaxed rate limits, access to content behind light authentication. Agent verification and tiered access control frameworks exist precisely to manage this. The impersonation attack exploits it: a bad actor builds an agent that presents itself as a recognized identity — GPTBot, PerplexityBot, Meta-ExternalAgent — to inherit the access those identities have earned.

DataDome’s AI Traffic Report tracked 7.9 billion AI agent requests across its network in January and February 2026 alone. Within that volume, Meta-ExternalAgent was the single most-impersonated agent identity, with 16.4 million spoofed requests in the same two-month window. ChatGPT-User recorded 7.9 million spoofed requests. PerplexityBot had the highest impersonation rate relative to its legitimate traffic: nearly 2.4% of all requests presenting that identity were fraudulent.

The reason is simple. These agents carry implicit trust. A security system that applies lighter scrutiny to traffic from ChatGPT or Perplexity is handing out hall passes — and fraudsters know exactly which identities to claim.

At the commerce layer, the risk goes beyond scraping or competitive intelligence. As agent authentication standards like Visa TAP and Google AP2 create verified agent identities that carry payment authorization, impersonating those identities becomes a path to transaction fraud. An agent that can convince your checkout that it holds verified purchasing authority can initiate transactions without it. The authentication standards are the right long-term answer. But most merchants aren’t waiting for standards to fully deploy — they are building agent access policies now, on top of identity signals that are spoofable today.

MCP Endpoints and the Tool-Poisoning Risk

If your site exposes MCP endpoints for AI-ready commerce, there is a third attack surface to consider: tool poisoning.

MCP tools present metadata — names, descriptions, parameter schemas — that agents read when deciding how to use a tool. Tool poisoning embeds malicious instructions in that metadata. The agent reads a description that appears to describe a legitimate capability but contains hidden directives that redirect the agent’s behavior when the tool is invoked.

A 2026 analysis of over 1,800 deployed MCP servers found that more than 30% contained at least one exploitable vulnerability — a higher base rate than most enterprise software categories at equivalent deployment scale. The Cloud Security Alliance documented a systemic design flaw in April 2026 affecting Anthropic’s official MCP SDKs across Python, TypeScript, Java, and Rust: STDIO transport processed incoming configuration by passing parameters directly to the host OS shell without input sanitization. The estimated exposure at disclosure time was 200,000 vulnerable instances across a supply chain touching 150 million package downloads.

If you have deployed MCP endpoints assuming that agents will only interact with them as designed, you have made the same assumption that early REST API developers made about browser clients: that the interface you built is the only interface anyone will use.

What You Can Actually Do

The defenses are not magic, but they require deliberate implementation.

Verify agent identity cryptographically, not just by header

Checking the User-Agent header tells you what an agent claims to be, not what it is. Verifying reverse DNS against published IP ranges — the method used for identifying GPTBot and PerplexityBot — raises the bar significantly. Spoofing a header is trivial; spoofing a reverse DNS record requires compromising the underlying network infrastructure. For high-trust interactions like checkout or account access, require cryptographic proof of identity as Visa TAP and FIDO’s Agentic Authentication Working Group define it.

Treat agent-read content as untrusted input

Any content your agents read from external sources — product feeds, reviews, third-party enrichment data — is a potential injection vector. Systems that read third-party content should be sandboxed from systems that have action-taking capabilities (checkout, order placement, account modification). The principle is the same as SQL injection defense: you do not trust user input to form your queries, and you should not trust agent-read content to form your agent’s intentions.

Audit your MCP tool descriptions

If you have deployed MCP endpoints, review your tool descriptions with the same scrutiny you would apply to SQL queries or input validation rules. Tool descriptions are agent-readable code. Apply input validation to MCP parameters. Log what your tools are called with. Review your dependencies for known-vulnerable MCP SDK versions and apply available patches.

Set explicit scope limits on agent sessions

Legitimate purchasing agents operate within a defined scope: a budget, a product category, a maximum order quantity. If an agent session is taking actions outside that scope — quantities that don’t match user history, categories the customer has never purchased in, shipping destinations that differ from account profile data — that is a signal, not a curiosity. Flag and rate-limit out-of-scope agent behavior the same way you flag anomalous human behavior.

Know which agents you are actually letting in

An agent access control policy is only as good as your ability to enforce it. If you have defined tiers of access for different agent types, your enforcement layer needs to do more than check a header. The DataDome data makes clear that header-level impersonation is operational at scale. Any access policy that does not include identity verification is being subverted by a meaningful fraction of the traffic claiming trusted identities.

The Gap That Still Needs to Close

The longer-term solution to both problems is standardized agent identity: cryptographic credentials that prove an agent is what it claims to be and is operating within its authorized scope. The authentication standards covered elsewhere on this blog — Visa TAP, Google AP2, FIDO’s Agentic Authentication Working Group — are building that infrastructure. When they reach sufficient deployment, impersonating a trusted agent will require compromising its cryptographic keys, not copying a string in a header.

But those standards are not fully deployed today. Prompt injection defenses are not something a standard solves for you — they require architectural decisions about what your agents read and what they can do with that content. Those decisions need to be made now, before agent-initiated commerce scales to the point where the attack surface becomes an incident report.

QAIL’s Agent Readiness Score evaluates your site’s exposure across these dimensions — not just whether you are discoverable by agents, but whether you are doing so safely. If you have not run it, the free assessment is a ten-minute starting point for understanding where your agent security posture actually stands.