Privacy Policy

On-device by design. The foxy-audit SDK computes every cryptographic commitment on your own infrastructure, before anything is sent to us. We structurally cannot see the raw text of your AI prompts or responses — not because of a policy promise, but because our servers have no field capable of storing them. See Section 3.

Document details

• Document title — Foxy Audit Privacy Policy
• Version — 3.9
• Effective date — 21 July 2026
• Last reviewed — 4 August 2026
• Document owner — Foxy Audit

Contents

1. Introduction & Scope
2. Definitions
3. Our Architecture: Runtime Security Without Raw Data
4. Information We Collect
5. Information We Do Not Collect
6. How We Use Information
7. Legal Bases for Processing (EEA / UK)
8. Sub-processors & Third Parties
9. Data Retention & Deletion
10. Security Measures & Blockchain Anchoring
11. Access Controls & Authentication
12. Cookies
13. International Data Transfers
14. Your Rights & Choices
15. Security Incidents & Breach Notification
16. Additional Disclosures
17. Changes to This Policy
18. Contact Us

1. Introduction & Scope

Foxy Audit is a Runtime Auditing and Security Management platform for AI systems — what Gartner's framework calls an "AI TRiSM" (Trust, Risk, and Security Management) platform. This Privacy Policy explains how Foxy Audit, a company incorporated in and operating from the Islamic Republic of Pakistan, collects, uses, and protects information in connection with the customer dashboard at app.foxyaudit.tech, the marketing site at foxyaudit.tech, the open-source foxy-audit SDK (MIT-licensed, published on PyPI), the desktop application, and the admin console (together, the "Service"). Where the desktop app's optional AI chat feature is used, prompts are sent directly from your device to the AI provider you configure (for example Anthropic, OpenAI, or a local model), using your own API key — Foxy Audit is not an intermediary for that traffic and does not receive it. Foxy Audit currently operates online without a registered physical office; this section will be updated with a registered legal entity name and address once formal SECP registration is complete.

It applies to workspace account holders, the individuals they invite to a workspace, and visitors to our sites. It does not separately govern the AI systems our customers operate — those remain the customer's own responsibility as data controller for their own end users.

A note on applicable law. Pakistan has not yet enacted a comprehensive personal data protection statute; the Personal Data Protection Bill remains in draft form before Parliament. In the interim, data-related conduct is primarily governed by the Prevention of Electronic Crimes Act, 2016 (as amended in 2025). Because we serve customers internationally, we have voluntarily built this Policy to the higher standard of the GDPR and comparable frameworks (see Sections 7 and 13–14) rather than waiting for Pakistani law to catch up, and we will update this section promptly once the Bill is enacted.

2. Definitions

• "Personal Data" means information relating to an identified or identifiable individual, as defined under applicable law.
• "Service" means the Foxy Audit dashboard, marketing site, SDK, desktop application, and admin console, collectively. Our Terms of Service uses the same definition for customer-facing purposes, except that it excludes the admin console, which is internal-only and not made available to customers.
• "Compliance Passport" means the exportable evidence package (audit ledger records, policy findings, and anchor receipts where enabled) a workspace administrator can generate from the dashboard at any time, including after cancellation.
• "Workspace" means a customer's organization-level account within the Service.
• "Sub-processor" means a third party we engage to process data on our behalf, as listed in Section 8.
• "Commitment" means the SHA-256 or HMAC-SHA-256 cryptographic digest computed from an interaction, on your infrastructure, as described in Section 3.
• "Anchor" means the optional publication of a Commitment fingerprint to a public blockchain, as described in Section 10.

3. Our Architecture: Runtime Security Without Raw Data

In short: The SDK hashes your prompts and responses on your own servers. Only the hash — never the content — reaches us.

Most AI observability and audit tools work by ingesting your prompts and responses onto their servers so they can be logged, searched, or reviewed. Foxy Audit is built the opposite way: it is designed as trust infrastructure that cannot leak what it never receives.

The foxy-audit SDK runs inside your own application, on your own infrastructure. When it observes an interaction, it computes a SHA-256 digest and a customer-keyed HMAC-SHA-256 Commitment of the prompt and response locally, in your own process, before anything is transmitted to us. Only the resulting Commitment, a policy tag, a token-count estimate, the model/agent name, and — if you enable it — client-side PII signal labels ever leave your environment. The plaintext does not.

