> ## Documentation Index
> Fetch the complete documentation index at: https://docs.torch.security/llms.txt
> Use this file to discover all available pages before exploring further.

# Bot User-Agent

> How Torch identifies itself in the User-Agent header on outbound requests, for bot verification and allowlisting.

When Torch's platform makes an outbound request to a customer application, it can
identify itself with a stable, parseable `User-Agent` header. This lets your
infrastructure (WAFs, bot-management products like Cloudflare, access logs)
recognize legitimate Torch traffic.

For the source IP addresses Torch connects from, see [Bot IP Addresses](/bot/ip-addresses).

<Note>
  **Opt-in identification is on our roadmap and not yet available.** The format below
  is the proposed shape we intend to ship. It is published here so verification and
  allowlist tooling can be written against a stable contract ahead of the feature
  going live. Until then, rely on the [IP address list](/bot/ip-addresses) for
  verification.
</Note>

## Proposed format

```text User-Agent theme={null}
TorchSecurityBot/1.0 (+https://docs.torch.security/bot/user-agent)
```

The header follows the conventional product-token format
`Product/Version (comment)`:

| Component     | Example                                       | Purpose                                                                                   |
| ------------- | --------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Product token | `TorchSecurityBot`                            | Stable, unique name identifying the bot. Never changes — safe to match on as a substring. |
| Version       | `1.0`                                         | Version of the Torch bot/agent making the request. May increment over time.               |
| Info URL      | `+https://docs.torch.security/bot/user-agent` | Points back to this page so anyone seeing the traffic can learn what it is.               |

## Proposed optional parameters

For richer, opt-in identification, the comment section may carry extra `key=value`
parameters. These are **proposals** for the future feature — included so we can
settle on the contract now:

| Parameter  | Example                     | Purpose                                                                                                                               |
| ---------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| `purpose`  | `purpose=access-governance` | What the request is doing (e.g. discovery, access review, provisioning), so customers can reason about intent.                        |
| `tenant`   | `tenant=acme`               | Opaque identifier for the Torch workspace originating the request, so a customer can attribute traffic to their own Torch deployment. |
| `region`   | `region=us`                 | Which Torch region the request originates from (`us` / `eu`), aligning with the published IP set.                                     |
| `instance` | `instance=connector-a1b2`   | Opaque ID of the specific connector/agent, useful for support and debugging.                                                          |

A fully-populated example:

```text User-Agent (proposed, fully populated) theme={null}
TorchSecurityBot/1.0 (+https://docs.torch.security/bot/user-agent; purpose=access-governance; tenant=acme; region=us; instance=connector-a1b2)
```

## Match pattern

For bot-management products that match on a substring, the stable token to match is:

```text theme={null}
TorchSecurityBot
```