Skip to content

Securing the Agentic Internet: Identity, Integrity, and Authority

Cloudflare Connect 2026 Exhibition

Cloudflare Connect 2026 definitively made the case that the agentic internet is here. The next step is making sure an agent that can prove who it is can also prove it is still the genuine software, and that it is allowed to do what it is about to do.

We spent this week at Moscone West for Cloudflare Connect. One message ran through the keynotes, the breakouts and the hallway: agents are no longer a forecast. Cloudflare told the room that agents made more than 600 billion requests across its network last quarter, close to four times the level at the end of 2025. Matthew Prince said he expects agent traffic to outgrow human traffic by up to three orders of magnitude within five years, and that his past forecasts have consistently erred on the low side.

Three themes stood out to me.

#1 Agents have to be found, recognized and paid. Prince's example stuck with me: ask an agent for lunch nearby and it reads the sites of thousands of venues, then sends you to one. Cloudflare's response runs from discovery tools to Web Bot Auth and signed agents, through to payments with the Monetization Gateway and Wallets. Mastercard's Jorn Lambert showed an agent buying services within a spending limit it could not exceed.

#2 Most automated traffic still won't say who it is. Cloudflare put the share of automated requests that come from a self-identifying bot at fewer than one in ten. Its answer is to classify the rest from telemetry across its network, and to let agents vouch for the humans behind them. Also this week, Cloudflare began continuously checking whether Verified bots keep honoring site preferences, rather than trusting them once and forever.

# 3 Least privilege, at machine speed. Cloudflare's Agent Access Model, published in August, starts from a rule I would put on every security team's wall: do not trust the run. Credentials are brokered per task, and every action is mediated. The Cloudflare API MCP server now supports step-up authorization, so an agent connects with minimal scopes and asks for more only when a tool call needs them. This is exactly the right instinct, and it is currently shipping, not just being talked about.

Stephanie Cohen added the network infrastructure argument in one line of arithmetic: in a second and a half, an agent 50 milliseconds from the network makes 30 calls, while one 300 milliseconds away makes only five calls. Agents are frenetic, so distance compounds. Security checks will have to be fast enough to sit in that loop.

Cloudflare is treating agents as first-class traffic, with identity, payment and policy designed in rather than added on. For Approov this is very familiar ground and we have worked with Cloudflare on the mobile half of this problem for some time. Approov’s mobile attestation is available through both Cloudflare Bot Management and API Shield, so their customers can deterministically distinguish a genuine, untampered app on an untampered (i.e. safe) device from a script imitating one, and enforce that decision at the edge with minimal latency. Seeing this same rigor applied to agents is encouraging, and we are glad to become part of that conversation.

The Elephant in the Room: Identity is not Authority

Much of what we heard this week answers one question: who is this agent? Signatures, agent directories, name services and credentials that vouch for a human all serve that question. It is essential work, however identity is only the first of three questions a protected service has to answer before it acts:

  1. Identity: who is this?
  2. Integrity: is it still the genuine, unmodified software, running where it claims to run?
  3. Authority: is it allowed to do this particular thing, for this person, right now?

A signature proves possession of a key. It does not prove that the software holding the key is the software that was registered, that the key was not copied along with it, or that this request sits inside what the user actually delegated. Answer the first question well and assume the other two, and you have rebuilt the exact same conditions behind a decade or two of API breaches.

We have Seen this Film Before, with APIs

Mobile APIs taught the lesson the hard way. API keys shipped inside apps can always be extracted in minutes, even when obfuscated. OAuth tokens only proved a user had logged in, not that the request came from the genuine app. Attackers replayed traffic from scripts, emulators and repackaged apps that looked perfect on the wire. Stronger user authentication could not fix it. What has worked is attesting the client software itself at run time, and making the API's behavior conditional on the result, and even then only briefly through short-lived tokens.

MCP servers are just APIs with a much bigger blast radius. A tool call does not just read a balance; it books, pays, sends and deletes. The client on the other end is now software whose behavior is shaped by whatever it last read. The MCP (Model Context Protocol) authorization specification has done serious work here, with OAuth-based authorization, protected resource metadata and step-up scopes. Those bind access to a user's consent. On their own, they do not tell the server that the agent presenting the token is the genuine one. If we protect MCP servers the way we protected APIs, with bearer tokens and hope, we will relive the API decade in a fraction of the time.

Why Mobile is Where this Gets Decided

Agents are rapidly moving onto phones, inside apps and the operating system, because that is where people, their credentials and their payment methods are. It is also where an attacker controls the hardware: rooting, hooking, emulating and cloning are routine. A server-side agent inherits some protection from the data center it runs in. A phone gives none by default.

The good news is that every modern phone carries secure hardware, a trusted execution environment (TEE), that can create a key which never leaves the chip. That gives each agent instance an identity that cannot be copied along with the app. Hardware alone is not enough, as a key in the TEE only proves which device signed; it does not prove that the software asking it to sign is untampered. Therefore a device alone should never be the judge of its own integrity.

Binding Identity to Authority

The architecture the industry needs is straightforward to describe:

  • A per-instance key generated in the device's secure hardware and never exportable.
  • A fresh challenge from the cloud, answered with a measurement of the agent's running software, including the configuration that shapes its behavior, and signed with that key.
  • Verification in a secure cloud service, not on the device, against what the publisher actually released and the device's integrity state.
  • Only then, a short-lived token is bound to that instance, to one audience such as a single MCP server, to narrow scopes, and to prove that the caller still holds the device key. Revoke the instance centrally and its access lapses within one token lifetime.

The agent never grades itself and can never mint its own credentials. A copied agent, while identical byte for byte, still cannot answer the challenge because it lacks the key. That is what binding identity to authority means in practice: authority is issued only to proven instances, scoped to the job, and it expires quickly.

The Hardest Parts are Still Ahead

Even a genuine, attested agent can be talked into the wrong action by something it reads: a poisoned web page, an email or a tool result. The agent is real, unmodified and doing exactly what it was told, by the wrong party. Identity and integrity do not settle that on their own. Cloudflare's "do not trust the run" points the right way, and the research community is working hard on it. We believe it is the hardest open problem in agent security.

What to do Now

For developers and CISOs, five steps that cannot wait on new standards:

  1. Inventory MCP servers and agent-facing APIs. Treat any static API key an agent holds as already leaked.
  2. Adopt MCP authorization with minimal and step-up scopes. Give each task only what it needs.
  3. Require proof of possession so tokens are not bearer artifacts that work for whoever holds them.
  4. Ask three questions of every agent that calls you: who is it, is it the genuine instance, and under what authority does it act? If your stack answers only the first, you know where the gap is.
  5. On mobile, anchor agent identity in device hardware but verify it in the cloud, and enforce at the edge before traffic ever reaches your origin.

Connect showed Cloudflare building the roads, the toll booths and the number plates for the agentic internet. Number plates matter, but even a plate still does not tell you who is driving, or whether they were allowed to take the car. We are moving at lightning speed; this time, let's not repeat the API decade. Attested agents, and MCP servers that insist on them, should be the bar.

 

Sources

 
, ,
Ted Miracco

CEO of Approov
Ted’s high-technology experience spans 30 years in cybersecurity, electronic design automation (EDA), RF/microwave circuit design, semiconductors, and defense electronics.

Popular Posts

See all blogs