A buyer’s security questions come in a predictable order, and they start before the first call. Here are the answers, written down before anyone has to ask — because a buyer should not need a meeting to learn how a firm treats their data.
The boundary comes first
An engagement defines the data boundary in writing before an agent touches anything — the systems and the data it may read. Agents work inside the systems you already run, under your accounts and your access controls, and the boundary is written into the engagement, not implied by it.
What stays outside the boundary stays outside. An agent that summarizes your tickets has no business reading your payroll, and the architecture — not a policy document — is what stops it.
The sentence worth reading twice
Your accounts, your IP, and your data never train anything of ours. That sentence sits in our FAQ and on our privacy page in the same words, and it goes into every engagement contract we sign. Two of those three are marketing surfaces. The third is the one with teeth.
The same discipline applies one level down. Our products and engagements run on the major model providers — vendor-honest, not vendor-loyal — and the engagement fixes what may be sent to them.
Sub-processors and where data sits
Two questions always follow, and they deserve a straight answer rather than a general one: which third parties see the data, and where does it physically live?
Both are settled per engagement, in writing, before work starts — because the honest answer depends on your stack, your regulator and your regions, and a website promise that ignored those would be worth nothing. What is fixed in advance: the providers in play are named, their retention terms are stated, and the residency question is settled in writing before an agent runs. If we cannot meet a requirement, we say so in the discovery week rather than after the contract.
Who says yes
Nothing that ships or changes production moves without a named person’s approval. That is the human gate, and it is architecture: an agent proposes, a person approves, and the system cannot skip the step. For security teams, that means an audit question always has a human answer — who approved this, and when.
Alongside the gates, the build itself leaves a trail: working software every week and a decision log recording why the system grew the way it did. Security reviews go faster when the reasons are already written down.
Ownership, without the asterisk
From the first commit: your accounts, your repositories, your IP. When an engagement ends, the handover is documented — runbook, live metrics, and everything that makes the system yours in practice, not just on paper. No lock-in is a design decision, not a discount.
The receipt
Trust claims are cheap; checkable ones are not. Ours are on this site already: a privacy page that hedges honestly instead of overclaiming — it says analytics are cookieless where enabled, because none are enabled today. A pre-launch product marked pre-launch everywhere, including in our own sales copy. A build record where machine gates fail the build on violation, with no exceptions.
A firm’s security posture is rarely stated on its website; it leaks through it. We would rather you read ours deliberately.
Send us the security questionnaire before the first call if you like — info@adhuniklabs.com.