# How to verify a web agent’s identity

A request can call itself a familiar crawler without coming from that crawler. To make decisions based on an agent’s identity, a website needs a check tied to the sender, such as a verified network origin or a signed request.

![Two folded ivory forms have circular openings; amber light passes through one.](https://ghostget.com/images/editorial/agentic-web-spoofing-paper.webp)

Generated with [SlopCamera](https://slopcamera.com/).

Drafted with AI and reviewed by Codex editorial review (AI).

## A user-agent name is supplied by the caller

The HTTP `User-Agent` header describes the client making a request. The caller supplies that text. A crawler name can help classify traffic, but copying the name does not require control of the crawler’s infrastructure or signing keys.

Imagine a request for a private endpoint that carries the name of a search engine’s bot. Granting access because the string looks familiar would let any caller make the same claim. The access decision needs evidence beyond the label.

## Check the sender using its supported method

Some crawlers document the network addresses or DNS checks a site can use to verify them. Signed-request systems instead let a receiver validate a signature and the identity associated with its key. Use the method the claimed sender publishes, and apply the complete check.

[Known Agents’ Agentic Web Index](https://knownagents.com/insights) distinguishes a claimed identity from its supported authentication. It counts a request as spoofed when that identity claim fails the relevant check. The failed check does not identify the actual software or person behind the request.

For a concrete example of a published verification method, [Google’s crawler documentation](https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot) describes IP-list and DNS verification. [HTTP Message Signatures](https://www.rfc-editor.org/rfc/rfc9421) defines a mechanism for signing selected parts of an HTTP message.

## Decide what that identity may do

Authentication answers who is making a request. Authorization answers whether that caller may perform the requested action. A verified bot may be allowed to read public pages while having no access to account data or publishing controls.

The same distinction matters when you give your own agent tools. Selecting an account establishes which account a request uses. It does not make every possible action on that account appropriate. A tool should define its actions and require the relevant permission for each one.

GhostGet applies that distinction through named account actions and previews for consequential writes. Its [security guide](https://ghostget.com/docs/explanation/security-model/) describes those controls. Website owners still need to enforce their own authentication and access rules on incoming traffic.