Security

Certifications and assurance

We don't yet hold SOC 2, ISO 27001 or IEC 62443 certification, and no independent penetration test has been completed. These are on our roadmap, and we'll publish dates once an auditor or assessor is engaged.

Until then, design partners can review our security documentation, architecture decisions and network requirements in detail under NDA. Ask at chinookintelligence@gmail.com.

Protecting your plant

Read-only by construction

CHINOOK's connectors and edge agent read data; they cannot change it. This is built into the code rather than configured:

• Inbound connectors receive an HTTP client that only allows reads. A write attempt is refused before a byte leaves the machine.
• The Modbus driver uses read function codes 01 to 04 only. The BACnet driver encodes read services only. The OPC UA client has no Write or Call. The Sparkplug client never publishes.
• Static scans and runtime tests fail the build if write-capable code appears in a read-only component.
• Every connector version is certified with a test that the vendor system saw no write.

Outbound connections only

No inbound connection to your plant network is ever required. The edge agent initiates every flow:

Signed configuration

Polling plans, alarm rule sets and connector certification reports are signed by the CHINOOK control plane. An edge agent refuses anything unsigned or altered, never accepts an older version than the one it runs, and keeps working from its last signed copy if the cloud is unreachable. Software updates roll out in stages, with an automatic halt and rollback if a site's health regresses.

Writing setpoints is separate and off by default

The only component that can change plant state is a separately built Actuator. It is off by default and can be enabled per site only after customer operations and insurer sign-off, an independent IEC 62443-4-2 assessment, and on-site tests of its kill switch and automatic revert. Life safety, fire, emergency power off, breakers, transfer switches, leak-isolation valves, interlocks and protection settings can never be written, at any level. The Actuator is not deployed during early access.

Protecting your data

Tenant isolation in the database

Every customer table is protected by PostgreSQL row-level security. The application connects with a role that cannot bypass it, and the customer is bound to each transaction, so even a bug in the application cannot return another customer's rows. Automated tests try to cross that boundary on every change.

Encryption

• All traffic is encrypted in transit with TLS; edge telemetry also uses mutual authentication.
• Integration secrets are encrypted per customer with AES-256-GCM, and the customer is bound into each ciphertext so it can't be decrypted in another customer's context.
• Customer keys can be held in a cloud key management service, including a key the customer controls. Revoking that key makes the encrypted data unreadable.
• Connector credentials are references to a secret store, never stored in configuration.

Data residency

The platform is built to place each customer in a regional deployment. Where your data will be hosted is agreed before any data is shared.

Your data stays yours

Models trained on one customer's data are never served to another. Contributing anonymised fault patterns to a shared library is opt-in.

Identity and access

• Single sign-on through your identity provider (Okta, Microsoft Entra ID or Google) using OpenID Connect.
• Multi-factor authentication enforced for administrators and commissioning leads.
• SCIM 2.0 provisioning, so leavers lose access when you deprovision them.
• Six roles, from viewer to administrator. Approving a test spec, a mapping or a report needs a named person; software cannot approve.
• API tokens are scoped, can be limited to one site, always expire and can be revoked instantly. Only a hash of each token is stored.
• Browser sessions use encrypted, http-only cookies. Access tokens never reach JavaScript in the browser.

Audit and accountability

Every action, by a person, an integration or an agent, is written to an append-only audit log that the application itself cannot alter. Every finding carries a SHA-256 hash over its evidence, so a report can be checked later against the data it was built on. Audit exports are protected against spreadsheet formula injection.

AI-specific safeguards

Text from documents and connected systems is treated as untrusted data, never as instructions, which limits prompt injection. Agents work through a fixed set of tools and cannot approve anything. Every statement an assistant makes must cite evidence or it is not shown. See Responsible AI for more.

Incident response

We track security incidents against the regulatory clocks that apply to us and our customers, and we will tell affected customers without undue delay.

This website

This website sets no cookies and loads no third-party scripts, trackers or fonts. It sends security headers that block framing, content-type sniffing and access to your camera, microphone and location. Early-access sign-ups are stored in a database that only our server can read; see the privacy policy.

Reporting a vulnerability

If you believe you've found a security vulnerability in CHINOOK or this website, please tell us at chinookintelligence@gmail.com with the subject line “Security report”. Please include:

• what you found and where (URL, component or version);
• the steps needed to reproduce it;
• what an attacker could achieve;
• how you would like to be credited, if at all.

We will acknowledge your report, keep you updated as we investigate, and tell you when it is fixed.

Good-faith research

We won't pursue legal action against research that follows this policy: you make a good-faith effort to avoid privacy violations, data destruction and service disruption; you only access data you need to demonstrate the issue and delete it afterwards; you give us reasonable time to fix the issue before disclosing it; and you don't exploit it beyond what is needed to confirm it.

Out of scope

• Any customer site, plant network, building system or equipment. Never test these.
• Denial of service, load testing and social engineering of our staff or customers.
• Physical attacks, and findings from automated scanners without a demonstrated impact.