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.19
• Effective date: 21 July 2026
• Last reviewed: 5 October 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, an unincorporated business operated from the Islamic Republic of Pakistan by its two founders, 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, OpenAI or Qwen 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 security logs, including failed login attempts, keep only a one-way hash of the IP address and user agent, computed with a secret key, together with the network the address belongs to and the browser family; staff-action security logs retain the plain IP address and user agent. Both are used 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: Seven categories of provider, each with one job: Google/OpenAI grade metadata, Alibaba Cloud grades it too and can escalate to a human, 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 bounded metadata about the interaction: the token count, the policy tag, the event type, the name of the commitment algorithm, the labels of any PII signals the SDK detected locally, the model and provider you called, how many responses you asked it for, the names of any tools you offered it, and the size of any gap in your client’s sequence numbers; with it go the policy settings the judge is asked to apply and a seven-day aggregate of your workspace’s breach and graded counts and the rate between them. Neither the Commitment nor any identifier of the event, your client, the request or the session is sent. On most plans this call uses a customer-supplied key; certain plans may instead use keys managed by Foxy Audit. Where a key managed by Foxy Audit is used (a Premium or evaluation workspace that has chosen to grade on Foxy Audit’s keys (the platform key mode; every workspace otherwise grades on its own key)), the call to the provider (Google, OpenAI or, for the Qwen judge below, Alibaba Cloud) is made under Foxy Audit’s own account, so Foxy Audit is the party contracting with that provider; where you bring your own key, you are.
• Alibaba Cloud (Model Studio), the Qwen judge: Singapore (Model Studio international region ap-southeast-1). Grades interaction metadata against your policy. It receives the same bounded, identity-blind metadata described above (never the Commitment, never an identifier, never raw prompts or responses) and, where the model asks for it, one thing the other judges never receive: aggregate counts of your own workspace's prior human-review outcomes for the same policy tag, over a fixed recent window. Those counts are how many interactions carrying that tag were escalated to a reviewer, and how many a reviewer then cleared, confirmed as a breach, or judged a policy gap, together with the length of that window. They are whole numbers and the tag itself: no reviewer's name, note or reason, and no prompt or response text. It is the one judge we give tools to, and the two tools differ in where the answer goes. When it asks for a person, the escalation is recorded inside your own workspace and nothing is sent onward. When it asks for that count lookup, the answer is sent back to the judge to grade with, so those counts do leave, to Alibaba Cloud, in Singapore. The judge provider is selected per workspace; as with the providers above, this call uses a customer-supplied key on most plans and keys managed by Foxy Audit on certain plans.
• 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): Qatar (Google Cloud region me-central1, Doha). Operates the servers behind our TLS-terminating reverse proxy. Backups are kept in two places, and only one of them is in Qatar. Nightly database dumps and avatar archives are written to the server itself, in Qatar, and kept for 14 days. Separately, Google Cloud takes a daily snapshot of the server's disk and stores it in the European Union multi-region, also kept for 14 days, so a complete copy of the data we host in Qatar is held in the EU as well. Those snapshots are taken while the machine is running, so they capture the disk as it stood at that moment rather than a cleanly closed database, which is why we keep the nightly dumps as well.

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. Deleting a workspace closes it at once and can be reversed for 30 days; after that an automated purge erases it permanently (see below for what survives that purge, and why).

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, and the records of our own staff's sign-in sessions, are retained for up to 365 days.

Sign-in security logs. Sign-in attempts, successful and failed, are recorded with the email address entered and, in place of the IP address and user agent themselves, a one-way hash of each computed with a secret key, the network the address belongs to (the /24 block for IPv4, the /48 block for IPv6) and the browser family (for example, “Chrome on Windows”). The hashes let us recognise repeated attempts from the same address without keeping the address; without the key they cannot be linked to one. These logs are retained for 30 days, after which they are deleted automatically. A failed attempt on an email address that has no account here is recorded the same way, so for that period this log can hold an email address belonging to someone who is not a Foxy Audit customer: a mistyped address, or one used in a credential-stuffing attempt against the Service. Thirty days is the shortest period over which we can still recognise a pattern of such attempts.

Session records. Each time you sign in to the dashboard we create a session record holding the IP address and user agent of that device, in plain form, so that you can see your active devices and revoke any of them. A session ends when it expires (12 hours, or 30 days if you chose to stay signed in) or when you sign out, revoke that device, or sign out everywhere. The record is deleted automatically 7 days after the session ends. A session that is still active is never deleted on this schedule, whatever its age: the period counts from the end of the session, not from its start.

