Verified AI Agent Evidence: What Your Edge Logs Can Actually Prove
An edge provider can verify automated traffic while the ordinary log stream feeding observability never carries that verification result. We mapped the strongest documented identity evidence across the five managed edge/CDN providers in AIWebSignals' connector cohort and compared it with the transport AIWebSignals currently consumes.
Aggregate result
- 2/5 providers have documented verification evidence that can be carried by the current or configurable request-log path.
- 1/5 exposes the strongest documented verification result through runtime/application instrumentation rather than assuming it is present in an ordinary request drain.
- 2/5 place the strongest documented verification result in a separate security/WAF event stream rather than the connector's current standard access-log path.
This is a connector evidence-transport study, not a provider capability ranking. A provider may support sophisticated bot authentication while an access-log-only integration still loses the proof.
The coverage gap: verification can disappear in transit
Bot detection, bot naming, and bot authentication are different evidence layers. A request can look automated without establishing who sent it. A User-Agent can name an agent without authenticating that name. A provider can authenticate the request but expose the result through a different product surface than the one your observability pipeline collects.
The practical question is therefore not only can the edge verify this bot? It is also does the verification result survive into the evidence stream we retain?
Provider-by-provider evidence transport
Observed at . The cohort is fixed by AIWebSignals' five managed edge/CDN connector paths rather than selected after reviewing results.
| Provider / connector | Evidence transport class | Strongest documented signal | AIWebSignals coverage |
|---|---|---|---|
Cloudflarecloudflare | Request-log evidence available or configurable | HTTP-request Logpush BotScoreSrc can report Verified Bot; BotTags can add verified-bot detail. | Parser can safely recognize BotScoreSrc=Verified Bot as provider verification after this study's normalization fix; numeric BotScore or arbitrary BotTags alone are not identity authentication. First-party source |
Fastlyfastly | Request-log evidence available or configurable | fastly.bot.category.is_verified is a boolean verified-bot classification and Fastly real-time logging supports configurable fields. | Customers must include the verified field in their Fastly JSON/NDJSON log format; the parser recognizes the field after this study's normalization fix. client.bot.name alone remains a User-Agent-derived claim. First-party source |
Vercelvercel | Runtime/application instrumentation required | BotID checkBotId() exposes isVerifiedBot, verifiedBotName, and verifiedBotCategory for verified bots. | The current Vercel connector consumes request Log Drains. The study did not locate first-party documentation that ordinary drain records automatically include BotID's verified-bot result, so verified identity requires explicit runtime/application instrumentation into the connected record. First-party source |
AWS CloudFront / AWS WAFcloudfront | Separate security/WAF stream required | AWS WAF Bot Control logs labels including bot name, organization, bot:verified, and web_bot_auth:verified/invalid/expired/unknown_bot outcomes. | The current connector path is CloudFront standard logs through Data Firehose. CloudFront standard access logs do not carry AWS WAF Bot Control labels, so the current path cannot establish WBA verification without a separate WAF/security-log integration or explicit forwarding. First-party source |
Akamaiakamai | Separate security/WAF stream required | DataStream 2 security/SIEM logs include Bot Manager assessment when applicable; delivery/CDN streams expose a different request-telemetry field set. | The current connector is modeled on DataStream 2 delivery JSON. The strongest documented Bot Manager assessment is a security-log surface, so the current delivery parser must not infer authenticated identity from securityRules or ordinary request telemetry. First-party source |
Two identity-confidence bugs this study exposed
BotScore is not bot identity. The prior connected-log normalizer treated the presence of a bot score or non-empty bot tags as enough to raise a recognized User-Agent from claimed to strong. That conflated automation-likelihood/context evidence with named identity evidence. The parser now leaves User-Agent-only identities at claimed unless a documented verification field is present.
A textual false is still false. The prior normalizer used ordinary JavaScript truthiness on verification fields, so a string such as "false" could evaluate as true. Verification values are now parsed strictly. Only true-like values accepted by the bounded verification contract can elevate identity confidence.
Provider-declared bot names without a verified signal are also retained as claimed, not strong. These changes reduce false confidence without discarding the underlying first-party request observation.
What the current connector paths can prove
Cloudflare: HTTP-request Logpush can expose a verification source such as BotScoreSrc = Verified Bot. AIWebSignals can preserve the derived verification outcome without retaining the raw User-Agent or client IP.
Fastly: Real-Time Log Streaming is configurable. If the customer includes Fastly's verified-bot boolean in the JSON/NDJSON format, AIWebSignals can preserve it as provider verification. A bot name inferred from User-Agent remains only a claim.
Vercel: BotID exposes verified-bot information through runtime APIs such as checkBotId(). We did not locate first-party evidence that an ordinary Log Drain automatically includes those BotID results, so the current drain-only path must not manufacture verification. Explicit application/runtime forwarding is required.
AWS CloudFront / AWS WAF: AWS WAF Bot Control logs can include verified-bot and Web Bot Auth labels. The current AIWebSignals AWS path consumes CloudFront standard logs through Data Firehose, which is a different evidence stream. WAF verification therefore requires a separate WAF/security-log integration or explicit forwarding.
Akamai: DataStream security/SIEM events can carry Bot Manager assessment. AIWebSignals' current Akamai connector is modeled on DataStream delivery/request telemetry, so ordinary delivery fields must not be treated as authenticated bot identity.
Evidence contract
- Observed request: a first-party HTTP record establishes that a request occurred.
- Claimed identity: a recognizable User-Agent or declared bot name says who the client claims to be.
- Provider-verified identity: a documented edge/runtime/security signal establishes that the provider verified the automated identity under its own method.
- Behavioral inference: journeys, transitions, or likely purpose remain separately labeled and do not reveal hidden model reasoning or intent.
These layers should remain independently queryable. A stronger identity signal should upgrade the identity field, not rewrite the underlying request observation or imply business outcome, user intent, ad approval, search ranking, or model-internal state.
Methodology and limitations
The five managed edge/CDN providers represented by AIWebSignals hosted connector paths: Cloudflare, Vercel, AWS CloudFront, Akamai, and Fastly.
The study classifies where provider-native identity verification evidence is documented to become observable relative to AIWebSignals' current connector transport. A provider supporting bot verification does not mean its default access-log stream carries the verification result.
This is a documentation and connector-contract study, not a live customer certification. native_or_configurable_log_evidence means the documented provider signal can be carried in the connector's current request-log transport when configured. runtime_instrumentation_required means the verification result is exposed in application/runtime APIs rather than assumed present in the ordinary drain. separate_security_stream_required means the strongest documented verification result lives in a separate security/WAF event stream rather than the connector's current standard access-log path.
This study reviewed public first-party provider documentation and the current AIWebSignals connector/parser contract. It did not access customer consoles, impersonate agents, forge signatures, or send authenticated traffic to third-party properties. Provider products, plans, fields, and logging options can change; a documented field does not prove it is enabled for a particular customer.
Primary references
- Cloudflare: HTTP request Logpush fields
- Cloudflare: Verified bots and agents
- Fastly: verified-bot category field
- Fastly: client.bot.name limitations
- Vercel: BotID verified bots
- AWS WAF: Bot Control labels
- Akamai DataStream 2: security/SIEM data format
Last reviewed September 8, 2026.
Related AIWebSignals evidence
Related technical evidence
Web Bot Auth edge-support study · AI Bot Index · Connect first-party AI traffic