Sample report · sanitised

Daily external exposure and threat-surface watch

A scheduled Ghostline run, reproduced in full. Every identifier of the organisation under watch has been removed; the structure, evidence discipline and conclusions are unchanged.

Agent: Silas Trace · Ghostline
Trigger: Scheduled automation · daily
Model: GPT-5.6 Sol · medium reasoning

Sanitised for publication. This is a real run from a live fleet, published with permission and sanitised for it. Organisation names, domains, addresses, tenant identifiers, mail routing and verification records have been removed rather than masked. Findings are described as posture classes, not literal record values.

Overall result

No significant external delta confirmed

Net-new exposures

Secrets or compromise evidence

Overall risk

Low to moderate

Escalation

No threshold triggered

Confidence

High on completed checks, medium overall

Mission summary

Defensive external monitoring across a bounded, pre-approved public surface, using passive and low-impact read-only checks only. No exploitation, no login, no credential use, no brute force, no auth bypass, no fuzzing, no deep enumeration, and no change to the state of any target.

Mission type: Defensive operations, external exposure watch
Execution path: Direct handling under an approved automation brief
Baseline: The previous day's run for the same surface
Overall risk: Low to moderate, driven by unchanged mail-hardening and inventory gaps rather than by anything new
Confidence: High for the DNS, identity and HTTP observations actually completed; medium overall because certificate-transparency, full response headers, passive service data and commercial breach telemetry were unavailable

Scope and ownership

Only assets already on the approved list were touched. Ownership was established from canonical workspace records and the prior authorised baseline before any request was made, and no ambiguous newly discovered host was probed.

2 public root domains belonging to the client organisation
4 approved web hostnames, including the marketing and application hosts
Identity-provider tenancy discovery for both roots
One collaboration-platform tenancy signal

Work completed

27DNS lookupsA, AAAA, MX, TXT, NS, SOA, autodiscover, DMARC, selected DKIM, BIMI, MTA-STS

2Identity tenancy checksOpenID configuration discovery on both roots

43Bounded web requestsRoots, robots and security metadata, approved exposure paths, identity and SAML paths

5Public exposure searchesDocuments, breach and infostealer terms, SaaS and wiki boards

2Archive availability checksHistorical snapshot presence for both roots

Findings

No significant external delta

Informational

Confidence: High within completed checks · No change from the prior baseline

No net-new exposed configuration artefact, subdomain, identity endpoint, mail regression, public document, collaboration board, breach signal or compromise indicator was confirmed.

One presentation-level change was observed: a root domain began serving a new public marketing site linking to its application login. Assessed as a presentation change, not a security exposure, and recorded as such rather than raised.

DNS and mail posture stable, with known gaps unchanged

Informational, with standing posture gaps

Confidence: High · No change from the prior baseline

Both roots resolved consistently with the previous baseline across address, mail, text, nameserver and authority records. Mail routing and sender-authentication records were present and unchanged on both. Three hardening gaps carried over from the prior run rather than appearing in this one.

Sender authentication on one root remains in monitoring mode rather than enforcement
Provider default signing selectors were not published for that same root
Transport security policy is not published for either mail domain
Brand indicator records are absent on both, which is cosmetic rather than a risk

Identity tenancy discovery stable

Informational

Confidence: High · No change from the prior baseline

Both roots returned a consistent identity-provider tenancy association, matching the prior baseline. The standing recommendation to confirm that one of those associations is the intended one remains open. Tenant identifiers were observed and are deliberately not reproduced here.

No exposed configuration artefact confirmed

Informational

Confidence: High on one estate, medium-high on the other · No change from the prior baseline

A fixed list of approved sensitive-looking paths was requested read-only across the bounded hosts, covering source-control metadata, environment files, server status and information endpoints, language info pages, framework actuator endpoints, search-index endpoints, identity configuration and SAML metadata.

One estate returned host-level not-found responses across the sensitive-looking set
The other returned its generic application shell with a 200 status rather than a hard 404, so absence is inferred from body content rather than status code
No likely secret or sensitive configuration content was observed on either

Collaboration tenancy denies anonymous access

Informational

Confidence: Medium · No change from the prior baseline

The public collaboration-platform hostname returned an access-denied response. This confirms a tenant hostname that refuses anonymous access. It is not evidence of public document exposure, and was not treated as such.

Public exposure searches returned no attributable evidence

Informational

Confidence: Medium · No change from the prior baseline

Public document searches returned nothing. Breach, leaked-credential and infostealer terms returned nothing attributable. Collaboration and wiki searches returned unrelated generic results only. This is public-search coverage, and it does not substitute for an approved commercial breach intelligence source.

Errors and limitations

Stated plainly, because a watch that hides its blind spots is worse than one that has none. Each item below is a check that did not complete, not a check that passed.

Certificate-transparency queries failed at the source, so CT and broad passive subdomain deltas were not established
The fetch path exposed status and body but not a complete response-header set, so security-header posture was not assessed
No approved commercial breach or infostealer connector was available on this run
Passive open-service intelligence was unavailable in the bounded tool path
Exact per-request timestamps were unavailable; the run records the observation date only
Binary favicon content was not fingerprinted

Recommended actions

Canonicalise both application hostnames in the approved public asset inventory
Confirm the intended identity tenancy association for the second root
Confirm provider signing for the first root, then stage sender authentication toward enforcement after alignment testing
Consider publishing transport security policy for both mail domains
Publish a security contact file where a formal vulnerability intake route is wanted
Return hard not-found or explicitly blocked responses for unknown sensitive-looking paths, which improves monitoring precision
Approve a reliable certificate-transparency source and a commercial breach intelligence source if complete daily deltas are required

Escalation and filing

No escalation threshold was triggered. No likely live secret, credible public compromise, legal or compliance consequence, ambiguous ownership requiring further probing, or need for active verification was observed. The run was written to the project's local output folder; no external filing was performed, and the durable destination was recorded rather than assumed.

Back to HumAi HQ AOS Talk to us about access