Trust
How this is secured, and what is not certified yet.
Clyreon holds your company's judgment, including judgments about people, suppliers and candidates. Everything below is built and running today. What is not yet done is named.
What is not certified yet
At the top of the page, where it belongs.
Independent penetration testing and a completed SOC 2 report are scheduled before general availability and are not done today. There is no certificate to show you, and nothing on this page implies otherwise.
What is complete is everything below. These are properties of how the system is built rather than settings somebody switched on. What is still ahead is having an auditor confirm it.
The same statement is made in the security policy shipped with the product and in the guide handed to design partners. It is not phrased more optimistically anywhere.
Access control
Authority is granted explicitly, never inherited from being logged in.
Every action requires a permission granted explicitly to whoever is acting: record.open, judgment.record, record.seal, and so on. There is no implicit role inherited from having an account, and no implicit administrator who bypasses the check. The same check runs whether the request comes from the product interface, a webhook, or the API.
“Was this person allowed to do that at the time?” is answered by replaying the permission history to that day, not by checking who has access now. Grants and removals are themselves append-only.
Single sign-on works with any identity provider that speaks OIDC, the standard most already use. New employees can be added or removed automatically through SCIM, the standard most company directories already speak too.
Every request is authenticated and rate-limited before it reaches any business logic. Signup, login and password reset, which have no credential to count against, get a separate, stricter, IP-keyed budget specifically to slow credential stuffing.
Isolation between organisations
Enforced twice, independently, and one of the two is below the application.
One running process serves every organisation it has provisioned. Application code resolves organisation scope fresh on every request from the authenticated caller’s own membership, never from client input, and never cached for the life of a connection.
The database itself then enforces the same wall a second time, independently of the application. It runs as a restricted account that physically cannot see or write another organisation’s data, even if a bug in the application forgot to check which company a piece of data belonged to. A dedicated test suite proves this holds even when a request deliberately asks for another organisation’s data by name, and under many organisations’ requests arriving at once.
The privileged migration role that applies schema and bootstraps that restricted role is never present in the running server’s environment.
Self-hosting a physically separate deployment remains available where a compliance posture requires that stronger guarantee.
Data protection
Secrets, deliveries, and getting your data back out.
Connector credentials and webhook signing secrets are encrypted at rest with AES-256-GCM, a standard, strong encryption method, using a separate key for every secret rather than one key protecting everything. Never stored or logged in plain text.
Outbound event deliveries are HMAC-SHA256 signed against a per-subscription secret, so a receiver can cryptographically verify a delivery actually came from Clyreon.
A logical export of every ledger for your organisation, on demand, with integrity verification. This is your data, and leaving with it intact is always possible.
Evidence can be redacted once its own retention schedule expires, as a deliberate, logged administrative act. Decision Records themselves are never swept automatically. There is no background job quietly deleting history.
Auditability
Access is logged, not only change.
Reads, exports, denials and administrative actions append to their own ledger, which is itself append-only and hash-chained. A record that some people can quietly read without a trace is not a trustworthy record, and a refused write that leaves nothing behind is the signature of a compromised credential going unnoticed.
Exports are logged separately from reads on purpose: a record leaving the building is a materially different event, because it is the point after which Clyreon’s immutability guarantees stop applying to that copy.
Deployment
Deliberately small, and sized for the stage the company is at.
One process backed by a single Postgres database, serving every organisation it has provisioned. Not a queue, a cache or a search cluster. It is sized for the scale this architecture is honestly built for, rather than a placeholder for infrastructure that does not exist yet.
The API is REST, authenticated by a bearer API key, a session token or an OIDC token, and documented by a live OpenAPI document generated from the routes the server actually serves, so the documentation cannot drift from the API it describes.
Data residency, encryption key rotation policy, incident notification timelines and the sub-processor list are handled directly, case by case, during the design-partner agreement rather than asserted here.
Reporting a vulnerability
Where to send it, and when you will hear back.
Email security@clyreon.com with a description and, if possible, reproduction steps. Expect an acknowledgment within one business day. Please do not open a public issue for a security vulnerability.