derived_only — the default
The raw dataset a source returns is never written to disk; the computed, intermediate result is.
SECURITY AND COMPLIANCE
The mechanism behind every claim on this page.
A reference for the people who have to sign off before this touches production data: where data lives, what can leave the box, how the model handles text it didn’t write, and what’s already on record — and what still isn’t.
Where your data lives.
Retention is set at three levels — the whole appliance, one data source, or a single instance — and a lower level can never loosen what a higher one set. Whichever mode is active for a run is written to the audit log.
persist
Both the raw dataset and the intermediate result are kept until their retention period ends. It’s the only mode a failed run can resume from partway through — the other two start over from the beginning.
ephemeral
Raw data, the intermediate result, and the filled-in prompt sent to the model all stay in memory and never touch disk — only the delivered report is stored. The cost: less to diagnose a failure with, so the data profile has to do more of that work, and it has to stay rich.
What leaves the box.
Your data stays in your network unless you connect an agent to the internet. When you do, that agent is marked, and every request it makes — target, full text, timestamp — is written to the audit log. One switch turns outbound access off for the whole box.
A step that reaches the internet — an HTTP call, a web search, a page fetch — carries a badge on the canvas and a counter on the agent’s header. There’s no undecorated way to leave the box.
The request itself is logged, not just the fact that one happened. Under ephemeral retention the text is hashed rather than kept in full — the record still proves what left, without keeping the sensitive text at rest.
The switch is appliance-wide and overrides every per-agent egress setting beneath it — the same rule that governs retention: a lower level can loosen nothing a higher one closed.
Untrusted content is marked before the model ever sees it.
Text returned from the web is always given to the local model as data, never as instruction.
This is the product’s first real prompt injection surface, and we would rather name it than leave you to find it.
No rule engine yet — enforcement today is mechanical, not authored.
There is no policy engine a security team writes rules into and every agent must obey. What holds today is narrower: the grounding gate checks every number a report contains against the deterministic output it came from; secret values are masked automatically wherever they’d otherwise appear in a log, a prompt or the audit trail; and retention and egress are switches an operator sets, not rules someone authors and signs.
A single authored rule set is on the roadmap: declared field classification (which columns are personal or sensitive data), rule families for where data can go and what gets masked before it leaves the deterministic layer, and an effect preview that shows how many agents a new rule would stop or change before it publishes. None of it exists in v1.
What’s already on record.
Hash-chained audit log.
Every read, every model call, every outbound request, every configuration change, every secret access — logging only that it happened, never the value — is appended and chained. Deleting or altering an entry breaks the chain, and that’s detectable.
Every run freezes its plan.
The template version and the exact configuration a run executed are stored with the run. Changing the configuration tomorrow doesn’t rewrite what happened today.
Source evidence, not just a source name.
Every read is recorded with the query text, the host, the timestamp, the row count and a hash of the data it returned, plus a data profile — the thing left to diagnose from once a retention mode has dropped the raw values.
A dedicated artifact store.
The delivered report and the run record it came from live in their own store, not scattered across logs someone would have to reconstruct by hand.
Identity and authorization: the product’s own front door.
There’s no LDAP or SSO in v1 — the product has its own login: Argon2 password hashing, a password policy, account lockout after repeated failures, session expiry and revocation, and TOTP-based two-factor authentication. A reset goes through an admin, who issues a one-time code; there’s no email channel for it yet.
Permission is action × scope, not a single flag — report.view isn’t a global grant, it’s a question of which instance’s report. Admin, Operator, Viewer and Auditor are starting points, not fixed code, and exceptions can be added per user.
An effective-permission viewer answers the one question that matters day to day — what this specific user can do right now — which is what keeps a fine-grained matrix usable instead of theoretical.
Secrets: encrypted, and masked wherever they’d otherwise leak.
Secret values are stored encrypted at the application level. The key sits on disk, protected by disk encryption, and every access to it is logged; the alternative — asking an operator for the key at every boot — is more secure but breaks the unattended operation the product promises, and we say so rather than pretend the trade-off doesn’t exist. Values are masked automatically wherever they might otherwise surface: logs, prompts, error messages, the audit log itself.
What we’re honest about not having.
We do not hold SOC 2 or ISO 27001 today. What we do have is the raw evidence your auditor asks for — recorded as the system runs, not assembled afterwards.
- LDAP and SSO — on the roadmap, not built; the product’s own login stands in for it today
- A rule engine you author policy into — each mechanism above enforces its own limit instead
- Container-level isolation for template code — process limits and a signed source stand in for it