One note per lab: what the check measures, how to read the numbers, and what to fix first. Written from engagements, not from vendor pages. Updated when the labs change.
Note 01Web
Security headers: what the grade actually measures
The MDN HTTP Observatory grade is not a vulnerability scan. It reads the response headers of your front door and scores whether the browser is told to behave safely: HSTS forces HTTPS, Content-Security-Policy limits where scripts may load from, X-Frame-Options and the frame-ancestors directive stop clickjacking, and the referrer and cookie flags limit what leaks to third parties.
A B or better means the basics are in place. A D or F almost always means one of two things: no Content-Security-Policy at all, or HTTPS that can still be downgraded because HSTS is missing. Both are configuration, not code, and both are fixed in the web server or the CDN in an afternoon.
What the grade cannot tell you: whether the application behind the headers is safe, whether the policy is so permissive that it protects nothing, or whether internal hostnames carry the same headers. That is where a review starts.
Run the lab: Security headers grade →
Note 02Email · DNS
Six DNS records decide whether your mail can be forged
Spoofing your domain takes one line in a mail client unless DNS says otherwise. SPF lists who may send, DMARC tells receivers what to do with mail that fails, DKIM signs every message, MX proves the domain receives at all, DNSSEC signs the answers so they cannot be swapped in transit, and CAA restricts which certificate authorities may issue for the name.
The most common finding, by a wide margin, is DMARC with p=none. That policy only monitors; it lets forged mail through and merely reports it. The second is SPF ending in ~all, a soft fail that most receivers treat as a shrug. The fix is p=quarantine or p=reject once the reports show every legitimate sender is covered, and -all on SPF.
The check looks for fourteen common DKIM selector names, so a custom selector shows as missing even when signing works. Read the DKIM line as a prompt to verify, not as a verdict.
Run the lab: Email and DNS posture →
Note 03Brand
Look-alike domains: which ones matter
The finder generates up to 140 variants of your name from the patterns attackers actually use: a dropped letter, a doubled one, two swapped, a keyboard neighbour, a hyphen, a homoglyph such as rn for m, a suffix like -login, and the same name under another top-level domain. It then resolves each one to see which exist.
A domain that resolves is not proof of abuse. Some are parked by speculators, some are registered defensively by the brand itself. The ones to act on first are the variants that also carry an MX record: they can receive mail, which is what a phishing campaign needs to look credible.
Practical order: register the three or four cheapest high-risk variants yourself, add the rest to a monitoring list, and make sure DMARC on the real domain is at reject so the look-alikes cannot borrow your name in the From line.
Run the lab: Typosquat finder →
Note 04Credentials
Why a leaked password is an identity problem, not a password problem
The check hashes the password locally with SHA-1 and sends only the first five characters of that hash to Have I Been Pwned. The service returns every hash with that prefix, hundreds of unrelated ones, and the browser looks for a match. The password itself never leaves the page.
A count above zero means the exact password appears in at least one public breach corpus. Attackers feed those corpora into credential-stuffing tools around the clock. If the password is still valid anywhere, that account is one script away from being taken over, MFA or not.
The fix is never one password. It is a manager that generates unique ones, MFA that cannot be replayed, and a directory policy that blocks breached passwords at the moment they are set. The last item is what an identity review verifies.
Run the lab: Pwned password check →
Note 05Blockchain
Reading a contract without trusting its README
The X-ray reads the bytecode of a mainnet address directly from public nodes and extracts the function selectors, the proxy slots defined by ERC-1967 and older Zeppelin layouts, the owner and paused state, and the dangerous opcodes: SELFDESTRUCT, DELEGATECALL and CREATE2. Sourcify tells whether the published source matches what is deployed.
The risk signals are exactly that: signals. An upgradeable proxy means the logic can change under your feet, an owner key means one private key controls privileged functions, a mint function means the supply can grow. Each is normal for some protocols and fatal for others; the question is who holds the key and how it is governed.
Unverified source is the one signal that should stop a transaction outright. If the deployed code cannot be matched to readable source, nobody outside the deployer knows what it does.
Run the lab: Contract X-ray →
Note 06AI · text
Text that says one thing to you and another to the model
Documents, e-mails and web pages can carry instructions a human never sees: Unicode tag characters that render as nothing, zero-width joiners, bidirectional overrides that flip what the eye reads, and homoglyphs from other scripts. An LLM reads all of it. The scanner exposes those characters and then matches the normalised text against the OWASP LLM01 injection families, tool-poisoning markers and common secret formats.
A hit is a reason to look, not a verdict: legitimate text sometimes contains a zero-width joiner from a copy-paste. Two or more findings in one document, or any exfiltration pattern pointing at a URL, is a different story.
Anything that feeds an assistant, from a support inbox to a CV pipeline, should pass through a check like this before the model sees it. That control is cheap; its absence is a finding.
Run the lab: Hidden-instruction scanner →
Note 07AI · agents
The tool description is part of the prompt
When an agent connects to an MCP server, every tool description becomes text the model reads and obeys. A poisoned description can tell the model to read a private key before adding two numbers, to route all mail through one tool, or to keep quiet about it. The scanner checks names, descriptions and schemas for those markers, for sibling-tool references and for outbound URLs.
The sample manifest on the labs page shows the shape: an innocent add tool with an <IMPORTANT> block that asks for ~/.ssh/id_rsa, and a send_email tool that claims precedence over the calendar. Neither would look odd in a chat transcript.
Treat MCP servers like browser extensions with shell access. Pin versions, diff descriptions on every update, and run untrusted servers with no file or network reach. An agent review checks exactly those three things.
Run the lab: MCP tool-poisoning scanner →