Those Commitments are then chained on our servers into a tamper-evident audit ledger, so that you or an independent auditor can later verify that a given interaction occurred and matched a given policy outcome without our having held the underlying content at any point. This is enforced in our data model, not only described in this policy: our backend has no database field capable of storing a raw prompt or response.

4. Information We Collect

In short: Account details, hashed keys, encrypted BYOK keys, ledger hashes, usage counts, and hashed security telemetry — never your prompts.

• Account & organization data — name, email address, organization name, and role. Where you sign in with Google, we store your Google account's stable identifier and verified email address only — never your Google password.
• API keys — your SDK bearer key is stored only as a salted/peppered HMAC-SHA-256 hash; the plaintext value is displayed once at creation and is not retained by us.
• Bring-your-own AI provider keys ("BYOK") — where you supply your own Gemini or OpenAI key so our AI judge can grade interactions, the key is encrypted at rest using Fernet symmetric encryption (AES-128 in CBC mode, authenticated with HMAC-SHA-256, random IV per record, bound to the owning organization and provider). It is decrypted in memory only for the duration of a grading call and is never logged, exported, returned by our API, or written into the audit ledger.
• Audit ledger records — for each reported interaction: the Commitment described in Section 3, a token-count estimate, your policy tag, the model/agent name, event metadata, and any judge verdict — never raw prompt or response text.
• Usage & billing data — daily counts of logged interactions, tokens, and policy findings, together with billing records maintained by Paddle, our merchant of record (Section 8).
• Security telemetry — request metadata used for rate-limiting and abuse prevention. Marketing analytics and consent records hash IP addresses and user agents one-way (Section 9). Sign-in and staff-action security logs, including failed login attempts, retain the plain IP address and user agent to detect abuse and credential-stuffing patterns, and are retained per Section 9.
• Consent records — where our cookie banner records an analytics or functional choice, we log that decision (region, regulatory regime, policy version, hashed IP/user agent) as evidence that consent was validly obtained. The banner itself does not set a tracking cookie. Consent records are retained for as long as needed to demonstrate valid consent, and are not on the 90-day telemetry schedule in Section 9.
• Marketing form submissions — if you contact us through a form on our marketing site, we collect the information you submit (name, email, company, message) and, where present, campaign source tags, to respond to your inquiry.

5. Information We Do Not Collect

In short: Your prompts, your responses, your end users' data, and your BYOK key in plaintext, ever.

• The raw text of your AI prompts or your models' responses.
• The underlying data your AI systems process on behalf of your own customers or end users.
• Your BYOK provider key, in usable plaintext form, outside the moment a grading call is made.
• We do not sell personal data, and we do not use customer content to train any model — as a structural matter, we do not receive it.

6. How We Use Information

• To operate the Service: build and verify your tamper-evident audit ledger, grade interactions against your organization's policy, and generate exportable compliance evidence (the "Compliance Passport").
• To administer accounts, authentication, billing, and customer support.
• To secure the platform, including rate-limiting, abuse detection, and enforcement of per-organization tenant isolation.
• To comply with applicable legal obligations and to enforce our Terms of Service.

7. Legal Bases for Processing (EEA / UK)

Where the General Data Protection Regulation applies, we rely on: performance of a contract, to provide the Service you have subscribed to; legitimate interests, for platform security, fraud prevention, and product improvement, balanced against your rights and freedoms; consent, for analytics cookies where required; and legal obligation, for tax, accounting, and regulatory record-keeping.

8. Sub-processors & Third Parties

In short: Six categories of provider, each with one job: Google/OpenAI grade metadata, Paddle bills you, Payoneer pays us, Google handles optional sign-in, Brevo emails you, and our cloud host runs the servers. No one else touches your data.

We share a limited set of data with the following providers, strictly as necessary to deliver the Service:

• Google LLC (Gemini API) and/or OpenAI, L.L.C. — United States. Grade interaction metadata against your policy. The judge provider is selected per workspace. Raw prompts and responses are never transmitted to these providers — only the Commitment and metadata described in Section 4. On most plans this call uses a customer-supplied key; certain plans may instead use keys managed by Foxy Audit.
• Paddle.com Market Ltd ("Paddle") — Global (UK-headquartered). Payment processing, invoicing, tax handling, and merchant of record for your purchase (see Terms of Service Section 6). We do not store your card details — Paddle does, under its own security standards. Paddle's verified webhook payload for each transaction — including your name, email, and billing address — is stored by Foxy Audit as usage & billing data (see above), not only held by Paddle.
• Payoneer, Inc. — United States. Used for manual, staff-entered invoicing on select enterprise arrangements, and as the method by which Foxy Audit receives its own revenue from Paddle. Payoneer does not process or receive customer payment data as part of standard checkout.
• Google Identity — United States. Optional "Sign in with Google" authentication.
• Brevo SAS — France / European Union. Transactional email: account verification, password reset, and alert emails.
• Infrastructure / hosting provider (Google Cloud, Ubuntu VM) — United States. Operates the servers behind our TLS-terminating reverse proxy.

