MMatt Senter
nowprojectsaboutconnectblog

← Blog

The Internet Is Becoming Agent-First: From Fighting Bots to Empowering AI Agents

The web was built for humans, hardened against machines, and is now being rebuilt for machines acting on our behalf.

August 24, 2026 · Matt Senter

A robot walks from a dark anti-bot internet of blocked access and verification barriers toward a bright agent-first internet built around open APIs, trust, security, interoperability, and user control

For most of the commercial internet’s history, a bot was something to stop.

We put CAPTCHAs in front of forms. We fingerprinted browsers, scored behavior, throttled requests, challenged unfamiliar devices, and blocked entire ranges of IP addresses. We built an enormous security industry around answering one question:

Is this a real person?

Now, almost overnight, we are asking the opposite question.

How do we let a machine book the trip, compare the insurance plans, buy the groceries, reschedule the meeting, file the expense report, and operate the software on a person’s behalf?

The internet is not simply becoming more automated. It is becoming agent-first. Machines are no longer only crawling pages in the background. They are becoming users, customers, negotiators, and representatives.

That change promises a much more convenient internet. It also forces us to revisit nearly every assumption we made while defending the last one.

The web was never human-only

The early web depended on automation.

Search crawlers made pages discoverable. RSS readers collected updates. Monitoring tools checked whether sites were online. Accessibility tools transformed content into forms people could use. Archival bots preserved pages that would otherwise disappear.

The original Robots Exclusion Protocol was created in 1994 as a lightweight agreement between website owners and automated crawlers. A site could publish preferences in a robots.txt file, and a well-behaved bot could choose to respect them.

It was a social contract, not a security boundary.

The commercial web changed the incentives. Automation became a way to scrape proprietary data, stuff stolen credentials, create fake accounts, scalp scarce inventory, send spam, commit ad fraud, and overwhelm systems. A bot could perform the same action as a person, but faster, cheaper, and millions of times.

So the working assumption hardened:

Humans are legitimate. Machines are suspicious.

That assumption was never completely accurate. Plenty of humans behave badly, and plenty of bots are useful. But it was simple enough to build defenses around.

Agentic software breaks that shortcut.

A bot can now be the customer

An AI agent may arrive at a site through a browser, click the same buttons a person would, and use the same account. The traffic is automated, but the intent belongs to a real customer.

Products such as ChatGPT agent made this concrete: an agent can navigate websites, use connected data, fill out forms, conduct research, and pause for approval before consequential actions. Similar capabilities are spreading through browsers, operating systems, workplace tools, and commerce platforms.

To the website, this can look uncomfortably similar to the automation it spent decades blocking. The difference is not whether software performed the action. The difference is whose interests the software represents, what authority it has, and whether the site can verify either one.

Blocking all machines will increasingly mean blocking customers. Allowing all machines would be reckless. The old human-versus-bot test is becoming the wrong abstraction.

The new question is:

Which agent is this, who authorized it, and what is it allowed to do?

The agent-first stack is already taking shape

Today’s agents often use a visual browser because that is the one interface nearly every service already exposes. It is a clever compatibility layer, but it is also a brittle one. Buttons move. Labels change. Popups appear. A workflow designed for a person may require an agent to interpret screenshots, imitate clicks, and hope the state changed as expected.

Agent-first applications expose capabilities directly instead of forcing machines to pretend to be people. Several initiatives are filling in different layers of that future.

MCP connects agents to tools and data

Anthropic introduced the Model Context Protocol as a standard way for AI applications to connect to external data and tools. Instead of building a custom integration for every pairing of assistant and service, a developer can expose a consistent interface that multiple agent systems understand.

MCP is less like a new website and more like a standardized service port beside the website. The human interface can remain, while agents get a structured way to search, read, create, or update information.

A2A lets agents work with other agents

Google launched the open Agent2Agent Protocol so independently built agents can advertise capabilities, exchange messages, coordinate tasks, and return artifacts. A travel agent should not need access to every airline’s internal database. It may instead work with an airline’s agent through a shared protocol.

That moves the internet from pages linking to pages toward services delegating work to other services.

Commerce is being redesigned around delegated intent

Google and retail partners created the Universal Commerce Protocol to give agents and merchants a common language for discovery, checkout, and post-purchase support. The related Agent Payments Protocol is working on a harder problem: proving that an automated payment reflects the user’s authorized intent, including transactions made when the person is not present.

A checkout page was built around a person being there to press the button. An agentic transaction may happen hours later when a fare falls below a limit or an item comes back in stock. The system needs evidence of what the person authorized, not just access to a stored payment method.

Agents are beginning to identify themselves cryptographically

A user-agent string is easy to fake, and IP allowlists work poorly when agents operate from shared cloud infrastructure. Cloudflare’s Web Bot Auth work uses HTTP message signatures so automated clients can prove who sent a request. Cloudflare later added a signed-agent category for user-directed systems.

