Trust & Security

Security is the product.

You point Audaitly at your clients' sites. That trust is the whole business, so we treat your data, and theirs, with the care a security company would.

Request early access Report a vulnerability

Tenant isolation

Every agency's data is walled off at the database.

Audaitly is multi-tenant, and we enforce that boundary where it actually counts, in the database, not just in application code.

Row-Level Security (RLS) policies scope every read and write to the organization that owns the row.
The application connects as an unprivileged role that cannot bypassthose policies, so a query bug can’t leak another agency’s data.
With no tenant context, queries fail closed, returning nothing rather than everything.

Default-deny by design

Your agency

sees only your organization's sites, audits, findings and reports

Another agency

is invisible, enforced by the database, not by hope

No session

no data, the safe failure mode

How we protect your data

The controls behind every audit.

Encryption in transit

Every connection to Audaitly is served over TLS. Traffic between your browser, our app, and our API is encrypted end to end.

Encryption at rest

Databases and stored artifacts (screenshots, reports) sit on encrypted volumes, so your data is protected even at the disk level.

No training on your data

Your sites, findings, and reports are never used to train AI models. We use foundation models via their API, which does not retain your content for training.

Scoped crawling

Audits only ever reach the URLs you explicitly authorize. Requests are guarded against SSRF so a crawl can never be redirected at internal or private infrastructure.

Role-based access

Members, admins, and superadmins get exactly the access they need. Sessions are database-backed and every privileged action is checked server-side.

Backups & recovery

Production data is backed up on a nightly schedule with a rolling retention window, and we take a fresh snapshot before every deploy.

Prompt-injection defenses

Crawled pages are untrusted input. The audit loop is built to treat page content as data, not instructions, so a malicious site can't hijack the analysis.

Network hardening

Production hosts expose only ports 22, 80, and 443 behind a firewall, run fail2ban against brute-force attempts, and apply security updates automatically.

Independent security reviews

Security-sensitive releases go through independent adversarial code review before they ship, so our own blind spots don't ride along into production.

How your data flows

From authorized URL to finished report.

Five steps, each with a control attached. No step happens without the one before it.

01
You authorize a URL
An audit starts with an explicit instruction from your team. We never crawl a site you haven't pointed us at.
02
Scoped crawl in an isolated browser
A sandboxed browser visits only the authorized pages, with SSRF navigation guards blocking any hop toward internal or private infrastructure.
03
Analysis by our AI engine
Page content is analyzed by our AI engine. Your content is never used to train AI models, and prompt-injection defenses keep page text from steering the audit.
04
Findings stored tenant-isolated
Results land in a database where Row-Level Security scopes every row to your organization, enforced by a role that cannot bypass those policies.
05
You control export and deletion
Your findings and reports are yours. Export them when you need them, and request deletion when you're done. Our DPA sets out the deletion terms.

The legal side of this pipeline, including sub-processors and deletion commitments, lives in our Data Processing Agreement and Privacy Policy.

Access and operations

Boring on purpose, where it matters.

The operational controls are deliberately unexciting: small roles, short-lived access, and the server as the only judge of what's allowed.

Least-privilege roles

The application talks to the database as an unprivileged role; a separate, narrowly scoped maintenance role handles administrative operations. Nothing runs with more access than it needs.

Database-backed sessions

Sessions live in the database, not in forgeable client-side tokens, so revoking access takes effect immediately and session state can be audited.

Server-side authorization

Every privileged action is authorized on the server at the moment it happens. UI state is never the security boundary.

Secrets stay server-side

API keys, database credentials, and signing secrets live in server-side environment configuration. They are never shipped to the browser or committed to the codebase.

Backups and continuity

If something breaks, your data doesn't.

Nightly encrypted backups

Production databases are dumped every night to encrypted storage, so there is always a recent restore point.

~14-day rolling retention

Backups are kept on a rolling window of roughly 14 days, long enough to recover from problems discovered late, short enough to honor deletion.

Pre-deploy snapshots

Every deploy is preceded by a fresh snapshot, so a bad release can be rolled back without data loss. Regular restore drills are planned as we scale.

Responsible disclosure

Vulnerability Disclosure Policy

We want to hear from security researchers, and we want the rules of engagement to be clear.

Scope

The Audaitly web application, API, and marketing site. Third-party services we rely on (hosting, email, payments) are governed by their own disclosure programs.

What we ask

Don’t access, exfiltrate, or modify data that isn’t yours; use test accounts and stop at the minimum needed to demonstrate the issue.
Don’t disrupt the service for other users (no denial-of-service, spam, or social engineering of our team or customers).
Give us a reasonable window to fix the issue before any public disclosure.

Our commitment

We will acknowledge your report within 72 hours, keep you informed as we investigate, and credit you if you’d like. Good-faith security research conducted in line with this policy is welcome here: we will not pursue or support legal action against researchers who follow it.

Report vulnerabilities to security@audaitly.ai. Please include steps to reproduce and, if possible, the affected URL or endpoint.

On our roadmap

What we're building next.

We're an early, invite-only product and we'd rather be honest about what's shipped versus what's coming.

SOC 2 Type II

Planned. We already run the practices it asks for; the formal audit comes as we scale.

Planned

Customer-managed data retention

Configurable retention and one-click deletion of a site's audit history.

Planned

SSO / SAML

Single sign-on for larger agency teams.

Planned

Found something? Tell us.

We welcome responsible disclosure. If you believe you’ve found a vulnerability, email us and we’ll acknowledge within 72 hours and work with you to get it fixed.

security@audaitly.ai