OpenAI is giving website operators a way to distinguish ChatGPT’s interactive browser from bots merely claiming to be ChatGPT. Its official allowlisting documentation says ChatGPT Work’s Cloud Browser cryptographically signs outbound HTTP requests, allowing CDNs, firewalls and origin infrastructure to verify that a request genuinely came from the service before granting it access.
The mechanism is documented in OpenAI’s Cloud Browser allowlisting guide. Cloud Browser uses Web Bot Auth and the HTTP Message Signatures standard defined by RFC 9421. Every signed request includes Signature, Signature-Input and a Signature-Agent header whose value is exactly "https://chatgpt.com".
The distinction matters because agentic browser traffic is not the same technical problem as ordinary crawling. A search crawler generally needs permission to fetch documents. ChatGPT Work’s Cloud Browser can interact with supported websites as part of a delegated user task. If a security layer blocks that traffic as generic automation, the user’s task may fail. If a site simply trusts a self-declared user agent, however, an impersonating bot could potentially receive the same treatment. Signed requests provide a third option: allow the verified agent without trusting the name alone.
The identity is cryptographic, not just a user-agent string
User-agent allowlists have an obvious weakness: strings can be copied. A malicious or unrelated automated client can announce itself as a well-known crawler even when it has no relationship with the company whose name it uses.
OpenAI’s approach instead lets a site validate the signature attached to the HTTP request. The public keys needed for verification are published through ChatGPT’s HTTP Message Signatures directory. A CDN, firewall or edge service can retrieve the relevant public key, validate the Signature and Signature-Input fields under RFC 9421, and confirm that the request was signed by the expected agent.
OpenAI explicitly tells operators using unsupported security providers to check that Signature-Agent exactly matches "https://chatgpt.com", including the quotation marks, retrieve the corresponding public key and allow the request only after successful cryptographic verification.
The header alone is therefore not the authentication mechanism. It identifies the signing agent; the signature verification is what establishes provenance.
Cloudflare exposes ChatGPT as a signed agent with a specific detection ID
For Cloudflare customers, OpenAI says the Cloud Browser is already represented in the provider’s Bots and Agents directory. Its bot tag is chatgpt-agent, and the documented detection ID is 129220581.
OpenAI’s instructions tell administrators to create a custom WAF rule under Security and select the detection ID associated with ChatGPT Operator, then configure matching requests to be allowed or skipped. Cloudflare performs the request-signature verification automatically, so customers do not need to implement RFC 9421 validation themselves for that rule.
This is a materially different control from broadly disabling bot protection. The administrator can create an exception for the provider-verified ChatGPT agent while leaving protections against unrelated automation in place.
That distinction is increasingly important as Cloudflare itself separates AI traffic into categories such as Search, Agent and Training. NetContentSEO recently covered how Cloudflare is aligning AI-bot policy across its firewall and robots.txt controls. Signed agent identity adds another layer: classification can be backed by verifiable request provenance rather than relying exclusively on behavioral detection or declared names.
Akamai and HUMAN identify it as ChatGPT Agent
OpenAI provides provider-specific instructions for Akamai as well. Akamai identifies the traffic under the existing bot name ChatGPT Agent in its Artificial Intelligence bots category. Administrators can add that Akamai-defined bot to a custom category and set the category action to Allow.
Akamai verifies the signatures automatically, according to OpenAI, so the site operator again does not need to build a custom signature-validation pipeline.
HUMAN uses the same ChatGPT Agent name. In HUMAN Sightline, the entry appears under Known Bots & Crawlers and can be explicitly allowed. HUMAN AgenticTrust additionally lets customers manage permissions associated with the ChatGPT Agent entry. OpenAI says HUMAN also verifies the request signatures automatically.
OpenAI’s current allowlisting page contains an important caveat in the HUMAN section: it says those permission settings do not alter Cloud Browser’s supported capabilities and states that, at launch, Cloud Browser cannot sign in to websites or complete payments. That wording should be read as a capability note attached to this security integration, not as a property of RFC 9421 itself.
Vercel recognizes the same traffic as chatgpt-operator
Sites hosted on Vercel require no additional allowlisting configuration under OpenAI’s documented setup. Vercel recognizes the traffic through its existing ChatGPT Agent entry, internally identified as chatgpt-operator, and automatically verifies signed requests.
The naming differences across vendors are worth documenting operationally. Cloudflare exposes chatgpt-agent and detection ID 129220581; Akamai and HUMAN use ChatGPT Agent; Vercel uses the chatgpt-operator identifier. A security team searching only for one label can therefore miss the relevant control in another provider.
The common identity underneath those vendor-specific labels is the signed ChatGPT request. That is the portable layer OpenAI is documenting for infrastructure providers that do not yet have a built-in integration.
Intermediate proxies must preserve the signature headers
Cryptographic identity can still fail operationally if infrastructure strips the information required to verify it. OpenAI’s troubleshooting guidance tells operators to ensure intermediate proxies preserve Signature, Signature-Input and Signature-Agent.
This matters for sites with several layers between the public edge and the application. A request may pass through a CDN, WAF, reverse proxy, load balancer and service mesh before reaching the component responsible for access policy. If a layer removes or rewrites the signed headers, downstream verification can fail and legitimate Cloud Browser traffic may be blocked.
Allowlisting therefore becomes an infrastructure task rather than an SEO-only configuration. Security, platform engineering and web teams need to agree where verification happens and ensure the relevant identity survives the request path up to that point.
This creates a different control plane from robots.txt
Traditional crawler governance revolves heavily around robots.txt. It is useful for communicating crawling preferences to compliant bots, but it is not a cryptographic authentication protocol and does not prove that a request belongs to the user agent it claims to represent.
Cloud Browser allowlisting operates at another layer. The question is not simply whether a machine is invited to crawl a path; it is whether the security system can verify a particular agent and permit its HTTP traffic through the edge.
The distinction is especially important for interactive agents. NetContentSEO has examined how Cloudflare can synchronize AI-bot preferences into robots.txt, but an autonomous browser that needs to operate a site can encounter WAF and bot-management controls long before crawler-policy semantics become the decisive issue.
A publisher can consequently have a permissive robots file and still block a legitimate agent at the firewall. The reverse is also possible: an infrastructure team can authenticate and permit an agent request while maintaining separate policies for search crawling or model training.
Agent identity makes selective access more practical
Without authentication, site operators face an uncomfortable choice. They can aggressively block automated browser behavior and risk breaking legitimate delegated tasks, or loosen protections and increase exposure to scraping, abuse and impersonation.
Signed agent requests make a more selective policy possible. A security system can ask whether the traffic is verifiably associated with ChatGPT before applying an exception. Other bots that copy a user-agent label but cannot produce a valid signature should not inherit that trust.
This does not mean verified traffic should automatically receive unlimited access. Authentication answers who signed the request; authorization still determines what that identity is permitted to do. A site can recognize ChatGPT and still restrict sensitive endpoints, apply rate limits, require user authentication or block actions its risk model does not permit.
That separation between identity and permission is fundamental. “Verified ChatGPT Agent” should be treated as an input into access policy, not as a universal bypass around security controls.
The agentic web needs identity in addition to discoverability
The technical direction fits a broader change in how AI systems use websites. Search crawlers discover documents. Retrieval systems select evidence. Browser agents may then need to navigate the actual application and act for the user.
NetContentSEO recently covered OpenAI’s separation of long-running work from the Cloud Browser execution layer. That architecture means a site can encounter ChatGPT through several technically distinct paths, including search discovery, integrations and interactive browser traffic.
A single “allow AI” switch is increasingly too coarse for that environment. A publisher may want search discovery, reject training use, permit a verified browser acting for a user and apply stricter controls to unknown automation. Those are different policies attached to different machine behaviors.
Web Bot Auth points toward a web where agents present credentials of their own
The deeper significance of OpenAI’s guide is that autonomous browsers are beginning to arrive with identities that infrastructure can validate. The web has spent decades authenticating human users through passwords, sessions, tokens and certificates while treating most automated clients as traffic to classify heuristically.
Agentic browsing creates pressure for something more explicit. If an AI agent can act on behalf of a real user, a website needs a reliable way to distinguish that recognized agent from an arbitrary script imitating it. HTTP Message Signatures provide a standards-based building block for that distinction.
The approach does not tell a site whether an individual action is safe, whether the user authorized a particular transaction or whether an agent should be permitted everywhere. Those remain separate questions. What it can establish is narrower and technically valuable: the request was signed by the agent identity it claims to represent.
For webmasters, the new checklist starts at the edge
Sites that want to support ChatGPT Work’s Cloud Browser should first identify where automated traffic is currently filtered. Cloudflare, Akamai, HUMAN and Vercel already expose provider-specific recognition paths documented by OpenAI. Other CDN and firewall stacks can validate the RFC 9421 signatures directly using the public key directory.
Teams should then verify that proxies preserve the three required signature headers and decide precisely what a verified agent is allowed to access. Authentication should narrow the exception, not erase existing application security.
Finally, publishers should test the actual user journey. Passing the firewall only solves the first access problem. An agent still needs usable navigation, forms, authentication flows and application states if it is going to complete a delegated task successfully.
AI agent optimization is becoming a security configuration
SEO historically asked whether Googlebot could crawl a page. GEO added questions about whether AI systems could retrieve and cite it. Browser agents add another operational layer: can the website recognize legitimate agent traffic and allow it to interact without weakening defenses against everything else?
OpenAI’s answer is now concrete enough for infrastructure teams to implement. ChatGPT Work’s Cloud Browser signs requests under RFC 9421, declares Signature-Agent: "https://chatgpt.com", publishes verification keys, and is already recognized by major bot-management and hosting providers under their own identifiers.
That does not make every ChatGPT action trustworthy by definition. It does something more precise: it gives websites a way to authenticate the agent before deciding what to trust it with.
As AI discovery evolves into AI action, that distinction may become as important to agent visibility as crawlability was to search.