We do not currently hold a SOC 2, ISO 27001, or comparable third-party attestation. Should this change, this section will be updated to reference the relevant report, together with a dedicated trust page.

9. Data Retention & Deletion

In short: Ledger data lives as long as your workspace is active. Deleted workspaces are placed in a restricted, inaccessible state within 30 days of your request, and permanently erased on request — see below for how this works today.

Audit ledger. Records are retained for as long as your workspace remains active, so your compliance history stays intact and auditable. The complete ledger may be exported at any time through the Compliance Passport.

Security telemetry. Hashed IP addresses and user-agent strings are retained for 90 days by default and then purged automatically. Internal staff-action audit logs are retained for up to 365 days.

Cancellation and deletion are different actions. Cancelling a subscription ends billing at the end of the period already paid for and leaves the workspace open: an administrator can still sign in and generate the Compliance Passport described in Section 2. Deleting a workspace is the separate action described next, and it closes access.

Workspace deletion. Deleting a workspace from the dashboard immediately blocks further sign-in and API access for that workspace, and places its records in a restricted, inaccessible state. This action can be reversed by contacting us within 30 days if deletion was made in error. We are building an automated process to permanently purge data after that window; until it ships, permanent erasure is performed by our team on request, which you can make at any time through Section 18.

10. Security Measures & Blockchain Anchoring

In short: TLS everywhere, hashed secrets, encrypted BYOK keys, database-enforced tenant isolation, and optional public blockchain anchoring for independent proof.

• All traffic to and from the Service is encrypted in transit using TLS.
• API keys and one-time passcodes are stored only as salted/peppered SHA-256 or HMAC-SHA-256 hashes. As described in Section 4, marketing analytics and consent records hash IP addresses and user agents one-way; sign-in and staff-action security logs retain the plain address to detect abuse.
• BYOK provider keys are encrypted at rest using Fernet (AES-128-CBC with HMAC-SHA-256 authentication), bound to the owning organization and provider, with support for key rotation without downtime.
• Per-organization data isolation is enforced at the database level through PostgreSQL row-level security, in addition to application-level checks, using a confined, non-superuser database role for tenant-scoped transactions.
• Security-hardening HTTP response headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and HTTP Strict Transport Security in production) and a request body-size limit are applied throughout.
• Public blockchain anchoring — customers may optionally publish a periodic cryptographic fingerprint (a root hash — never personal data or content) of their audit ledger to a public, independent Ethereum-compatible blockchain, currently the Sepolia network by default, using an on-chain AnchorRegistry contract. Anchoring is chain-agnostic and configurable, including to Ethereum mainnet, and is enabled per workspace rather than on by default. Where enabled, anchor transactions are independently viewable on a public block explorer (Etherscan), letting you or a third-party auditor verify ledger integrity without relying on Foxy Audit's word alone; where not enabled, no on-chain reference is published or implied.
• The audit ledger, staff-action log, and blockchain-anchor receipts are structurally read-only within our own administrative tools, such that undisclosed staff edits are not possible without detection.

11. Access Controls & Authentication

Multi-factor authentication. Available on an opt-in basis per account, using an emailed one-time passcode (six digits, single use, five-minute validity, stored only as a SHA-256 hash). Authenticator-app (TOTP) based MFA is not currently supported.

Enterprise single sign-on. Available on an opt-in basis per organization, using OpenID Connect (OIDC). SAML is not currently supported. An identity-provider connection is scoped to a verified email domain, and new users from that domain are provisioned into the correct organization only, on a just-in-time basis.

Administrative access. Our internal administrative console uses a session-signing secret distinct from that of the customer dashboard, supports an optional IP allow-list, and requires step-up authentication for sensitive actions. Every administrative action 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.

12. Cookies

