Security & trust
It reads attacker-written text for a living. So security is the product.
Locard holds the keys to your security tools and reads content an attacker controls. This page is the start of our trust centre: the security model, how data is handled, where our compliance work stands, and how to report a vulnerability.
Where we stand
Status, stated plainly.
Locard is pre-launch. We would rather tell you what is not done than leave you to find out in a questionnaire.
| Area | Status | Notes |
|---|---|---|
| Security architecture and threat model | Written | Available under NDA, with data-flow diagrams. |
| Automated gates on every change | In place | Secret scanning, licence check, SBOM, vulnerability scan, policy tests, tenant-isolation tests. |
| Vulnerability disclosure | In place | security.txt and a private reporting address (below). |
| Third-party penetration test | Planned | Before the first pilot connects real credentials. |
| SOC 2 Type I, then Type II | Planned | Not started. We will say so here when the audit window opens. |
| ISO/IEC 27001 and 42001 | Later | After SOC 2 Type II. |
| Legal pack (DPA, MSA, sub-processor list) | Not yet published | Published before the first production deployment. |
| Accessibility | In place | Built to WCAG 2.2 AA and checked with axe; a VPAT is planned. |
Security model
Guarantees from the architecture, not from a classifier.
Classifiers that look for prompt injection are useful telemetry, and they are not a boundary. These controls hold even when a classifier misses.
-
Untrusted input is quarantined
Alert, log, email and file fields reach a model only through a quarantined extractor that has no tools. It emits schema-checked, typed fields wrapped in data markers. The planner never sees raw attacker text.
-
Every tool call passes one gateway
The gateway enforces Cedar policy, the investigation’s budget and the tier rules on every call. Agents never hold connector credentials: the gateway’s broker injects them, and read and write credentials are separate for every connector.
-
Targets come from trusted telemetry
A host, user, account or mailbox that appears only in attacker-controlled text cannot be acted on. Indicators (URL, domain, IP, hash) also need a trusted platform’s observation and an allowlisted threat-intel verdict.
-
Injection is a detection, not a lever
Detected prompt injection raises its own alert. It can never lower a verdict or its severity, and nothing it names can become an action target.
-
Verdicts come from evidence
The skill’s rubric and policy decide; the model proposes. Every claim cites evidence IDs and uncited claims are rejected. A truncated result never means “nothing found”. Memory can raise suspicion, but only trusted evidence can lower it.
-
Everything is on the record
Every privileged action, approval, policy decision and model call is appended to a hash-chained audit log with a verify endpoint, and can be exported to your SIEM as OCSF.
-
Tenants are isolated, and that is tested
Every table carries a tenant ID under row-level security. Cross-tenant reads are tested to fail at the database, the API and the gateway.
-
Inputs and egress are bounded
Webhooks are HMAC-verified with a timestamp tolerance and a replay cache. Outbound calls are allowlisted and guarded against SSRF. Only public indicators go to threat-intel providers, never internal names, users or addresses.
Approvals
Who has to agree.
Policy outside the model sets each action’s tier. Approval cards show where the target came from and any counter-evidence, Approve enables only after a short dwell, and irreversible actions need an explicit acknowledgement.
| Tier | Examples | Who decides |
|---|---|---|
| T0 Read | SIEM queries, threat-intel lookups, directory reads | Automatic, within the budget |
| T1 Record | Comments, tags, tickets, status sync. Never changes a customer entity | Automatic, policy-checked |
| T2 Contain | Isolate a workstation, revoke sessions, remove a message | One approver, or a pre-approved policy with a lease that auto-reverts |
| T3 High impact | Isolate a server, block a service account | Two different people, each with a written reason |
| T4 Never | Delete logs, change its own permissions | Always denied |
Data handling
What Locard keeps, and what leaves.
- What is stored
- Cases; alerts normalised to OCSF with the raw payload and its SHA-256; evidence (the query, the result and its hash); verdicts, approvals and actions; the audit log and trace spans. In Postgres, with row-level security per tenant.
- What reaches a model
- Typed, extracted fields and evidence, after a redaction step. Secrets and sensitive personal data (government IDs, card numbers, bank accounts) are always masked; personal names are replaced with stable placeholders by default. Raw content such as an email body reaches a model only through the quarantined extractor, and you can require a self-hosted model or deterministic parsing for it.
- Which models
- Your choice, per workspace: Anthropic, OpenAI, Google, OpenAI-compatible hosts or a self-hosted model. Chinese-origin model families are off by default and PRC-hosted endpoints are never used.
- Training
- Locard does not train models. Your data is used to investigate your alerts, and for nothing else.
- Credentials
- Connector credentials are held by the gateway’s broker and injected per call; agents never see them. Model provider keys are held only by the model router.
- Retention
- Defaults are fixed in code today: cases and their evidence for 3 years after closing, payload blobs for 365 days (the hash stays), trace spans for 180 days, the audit log for at least 400 days. Sandbox workspaces expire at day 30 and are purged 14 days later. Per-tenant settings and legal hold administration come with general availability.
- This website
- No cookies, no analytics and no third-party scripts. The demo form opens your own e-mail app and stores nothing. See the privacy notice (draft).
Sub-processors
Sub-processors (placeholder).
No production service runs yet, so no sub-processor handles customer data today. This list will be completed and versioned before the first production deployment, and changes will be announced in advance.
| Category | Provider | Purpose | Location |
|---|---|---|---|
| Cloud hosting | To be confirmed | Runs the service and stores customer data | The region you choose |
| Model providers | Chosen per workspace by you | Investigation reasoning on redacted, typed inputs | Per provider and region; self-hosted is an option |
| Transactional e-mail | To be confirmed | Invites and notifications | To be confirmed |
| Support desk | To be confirmed | Support tickets you open | To be confirmed |
Vulnerability disclosure
Found something? Tell us first.
Report suspected vulnerabilities in Locard, its website or its open-source components privately to security@locard.si. Our security.txt has the same details in RFC 9116 form.
- Tell us what you found and how to reproduce it. Please don’t open a public issue.
- Use only accounts and data that are yours, such as a sandbox workspace with synthetic data.
- Give us reasonable time to fix it before you publish. We will keep you updated and credit you if you wish.
A full disclosure policy, including safe-harbour terms, will be published with our legal pack. Until then, we will not pursue anyone who reports in good faith along these lines.
Documents
More detail, on request.
- Security model and threat modelunder NDA
- Architecture and model data-flow diagramsunder NDA
- Software bill of materials (SBOM)on request
- Penetration test letterafter the first test
- SOC 2 reportafter the audit
Ask at hello@locard.si.