Security
We are asking to run software inside your network
So this page states plainly what the agent can reach, what it may execute, what leaves your perimeter, and who on your side can see what. If any of it is unacceptable, better to know on day one.
Threat model
Written as scenarios rather than assurances, because an assurance you cannot test is worth nothing to the person reviewing this.
The honest framing is that we are asking for read access to production systems from inside your perimeter. That is a significant request and no amount of reassuring language changes its shape. What can change is how much damage is possible if some part of it goes wrong.
Each row below is a scenario your reviewer should be asking about, and what structurally limits it. "Structurally" is load-bearing: several of these are properties of how the system is built rather than policies it follows, and those are the ones worth trusting.
| If… | The concern | What limits it |
|---|---|---|
| Our servers are compromised | Attacker sends the agent a malicious instruction | The agent accepts only catalogue identifiers, resolved against a file on your host. There is no code path that executes a statement received over the wire. |
| Agent credentials are stolen | Attacker reads your production data | The credential is read-only, scoped to named tables and catalog views, with explicit DENY on write verbs. Revocable from your side without involving us. |
| Agent host is compromised | Attacker pivots into our systems | The agent holds a tenant-scoped credential and no inbound path exists. Its egress reaches one hostname, which your network policy also constrains. |
| A redaction rule has a bug | A secret leaves your network | on_rule_error: drop_field is the default — a field whose rule throws is discarded rather than transmitted. |
| Insider at our end | Reads your production evidence | Evidence is tenant-scoped and access-logged. Retention is short by design, which limits what exists to read. |
| Insider at your end | Widens collection scope quietly | Catalogue and redaction changes are files in your repository, reviewed like any production change; scope changes are recorded in both audit trails. |
What crosses the boundary
The only question your data protection reviewer actually needs answered.
Everything in the "yes" column is redacted at the agent before it is queued for transmission. Everything in the "never" column has no code path — it is not a policy that could be relaxed by a configuration change or a support request.
| Category | Leaves? | Detail |
|---|---|---|
| Query results | Yes — redacted | Row-capped, from the approved catalogue only |
| Matched log lines | Yes — redacted | Selected lines with context. Never whole files |
| Catalog metadata | Yes | Object, column and module definitions — structure, not contents |
| Named config files | Yes — redacted | Secrets removed at the agent before transmission |
| Source files | On demand | A specific path at a commit, once already implicated |
| Whole tables | Never | No bulk extraction path exists |
| Credentials or secrets | Never | Built-in redaction rules cannot be disabled |
| Backups or snapshots | Never | The agent has no such capability |
Network
One hostname, one port, outbound only. The agent initiates every connection and polls for work; there is no mechanism by which we contact your network, including for support.
# The complete egress requirement. One hostname, one port.
# The agent is proxy-aware and pins our certificate.
destination: ingest.decim.dev
port: 443/tcp
protocol: TLS 1.3 (1.2 minimum), certificate pinned
direction: outbound only — the agent initiates every connection
proxy: HTTP CONNECT supported (DECIM_EGRESS_PROXY)
inbound: none. no listening socket, no inbound firewall ruleBecause collection is pull-based, there is no standing inbound channel to compromise and nothing to revoke on our side in a hurry — stopping the agent or revoking the database credential you issued ends collection immediately, using only controls you already own.
What may execute
A finite catalogue of read-only statements, held on your host, reviewed by your team.
The catalogue is a file in your infrastructure listing every query the agent may run, each with a stated purpose, bound parameters, a row cap and a timeout. Adding one is a pull request against your own repository — the same friction as any other production change, and deliberately so.
Database permissions are correspondingly narrow. Most of what an investigation needs is
metadata: VIEW DEFINITION, VIEW DATABASE STATE, and read on
scheduler tables. Row access is granted on specific named tables, and fact tables are usually
granted at column scope — enough to count rows per batch, structurally unable to read
an amount or a customer identifier. The full grant set is written out on
the agent page.
Redaction
At the agent, before transmission. Not on ingest — by then the data has already left your network.
This distinction is the entire control and it is worth being pedantic about. A vendor that scrubs on receipt has, by definition, received the unscrubbed data: the secret crossed your boundary and existed in their systems. No retention policy undoes that, and no incident report about their infrastructure will exclude it.
Built-in rules cover connection strings, bearer tokens and API keys, private key blocks, and card numbers validated by Luhn check rather than matched by length. They cannot be disabled — not by us, not by an administrator on your side. Custom rules are yours to add, and support substituting a stable truncated hash so a value stays correlatable across artefacts without being readable.
Retention and deletion
Raw evidence expires well before the diagnosis that cites it.
This asymmetry is intentional. The reasoning in a diagnosis is durable and useful for as long as the incident record matters. The underlying rows are a working artefact of one investigation and there is no reason to keep them once it is settled — so a citation may outlive the evidence it points at, and the record says so rather than pretending otherwise.
| What | Retained | Note |
|---|---|---|
| Raw evidence | 30 days (configurable) | The artefacts themselves — query results, log lines |
| Diagnosis and reasoning | Life of the incident record | Claims and citations; the artefact may already be gone |
| Topology graph | Rolling, refreshed on discovery | Structure only — object names, no row data |
| Audit log | 12 months | Retained deliberately longer than the data it describes |
| On termination | 30 days, then deleted | Export available throughout the window |
Access on your side
Seeing that an incident exists and reading production rows are different decisions.
Most people who need to read a diagnosis do not need to see the rows underneath it, and collapsing those into one permission forces an unnecessary choice: either grant broad access or exclude people from the investigation. Raw evidence is therefore a separate grant.
| Action | Required | Why |
|---|---|---|
| See that an incident exists | All members | Titles, status and timing carry little sensitive content |
| Read a diagnosis | All members | Claims and reasoning, with citations |
| Open raw evidence | Separate grant | Redacted production rows are a deliberately distinct decision |
| Approve a catalogue query | Admin | Changes what the agent is able to read |
| Change redaction rules | Admin | Built-in rules cannot be disabled at any level |
| Widen an incident scope | Admin | Recorded in both audit trails |
Every one of these actions is recorded. Here is the shape of an audit line as it appears in your own logging, where your SIEM can consume it independently of anything we hold:
{
"ts": "2026-08-05T08:14:22.417Z",
"event": "query.execute",
"agent": "sql-prod-weu",
"incident": "INC-1042",
"catalogue_id": "reject-profile-by-reason",
"statement_sha256": "9f2c…a41d",
"parameters": { "schema": "dbo", "table": "RejectedTransactions",
"since_utc": "2026-08-05T00:00:00Z" },
"server": "sql-prod-02", "database": "Sales",
"rows_returned": 3, "truncated": false, "duration_ms": 412,
"redaction": { "rules_applied": ["pan"], "fields_dropped": [] },
"requested_by": "engine/hypothesis:hyp_04"
}The same record exists server-side and in the investigation timeline. Two independent copies is the design: if they ever disagree, that is a finding, and you should be able to detect it without asking us.
Our stage, stated plainly
The section most vendors write vaguely. Here is the actual position.
Decim is pre-release. We hold no SOC 2 report, no ISO 27001 certificate, and no external penetration test. All three are on the roadmap and none of them are done. There is no published customer list, and any figure elsewhere on this site is illustrative demo data rather than a measured result.
We could phrase that as "compliance roadmap in progress" and it would technically be true. It would also be the first thing you discovered was hollow, which is a poor foundation for a relationship that begins with us asking for read access to your production databases.
What is available now is concrete and reviewable before any pilot: the agent's permission model, the query catalogue, the redaction rules, the data flow above, and a conversation with whoever on your side has to sign this off. If something here is disqualifying, we would much rather establish that on day one than three months in.
Questionnaire answers
Do you hold SOC 2, ISO 27001 or equivalent?
Where is data processed and stored?
Do you use our data to train models?
Which subprocessors do you use?
Can we run it entirely on our own infrastructure?
How do we revoke access immediately?
What is logged, and can we see it?
Has this been penetration tested?
Get started
Send us your security questionnaire
We would rather answer it before a pilot than during one. If something on this page is disqualifying, that is a useful thing for both of us to learn on day one.