This is an important inversion. The goal is no longer to hide automation well enough to pass as a human. The goal is to make legitimate automation explicit, verifiable, and governable.

What an agent-first internet solves

The convenience case is real.

Much of the web is work disguised as navigation. We search across dozens of tabs, re-enter the same information, compare incompatible options, copy data from one system to another, wait for a condition to change, and repeat processes that software should have handled years ago.

Agents can collapse that work into an outcome:

  • Find three flights that satisfy my actual constraints, not just the cheapest headline price.
  • Move this meeting and preserve everyone’s stated availability.
  • Prepare the expense report from the receipts, then let me review it before submission.
  • Watch for this replacement part and buy it only from an approved seller below my limit.
  • Transfer the customer record without making me learn two administrative interfaces.

Agent-first access can also make software more available to people who struggle with complex visual interfaces, unfamiliar terminology, or workflows spread across multiple services. The agent can translate a person’s intent into the rigid sequence each system expects.

For developers, standardized agent interfaces can open the long tail of a product. A conventional interface must anticipate the most common paths and fit them on a screen. An agent can compose lower-level capabilities into workflows the product team never designed as a dedicated feature.

This could make software feel less like a collection of destinations and more like infrastructure that cooperates around the user.

Identity is necessary, but it is not trust

There is a temptation to treat cryptographic agent identity as the replacement for CAPTCHA.

It is only one layer.

A valid signature can prove that a request came through a particular agent provider. It does not prove that the user wanted this specific action, that the agent interpreted the request correctly, or that the agent has not been manipulated since the task began.

An agent-first system must answer at least four separate questions:

  • Identity: Which agent or service sent this request?
  • Authority: Which person or organization delegated power to it?
  • Scope: What data, actions, budget, and time window did that delegation cover?
  • Intent: Does this particular action match what the person asked the agent to do?

The distinction matters because the most dangerous agent may be a legitimate one with excessive permission.

In 2026, NIST’s National Cybersecurity Center of Excellence opened work on software-agent identity and authorization. The questions include identification, authorization, auditing, non-repudiation, and protection against prompt injection. That list is a useful reminder that “authenticated” and “safe” are not synonyms.

We should not hand an agent a master key merely because we recognize the logo on its uniform.

Prompt injection turns the web itself into an attacker

Traditional software usually distinguishes instructions from data. An application executes its code and treats a product description, email, document, or comment as content.

Language models consume both through language.

That creates the indirect prompt-injection problem. An agent researching a purchase can encounter text placed on a page to influence its behavior. The instruction may be visible, hidden in markup, embedded in a document, or disguised as ordinary content. It might tell the agent to ignore the user’s criteria, reveal private data, visit a leak URL, or take an unrelated action.

Google’s 2026 survey of prompt injections found on the public web included attempts to manipulate recommendations, deter agents, exfiltrate data, and cause destructive actions. This is no longer only a laboratory thought experiment.

There is no filter that can perfectly separate malicious instructions from legitimate content in every context. OpenAI’s work on prompt-injection-resistant agents makes the right shift: assume some manipulation will get through, then constrain the damage the agent can cause.

An agent that is reading an untrusted webpage should not simultaneously have unrestricted access to email, cloud files, financial accounts, and the ability to send information anywhere. The security boundary cannot live only inside the model’s judgment.

The assistant-with-your-keys problem

Most internet authorization was designed for applications with predictable behavior. We grant a calendar app access to calendars because its functions are known. We grant a photo editor access to photos because its operating boundary is relatively clear.

A general-purpose agent is different. Its feature is that it can decide what steps are necessary. Give it access to email, documents, the browser, payments, and messaging, and it can combine those permissions in ways no individual consent screen described.

This is ambient authority with a natural-language interface.

Convenience pushes toward persistent access: stay logged in, remember everything, connect every service, and stop interrupting me for approval. Security pushes in the opposite direction: narrow the task, minimize the data, expire the credentials, isolate untrusted content, and require a person before an irreversible action.

The right balance will not be one universal autonomy setting. It should depend on consequence.

Let an agent reschedule a low-stakes internal meeting within defined hours. Let it prepare a tax filing, but not submit it. Let it fill a shopping cart, but require approval above a budget. Let it renew the same prescription, but not choose a new medication. Let it draft a message, but make the sender visible before it speaks in your name.

The safest useful agent is not powerless. It has exactly enough power for the current job, for as long as the job should take.

The business model of the web changes too

The current web assumes a person will arrive, see the interface, absorb the branding, encounter the upsell, view the advertisement, and become part of the site’s customer relationship.

An agent may skip all of that.

It can compare products without visiting ten stores, extract the answer without reading the full article, or complete a transaction through a protocol without seeing the carefully optimized checkout page. That is wonderful for the user and potentially devastating to businesses built on attention, referral traffic, or control of the interface.

