Foxy Audit Trust Center

The short version. Foxy Audit is built so that we structurally cannot see the content we audit. Your prompts and responses are hashed on your infrastructure, before anything reaches us. That is not a policy promise — our database has no column capable of storing raw prompt or response text. Everything below explains how the rest of the platform is secured.

Document details

• Document title — Foxy Audit Trust Page
• Version — 1.7
• Last reviewed — 4 August 2026

Contents

1. Data we never receive
2. Encryption
3. Tenant isolation
4. Audit integrity
5. Access control
6. Sub-processors
7. Certifications status today
8. Availability
9. Incident notification
10. Responsible disclosure
11. Open source

1. Data we never receive

• The raw text of your AI prompts or responses
• The data your AI systems process on behalf of your own end users
• Your BYOK provider key, in usable plaintext, outside the moment a grading call is made

Full detail: Privacy Policy, Section 3 & 5.

2. Encryption

• In transit: TLS on all traffic to and from the Service.
• At rest secrets: API keys and one-time passcodes are stored only as salted/peppered SHA-256 or HMAC-SHA-256 hashes, never in reversible form.
• At rest BYOK provider keys: encrypted using Fernet (AES-128-CBC, HMAC-SHA-256 authentication, random IV per record), bound to the owning organization and provider, so a stored credential cannot be replayed into another tenant's row or the wrong provider slot. Key rotation is supported with zero downtime.
• Not yet encrypted at rest: the OIDC client secret and the webhook signing secret are currently stored in plaintext. This is a known gap, not an oversight in this page — it's on our roadmap to close, listed here rather than left undisclosed.

3. Tenant isolation

Per-organization data isolation is enforced at the database level through PostgreSQL row-level security, using a confined, non-superuser database role for tenant-scoped transactions — not application logic alone. This means a bug in a single API route cannot, by itself, leak one organization's data into another's response.

4. Audit integrity

• Every logged interaction is chained into a tamper-evident hash ledger.
• The audit ledger, staff-action log, and blockchain-anchor receipts are read-only within our own administrative tools — there is no edit path. Where anchoring is enabled, the customer audit ledger goes further: an undisclosed edit is detectable by you, independently, rather than merely prohibited by our policy. The staff-action log is hash-chained and anchored the same way, so a removed entry is detectable by you rather than only by us. Both are tamper-evident and independently verifiable; neither is immune to change, because an anchor proves what a record looked like rather than preventing an edit.
• Optional public blockchain anchoring: a periodic root-hash fingerprint (never content) can be published to a public, independent chain — currently Sepolia by default, mainnet-configurable — so you or an independent auditor can verify ledger integrity without relying on our word alone.

5. Access control

• Optional multi-factor authentication (emailed one-time passcode, single-use, 5-minute validity).
• Optional enterprise SSO via OpenID Connect, scoped to a verified email domain with just-in-time provisioning.
• Internal admin access uses a separate signing secret from the customer dashboard, supports IP allow-listing, requires step-up authentication for sensitive actions, and is recorded in a staff audit trail that is tamper-evident, independently verifiable: an entry that is edited, removed from the middle, or re-ordered breaks the chain, and because the chain's head is published to a public blockchain, so does an entry removed from the end. Entries recorded before the chain existed are not covered by it.

6. Sub-processors

7. Certifications status today

We do not currently hold SOC 2, ISO 27001, or a comparable third-party attestation. We consider this normal for our stage and are building toward it deliberately rather than claiming it early — see our roadmap below. If a signed attestation is a hard requirement for your procurement process today, tell us; we're happy to complete a security questionnaire (CAIQ or your own SIG) in the meantime.

Roadmap: ISO 27001 gap analysis — Q2 2027. SOC 2 Type I — intended, but no auditor is engaged yet, so we are not putting a date on it. We would rather tell you that than name a quarter we might miss.

8. Availability

Current architecture runs on a single hosting provider. We target 99.5% monthly uptime at this stage; formal SLA commitments are available as part of an Order Form for paid enterprise plans. See our Service Level Agreement.

9. Incident notification

If we determine a security incident is reasonably likely to have resulted in unauthorized access to your data, we notify affected workspace administrators without undue delay. Full detail: Privacy Policy, Section 15.

10. Responsible disclosure

We welcome good-faith security research. See our Responsible Disclosure Policy — good-faith reporters following that process will not face legal action from us.

11. Open source

The foxy-audit SDK is MIT-licensed and published on PyPI. Reviewing its source — including the hashing and PII-detection logic — is the fastest way to independently verify the data-minimization claims on this page, rather than taking our word for them.

Questions this page doesn't answer? Email security@foxyaudit.tech or call +92 3398123944 — we'll answer directly, or point you to the relevant policy section.