Known devices. To tell you when your account is signed into from a device we have not seen before, we keep a fingerprint of each device that signs in successfully: a one-way hash, computed with a secret key, of the browser’s user-agent family and the network it connected from (the /24 block for IPv4, the /48 block for IPv6). It holds neither the IP address nor the user agent itself, and it cannot be turned back into either. Each fingerprint is deleted automatically 12 months after that device was last used to sign in.

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. Once those 30 days have passed, an automated process permanently erases the workspace in one operation: every record kept under the workspace (the audit ledger, its users and their settings, encrypted provider keys, usage records, its sign-in and session records, and the request-level security telemetry attributed to it) and then the workspace itself. What survives that purge, and why: invoices and payment records, which we retain as financial records under a legal obligation for their own period; the record that an evaluation offer was redeemed for an email address (a one-way hash of the address, not the address), kept so the same offer cannot be claimed again by deleting and re-creating a workspace; the entries in our own staff-action log that name the workspace, which are not workspace data and expire on the 365-day schedule above; any marketing form submission you made before the workspace existed, which is pre-sales data held under Section 4, not workspace data, and keeps only a reference to a workspace that no longer exists; and cookie-consent records, which are not tied to a workspace at all. Backups are not edited: the nightly dumps and daily disk snapshots described in Section 8 are each kept for 14 days and roll off on their own schedule, so a purged workspace is out of every backup 14 days after the purge.

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, and sign-in security logs keep a secret-keyed hash of them with the network block and browser family; 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 workspace data is hosted in Qatar, and daily snapshots of that server's disk are stored in the European Union. Interaction metadata also reaches sub-processors in the United States, and in Singapore where a workspace selects the Qwen judge. Neither Qatar nor Singapore is the subject of an EU adequacy decision, and for the United States we cannot yet evidence a safeguard for every sub-processor: all three destinations are set out below.

Based on the sub-processors listed in Section 8 and the region in which our own infrastructure runs: your workspace data is hosted and processed in Qatar (Google Cloud region me-central1, Doha). Interaction metadata is additionally processed in the United States by our judge providers (Google, OpenAI) and by Paddle, Payoneer, and Google Identity for the purposes described in Section 8, in Singapore by Alibaba Cloud's Model Studio where a workspace selects the Qwen judge, and in the European Union by Brevo for transactional email. Daily snapshots of our server's disk are also stored in the European Union multi-region (see Section 8), so a complete copy of the hosted data is held there as well as in Qatar. We do not process personal data in Pakistan: our founders operate the business from there (Section 1), but no customer data is currently hosted or processed on Pakistani servers.

Transfers to the United States. The safeguard Article 46 GDPR requires for a transfer from the EEA, UK, or Switzerland to the United States is 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. We cannot evidence that safeguard for every US sub-processor. Rather than state it as settled, here is where each one stands, and we update this list as agreements are executed:

• OpenAI, L.L.C.: no data processing agreement has been executed, so no Standard Contractual Clauses cover this transfer. OpenAI receives interaction metadata as described in Section 8, and receives no prompt or response content.
• Google LLC: our hosting, the Gemini judge, and Google Identity are all Google services. Google's standard cloud terms incorporate the Clauses and we expect them to apply, but we have not obtained the executed instrument and have not confirmed which of these services those terms cover. We describe this as expected, not established.
• Paddle.com Market Ltd and Payoneer, Inc.: no processing agreement has been evidenced for either, and we are requesting both.

Transfers to Singapore. Where a workspace selects the Qwen judge, interaction metadata (and, where the judge asks for it, the aggregate prior-review counts described in Section 8) is processed by Alibaba Cloud's Model Studio in Singapore. Singapore is not the subject of a European Commission adequacy decision, so this is a transfer to a third country without adequacy and it too requires a safeguard under Article 46 GDPR. No Article 46 instrument has been executed for this destination. We have entered into no Standard Contractual Clauses and no other Article 46 mechanism with Alibaba Cloud; intending to obtain one is not the same as having one, so we name none here until one exists and we will publish the date it took effect when it does.

Transfers to Qatar. Qatar is not the subject of a European Commission adequacy decision. A transfer of personal data from the EEA, UK, or Switzerland to our hosting region in Qatar is therefore a transfer to a third country without adequacy, and it requires a safeguard under Article 46 GDPR. That safeguard is not yet in place. We are putting one in place with counsel, together with the transfer impact assessment that supports it, and we will name it here, with the date it took effect, rather than describe a mechanism before it exists. If you are an EEA, UK, or Swiss customer and need a named Article 46 safeguard for any of these destinations before sending personal data, write to privacy@foxyaudit.tech and we will tell you exactly where we are.

14. Your Rights & Choices

• Access and export: your organization's audit and account records may be exported at any time. The Compliance Passport summarises the evidence for a reporting period; a machine-readable copy of the workspace data we hold about your organization and its users (the artefact that answers a right-of-access request) is the account export, available to workspace admins from the dashboard (“full account export (JSON)”) or at GET /v1/account/export. The export states its own boundaries: it names the tables it includes, those it excludes and why, and the fields it withholds.
• 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. The source ships with every release as the sdist (source distribution) on PyPI (pypi.org/project/foxy-audit, under “Download files”), so the review needs no access to any repository, and what you download is exactly the code that pip install runs.

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 effective date above will move to the date they take effect. Every revision, material or not, carries a new version number and last-updated date above.

18. Contact Us

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