We use a small number of first-party cookies to maintain sign-in state and basic security on the dashboard (including a staff session cookie and a CSRF-protection cookie) — full detail, including exact retention periods, is in our Cookie Policy, not repeated here to avoid the two documents drifting out of sync. Our marketing site displays a geography-aware consent banner (opt-in in the EEA/UK, opt-out in jurisdictions such as the United States) prior to setting any optional first-party analytics cookie. We do not use third-party advertising or cross-site tracking cookies. See our Cookie Policy for full details.

13. International Data Transfers

In short: Your data is processed in the United States (our hosting infrastructure, Google, OpenAI, and Paddle) and the European Union (Brevo).

Based on the sub-processors listed in Section 8 and the region in which our own infrastructure runs, data is processed in the United States (our hosting provider, Google, OpenAI, and Paddle) and the European Union (Brevo). Where personal data is transferred from the EEA, UK, or Switzerland to the United States, we rely on the EU Standard Contractual Clauses, together with the UK International Data Transfer Addendum for UK transfers and Swiss Federal Act on Data Protection safeguards for Swiss transfers, as our transfer mechanisms. We do not process personal data in Pakistan — our operating company is incorporated there (Section 1), but no customer data is currently hosted or processed on Pakistani servers.

14. Your Rights & Choices

• Access and export — your organization's audit and account records may be exported at any time through the Compliance Passport.
• Correction — account and organization details may be updated directly from the dashboard.
• Deletion — a workspace may be deleted from the dashboard (see Section 9), or permanent erasure may be requested by contacting us.
• Configuration — organization-level Policy settings allow you to control PII-detection and enforcement behavior.

Rights by region

We do not limit these rights to any one region — the list below names the frameworks we specifically align with; if your home jurisdiction is not listed, the general commitment in the final paragraph of this section still applies to you in full.

• European Economic Area, UK, Switzerland (GDPR / UK GDPR): rights of access, rectification, erasure, restriction, portability, objection, and the right to lodge a complaint with your local supervisory authority.
• California (CCPA/CPRA) and other U.S. states with comprehensive privacy statutes (including Virginia, Colorado, Connecticut, Utah, and others as they take effect): rights to know, delete, correct, and opt out of the sale or sharing of personal information — we do not sell or share personal information as those terms are defined under these laws.
• Brazil (LGPD — Lei Geral de Proteção de Dados): rights of confirmation, access, correction, anonymization, portability, deletion, and information about with whom your data is shared, exercisable through the same contact channel below.
• Canada (PIPEDA and applicable provincial law): rights of access to, and correction of, your personal information, and the right to withdraw consent where consent is the basis for processing.
• Singapore (PDPA), Australia (Privacy Act 1988), and other jurisdictions with comprehensive privacy frameworks: we extend equivalent rights of access, correction, and deletion on request.
• Pakistan: while the Personal Data Protection Bill remains in draft form (see Section 1), we extend the same rights described above to individuals in Pakistan as a matter of policy, not only where currently legally mandated.

Our general commitment

Regardless of where you are located, on a verified request we will provide access to, correct, delete, or export your personal data, consistent with the architecture described in Section 3 (which structurally limits what we hold in the first place). We will respond to a verified request within 30 days (the standard period under GDPR Article 12; where a shorter period applies under other law, including certain U.S. state statutes, we will meet that shorter period). Such requests may be directed to us at privacy@foxyaudit.tech or as set out in Section 18.

15. Security Incidents & Breach Notification

In the event of a security incident that we determine is reasonably likely to result in unauthorized access to, or disclosure of, personal data we hold, we will notify affected workspace administrators without undue delay and in accordance with applicable law, together with a description of the nature of the incident and the steps being taken in response.

This section addresses incidents affecting Foxy Audit's own systems. It is distinct from the in-product policy-breach alerts your organization may configure to notify your own team when a logged AI interaction violates your organization's policy (see your Workspace notification preferences).

16. Additional Disclosures

Children. The Service is intended for business use by adults and organizations; we do not knowingly collect personal data from anyone under 16. If you believe a minor has provided us data, contact us and we will delete it.

Open source. The foxy-audit SDK is published under the MIT License. Reviewing its source — including the hashing and PII-detection logic described in Section 3 — is the fastest way to independently verify the data-minimization claims in this Policy, rather than taking our word for them.

17. Changes to This Policy

We may update this Policy from time to time to reflect changes in our practices or for legal, operational, or regulatory reasons. Material changes will be communicated to account holders by email or in-app notice prior to taking effect, and the version number and effective date above will be revised accordingly.

18. Contact Us

Questions regarding this Policy, or requests concerning personal data, may be directed to privacy@foxyaudit.tech.