The News
Fingerprint is expanding its device intelligence platform as AI assistants, autonomous agents, and other forms of automation come to account for a larger share of web traffic. Through Authorized AI Agent Detection, AI Assistant Detection powered by the Automation Intelligence API, and the Fingerprint MCP Server, the company is building a broader identity and automation layer designed to help organizations understand which automated systems are interacting with their applications, whether those systems are legitimate, and provide an improved way to query their Fingerprint data.
Authorized AI Agent Detection focuses on browser-based agents and can verify signed AI agents from providers, including OpenAI, AWS AgentCore, Browserbase, Manus, and Anchor Browser. The Automation Intelligence API, currently launched in preview, brings that detection outside the browser. It can run at the edge, in middleware, or on the backend without depending on client-side JavaScript. It also enables AI Assistant Detection, which works at the HTTP layer to identify traffic from assistants such as ChatGPT, Gemini, and Claude, while flagging requests that claim to come from those providers but cannot be verified. The Fingerprint MCP Server provides compatible AI assistants and agents with access to Fingerprint’s device intelligence data, enabling developers, product teams, and fraud analysts to investigate events and build AI-assisted workflows through natural language.
Web security is evolving beyond simply detecting automated traffic. Security teams now need to understand who or what is behind that traffic, what it is trying to do, and whether it can be trusted, especially as AI-driven traffic continues to grow.
Analyst Take
Human Versus Bot Is Becoming the Wrong Abstraction
Bot detection used to be a job of determining whether traffic came from a human or an automated system, then deciding whether to let it through. AI is making this process much more difficult. An autonomous shopping agent, an AI assistant looking up product information, and a credential-stuffing bot are all non-human traffic, but they pose very different risks. Simply identifying traffic as a bot is no longer enough. Security teams need to know what it is, whether it can be trusted, and what policies should apply.
This could be especially important in e-commerce and financial services. Retailers, for example, have good reason to let legitimate shopping agents access product catalogs. That doesn’t mean they want unidentified scrapers doing the same thing at scale. Banks and financial applications face a similar issue. Automation that poses little risk in one part of an application may need much closer scrutiny when it reaches a login, creates an account, or initiates a payment.
There is already plenty for security teams to manage. In ECI Research’s 2026 DevSecOps & Application Security study, nearly four out of five respondents (78.7%) said their organization had experienced some sort of application security event during the previous year. Credential compromise was reported by 39.4% and API abuse by 37.2%. For developers, identifying automation is now becoming part of application policy.
[CHART 1: Have you experienced any of the following in the past 12 months? (Select all that apply)]
AI Traffic Now Arrives Through Multiple Technical Paths
Fingerprint’s distinction between AI Agent Detection and AI Assistant Detection is important because AI traffic doesn’t reach applications through a single interface. An AI agent operating through a browser may click, type, navigate, and fill out forms much like a human user. An AI assistant fetching content directly over HTTP may never load a page or execute JavaScript. In that case, traditional browser-centric defenses lose visibility.
Fingerprint’s Automation Intelligence API addresses this gap by analyzing AI traffic at the HTTP layer. It looks at signals including the claimed user agent, source IP, reverse DNS, and network ranges published by AI providers. Together, these signals can help identify assistants such as ChatGPT, Gemini, and Claude, as well as traffic that claims to come from those services but cannot be verified. Teams get more than a general bot classification: they can see the provider, the type of assistant, and whether its identity has been verified.
The Automation Intelligence API can run at the CDN edge, in middleware, or on the backend, allowing teams to classify AI traffic before it reaches the application. This is true even when browser telemetry or client-side JavaScript isn’t available. That classification can be paired with signals such as proxy, VPN, Tor, and geolocation data to help teams decide what traffic to allow, challenge, or block.
[CHART 2: Which security controls are integrated directly into your CI/CD pipeline? (Select all that apply)]
This is especially relevant as security teams move more controls toward APIs and integration points. ECI Research found that 64.1% of respondents have API security testing integrated directly into their CI/CD pipelines, making it one of the most widely adopted controls in the study. As more AI traffic arrives directly over HTTP and APIs, identity decisions will need to be made in those same places. Waiting for a browser-side signal will not always be an option.
Using MCP for Fraud Detection and Response
The Fingerprint MCP Server brings these capabilities into day-to-day fraud operations by giving AI systems access to an organization’s own Fingerprint data. Fraud analysts can investigate suspicious activity, developers can connect tools such as Claude Code or Cursor, and teams configure Fingerprint workspaces, all using natural language prompts.
MCP is still a relatively new part of the application stack, but it is already showing up in production environments. ECI Research’s 2026 Application Development study found that 35.0% of respondents are using agents or MCP servers as part of API lifecycle management. For fraud teams, this creates a new way to use AI during investigations. An assistant can work with device, session, and transaction data without being given unrestricted access to the underlying systems.
The level of access granted is the most important part. Reading fraud data differs from changing a policy or blocking an account since those actions still require the appropriate access controls, audit trails, and, where necessary, human approval. MCP may be able to provide the connection, but it does not replace those safeguards.
Looking Ahead
The web is moving toward a model in which humans, traditional bots, AI assistants, and autonomous agents all use the same applications but do not necessarily reach them through the same technical path.
Visibility should come first. Both developers and security teams need a clear idea of where AI assistants and agents are already interacting with their applications. This includes public content and APIs, as well as login flows, checkout systems, and other areas where the risk may be higher. Once a team knows where that traffic is showing up, they can determine what is acceptable and where stronger controls may be necessary.
Existing fraud and bot management tools also need a closer look. A user-agent string saying “ChatGPT” is not much of an identity signal on its own. As legitimate AI traffic becomes more valuable, spoofing that traffic becomes more valuable too. Verification will need to draw from multiple sources, including network intelligence, device signals, behavior, and transaction context.
Organizations can start by looking at five key areas:
- Identify both browser-based agents and HTTP-level assistants. Some AI traffic will arrive through a browser, while other assistants will connect directly over HTTP. Existing controls should account for both rather than grouping all automated traffic.
- Verify AI identity before granting trust. Identifying an assistant is only part of the job. Before giving that traffic more permissive access, organizations need a way to determine whether it actually belongs to the provider it claims to represent.
- Move automation intelligence closer to request ingress. Not every request will provide JavaScript or other browser-based signals. Evaluating traffic at the edge, in middleware, or on the backend gives teams another opportunity to understand a request before it reaches sensitive application workflows.
- Use AI identity as one signal, not the only signal. Knowing what generated a request helps, but it doesn’t tell you everything. Device, network, behavior, and transaction data still have a role in deciding how that request should be handled.
- Decide what AI can access and change. An assistant helping with a fraud investigation may need to see the underlying data, but that doesn’t mean it should be able to change settings or act on an account. Keep more sensitive actions behind additional permissions or human review.
As AI-driven traffic becomes more common, organizations will need to know not only when they are interacting with AI, but also when to trust it and what it should be allowed to do. Fingerprint is building the visibility and controls to help teams make those decisions.
Longer term, AI identity looks less like a niche extension of bot management and more like another piece of digital trust architecture. Applications will increasingly need to make decisions about visitors who are neither users nor bots. For developers, that changes a basic assumption of application design: the thing on the other side of a request may now be a person, an assistant, an autonomous agent, or something pretending to be one.
68.8% of respondents selected “Increase moderately (5–20%)” when asked: “How will your AppSec/DevSecOps budget change in 2026?”
ECI Research. (2026). 2026 Application Development: DevSecOps & AppSec. ECI Research Portal. https://www.eciresearch.ai/surveys/a48f1b79-ad6f-4e54-bfac-3b94aa36c63e
Stay Ahead of Application Development Trends
Get weekly analyst insights, research notes, event coverage, and AppDevANGLE updates delivered directly to your inbox.
Subscribe for Weekly Insights
Join technology leaders, practitioners, and GTM teams following the trends shaping modern software delivery.
Looking for deeper research access?
Explore ECI Research reports, survey insights, and market analysis through the ECI Research Portal.
