Security is part of the architecture.
Security tooling has to earn trust before it earns a workflow, so the platform is built around isolation, explicit access, and evidence that can be re-run.
How we handle your code, and ours
Four commitments that hold today. The sections below give the specifics behind them; anything not yet finished is listed as unfinished rather than claimed.
Private by default
Your contracts, sessions, forks, and findings are visible only to your workspace. Access is explicit and controlled, never implicit.
Isolated execution
Analysis and proof-of-concept testing run only against isolated forks of chain state. Nothing the platform runs touches a live network or real funds.
Reproducible evidence
A finding reaches your report only if it reproduces deterministically on the pinned fork. Evidence is tied to execution rather than to an assertion.
Responsible disclosure
We publish a security contact and a disclosure process, and we support coordinated disclosure of issues found in our own site and tooling.
The specifics, section by section
Each entry states what holds today. Where a control is not finished, it is listed as unfinished rather than claimed.
Reporting a vulnerability
Send reports to security@trilocore.com. The machine-readable contact record and policy live at /.well-known/security.txt.
Scope — this website and the Trilocore platform. Third-party services we depend on should be reported to their own programmes.
Testing — do not access or modify data that is not yours, and do not degrade the service for others while testing.
Timeline — allow a reasonable window to remediate before public disclosure. We will acknowledge your report and keep you updated until it is closed.
What we store, and where
Source code is held as content-addressed objects. The databases hold references and metadata, not code.
Source code — stored in a content-addressed object store. It is never written into the database as bytes; the database holds only a reference to the stored object.
Workspace records — the workspace service stores no source and no bytecode at all. It holds chain, address and selector metadata only.
Encryption at rest — object storage, block storage and the shared file system are encrypted with KMS-managed keys.
Encryption in transit — TLS is required for object storage access, enforced by bucket policy.
Who can reach a workspace
Workspaces are scoped to one tenant. A caller who is not entitled to a resource is not told that the resource exists.
Sign-in — email, or Google or GitHub OAuth.
API keys — stored only as a SHA-256 hash. The key itself is shown once when it is created and is never persisted in plaintext, so it cannot be displayed again; a lost key is replaced, not recovered.
Tenancy — workspaces are tenant-scoped and private by default.
Cross-tenant requests — a resource belonging to another tenant answers with a not-found response rather than a forbidden one, so the API does not confirm that it exists.
Where the platform runs
One cloud, one region, and a database we operate ourselves.
Hosting — Amazon Web Services, in a single region.
Database — PostgreSQL, self-hosted on Kubernetes rather than a managed database service.
Backups — database backups are kept for 45 days; shared file system backups for 30 days.
Logs — application logs are kept for 30 days; cloud audit and storage access logs for 90 days.
What the platform records
Request logs — carry identifiers and a salted pseudonymous user id. They do not carry request or response bodies.
AI-assisted features — not currently active on the platform.
What this page does not cover yet
A control appears here once it is complete and verifiable, and not before. The following are not claimed.
Compliance — no certification or independent assessment is claimed, and none will be published here until the assessment behind it is finished.
Development and review process — how a change is reviewed before release, and how a reported issue is tracked through to a fix.
Legal — data processing terms and an incident notification commitment. Our privacy notice is at /privacy.html.
Check the evidence yourself
Open a fork, reproduce a finding, and read the trace that produced it.