The Internet Has a New Identity Problem​: Sometimes the “User” Isn’t a Person

Editor’s Note: This guest post was written by Dave Shackleford, owner and principal consultant of Voodoo Security, senior instructor with SANS, and faculty member at IANS Research.

—
For years, security teams have spent an impressive amount of time answering a seemingly straightforward question: Is this a human or a bot?

AI agents have made that question considerably less useful.

Agents increasingly browse websites, research products, interact with applications, and perform tasks on behalf of actual humans. Meanwhile, malicious automation has gotten better at looking legitimate. Modern bots can execute JavaScript, maintain sessions, vary their timing, use real browsers, and route traffic through residential proxies and commercial VPN services.

A connection can arrive from a residential IP address, present valid credentials, and behave reasonably normally while carrying out activity the account owner never authorized.

At the same time, organizations increasingly want agents interacting with their services. Customers may authorize shopping assistants. Businesses may depend on automated research, monitoring, and customer support workflows.

Welcome to the wonderfully inconvenient world of deciding which automated interactions your business actually wants.

On-Demand Webinar | Beyond Human vs. Bot

Learn why human-versus-bot detection is breaking down and how session-level context helps teams evaluate AI agents, automation, and anonymized traffic.

Watch the Webinar

A Familiar IP Address Tells Only Part of the Story

An IP address remains useful evidence. The trouble begins when we ask it to explain an entire session.

Residential proxies route traffic through consumer connections, allowing an automated request to emerge from the same ISP space as ordinary customers. Attackers can spread activity across many exit IPs, weakening controls that depend on one address accumulating enough suspicious activity to trigger a block.

Consumer bandwidth can also become part of the underlying proxy infrastructure, sometimes through arrangements the person behind the connection may not fully understand, as we’ve seen across the broader residential proxy ecosystem.

Blocking every residential connection would create a fairly spectacular customer experience problem. Looking only for known malicious IPs leaves another gap: an address may have little recorded abuse history when the request arrives.

Credentials introduce a similar problem. Successful authentication establishes that someone or something supplied acceptable proof of identity. It does not establish that the account owner authorized the current activity, or that every subsequent action should be permitted.

A VPN connection alone does not prove abuse. Neither does cloud hosting or automation. Each becomes more useful when considered alongside the identity, behavior, and requested action.

Agent Authorization Needs Its Own Questions

AI agents add another layer between an authenticated identity and the activity an application sees.

A customer might authorize an assistant to compare prices. That does not automatically authorize purchases. An employee might permit an agent to summarize support records without permitting it to export the customer database.

Security teams need to understand the scope of that delegation:

• Who authorized the agent?
• Which actions and resources are covered?
• When does that permission expire?
• Which actions require human approval?
• How can access be restricted or revoked?

Recognition of a known AI service can help inform a decision. Permission still needs to be established for the specific workflow.

Content access deserves the same attention. An organization may welcome search indexing or customer-directed research while prohibiting bulk extraction of proprietary material. The Robots Exclusion Protocol explicitly states that robots.txt rules are not access authorization. Preferences need enforceable controls behind them.

Session Intelligence Connects the Evidence

The more useful question is: Should this session be allowed to perform this action?

Answering it requires combining information that often sits in separate systems:

• Identity and delegation: The authenticated account, agent identity where available, and scope of authorization.
• Behavior and continuity: Expected activity, request patterns, and changes within the session.
• Network and infrastructure: VPNs, residential proxies, data-center hosting, remote access indicators, geography, and service attribution.
• Application context: The resource being accessed, transaction value, data sensitivity, and consequences of an incorrect decision.

Infrastructure attribution can help connect activity that appears scattered across unrelated IP addresses. Application telemetry helps establish whether that activity makes sense for the account and workflow.

It is important to note, these signals support a defensible decision. They do not magically reveal intent. This approach also fits established NIST zero trust principles: network location alone should not confer trust. Authorization needs to reflect the resource being requested and the available evidence.

