Executive Summary

AI is changing who, and what, interacts with enterprise applications. Websites, APIs, commerce platforms, and financial services environments continue to serve a mix of humans, traditional bots, AI assistants, autonomous agents, and automated workflows. That shift makes the traditional human-versus-bot model no longer sufficient in detecting and preventing fraud. Enterprises must now understand what type of automated actor is present, whether its claimed identity can be trusted, what level of access it should receive, and which policies should govern its behavior.

Fingerprint has been building out its products around that problem, offering AI Assistant Detection, powered by its Automation Intelligence API, and AI Agent Detection. Taken together, the products point to a change in how enterprises will have to think about automated traffic. Knowing that a request came from a machine is only the starting point. Teams also have to determine whether they recognize and trust the system behind it, then decide what that system should be allowed to do. 

Digital Identity Is Expanding Beyond Human Users

Enterprise identity architecture was previously built around people, applications, services, and machines. AI introduces another category that does not fit neatly into any of them.

Automated traffic can now come from a wide range of sources. It might be an AI assistant seeking content, a shopping agent acting on behalf of a customer, or an enterprise agent working within a CRM. It could also be a malicious scraper impersonating ChatGPT.

This shift is already happening, as demonstrated in theCUBE Research’s 2025 AI Builder Summit study. Our data show that 55.0% of respondents had already deployed AI agents, while 60.5% expected to do so within the next 18 months. Reasoning systems were even further along, with 62.2% already deployed and 62.9% planned.

[CHART 1: Which of the following AI capabilities is your organization planning to enable or invest in over the next 18 months? (select all that apply)]

This ability to differentiate types of automated traffic is increasingly important because blunt automation policies can create two equally problematic outcomes. Blocking all non-human activity can prevent legitimate AI services from interacting with applications, but allowing it broadly creates opportunities for scraping, account abuse, fraud, and impersonation.

More autonomous systems will mean making different decisions about different types of traffic. For example, a verified assistant who can access product information may be welcome. A request claiming the same identity without verification is a different matter. And once an autonomous agent reaches checkout or payment, the risk changes again and may call for stronger controls.

For CIOs and security leaders, this is the beginning of a shift from bot detection toward machine identity governance.

AI Agents & Assistants Create Different Security Surfaces

One important element of Fingerprint’s approach is the distinction between AI agents and AI assistants.

Authorized AI Agent Detection focuses on agents working through a browser. From there, an agent can navigate a site and interact with it much as a person would, including filling out forms, clicking buttons, or completing a transaction. Fingerprint uses signed agents so their identities can be cryptographically verified rather than relying solely on simple, rule-based checks to determine who they are.

AI assistants present a different problem. Services such as ChatGPT, Gemini, and Claude can retrieve information directly over HTTP, which means they may never open a browser or execute client-side JavaScript.

That distinction exposes a growing limitation in web security architecture, since many existing fraud and bot-management systems were built around browser telemetry, as browser sessions historically accounted for the majority of meaningful user interactions. As AI-driven traffic becomes more browserless, request-level identity and network context become more important.

Fingerprint handles AI assistant traffic through its Automation Intelligence API, currently available in preview. It can be deployed at the CDN edge, in middleware, or on the backend. To verify an assistant, Fingerprint looks at information such as the user-agent it claims to use, the request’s origin, reverse DNS, and network information published by the provider. Network signals around VPNs, proxies, Tor, and geolocation can provide more context when a request is evaluated for fraud or security risk.

This also changes where certain identity decisions can be made. By evaluating AI traffic as requests enter the environment, enterprises can determine who or what is requesting before they reach a sensitive workflow. Existing authentication, fraud, network risk, and application policies can then factor into the next steps.

The Policy Question Becomes More Important Than the Detection Question

The technical ability to identify AI traffic is only the first step. The more difficult enterprise question is what to do once that identity is discovered. A verified AI assistant should not be automatically trusted in every workflow. Likewise, an autonomous agent legitimately acting on behalf of a user may require different permissions depending on whether it is browsing public content, modifying an account, or initiating a financial transaction.

There are some parallels here with Zero Trust. Knowing an agent’s or assistant’s identity is useful, but it should not automatically grant that system access. The circumstances around the request and the organization’s own policies should still determine what happens next.

The answer will also depend on what the application does. A retailer may have little reason to stop a verified assistant from reading publicly available product information, but access to inventory or checkout is another matter. Banks and financial services companies have even more reason to be cautious when an agent attempts to change account information or make a payment.

[CHART 2: What best describes the CURRENT state of AI implementation within your organization?]

The governance requirements become even more important as the gap between enterprise AI adoption and the establishment of formalized operating models widens. theCUBE Research’s AI Builder Summit study found that 50.7% of respondents primarily relied on public AI tools, while only 20.2% reported enterprise-wide AI deployments operating under governed frameworks. Taken together, this means that AI adoption is advancing faster than organizations’ ability to establish controls around it consistently.

Over time, simply detecting AI will solve less of the problem. Organizations will also have to decide what an identified AI system can access and what actions it can take.

MCP Extends AI From Traffic Source to Operational Interface

Fingerprint’s MCP Server represents a different, but strategically connected, part of this architecture. Agent and assistant detection helps organizations understand how AI systems interact with their applications, while the MCP allows AI systems to interact with the organization’s operational data.

MCP gives AI assistants and agents a common way to connect to external tools and data. Fingerprint’s MCP Server puts that connection to use with its own platform. An AI system can use natural language to query device intelligence and fraud events, investigate unusual activity, and configure and manage Fingerprint environments.

This changes the operational model for fraud and security teams. Instead of navigating dashboards, correlating device identifiers, and manually searching event histories, an analyst could ask an AI assistant whether suspicious accounts appear related or what changed during a recent spike in fraudulent activity. The AI system can then query current operational information through Fingerprint’s MCP and return an analysis.

