Security is part of the architecture.

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 programs.

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.

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.

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.

Multi-factor authentication — time-based one-time codes and WebAuthn passkeys, enrolled per user.

Organizations and roles — organization, team, and membership roles from a fixed catalog, with invitations. Each account also carries a developer or auditor persona that the API enforces.

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. Keys can be listed and revoked.

Administrative audit trail — administrative actions are written to an append-only log that database triggers prevent updating or deleting, and it is retained indefinitely.

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.

Enterprise buyers ask for a specific list, so here is what you can use today. We do not list capabilities as available until they are.

Available today — Google and GitHub sign-in; TOTP and WebAuthn passkey multi-factor authentication, enrolled per user; organization, team, and membership roles; invitations; developer and auditor personas enforced by the API; revocable API keys; an immutable administrative audit trail.

Not available today — SAML 2.0, enterprise single sign-on, SCIM provisioning, custom role definitions, standalone service accounts, session policy controls, and organization-wide enforcement of multi-factor authentication. Each of these is on the table for enterprise contracts: write to security@trilocore.com before you evaluate us further and we will tell you honestly what we can support for your account and when, and walk your team through the plan under NDA.

We publish no availability target and no service level agreement. We will not publish one until we can measure it and stand behind it, and we would rather say that than quote a number we cannot evidence.

Region — the platform runs in a single Amazon Web Services region. There is no second region and no cross-region failover.

Backups and recovery — the database is backed up continuously, with point-in-time recovery to any moment inside a 30-day window; backup objects are deleted from storage no later than 45 days after they are written. Recovery procedures are documented internally.

Monitoring — the platform is monitored continuously and warning and critical alerts reach a staffed channel.

Not yet in place — a published availability target, a public status page, and independently verified recovery objectives.

Enterprise customers who need our architecture, recovery objectives or resilience posture in detail — or a committed path to any item listed above as not yet in place — can request them under NDA from security@trilocore.com. We do not publish infrastructure specifics openly.

Hosting — Amazon Web Services, in a single region. Infrastructure is defined as code and changes are applied through a version-controlled pipeline rather than by hand.

Data residency — customer data stays in that one region. If you need a specific residency commitment in writing, ask us before you sign.

Backups — the database keeps a 30-day point-in-time recovery window; backup objects are deleted from storage no later than 45 days after they are written. Shared file system backups are kept for 30 days.

Logs — application logs are kept for 30 days; cloud audit and storage access logs for 90 days.

Trilocore operates from exactly four hostnames, across two registered domains. Both domains are registered to and operated by Trilocore: the company site and documentation run on trilocore.com, and the product runs on trilocore.ai. If your security team maintains an allow-list, these are the entries — anything else presenting itself as Trilocore is not us.

trilocore.com — this website, including the Trust Center and research.

platform.trilocore.com — product and API documentation.

app.trilocore.ai — the application, including sign-in.

api.trilocore.ai — the platform API.

Mail from us comes from @trilocore.com addresses, such as security@trilocore.com. We will never ask for credentials by email.

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. Janus AI is in development and is not available. No contract source, bytecode, or workspace content is sent to any model provider, which is why no model vendor appears in the subprocessor list on our privacy page.

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. We are not going to publish a certification timetable either: a date is not a control, and an audit that has not been booked is not a roadmap. Several of the practices those frameworks look for are already in place and described elsewhere on this page — encryption at rest under managed keys, tenant isolation, an immutable administrative audit trail, and cloud-level audit logging. What is missing is somebody independent saying so, and a documented development and review process, which is listed below as not claimed for exactly that reason.

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.

None of the above is a dead end: enterprise buyers who need to assess any of these areas now can request our current posture and the evidence behind it under NDA from security@trilocore.com.