Published 2026-04-28 — v1.1

Scanning operations

CipherCue runs an external observation programme that looks at publicly reachable systems and public metadata. This page describes what we observe, how we identify ourselves, how to verify that a request came from us, and how to opt an organisation out of observation.

What we observe

Our observation covers publicly exposed infrastructure and public metadata. We group our activity into four categories:

• Public observation. DNS records, Certificate Transparency log entries, WHOIS metadata, and similar published records.
• Service identification. TCP service banners and protocol responses on publicly reachable hosts, for the purpose of identifying the software and service in use.
• Configuration collection. Publicly visible configuration signals: HTTP response headers, TLS certificate metadata, DNS policy records (such as SPF, DMARC, DKIM, MTA-STS, CAA, DNSSEC), published trust pages, and .well-known/ resources including security.txt.
• Change detection. Comparing the current observation against prior observations for the same host to record what has changed.

Origin

Outbound observation traffic originates from US-based cloud infrastructure, operated by CipherCue. Our customer-facing web application and data stores are separate systems and do not participate in observation traffic.

We are preparing a published list of outbound IP addresses and will add it to this page when available. Until then, confirmation of origin is best obtained by emailing abuse@ciphercue.com with the source IP and timestamp from your access logs.

Request posture

• Paced enumeration. Port and service enumeration is rate-limited. We do not run floods, rapid bursts, or parallel high-volume scans against a single host.
• Service-level identification only. We record banners, protocol responses, and response metadata for the purpose of identifying software and configuration. We do not submit credentials, we do not attempt authentication, and we do not probe for vulnerabilities.
• Web observation. For each host we may retrieve a small number of publicly advertised resources, including the root document and well-known paths such as /.well-known/security.txt, /robots.txt, and customer-published trust pages. Response bodies are size-capped. We do not crawl, we do not submit forms, and we do not mutate request parameters to probe application behaviour.
• DNS. We perform public record lookups for domains in our observation set. Record types covered may expand over time as public records become relevant to our observation goals.
• Certificate Transparency. We read public CT logs. We do not submit certificates.

How to identify us

Our HTTP requests carry the headers below. These headers identify the programme, link to this page, and provide contact and opt-out routes. Headers alone are not cryptographic proof of origin: headers can be set by anyone. For authoritative verification, match the source IP against our published outbound address list (when available) or contact abuse@ciphercue.com with timestamped log entries.

User-Agent: CipherCue/1.0 (+https://ciphercue.com/scanning; observational research)
From: abuse@ciphercue.com
X-CipherCue-Purpose: external-observation-research
X-CipherCue-Methodology: https://ciphercue.com/methodology/observations
X-CipherCue-OptOut: https://ciphercue.com/opt-out
X-CipherCue-Standards: RFC-9359, NIST-SP-800-115, RFC-9116
X-CipherCue-Disclosure-Policy: https://ciphercue.com/disclosure-policy
Accept: text/html,application/xhtml+xml;q=0.9,*/*;q=0.8

Non-HTTP probes (DNS, TLS handshakes, TCP service identification) do not carry these headers by protocol necessity. Attribution for non-HTTP probes is via origin IP.

Standards and disclosure practice

Our operating practice is informed by the following references. We do not claim audited compliance or formal endorsement against any of them.

• RFC 9359 — Reliable Operation of IP Reputation Services. Informs our posture of a documented programme, identifiable origin, and a contactable operator.
• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment. Informs the scope distinction between passive observation and active testing. We stay within observation.
• RFC 9116 — security.txt. We read published contacts for coordinated disclosure routing.
• CERT/CC coordinated disclosure guidance and ISO/IEC 29147. Inform the structure of our 48-hour silent disclosure window. See /disclosure-policy.

Frequency

Observation is periodic, not continuous. An individual host is typically re-observed on a cadence of weeks rather than hours or days, and the cadence may be adjusted when change detection indicates that a recent observation has meaningfully changed. See /methodology/observations for how change detection informs cadence.

Opting out

Either of the following is sufficient on its own:

1. Publish a DNS TXT record at your apex domain: ciphercue-optout=true. We read this record on each observation pass, and once observed the opt-out is applied within seven days.
2. Email abuse@ciphercue.com from an address at a domain you control, listing the domains to be excluded. We acknowledge receipt and apply the opt-out within seven days of acknowledgement.

Full details and a self-service form: /opt-out.

Scope limits

We do not:

• Access private, authenticated, or credentialed endpoints.
• Attempt exploitation, payload fuzzing, or vulnerability validation against any service.
• Attempt to bypass access controls, rate limits, bot protection, WAF rules, or authentication mechanisms.
• Generate volumes of traffic intended to degrade the availability of an observed host.
• Observe or record individual-level personal data, beyond the contact records that are themselves part of the public observation surface (such as security.txt contacts and WHOIS abuse addresses).
• Resell raw observation data to third parties. We build commercial intelligence products on top of our own observations; we do not operate a data brokerage of the underlying records.

Contact

For questions about a specific request in your logs, opt-out confirmations, or general correspondence about this programme, email abuse@ciphercue.com.

Changelog
v1.1 — 2026-04-28 — Removed inconsistency between "continuous" and periodic cadence. Clarified that identification headers apply to HTTP probes only, and that non-HTTP probes are attributed via origin IP. Softened standards section to "informed by" rather than implying compliance. Reorganised observation categories into public observation, service identification, configuration collection, and change detection. Reworded opt-out timing to be based on acknowledgement / next observed pass. Rewrote scope-limits section to cover access controls, availability, and data brokerage concerns without over-narrowing permitted observation methods.
v1.0 — 2026-04-23 — Initial publication.