Which PCI SAQ is yours, and where does card data leak in your code?
Answer six questions about how you take cards, and paste the checkout page, the server code, the
schema, the web-server config or a log excerpt. Your browser reads the SAQ each channel points
at, your merchant level, and every place your answers and your code disagree - and scans the
paste for unmasked card numbers, track data, stored or logged CVVs, card numbers in
logs and URLs, unkeyed hashes, http:// and old TLS, card fields on your own page and
third-party scripts on a payment page. Free, before you sign in, and nothing is uploaded. Then pick a
lane: the scope reading names the SAQ, the systems in scope, the data flows and how to
shrink it; the review gives exact edits for each finding, and the page re-checks them.
Card numbers, track data and secrets are masked before anything is sent.
The businesses, hosts and card numbers in the examples are invented (the numbers are Luhn-valid numbers in a test range). The first is a scope reading (it also carries a saved review of its code, one click after the scope reply), the second a review that is blocked, the third a review that is ready; each comes with a saved model reply, so you can see the whole page without signing in or spending a credit.
The scope reading names the SAQ and level, the systems in scope and why, the path card data takes, the requirements that carry the weight and how to shrink the scope - and answers every scope flag below.
What this does, and what it does not
The SAQ reading follows the eligibility criteria of the PCI DSS v4.0.1 Self-Assessment Questionnaires: how each channel takes cards decides its SAQ, keeping card data electronically makes it SAQ D, and service providers use SAQ D for Service Providers. The level uses Visa's thresholds. It is a guide: your acquirer assigns the level and decides which SAQ it accepts, and a QSA makes assessment decisions.
The scan reads text, not running systems. Card numbers are found by the Luhn check and the issuer's
number ranges, and the numbers processors publish for testing are told apart. It cannot see a key vault,
a WAF, a CSP header set by a CDN, or how your network is segmented - those are noted, not assumed.
Before a paid run, every card number is cut to its first six and last four digits, and track data,
card-code values and secret values are replaced; the model never sees them. The paid lanes see your
answers, your description, the masked paste and the page's facts, and every quote and edit they return
is checked against them. Derived from the pci-compliance agent skill by Seth Hobson
(wshobson/agents, MIT):
@wshobson/pci-compliance.
Sources are listed in llms.txt.