Security | Coherence Energy Labs™

Reporting a vulnerability

If you find a security issue in this site or in any Coherence Energy Labs™ software, email security@coherenceenergylabs.com with enough detail to reproduce it. You will get a human reply. Please give us a reasonable window to fix the issue before public disclosure; we will credit reporters who want credit.

Send the finding in your first message. Everything you need is already on this page - the address, the scope, the rules of engagement and the safe harbour - so there is nothing to confirm first and no permission to wait for. We answer reports; a message asking whether this is the right address, with no finding in it, may not get a reply. Plain text is fine and preferred over attachments.

Machine-readable contact details are published at /.well-known/security.txt.

Cryptographic trust roots for VMP campaign artifacts are published at /trust-roots/.

Scope and safe harbor

We welcome good-faith security research and we would rather you test us than wonder. If you make a good-faith effort to follow the rules below, we authorise your testing, we will not initiate or support legal action against you for it, and if a third party raises it we will make clear that your activity was authorised. This safe harbour follows the widely used disclose.io good-faith framework.

In scope

coherenceenergylabs.com and its subdomains (www, demos, admin, mta-sts), and the registered look-alike domains that redirect to them.
The Cloudflare Worker that serves them and its public endpoints, including /mcp, /api/contact, /api/csp-report, /api/sentinel and /api/sentinel/ingest.
The published cryptographic provenance: the transparency log at /transparency/, the signed release manifest, and the sentinel observation chain. We publish a deliberate forgery and invite you to break the verifier - if your check accepts both the real head and the forged one, that is a finding we want.
Our public DNS, TLS and email configuration (SPF, DKIM, DMARC, MTA-STS, DNSSEC, CAA).

Rules of engagement

Be non-destructive. No denial-of-service, no volumetric or stress testing, no automated scanning heavy enough to degrade the service for others.
Use your own or synthetic data. Do not access, alter, or exfiltrate data that is not yours. If you access data that is not yours by accident, stop, do not save it, and tell us.
Stay technical. No social engineering of our people, no phishing, no physical attempts, no attacks on our vendors’ own infrastructure (Cloudflare, Google) - only on how we configure them.
Give us time. A reasonable window to remediate before public disclosure. We will keep you informed and we do not consider coordinated disclosure a hostile act.

What you can expect from us

A human acknowledgement within 3 business days.
A triage and severity assessment, and honest updates as we fix.
Public credit on this page if you want it, with the date the finding was fixed.

We do not run a paid bug-bounty programme at this time; this is a coordinated vulnerability disclosure policy. Where a finding leads to a material improvement, we are glad to acknowledge it publicly and to serve as a reference.

Acknowledgments

Our security.txt points its Acknowledgments field here, so this section exists to honour that pointer rather than leave it aimed at nothing. No external vulnerability reports have been received to date, so there is nobody to credit yet. That is a statement of fact, not a claim that none exist. When a researcher reports an issue and wants credit, their name and a one-line description of the finding will be listed here, with the date it was fixed.

How the site is built

The core site is static HTML and CSS served by a Cloudflare Worker. It ships no JavaScript at all: no first-party script, no third-party script, no trackers and no cookies. Its only <script> tags are declarative JSON blocks (structured metadata and prefetch hints) that browsers read as data and never execute. The Content-Security-Policy enforces this rather than merely describing it – script-src grants no origin at all, so a script injected into one of these pages is refused by the policy itself. HSTS and frame denial apply throughout. The interactive demos under /demos/ do run JavaScript to compute their visuals in your browser; they are served under a separate, scoped CSP and are isolated from the core site. The site stores no visitor data, and the attack surface is intentionally small.

The exact header set, published

Security headers are worth nothing if you have to take our word for them, so here is the policy this site actually serves. It comes from one source: it is written into the Cloudflare headers config (published byte-identically at /headers.txt, which is SHA-256 hashed into the signed release manifest) and it is applied by the Worker to every response, including redirects and the 404, so there is no unhardened surface. A build gate compares those copies and fails the release if they ever drift apart.

Content-Security-Policy: default-src 'self'; script-src 'inline-speculation-rules'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; media-src 'self'; object-src 'none'; frame-src 'none'; frame-ancestors 'none'; base-uri 'none'; form-action 'self'; manifest-src 'self'; report-uri /api/csp-report; report-to csp-endpoint; upgrade-insecure-requests
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: accelerometer=(), autoplay=(), camera=(), display-capture=(), encrypted-media=(), fullscreen=(self), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), midi=(), payment=(), usb=(), interest-cohort=()
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
Origin-Agent-Cluster: ?1
X-Permitted-Cross-Domain-Policies: none

Check it against the live site yourself, from any machine:

curl -sI https://coherenceenergylabs.com/

Security program

Coherence Energy Labs™ maintains a documented information-security program covering identity, credentials, endpoints, model usage, incident response, and vendor risk. It is versioned alongside our source, reviewed annually, and reviewed again after any significant incident. Controls are recorded against dated evidence rather than asserted: a control is treated as in place only when there is a receipt for it.

Identity and access

Phishing-resistant multi-factor authentication, using hardware security keys, on every account that administers company systems.
Two-step verification enforced organization-wide at the corporate directory, not left to individual opt-in.
Least-privilege role assignments, with documented joiner, mover, and leaver procedures and a quarterly access review.
Administrative rights separated from day-to-day accounts.

Credentials and secrets

Long-lived secrets held in an encrypted vault with threshold-based recovery, so no single stored artifact can disclose them.
Per-service credentials, scoped to the minimum permissions the provider supports, with short lifetimes where available.
Documented rotation and revocation procedures, with revocation verified against the provider rather than assumed.
Automated, value-suppressing secret scanning in continuous integration.

Endpoints

Full-volume disk encryption with recovery keys escrowed to managed enterprise storage.
Centrally managed devices with automated compliance evaluation; access to sensitive work is limited to compliant devices.
Endpoint protection with real-time monitoring and tamper protection, an enforced patch deadline, and an enforced inactivity lock.
Hardware-backed platform security: TPM-resident keys and verified boot.

Model and API usage

Model API traffic is routed through an authenticated gateway that records usage and retains it for retrospective review.
Spending caps are set at the provider, and usage is reviewed on a quarterly cycle.
Credentials are never transmitted inside prompts, and logs are not permitted to become a secret store.

Incident response

A documented response process, modeled on NIST SP 800-61, defining severity levels, containment, evidence preservation, notification, recovery validation, and post-incident review.
The process is exercised, not shelved: real incidents are run through the full lifecycle and closed with a written root-cause review and a class-level fix.

Email and domain integrity

Mail and DNS for this domain are hardened and publicly verifiable: SPF configured to hard-fail, DKIM signing, a published DMARC policy with aggregate reporting, MTA-STS with TLS reporting, and DNSSEC. Look-alike domains are registered and redirected to the canonical site.

Risk and vendors

We maintain an annual risk assessment with explicitly accepted risks, and a vendor register recording what each provider holds, how our side of the relationship is authenticated, and where assurance is missing.

Certifications and assurance

An external security review in June 2026 assessed our public web and email surface; the findings were remediated and the remediations independently re-verified.

Coherence Energy Labs™ does not currently hold SOC 2 or ISO 27001 certification. We consider it more useful to say so plainly than to imply equivalence: our program is documented and evidenced, and pre-engagement materials, including a risk assessment, change-management procedure, and vendor register, are complete. Prospective partners who require certification should contact us before relying on one.

Counterparties conducting security due diligence may request a summary of our control evidence at security@coherenceenergylabs.com. Detailed control documentation is shared under a mutual non-disclosure agreement.