It is also why “AI traffic” is too broad a category. Cloudflare now distinguishes among search, agent, and training traffic. A search crawler may index content and return a visitor. A training crawler may consume content to improve a model. A user-directed agent may arrive in real time to complete a task. Those are different relationships and deserve different permissions and economics.

Sites will need to decide which agents they welcome, what capabilities they expose, and how value flows back when the human never arrives. Agents will need to disclose when a recommendation is sponsored, when a merchant paid for preference, and whether the agent is optimizing for the user or for the platform that controls it.

If one agent becomes the layer through which a person buys, reads, travels, communicates, and discovers, that agent may know more about the person than any search engine or social network ever did. It will not only know where they went and what they clicked. It will know what they were trying to accomplish.

Are we delegating work, or surrendering agency?

I want agents to remove administrative work from my life.

I do not want them to quietly become the authors of it. There is a difference between delegating a task and outsourcing a decision.

“Find a flight that lands before dinner” delegates work. “Plan my ideal vacation” begins to delegate preferences. “Handle my inbox” delegates judgment about which relationships matter. “Fix my finances” may allow a system to choose between values that cannot be reduced to a return percentage.

The more an agent learns, the more convenient it becomes. It can remember the seat I prefer, the people I avoid scheduling early, the causes I support, the stores I trust, the medical issues I do not want to explain again, and the price I am willing to pay to save an hour.

That same memory is an extraordinary behavioral profile.

The risk is not only privacy. An agent that filters every option can narrow the world around me. It can optimize away surprise, steer me toward the familiar, and turn its own assumptions into my future behavior. If its business model rewards a particular outcome, convenience can hide the conflict better than any banner ad ever could.

We should be suspicious of the idea that maximum autonomy is automatically the best user experience. Sometimes friction is waste. Sometimes friction is the moment when a person notices what is about to happen.

What agent-first applications should do differently

Agent-first should not mean removing the website, publishing one enormous API key, or allowing a model to improvise against production systems. It should mean designing an explicit path for delegated action.

That is the approach I am taking with Orgabot, an AI agent orchestration platform. I am building a governed fleet of agents to replace my direct interactions with the services that drive my applications. Instead of opening every dashboard, moving data between systems, and clicking through each operational workflow myself, I want specialized agents to do that work through explicit, scoped connections. The goal is not one all-powerful assistant holding every key. It is a group of bounded agents that can handle the routine work while preserving permissions, approvals, audit trails, and accountability.

I would start with these principles:

  • Make agents visible. Legitimate agents should identify themselves instead of disguising their traffic as human activity.
  • Authorize capabilities, not accounts. Grant permission to read these records, draft this change, or spend up to this amount—not blanket access to everything the user can do.
  • Separate preparation from commitment. An agent can research, compare, fill, calculate, and draft before receiving authority to send, purchase, publish, delete, or sign.
  • Bind authority to intent. Credentials should carry the purpose, limits, and expiration of the task, not merely the identity of the account.
  • Treat outside content as hostile. A page, email, document, tool result, or other agent’s message is data until a trusted policy says otherwise.
  • Keep receipts. Users and services need a durable record of what the agent saw, decided, attempted, changed, and who approved it.
  • Make access easy to revoke. Persistent convenience should never become permanent, invisible authority.
  • Preserve the human path. People still need an understandable interface to inspect, correct, appeal, and take over from the agent.

The best agent interface may be an API, a protocol server, a signed browser session, or a mixture of all three. The implementation matters less than the control model around it.

The next internet needs a better question

The anti-bot internet was built around a crude but useful challenge:

Prove you are human.

The agent-first internet needs a more demanding one:

Prove who you represent, what they asked you to do, and why this action is allowed.

We should welcome the shift. An internet that can act on our behalf could remove an enormous amount of pointless work. It could make services more accessible, more composable, and more responsive to what people actually want.

But we should not confuse fewer clicks with more control. If we rebuild the web for agents before we build identity, permission boundaries, audit trails, economic rules, and meaningful human override, we will repeat an old pattern: deploying the convenience first and discovering the trust model later.

For decades, websites tried to keep machines out. The next phase is not about opening every door.

It is about giving the right machine the right key for the right reason—and getting it back.

Matt Senter

Matt Senter

Founder, entrepreneur, and CEO based in Durham, NC, with 30 years building software and 11 companies founded. Currently Founder & CEO of Senternet and Co-Founder, COO, and CTO of BeeReady, and the builder behind Highwire, StockCar, Premail, Comoji, and Burly. More about Matt.

← All postsNext: What Will Be the First Agent-Native Programming Language? →

© 2026 Matt SenterDurham, NCBuilt for buildersAboutBlogToolsPrivacyTerms