Git URL audits
We perform a shallow, read-only clone of your repo. Remote access is removed immediately after — the audit environment cannot push anything back to GitHub.
Security & confidentiality
Your code stays yours.
Smart contract auditing demands access to your most sensitive intellectual property. Here is exactly what we do with it, how we protect it, and when we delete it.
- Never trained on your code
- AES-256-GCM encryption at rest
- Deleted after delivery
- Tenant-isolated database
How your code is handled
Isolated, contained, never shared
Every audit job runs inside its own private filesystem workspace on AuditAid infrastructure. Your repository or upload lands in a directory no other job can access, with our proprietary audit methodology kept entirely separate and never included in what you receive back.
ZIP upload audits
Your archive is extracted into a private workspace. It is never routed through a third-party cloud audit service — processing runs entirely on our servers.
CI/CD integrations
PR diffs and push payloads arrive via signed GitHub webhook. Each organization's data is isolated at the database layer — cross-tenant reads are blocked at the SQL level.
Your code never trains an AI model. Audits run via a local execution runtime on our servers — your repository is not uploaded to any public AI service or audit gallery as training or evaluation data.
Data retention
We delete your code, on a schedule you control
We store the minimum amount of data for the minimum amount of time. Code and reports are purged on a clear schedule — and you can trigger deletion immediately at any point.
| What | Default timeline | Early deletion? |
|---|---|---|
| Web audit workspace & source code | Deleted 72 hours after first report download | Available immediately |
| Pre-audit quote scan | Purged automatically after 2 hours | Automatic |
| CI/CD findings (encrypted) | 90 days by default; configurable 1–3,650 days | Via dashboard or API |
| Billing metadata | Standard financial record-keeping | — |
A background process runs hourly to sweep and remove expired workspaces. When you download your report, the retention clock starts. If you want your code deleted sooner, one API call is all it takes.
Encryption & access control
Access is scoped, secrets are encrypted
Reports and job data are not publicly listable. Every audit job produces a single-use 256-bit bearer token, and only the token holder or the account owner can access that job's outputs. For CI/CD integrations, every organization gets its own encryption key.
Per-job access tokens
A 256-bit bearer token is issued once at job creation. Only its hash is stored server-side. Knowing a job ID alone is not enough to read the report — the token is required.
AES-256-GCM encryption at rest
CI/CD audit findings, organization names, and contact data are encrypted at the application layer before being written to the database. Each organization has a unique data encryption key, which is itself wrapped by a root envelope key stored outside the database.
Database row-level security
Every CI/CD query runs inside a Postgres row-level security context. Your organization can only read and write its own rows — the database itself enforces this boundary, not just application logic.
No passwords collected
Authentication is OAuth-only (Google or GitHub). CI/CD API keys are stored as Argon2id hashes — the plaintext is shown once at creation and never stored again.
API responses are sanitized
Internal fields — filesystem paths, agent identifiers, token hashes — are stripped from every response returned to browsers. Live job progress streams show generic status messages, not raw pipeline internals.
Your controls
You are in control of your data
You have direct controls over your data at every stage.
Delete a web audit now
Call POST /api/audits/:id/purge with your job token to schedule deletion within ~15 minutes.
Set findings retention
Enterprise and org plans can configure CI/CD findings retention from 1 day up to 10 years in the dashboard.
Revoke API keys
Revoke any CI/CD API key at any time from the dashboard. Rotation is immediate.
Decline analytics
Analytics only loads after explicit consent. Declining has no effect on audits or sign-in.
Third-party subprocessors
Who else touches your data, and what they see
We use a small number of infrastructure providers. Here is exactly what each one can access.
Railway (API, database, workers)
Hosts our backend and managed Postgres/Redis. Code workspaces, database rows, and server logs reside here. Railway's own backup policy applies to managed volumes independently of our application-level purge.
Cursor (AI execution SDK)
The audit agent runs via Cursor's SDK in local runtime mode on our servers. Your source code is in the workspace during the audit but is not sent to Cursor Cloud as an execution target.
Stripe (payments)
Card payments go through Stripe Checkout. We receive a payment completion webhook and record the amount and session ID only — no card numbers or CVVs are stored by AuditAid.
GitHub (CI/CD integration)
Repo content is accessed only within the scope of your GitHub App installation. Webhooks are verified using HMAC signature validation on the raw payload before any processing occurs.
Google Analytics & Microsoft Clarity (analytics)
Privacy-respecting, consent-gated website analytics — loaded only after you accept analytics cookies, never on your source code or audit data. Used to understand site usage and improve UX; you can decline with no effect on audits or sign-in.
Questions?
Get in touch
If you have questions about how we handle your data, or want to report a security vulnerability, reach out at support@auditaid.io.
This page is updated alongside the AuditAid codebase — last updated June 2026.