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.
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 for
verification.
Proposed format
User-Agent
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 extrakey=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. |
User-Agent (proposed, fully populated)