It has to be inside to be useful, so it comes on a short leash

Consider what the worked investigation actually needed: a count from a reject table grouped by reason, the modify_date of a target object, a file manifest against a trailing median, and the contents of a mapping file as deployed. None of that is in a webhook. An alert says row count below threshold; it cannot tell you where the rows went, because the thing that knows is a table on a server in your estate.

So the choice is between a tool that reasons about alert text — which is to say, produces the plausible prose this product exists to replace — and one that can read. There is no third option, and pretending otherwise by calling it "agentless" would just move the same access somewhere less inspectable.

Which makes the interesting question not whether something runs inside, but what it is structurally incapable of doing. The rest of this page is that answer.

The agent initiates every connection. There is no inbound port, no listening socket, and no mechanism by which we contact your network — including for support. If your egress policy allows one hostname on 443 through a proxy, that is the entire network requirement.

This is the control that matters most, so it is worth being precise about how it works. The agent does not receive SQL and check it against rules. It receives an identifier, looks that identifier up in a local file, and executes the pinned statement with bound parameters. A statement absent from the file is not rejected; it is unreachable.

Every entry carries a purpose in plain language, because a reviewer approving this file should not have to infer intent from SQL. Parameters are bound, never interpolated — the identifiers in braces are validated against the schema before substitution rather than pasted in. max_rows and timeout_seconds are mandatory, which is as much about protecting your production instance from a pathological query as about limiting what leaves.

Adding a query is a pull request against a file on your infrastructure. That is deliberately the same friction as any other production change, and it means the answer to "what could this thing read?" is a file your team owns rather than an assurance we give.

Most of what an investigation needs is metadata — what objects exist, when they changed, what a procedure references, which tables took writes. That requires catalog permissions, not data permissions. Row access is needed in a small number of named places: the reject table, the intake counts, and column-scoped counting on fact tables.

Note the last two statements. GRANT SELECT ON dbo.[Transaction](BatchId, LoadedAtUtc) is a column-scoped grant: enough to count rows per batch and establish when they landed, and structurally incapable of reading a transaction amount or a customer identifier. The explicit DENY is redundant against grants never given, and it is there anyway — a permission the agent must never hold is worth stating twice, because the second statement survives someone later adding a role membership by mistake.

This distinction is the whole control. A vendor that scrubs data when it arrives has, by definition, received it unscrubbed — the secret crossed your boundary and existed in their systems, however briefly, and no retention policy undoes that. Redaction here runs in your network, in the agent process, before anything is queued to send.

Built-in rules cover the categories that cause the most damage and are the least likely to be anticipated: connection strings in configuration, bearer tokens in log lines, private key blocks, and card numbers validated by Luhn rather than matched by length alone. They cannot be disabled.

Custom rules are yours. The replace template is worth noticing — substituting a stable truncated hash rather than a fixed placeholder keeps a value correlatable without being readable. If the same customer appears in a log line and a query result, an investigation can still establish they are the same subject, which is often the analytical point, while nothing recoverable leaves your network.

on_rule_error: drop_field is the default and the right one. A rule that throws is a rule whose output nobody can reason about, and the cost of losing a field is always lower than the cost of shipping the thing it existed to remove.

One agent per network segment that needs reaching, identified by a site id. Enrolment is a one-time token; after that the agent holds its own credential and rotates it.

The container drops all capabilities, runs as a non-root user with a read-only root filesystem, and mounts log directories read-only. Nothing here is unusual — it is the configuration you would require of any third-party agent, written down so your review does not have to ask.

The agent writes a local audit line for each query it executes — catalogue id, parameters, row count, duration, and the investigation that requested it — to your own logging, where your SIEM can see it. The same record exists server-side and is visible in the investigation timeline.

Two copies is the point. A record that only we hold is a record you have to take on trust; one written into your logging is one you can reconcile against independently. If those two ever disagree, that is a finding, and you should be able to detect it without asking us.

Related: security for the threat model and data handling; evidence for how collected artefacts are cited; and pipeline topology for what the read-only metadata is used to build.