Give the Policy More Options Than Allow and Block

Different actions deserve different levels of scrutiny.

An approved assistant retrieving public product information may proceed with reasonable request limits. An authenticated session making an unusual account recovery request may require stronger verification. Activity attempting unauthorized bulk extraction may warrant restriction or blocking.

A practical enforcement policy needs several options:

• Allow expected activity within its authorized scope.
• Verify the user or agent’s authorization when stronger proof is needed.
• Challenge uncertain activity where the challenge is appropriate to the workflow.
• Restrict sensitive functions or data access.
• Rate-limit activity that exceeds permitted volume.
• Block prohibited activity or sessions presenting unacceptable risk.

CAPTCHA can remain one tool in that process. It cannot establish the scope of an agent’s delegated authority.

Decisions also need to be revisited as activity changes. Permission to browse a catalog should not silently become permission to change payment details.

Put the Context Where Decisions Happen

Session intelligence cannot live in another console that nobody checks until Tuesday.

It needs to inform the controls already handling traffic and access: WAFs and CDNs, IAM, bot management, API security, fraud platforms, and SOC workflows. At the edge, for example, additional infrastructure context can give existing CDN and security controls more information to work with when deciding how a session should be handled, rather than forcing policy to depend on the IP address alone. That same approach applies across CDN security and session enrichment workflows.

Session enrichment provides this network and infrastructure layer by supplying real-time context about anonymization, infrastructure, service attribution, geography, and AI-related activity to active sessions, along with a session assessment and policy recommendation that existing controls can use.

Those outputs can support the organization’s policies and downstream investigations. They complement the identity, device, behavioral, and application evidence already available, particularly when teams are trying to distinguish useful automation from activity that should be challenged, restricted, or blocked.

The same principle applies when using session enrichment to address bot and automation abuse: the signal helps inform the decision rather than replacing the surrounding evidence.

Emerging Agent Protocols Help Establish Authority

Several emerging protocols address parts of the agent authority problem.

The Agentic Commerce Protocol, developed by Stripe and OpenAI, defines an open standard for commerce flows between buyers, AI agents, and businesses.

Google’s Universal Commerce Protocol defines common commerce primitives for interactions among consumer surfaces, businesses, and payment providers.

Visa’s Trusted Agent Protocol describes cryptographic mechanisms that can help merchants verify an approved agent’s identity and associated authorization.

Google’s Agent Payments Protocol uses cryptographically signed mandates to provide evidence of a user’s authorization for agent-led payments.

For agent-to-tool interactions, KYA-OS is developing an MCP binding for cryptographic identity, delegation, and verifiable proofs.

These efforts address different layers and are at different stages of maturity. Their relevance depends on the workflow and implementation. Verified authority still needs to be evaluated alongside current behavior and application policy.

Decide How to Stop an Agent Before You Need to

Organizations can start by identifying where automation already touches their applications and defining which interactions are allowed, conditional, or prohibited.

Prioritize login, account recovery, registration, payments, and data export. Establish the evidence needed for each decision, the conditions requiring human approval, and who owns enforcement.

Then test what happens when an approved agent exceeds its scope.

Who can revoke its credentials? Can the organization disable one sensitive function while preserving useful activity? Which business process takes over if the agent must be stopped?

Those answers become harder to negotiate after an agent is embedded in a critical workflow.

The New Question: What Should This Session Be Allowed to Do?

The internet now contains people, scripts, services, assistants, and autonomous agents. Security teams need enough context to decide what each session may do, explain that decision, and change it when the evidence changes.

“Human or bot?” can still be a useful question.

“Can I trust this session to do this?” is the question our controls need to answer.

That gets more complicated as agentic traffic becomes a normal part of the application environment. The practical challenge is giving the systems already making access decisions enough context to govern what agentic AI traffic is allowed to do.

To get more granular visibility into agentic AI in your session traffic, try Spur Monocle for free up to 100,000 user sessions per month.