Security

Security is part of the engineering baseline rather than a review stage at the end. This page states what that means concretely, and how to reach us if you find a problem.

Reporting a vulnerability

If you believe you have found a security issue in this website or in anything we have published, email [email protected] with the subject line SECURITY. Include enough detail to reproduce it.

• We will acknowledge within two working days.
• We will tell you our assessment and intended fix timeline within ten working days.
• We will credit you if you would like to be credited, and not if you would not.
• We ask that you do not access or modify data that is not yours, and that you give us a reasonable window to fix the issue before disclosing it publicly.

We do not currently run a paid bug bounty. We do treat reports seriously and respond to every one.

This website

• Static files only — no application server, no database, no user accounts.
• No advertising or tracking scripts, and no cookies. The only third-party script is the cookieless Cloudflare Web Analytics beacon, documented in the privacy note.
• Served over HTTPS with HSTS, and a restrictive Content Security Policy.
• Fonts, styles, images and every other asset are served from this domain.
• Dependencies are pinned and reviewed; builds are reproducible from source.

In client engagements

Our standing practices, applied unless a client's own standards supersede them:

• Threat modelling per service. Written, reviewed, and revisited when the design changes materially.
• Least privilege by default. Scoped credentials, short-lived tokens, no shared accounts, rotation automated rather than diarised.
• Supply chain. Dependency scanning, SBOM generation, pinned versions, and review of any new third-party dependency before it enters a build.
• Secrets. Managed in a secret store, never in source, with detection in CI to keep it that way.
• Data minimisation. Synthetic or anonymised data for development; production data accessed in your environment, with access logged.
• Audit trails. Designed to be sufficient as evidence, not merely present.
• Industrial environments. Network segmentation respected, one-way flows where required, and nothing placed in a safety-instrumented loop without an explicit reviewed hazard analysis.

AI-specific practices

• Client data is not used to train third-party models, and we configure providers accordingly.
• Prompt-injection and data-exfiltration paths are threat modelled for retrieval and agent systems.
• Model outputs that trigger actions pass through explicit authorisation boundaries.
• Evaluation, logging and rate limiting are treated as security controls, not just quality ones.

Our own operations

• Hardware is encrypted at rest with screen locks enforced.
• Multi-factor authentication on every business system that supports it.
• Password manager for all credentials; no credential sharing over chat or email.
• Access to client systems is requested per engagement and revoked at the end of it.