Demonstration

We ran our own method against ourselves

This is a demonstration, not a client engagement. The target is penthropic.ai, our own domain. Every source used is public, every check is passive, and every finding below is real, including the two gaps it found in our own configuration.

Run 26 July 2026. Sources: public DNS and published HTTP response headers. Two gaps found and fixed the same day, both shown below.

Read this first. This page is a demonstration of method, published to show what the output looks like. It is not a client engagement, no client data appears on it, and no third-party organisation was examined to produce it. We used our own domain precisely so that nobody else is implicated in a marketing exercise.

The situation

Penthropic sells the argument that a vendor's attestation should be checked against what is actually exposed. That argument is worth nothing if we have not run it against ourselves. So we did, using only the sources available to any member of the public with a terminal.

What was verified

Four things, all of them observable without touching anything we do not own, and all of them things an attacker checks first:

  • Who is allowed to issue TLS certificates for the domain.
  • Whether mail claiming to be from us can be rejected by a recipient.
  • Which security headers the site actually returns.
  • Whether plain HTTP is redirected and whether HTTPS is enforced onward.

What was found

Two real gaps and one piece of deprecated configuration. Both gaps have since been fixed and the rows below say so, with dates. The rest was already correct, which is worth stating plainly rather than hiding.

penthropic.ai, observed 26 July 2026. Every value below is reproducible with the commands given.
CheckObservedAssessment
CAA record 9 records Fixed 26 Jul 2026 Issuance restricted to the Amazon CAs that actually issue our certificates, with iodef reporting to security@. Was: none published, so any public CA could issue.
DMARC policy p=quarantine Tightened 26 Jul 2026 Spoofed mail is now sent to junk rather than accepted. Was p=none, which instructed recipients to do nothing. Moving to p=reject once the aggregate reports confirm a clean window.
SPF policy ~all Soft Softfail rather than hardfail. Tightens to -all alongside the move to DMARC p=reject, not before, so a misaligned sender fails visibly rather than silently.
X-XSS-Protection 1; mode=block Deprecated Superseded by Content-Security-Policy, and in some legacy browsers this header introduced its own issues. Current guidance is to remove it.
HSTS max-age=31536000; includeSubDomains; preload Correct One year, subdomains included, preload requested.
HTTP to HTTPS 301 Correct Plain HTTP is redirected permanently.
X-Frame-Options DENY Correct Framing refused, so clickjacking is blocked.
X-Content-Type-Options nosniff Correct MIME sniffing disabled.
Referrer-Policy strict-origin-when-cross-origin Correct Paths are not leaked to third parties.

Check it yourself

None of this requires our cooperation, which is the entire point. Run these and you will get the same answers, or you will catch us having quietly fixed something without updating this page.

  • dig +short penthropic.ai CAA
  • dig +short _dmarc.penthropic.ai TXT
  • dig +short penthropic.ai TXT
  • curl -sI https://penthropic.ai/

What changed

Both gaps were ours, and both were fixed on 26 July 2026, the day this page published them. The commands above are unchanged, so you can verify the fix rather than take our word for it.

CAA record
Published 26 July 2026. Issuance restricted to the Amazon CAs that issue our certificates, with violation reporting to security@penthropic.ai. Verify: dig +short penthropic.ai CAA. Done
DMARC policy
Moved from p=none to p=quarantine on 26 July 2026, with sp=quarantine so subdomains inherit it. Both senders (Google Workspace and Amazon SES) are DKIM-signed and aligned, which is why this was safe to tighten. p=reject follows once the aggregate reports confirm a clean window. Done
SPF
Still ~all. It tightens to -all alongside the move to p=reject, not before. Deliberately pending
X-XSS-Protection
Deprecated and superseded by our Content-Security-Policy. Removal is a CloudFront response-headers change, not a DNS one. In progress

Over what period

The observation took under two minutes. That is the honest answer, and it is also the argument: the checks that catch the most common domain-level failures are cheap, repeatable, and almost nobody runs them on a schedule. Doing this once tells you about today. The value is in doing it every day and raising a finding the moment an answer changes.

What this demonstration does not show. It covers one domain and four checks. A real engagement covers your vendors as well as you, adds the attestations they have given you, and looks for the gap between the two. It also runs continuously rather than once.

See the same thing for a vendor of yours

The free vendor check runs the passive half of this against any domain you name. No scanning, no probing, no account required.

Run a free vendor check