AI is starting to play two roles inside the enterprise. It can act on behalf of a user or organization, but it is also becoming a way for employees to work with the systems they already use. theCUBE Research’s AI Builder Summit study shows how far some of that adoption has already gone. AI assistants were used by 72.8% of respondents, while 49.3% reported AI-powered workflows and 41.8% had multi-agent systems in place. Another 56.6% planned to adopt AI-powered workflows, and 50.9% planned to adopt multi-agent systems.

Access is where things get more complicated. An AI assistant may need fraud data to answer an analyst’s question, but it does not necessarily need the ability to change a policy or block an account. Those are different levels of authority and should be treated that way. As MCP connects AI more directly to enterprise systems, IT teams will need to account for these connections in their existing identity and access controls.

Financial Services & E-Commerce Will Feel This Shift First

The implications of these market changes are particularly pronounced in financial services and e-commerce because both industries sit at the intersection of identity, money, fraud, and customer experience.

Agentic commerce has the potential to change how consumers discover and purchase products. Instead of visiting multiple websites, a consumer may delegate research, comparison, and eventually purchasing to an AI agent. This creates a new type of customer interaction in which the enterprise may interact primarily with an agent representing the customer rather than directly with the customer.

Financial services adds another layer of risk. Consumers may eventually rely on AI agents for everything from researching financial products to managing an account or moving money. At that point, knowing the customer is only part of the equation. The financial institution also has to know who or what is acting on behalf of that customer and whether it has permission to do so.

There is still some hesitation around giving AI that much independence. In theCUBE Research’s AI Builder Summit study, 42.9% of respondents said they were highly confident in AI agents acting autonomously without human intervention, while 44.2% described their confidence as moderate.

[CHART 3: What level of confidence do you have that AI agents can be trusted to ACT AUTONOMOUSLY on your behalf — that is, to take actions without human intervention in pursuit of a defined goal?]

That distribution suggests enterprises are becoming comfortable with autonomous AI, but not unconditionally. A future digital trust architecture will need to answer several questions simultaneously: 

• Is this an AI system?
• What agent or provider is behind it?
• Is it really who it claims to be?
• Who permitted it to act?
• What does it have access to?
• What is it trying to do?
• Does this particular action need another layer of verification?

Vendors that solve only the first question will address only a fraction of the emerging problem.

Analyst Take

Fingerprint’s recent AI capabilities are timely in this shifting market. The internet is moving from an environment where most meaningful interactions originated from humans using browsers toward one where humans, assistants, agents, and automated services coexist.

Traditional bot management was primarily designed to determine whether to block automation, but the emerging requirement is different. Enterprises need sufficient identity and context to determine which automation to trust, what it represents, and under what conditions it should be allowed to act. That turns AI traffic management into an identity and governance problem.

Fingerprint is approaching the problem from several directions. Its products can identify agents in the browser, recognize assistants connecting directly over HTTP, evaluate automation earlier in the request path, and give AI systems access to Fingerprint data through its MCP. The common thread is having more information about the AI system involved before deciding how to handle it.

This is still a new area, and the way companies handle AI identity will continue to develop. What is already becoming clear is that it touches several parts of the security stack. Fraud prevention, API security, Zero Trust, and even the digital experience can all depend on knowing what is behind a request.

Companies can start by examining where AI already interacts with their applications and what their existing controls can detect. Can they tell a verified AI service from something pretending to be one? And if the traffic is legitimate, do their current policies account for what an AI system should and should not be allowed to do?

The same questions apply when the direction is reversed, and AI is given access to internal systems or operational data. An assistant that can retrieve information does not necessarily need permission to change it or take action. The more an AI system can do, the more important it becomes to be deliberate about its access and when a person still needs to be involved.

These questions will become harder to avoid as AI agents move into production. Simply recognizing that an AI system is present will only get an organization so far. It also needs to know whether that system is legitimate and whether what it is trying to do should be allowed.

Looking Ahead

AI assistants and autonomous agents are already changing how automated traffic reaches enterprise systems. Organizations can start preparing by focusing on five areas:

• Find where AI is already showing up. Look across customer-facing applications, APIs, login systems, and transaction flows for interactions coming from assistants, agents, or other automated systems. That includes traffic arriving through a browser as well as connections made directly over HTTP.
• Decide what trusted AI can actually do. Verifying an AI system does not mean it should have access to everything. A system that reads public content poses a different level of risk than one that makes changes to an account or initiates a financial transaction, and its access should reflect that difference.
• Check what existing security tools can see. Identity and fraud platforms may already provide some of the information teams need, but it is worth determining how they handle AI traffic specifically. That includes whether they can recognize spoofed identities and use AI-related signals alongside existing fraud, access, API security, and Zero Trust controls.
• Set limits for AI used by security teams. MCP can give AI systems a useful role in fraud investigations and other operational work. Teams still need to decide when an assistant can only retrieve information, when it can make a recommendation, and when it has permission to make a change or take action.
• Treat AI identity as a long-term architecture requirement. AI traffic management should not be approached as a temporary extension of bot detection. As machine-mediated interactions expand across commerce and financial services, AI identity and automation governance will increasingly need to become part of enterprise digital trust strategy.

Fingerprint’s recent expansion allows for greater visibility and control across AI-driven interactions. The larger opportunity for enterprises is to build an identity architecture capable of making policy decisions regardless of whether the actor is a person, an assistant, an autonomous agent, or another automated system.  Some AI traffic will be useful. Some will not. The controls around it need to account for the difference.

theCUBE Research. (2025). 2025 AI Builder Summit. ECI Research Portal. https://www.eciresearch.ai/surveys/c46dc7fe-81ae-403f-9371-9a38163ced15