Trust & Security

1. What this page is

Assurly is a pre-deploy ship gate: it tells you what will break in production before you deploy. Customers connect repositories and let us probe live applications, so they are entitled to know exactly how we operate.

This page describes the controls that are actually implemented in the product today. It is a factual statement of our security posture, not a certification, an audit report, or a contractual warranty. Your contractual rights are in our Terms of Service; how we handle personal data is in our Privacy Policy.

3. Tenant isolation and access control

• Isolation at the database boundary. Customer records are protected by PostgreSQL Row-Level Security scoped to the owning organization. A cross-tenant read is denied by the database itself, not only by application code — so an application bug alone does not expose another tenant.
• Least privilege.Request-time API-key authentication resolves only the caller's organization. The hosted verdict API is read-only and shape-only: it returns a verdict and score, never evidence rows, raw findings, or table names.
• API keys. Keys carry 192 bits of CSPRNG entropy and are stored as a SHA-256 hash. The plaintext is displayed once, at creation, and is never persisted or logged — we cannot recover a lost key, only replace it.
• Production access. Access to production systems is limited to the maintainers who need it, and the provider accounts behind the Service are protected by multi-factor authentication.

5. Evidence handling and PII redaction

• Proof is redacted at the source. When a probe demonstrates a risk, we record the shapeof the exposure — for example “500 rows; columns: email, password_hash; sample: t***@***.com” — never full personal data. Redaction happens inside the scanner, before anything is stored or displayed.
• We prove scale without exfiltrating it.Row counts come from a count-only query, so we can state “we could read N rows” without retrieving them.
• Source code is not retained. The CLI runs entirely on your machine. Web and connected scans transmit content over encrypted connections and persist scan metadata and findings — file paths, line numbers, messages — not complete source files.
• The improvement corpus is aggregate-only. We learn from patterns: the AI-builder fingerprint, which rule fired, and whether a fix verified. It carries no finding messages, table names, organization identifiers, or per-customer rows, so it cannot surface a customer.
• Shared reports are your choice. A share link, public badge, or trust page is published only when you enable it, and stops being accessible when you revoke it.

6. Application security controls

• Transport. All traffic is served over TLS, with HTTP Strict Transport Security set to two years, includeSubDomains, and preload.
• Response headers. X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a strict Referrer-Policy, cross-origin opener and resource policies set to same-origin, and a Permissions-Policy denying camera, microphone, geolocation, and payment.
• Request hardening. State-changing routes require authentication, CSRF protection, a bounded request body, and schema validation of query, path, and body before any handler logic runs.
• Rate limiting. Per-caller limits protect the Service from abuse. The identifiers used are pseudonymised with a keyed hash before storage, so the stored value cannot be read back as an IP address or an account.
• Inbound webhooks. GitHub, Stripe, and deployment webhooks are signature-verified and processed idempotently through a unique-constraint ledger, so a replayed or forged delivery cannot double-apply.
• Sessions. The session cookie is HttpOnly and is expired server-side on sign-out. Legacy cookies from earlier builds are actively cleared.

7. How we build

Every change runs through a blocking CI pipeline before it can merge: the full automated test suite across all workspaces, ESLint, a production build of the CLI, GitHub Action, and web application, and Playwright responsive and accessibility checks.

We run Assurly against Assurly on every commit. The dogfood gate is a required CI job — if our own scanner reports blockers in our own codebase above the configured threshold, the pipeline fails. We are subject to the product we sell.

Third-party GitHub Actions are pinned to a full commit SHA rather than a moving tag, so a compromised or retagged action cannot silently enter our build.

8. AI safety

The AI reasoning layer is powered by Anthropic's Claude models and is optional and advisory. Three properties matter for your security:

• The gate never depends on AI. The deterministic scanner and the proof-of-exploit rails run independently. If the model is unavailable, degraded, or wrong, the verdict logic still holds.
• Scanned content is treated as untrusted.Content taken from a scanned application is wrapped as data, not instruction, so text planted in a repository or a page cannot redirect the model into acting on the attacker's behalf.
• Bounded context. We send the target origin, a technology fingerprint, the rule identifiers and messages our own scanner already produced, and an application context sample truncated to 3,000 characters — never your repository, complete source files, credentials, or account identity. Anthropic states that inputs and outputs from its commercial API are not used to train its models.

Section 6 of our Privacy Policy sets this out in full.

9. Subprocessors

We rely on a small, deliberately short list of infrastructure providers. Each processes data on our documented instructions under a data processing agreement.

We never store card data. If we add or replace a subprocessor in a way that materially affects the processing of your data, we will update this page and our Privacy Policy before the change takes effect.

10. Data location, retention, and deletion

Several of our providers are established in the United States, so data may be transferred outside the European Economic Area. Those transfers rely on the EU–U.S. Data Privacy Framework adequacy decision and/or the European Commission's Standard Contractual Clauses, supported by encryption in transit. Section 8 of our Privacy Policy covers this, and section 9 sets out how long each category of data is kept.

You can delete scans and targets from the dashboard at any time. Deleting your account removes associated workspace records by cascading deletion, except records we are legally required to keep, such as invoices.

11. Availability and resilience

The Service runs on managed infrastructure with provider-level redundancy and managed database backups. We monitor for failures and treat a scan pipeline outage as a priority incident.

To be clear about the limits: the Free and Pro plans carry no service level agreement, and we depend on GitHub, Vercel, Supabase, Stripe, and Anthropic remaining available. OEM and platform customers can agree service levels separately in writing.

12. Incident response

If we identify a security incident, we contain it first, then assess what data and which customers are affected, remediate, and record what we learned.

Where a personal data breach is likely to result in a risk to the rights and freedoms of individuals, we notify the competent supervisory authority within 72 hours of becoming aware of it, as required by Article 33 GDPR, and we inform affected individuals directly where the breach is likely to result in a high risk to them (Article 34).

14. Responsible use of Assurly

Our safeguards do not replace your own authorisation. Scan and probe only what you own or what you are authorised in writing to test — even where ownership verification succeeds technically. Section 11 of our Terms of Service sets out the rules you agree to when using the Service.

15. Contact

Security questions, vulnerability reports, subprocessor questions, and vendor security reviews all go through our contact form, which opens with the Trust & Security subject already selected.

For privacy and data-subject requests, use the Privacy Policy contact route; for contractual questions, the Terms of Service route.