An analyst asks an assistant to pull last quarter's utilization by project. There is no API for that view. The agent opens a browser, signs into the professional services tool using a session the analyst authorized weeks ago, navigates three screens, applies filters, exports a CSV, and returns a clean summary in ninety seconds. It works. Nobody in IT knows it happened.
The audit log in that tool records a human user, at a human's IP address, doing something a human plausibly does. The API gateway, where the security team put rate limits, schema validation, and logging, was never touched, because the agent went through the front door like everyone else. This is agentic browsing, and it is arriving in most organizations the way shadow SaaS did: usefully, quietly, and from the business side rather than from IT.
The instinct to block it is understandable and mostly futile. The better move is to recognize what is actually new. An agent driving a browser is a non-human actor operating with human credentials at machine speed, and every access control an organization owns assumes the actor is one or the other. This article covers what breaks, how to tell agent traffic from human traffic in both directions, and the specific controls to put in place before agentic browsing is permitted rather than after it is discovered.
Because coverage is the binding constraint. Most business software exposes a fraction of its functionality through a documented API, and the parts an agent needs most are frequently in the fraction that is missing.
Consider what an ordinary operations workflow actually touches: a filtered report view that exists only in the UI, a multi-step approval built as a wizard, a vendor portal from a supplier with no integration roadmap, a legacy internal application whose API was never finished. A person handles all four without thinking. An API-first agent handles none of them without an integration project per system, vendor cooperation, and a credential negotiation. A browser-driven agent handles all four today, with no engineering work and no vendor involvement.
The tooling has moved to meet that reality. Cloudflare shipped Kitesurf in August 2026, a browser engineered for agents rather than for people, with the human-facing rendering and interaction machinery stripped out. Every major assistant platform now ships some form of computer use or browser control. Meanwhile Gartner predicts that 40 percent of enterprise applications will feature task-specific AI agents by 2026, up from less than 5 percent in 2025, which means much of this capability will arrive inside software you already bought rather than through anything your team builds.
For IT the consequence is structural, not philosophical. Years of investment went into the API layer as the control point for machine traffic: the gateway, the service accounts, the rate limits, the schema validation, the request logs. Browser-driven agents route around all of it. The control point moved and the controls did not follow.
Four controls fail simultaneously, and each failure is quiet enough that nothing alerts.
Attribution. Every action the agent takes is written to the audit log under the employee's name. Six months later, during an access review or an incident investigation, no process can separate what the person decided from what the software did on their behalf. That distinction is the entire basis of accountability in a SOX control, a customer data inquiry, or a disciplinary matter.
Least privilege. The agent inherits the full permission set of a role that was scoped for a human exercising judgment. A controller's account can post journal entries, approve payments below a threshold, and export customer data. Those permissions were sized against a person who understands consequences and works at human speed. Handing the same set to unattended software is a category error, and it is the default outcome of session sharing.
Joiner, mover, leaver. Identity lifecycle assumes one account maps to one person. When that employee changes roles, the agent's effective permissions silently change with them. When they leave, deprovisioning quietly kills a production workflow that finance depends on, and the first symptom is a missed close task, not a clean error.
Session assurance. For an agent to work unattended, something has to keep a session alive across days. That means long-lived cookies, suppressed re-authentication, and multi-factor prompts routed around or pre-satisfied. Those prompts are the control. Working around them to make the agent function removes the strongest authentication assurance in the stack, in exchange for convenience, without a decision ever being recorded.
This is not a hypothetical distribution of practice. Gravitee's State of AI Agent Security 2026 report, a vendor survey of more than 900 executives and practitioners published in February, found 45.6 percent of teams still relying on shared API keys for agent-to-agent authentication, and only 21.9 percent treating agents as independent identity-bearing entities. The market is responding: Okta signed a definitive agreement on July 30, 2026 to acquire Permiso Security, which detects threats across human, non-human, and agentic identities. Terms were not disclosed, though TechCrunch reported a price just under 200 million dollars, citing a source familiar with the deal. Identity vendors are building for this because the gap is real and widening. The related discipline is covered in our work on AI agent identity and access management and on credential delegation for AI agents.
A browser-driven agent bypasses the API gateway where machine-traffic controls live, and using a human's session destroys attribution, least privilege, lifecycle management, and MFA assurance in one move. Give every agent its own directory identity with an accountable owner, scope permissions to the task instead of copying a human role, split read from write with an approval gate, and treat page content as untrusted input.
You instrument it deliberately, because none of the usual signals survive contact with a competent browsing agent. It presents a real browser fingerprint, executes JavaScript, and moves through pages in a plausible sequence. Behavioral heuristics catch clumsy scripts, not this.
Two things make agent traffic identifiable, and both require a decision rather than a detection product. The first is identity: if the agent authenticates as itself, using its own account or a workload identity, the question answers itself in every downstream log. The second is a declared marker, meaning a distinct user agent string, a signed request header, or an egress path reserved for agent workloads. Cryptographically signed agent identity in HTTP requests is the direction the standards work is heading, and it is worth tracking, but an internally issued marker plus a dedicated egress IP range works today and costs a week.
The reason to care is operational, not academic. Once agent traffic is distinguishable, ordinary tooling starts working again. Rate limits can differ by actor type. Anomaly detection stops flagging an agent's normal burst pattern as a compromised human account. Capacity planning becomes possible. Most importantly, an incident timeline can be reconstructed, which is the difference between a two-hour investigation and a two-week one.
The same question runs in the other direction, and most organizations have not asked it. Agents are arriving at your customer-facing web properties right now, reading your pricing, filling your forms, and consuming your documentation. Some of that traffic is welcome, since being readable by AI systems is now part of being findable at all. Some of it is not. The distinction to hold is between reading and acting: an agent reading published documentation is a visitor, while an agent submitting a form, creating an account, or initiating a transaction is performing an action that deserves the same identity and rate controls as any other machine client. Blanket blocking is the wrong default in 2026 and costs visibility. Unmetered write access is worse.
Sort every action into three tiers and enforce the boundaries in the environment rather than in the prompt, because a prompt is guidance and an environment is a control.
Read and retrieve. Pulling a report, checking status, gathering context, exporting data the requester is already entitled to. This tier can run unattended once the identity and scope are right, and it is where nearly all the early value sits. Most organizations should stop here for the first quarter.
Prepare but do not commit. The agent drafts the journal entry, stages the purchase order, builds the customer reply, populates the ticket, then stops and presents the result for approval. This is the tier that produces real time savings while keeping a human accountable for the commitment, and it is the correct default for anything touching money, customers, or the record of the business. The approval must be meaningful, which means the reviewer sees what changed and what it was based on, not a blank confirm dialog that trains people to click.
Commit autonomously. The agent completes the action. This tier should be earned, one workflow at a time, with a defined value threshold, a reversal path, and monitoring in place before the first autonomous run. It should never be the setting an agent starts in.
Two mistakes recur. The first is treating "the agent has read-only access" as a complete answer, when a read-only agent that can export the full customer table has meaningful data exposure even though it changed nothing. The second is defining the boundary in the system prompt. An instruction not to submit forms is a preference. A credential that cannot submit forms is a control. Where the interface offers no such granularity, the boundary belongs in an AI gateway or control plane that sits in front of the destination and enforces it in traffic.
Because it reads content that other people wrote, and content it reads becomes input that influences what it does next. That is the whole attack. A vendor portal page, a support ticket a customer submitted, a PDF in a shared drive, or a search result can carry instructions aimed at the agent rather than at the person.
The severity scales with capability. An agent that only reads and summarizes yields a wrong summary, which is bad. An agent that reads a page, is instructed by that page to open a different internal system and export a record, and holds credentials for both, yields a data exfiltration path that no perimeter control sees, because every request is authenticated and originates inside. This is why the read and act tiers must be separated by more than intent, and why an agent's destination allowlist matters as much as its permissions. The defenses are covered in depth in our piece on defending against indirect prompt injection. The short version for browsing specifically: constrain where the agent may go, strip or neutralize instruction-like content from retrieved pages, never let untrusted page content expand the agent's tool or destination set, and require human approval for any cross-system action initiated by content rather than by the user.
Seven, and none of them are exotic. They are ordinary IT controls applied to a new kind of user, which is why most teams can implement them in weeks rather than quarters.
A practical sequencing note: discovery comes first. Most organizations already have browsing agents running, authorized by individual employees inside tools the business bought directly. Inventory before you write policy, because a policy written against an imagined footprint gets ignored by the people already doing the work. The method is the same one we describe for discovering and inventorying shadow AI agents: start from egress logs, SaaS admin consoles, and expense data rather than from a survey.
Agentic browsing is not a trend to evaluate. It is a capability already present in software your organization licensed and in assistants your employees use, and its adoption curve is being set by business teams rather than by IT. The organizations that handle it well will not be the ones that blocked it longest. They will be the ones that made agent identity a first-class object early, kept the write path gated while the read path ran free, and could answer, on any given Tuesday, which agents were operating, as whom, against what, and with what authority.
That is a governance question with an engineering answer, and the engineering is tractable. The work is identity design, permission scoping, egress control, and instrumentation, all of it built on tools most organizations already own. Teams deploying custom AI agents should design the identity and the boundary alongside the agent rather than after the first surprise, because retrofitting an access model onto a working agent usually means rebuilding how it authenticates. The broader control set is covered on our AI security page and in our AI agent governance checklist.
Our consulting practice does this work on site across Texas and Oklahoma, at each of our service area locations, and remotely for clients nationwide. Infonaligy is an AI consulting and IT services firm based in Dallas-Fort Worth, working with organizations that need AI agents to operate inside the same access discipline as everything else in the environment. To discuss agent access design for a specific workflow, contact hello@infonaligy.com or 800-985-1365.
Infonaligy works with organizations across the Dallas-Fort Worth metroplex, Texas and Oklahoma on site, with remote delivery nationwide.
Engagements start with discovery: which agents are already browsing your systems, as whom, and against what. From there we design agent identities in your directory, scope permissions to the task, set the destination allowlist and egress path, and put an approval gate between read and write. You get an agent inventory, a documented access model, working controls, and logging that tells human traffic from agent traffic. Vendor-neutral, and it runs on the identity stack you already have.
Infonaligy