Trust center

Your data stays on your infrastructure. Everything else, you can check.

QueryAPIGate is software you run, not a service we host. This page collects what a security review asks for, with each claim pointing to where you can verify it: in the code, in CI, or on your own running server.

Read where data goes Security controls Report a vulnerability

Checked continuously:

✓Self-hostedRuns in your network. No telemetry, no licence server, nothing sent to the project.Checkevery outbound path is in the Where data goes table; a test fails if the code gains one it doesn't list

✓FIPS 140-approvedEvery algorithm, enforced by a test; the suite also runs under OpenSSL's FIPS provider.Checka test rejects any non-approved algorithm; CI runs the suite on UBI 9 with FIPS mode on (FIPS: True). Guide 57 →

✓Signed releasesImage and Helm chart signed with cosign, with SLSA provenance and an SPDX SBOM.Checkcosign verify ghcr.io/anantharajuc/queryapigate:<tag> Guide 59 →

✓Tamper-evident auditEach administrative change chained and HMAC-signed, verifiable in one command.Checkqueryapigate audit verify → Intact: entries 1 to 214 Guide 20 →

✓Reviewed before stableFeatures that guard access or data graduate only after a security review.CheckADR 17 records the rule and each graduation. The ADRs →

✓Private disclosureVulnerabilities reported privately through GitHub, never in public issues.CheckSECURITY.md: private form or email, acknowledgement within a few days. The policy →

01 · Your data

Rows pass through. Nothing is kept unless you ask.

What QueryAPIGate keeps, where it sends anything, and how to remove one person's trace.

Every table, what it holds and for how long →Erase a person →

Apps · partners · agentsget rows, masked

QueryAPIGaterows pass through · masked · not kept

Your databasesparameters bound, never logged

Every outbound path, and what bounds iteach one goes only where you point it

The log (stdout)one line per request; never the query string

Traces (OTLP)→ your collector; never a value, row or credential

/metrics→ your Prometheus; counts and timings only

Audit copies→ your file and SIEM, each entry with its place in the chain

Live events (/events)each run as it happens; not kept

AI agents (MCP)rows after masking, up to a row cap per call

Exports→ the bucket or folder you name, after maskingS3

Secret providersrequests for the secrets a connection names; nothing else

AWS

Data flows

Rows pass through and aren't kept

Results are streamed or paged to the caller after masking, and written nowhere unless you turn on the response cache or an export. Parameter values are bound, never logged, never put in a trace; the access log leaves query strings out.

Where data goes →

Data flows

Every outbound path is listed

Logs, traces, /metrics, the audit stream, live events, AI agents, exports and secret providers: each one goes to infrastructure you name. A test fails if the code gains a path the document doesn't list.

The full table →

Personal data

Erase a person on request

queryapigate history forget deletes every run and usage count for one caller, in the store and in Redis, and audits it by the caller's hash, not their name.

Guide 57 →

02 · Controls

Access, audit, cryptography and releases, on the Enterprise page

Each control is explained once, on the Enterprise page, with the guide or test that backs it.

The audit chain, on your server

#1 create_connection09:02 · hmac ✓#2 create_query09:07 · hmac ✓#3 update_key09:14 · hmac ✓edited#4 create_role09:21 · hmac ✓#5 publish_query09:30 · hmac ✓

Each entry is HMAC-signed over itself and the one before, with a key kept outside the store. Edit one and every verification from it onward fails, by name.

audit verify

            $ queryapigate audit verify
            Intact: entries 1 to 5, keyed with QUERYAPIGATE_AUDIT_KEY.BROKEN at entry 3 (update_key, 09:14:02): changed
alert audit_chain_broken raised
            the SIEM's copy verifies on its own: --file rsyslog.log
          

Access

Sign-in and roles

Single sign-on through your identity provider, four administrator roles and a break-glass key.

Identity and access →

Audit

A signed audit trail

A tamper-evident audit log you can verify, with a copy streamed to your SIEM.

Audit and monitoring →

Cryptography

Approved algorithms, signed releases

Every algorithm FIPS-approved; every release since 0.31 signed, with an SBOM and provenance.

Cryptography and supply chain →

Disclosure

Reporting and scope

How to report a vulnerability, which versions get fixes, and what we don't claim.

Shared responsibility →

03 · Documents

Documents for your review

The architecture overview, questionnaire answers, threat model, where data goes and the security policy are in the security pack. These sit alongside it, in the repository next to the code they describe.

DOC 01Support and versions	What is covered by the compatibility promise, which versions get security fixes, how deprecations work.	Open →
DOC 02Guide 57	Answering a security questionnaire from a running server, every answer checked.	Open →
DOC 03Architecture decisions	Twenty-one ADRs, including key rotation, the audit chain, secrets managers, FIPS and signed releases.	Open →
DOC 04OpenSSF Scorecard	An independent, automated check of the project's security practices, re-run on every change and weekly.	Open →

Answer the questionnaire from the running system

Guide 57 walks through a security questionnaire's data and cryptography sections, with every answer checked against your own server.

Guide 57 Threat model