Skip to content

Security

Report a vulnerability to operations@aqx.llc. Below: what a receipt records, how API keys are stored, what infrastructure runs PIT, and which certifications we do and do not hold.

Policy dated 26 August 2026. Machine-readable copy: /.well-known/security.txt (RFC 9116). Operator: AQX LLC.

Reporting

Email operations@aqx.llc with Security at the start of the subject, and include the host, the path, and enough detail to reproduce. Please use email, not a public tracker or forum, while a hole is still open.

Fetching a public URL is fine. Scanning, fuzzing, and load testing need a note to the same address first. There is no bug bounty.

Receipts and hashes

A receipt is one line recording a single fetch: the URL, the SHA-256 of exactly what came back, the length, and the time it arrived. Every fetch that becomes corpus data writes one. Here is a line off the SEC acceptance-header tape, wrapped to fit:

data/raw/sec/acceptance/2023-03/2023-03-10/headers.jsonl line 1 of 1,867

{"accession":"0000003499-23-000010","cik":"3499","form":"8-K",
 "url":"https://www.sec.gov/Archives/edgar/data/3499/000000349923000010/0000003499-23-000010.hdr.sgml",
 "http_status":200,
 "sha256":"6f457640825b4a925280e238595dc6dcdc09d2b0c6153f5304d8126b04e81b0a",
 "bytes":776,
 "received_at":"2026-08-25T13:38:47Z",
 "acceptance_at":"2023-03-10T21:17:33Z"}

A coverage certificate is our day-by-day statement of what we read and what we found. The one for 2023-03-10 counts 3,124 rows against 1,867 receipts. A receipt covers one accession, which is the SEC’s id for a single filing. A row is narrower: one filing paired with one filer. The widest filing that day, 0001104659-23-031376, produced eleven rows from one set of header bytes.

Receipts append to a per-day file, one flushed write each, so a crawl that dies halfway keeps every answer it already had. That same file is the resume state: a restart reads the receipts on disk rather than a separate progress counter that could disagree with them. Only a definitive answer earns a receipt, so a fetch that failed in transit is simply retried on the next run.

We keep the fetched bytes themselves, not only the parsed rows. The bytes and their receipts are the archival record; the copy in Cloud Storage is what serves traffic. Corrections are appended, never written over the top. revision_id and supersedes link a row to the row that restates it. A query bounded to an earlier instant still returns what the record said then.

MANIFEST.json lists every published partition (one file of stored rows), and corpus_version is sha256: plus the hash of that file. It appears in every /v1 response body, in the X-Corpus-Version header, and inside the ETag. If a backfill changes what a historical query returns, that version changes with it, so a cached client sees the change instead of missing it.

Every stored month can be re-checked against its own evidence. That means the certificate for each day, the receipts that vouch for the bytes, a fresh parse of those bytes against the rows we published, row identity, and the day-end clock. The same check repairs a damaged month, which is rebuilt from bytes we already hold rather than re-fetched. If a hash disagrees, or if a fresh parse would move rows between days, the rebuild stops and writes nothing.

API keys

AreaWhat is in place
ShapeA key is pit_live_ followed by a 256-bit random secret in base64url. In a hosted environment that is the whole string: prefix, then secret.
At restOnly the SHA-256 of the full string is stored, in Cloud SQL Postgres. The raw value is shown once, at creation, and cannot be read back.
In the dashboardEach key lists as a prefix hint — pit_live_ plus four characters — with its created and last-used times, and can be revoked from there.
SessionsA pit_session cookie signed with HMAC-SHA256, HttpOnly, SameSite=Lax, Secure whenever the app is hosted, valid 14 days.
CSRFA readable pit_csrf cookie pairs with the X-CSRF-Token header on cookie-authenticated POSTs. Account deletion takes the session path only and refuses a Bearer key.
LoginGitHub and Google use the authorization code flow with PKCE. Email sign-in links are single use, valid 15 minutes, and stored as SHA-256 of the token.

Infrastructure

Cloudflare terminates TLS and fronts pit.aqx.llc and api.pit.aqx.llc as Workers Custom Domains. Anycast routing and DDoS handling sit there. Behind it, one Cloud Run service in us-central1pit-prod-api, scaling between 0 and 10 instances — serves the site, the docs and /v1. A separate Cloud Run Job writes the live tape every 15 minutes.

The corpus is one Cloud Storage bucket with uniform bucket-level access, public access prevention enforced, object versioning on, and a 7-day soft-delete window. Accounts, API keys, and billing state live in Cloud SQL Postgres 16 on a private IP, with point-in-time recovery and deletion protection on. Encryption at rest is Google-managed on both; customer-managed keys are not offered.

Application secrets live in Secret Manager. Deployments authenticate to Google Cloud through Workload Identity Federation. No service-account JSON key exists anywhere: the organization policy constraints/iam.disableServiceAccountKeyCreation refuses to create one, so signed download URLs are minted through IAM SignBlob instead.

Rate limiting is counted inside the serving process. Analytics is a first-party POST /t to this origin. No third-party script loads on any page, and that is why the site has no cookie banner.

Compliance posture

PIT holds no SOC 2 report, no ISO 27001 certificate, and no third-party penetration test. Everything runs in one region, us-central1, so an outage in that region takes the API down for its duration. A commercial DPA is available from operations@aqx.llc.

Processors

Google Cloud runs compute, object storage and the database. Stripe runs checkout and the billing portal. GitHub and Google handle OAuth. An email vendor sends sign-in links. Every vendor is named at subprocessors.

Status

/status prints what /health and /v1/meta return. The process serving that page is the same process it reports on.

Related

Privacy · Terms · Changelog