Security at Devence Lab

Effective September 29, 2026

We work in AI security. It would be difficult to justify writing about the assurance of autonomous systems while running a website that could not withstand scrutiny, so this page describes what actually protects the data you send us.

This page describes the security of devencelab.com and the systems behind it. Security commitments for any commercial product, pilot, or professional service are set out in the agreement governing that engagement.

1. Transport security

Every page, asset, and API endpoint is served exclusively over TLS. Plain HTTP requests are redirected to HTTPS before any content is returned.

• HTTP Strict Transport Security is enabled, so a browser that has visited us once will refuse to connect over plain HTTP thereafter.
• TLS certificates are issued by a publicly trusted certificate authority and renewed automatically.
• Modern protocol versions and cipher suites only, with forward secrecy.

2. Application security

Content Security Policy. Every page carries an enforced Content Security Policy. Inline scripts run only where they match a hash computed at build time, rather than under a blanket allowance, and every external source is restricted to a named allowlist.

Response headers. We set the headers that prevent MIME-type confusion, prevent the site being framed, and limit what is disclosed to sites you navigate to, and we deny camera, microphone, and geolocation access outright.

No credentials in the browser. Third-party API credentials are held server-side and are never transmitted to your browser. Form submissions are relayed through our own server, which attaches the credential; your browser never contacts the third party directly.

3. Form and submission security

Our submission endpoints are the only part of the Site that accepts input. They are treated accordingly.

• Request validation. Requests that do not match the expected shape are rejected before any processing takes place.
• Size limits. Text submissions and file uploads are both bounded, enforced in the application and in the runtime beneath it, so that an oversized request is rejected before application code runs.
• Type and length checking. Every field is validated before it is used, so that an unexpected value cannot induce a fault.
• Sanitisation. HTML is stripped from every field, and a submitted address must use a web scheme, so that no submitted value can become an executable link for a colleague to click.
• Upload verification. An uploaded document is identified by its actual contents, not by its filename or by the type the browser reports.
• Rate limiting. Submissions are limited per source address over both a short and a long window. Rejected requests count toward the limit, so probing is limited too, and the counters hold no readable identifiers.
• Minimal error responses. A failed submission returns only whether it succeeded. Diagnostic detail goes to our logs, where it is useful to us, rather than to the client, where it would describe our infrastructure to someone probing it.

4. Infrastructure and access control

• Administrative access is restricted to named individuals and uses key-based authentication. Shared accounts and password-based administrative login are not used.
• Internal services are not directly reachable from the internet, and any that require authentication refuse to start without it.
• The public site is a static export. There is no database behind the public pages and no server-side rendering of user input, which removes entire classes of injection and deserialisation risk from the public surface.
• Releases are deployed atomically, so a deployment cannot leave the site partially updated, and a failed release can be reversed immediately.

5. Data minimisation and retention

The strongest protection for data is not to hold it. We collect only the fields a given form needs, mark only the email address as mandatory, and delete on the schedule published in Section 11 of our Privacy Policy.

We do not maintain a customer database on the public infrastructure, do not store payment details — the Site takes no payments — and do not retain server logs beyond the period needed to investigate faults and abuse.

6. Vendor management

Every third party that processes Personal Data on our behalf is listed on our Subprocessors page, with what it receives, why, and where it processes it. We assess each provider before engaging it and contract with each under terms meeting Article 28 GDPR.

7. Vulnerability management and disclosure

We welcome reports from security researchers. Our Responsible Disclosure Policy sets out what testing is authorised, what is prohibited, how to report a finding, and the safe harbour we offer to good-faith research.

Report a vulnerability to security@devencelab.com. We acknowledge within three business days.

8. Incident response

If we become aware of a personal data breach likely to result in a risk to the rights and freedoms of individuals, we will notify the competent supervisory authority within 72 hours of becoming aware of it, as Article 33 GDPR requires, and will notify affected individuals directly where Article 34 requires it. Our notification will describe what happened, what data was involved, what we have done, and what you can do.

9. What this page does not claim

We would rather state our limits than imply capabilities we do not have.

• This page is a description, not a warranty. It summarises our practices at the date above, in general terms. It is not a specification, forms no part of any contract, and creates no representation, warranty, or commitment on which reliance may be placed. Security obligations for a commercial engagement are set out in the agreement governing it, and where that agreement differs from this page, the agreement governs.
• It is deliberately not a complete description. Publishing the precise configuration of a control is an invitation to test its edges, so we describe what we do rather than how each measure is tuned.
• We make no certification claim for this website. Where we hold an attestation relevant to a commercial offering, it is stated in the material for that offering and evidenced on request.
• We do not operate a paid bug bounty programme. We acknowledge good-faith reports and credit researchers who wish to be credited.
• No system is perfectly secure. The measures above reduce risk; they do not eliminate it, and we do not guarantee that the Site, or data you send us, will be free from compromise. Please do not send us confidential information through the Site — see Section 4.2 of our Terms of Use.
• We may change these measures at any time and without notice, including where a change is needed to respond to a threat.

10. Contact