Security and access
Where your data goes, and who can reach it
We work inside your systems under your access controls, in your repositories, under your license. This page is what we can tell you before an NDA: the access model, tenancy isolation and how it is tested, what is retained, and which model providers touch your records.
The access model
The work happens in your systems, not in ours
There is no Ilayer environment your records get copied into so we can work on them. We build in your accounts, your repositories and your systems, under access you grant and can withdraw. That is the delivery model the whole studio runs on rather than a rule written for this page.
Which systems, which environments and which accounts is set per engagement and written into the scoping document before the price is agreed. A blanket access policy published here would be a fiction: the right answer for a rent roll behind a VPN is not the right answer for a public documentation corpus.
- Access is granted by you, scoped by you, and withdrawn by you.
- Code lands in your repositories from the first commit, under your license, where your engineers review it like any other change.
- The systems in scope, and the person who can approve access to each one, are named in the scoping document both sides sign.
Set per engagement, not by policy: the specific accounts, environments and data a build touches. That list is written down before anyone is granted anything.
What the scoping document containsTenancy isolation
One client's records in another client's answer
For a retrieval system serving more than one tenant, this is the failure that matters more than the rest. A question asked by one tenant returns a passage belonging to another, the answer reads perfectly well, and nobody notices until somebody does.
It is a check in the gate rather than a design intention, so it is re-run on every release and it is tested across both embedding spaces. A leak that only shows up in one of them is still a leak.
Read the number as one system's record. It is not a studio average, and it is not a promise about a system that does not exist yet. A leak test is only as wide as the tenant pairs somebody wrote into it.
What is retained
The index, the logs and the eval cases sit where your data sits
A system built to run inside your environment keeps its index, its answer logs and its eval cases there too. The plain version is that we are not running a store of your records on the side, and the reason is architectural rather than a promise: there is nowhere in this delivery model for that store to live.
If a piece of work needs anything to cross that boundary, it is named in the scoping document and agreed before it happens, not assumed and mentioned later.
What we cannot state as fixed policy: a retention window in days. Retention on a system running in your accounts is set by your accounts, so it is an engagement decision and it belongs in the document both sides sign.
Model providers
Which model providers touch your records
The models are the ones you already pay for. Which providers a design calls is a scoping decision made with you, not a house stack we bring along, and the choice is written down with everything else before the build starts.
On the production system the numbers on this site come from: Claude on AWS Bedrock for inference, OpenAI embeddings for the vector index, and a Voyage reranker. That is one system's design. It is published because a buyer should be able to check what we run on, not because it is a default we would apply to you.
What a provider does with what you send it is governed by your contract with that provider, and it is worth asking them directly. We can tell you which providers a design calls and what leaves your boundary. We cannot speak for their terms.
What we do not have
No SOC 2, no ISO certificate, no penetration test report
We hold none of those and we are not going to imply otherwise on a page whose whole job is answering this question. If a certificate is a hard requirement in your procurement process, we are the wrong vendor for that box, and reading it here is cheaper than finding it out in week six.
What is here instead is the thing we can put a record behind: a number measured by a gate that runs at every release, published with what it does not cover. That is the standard every other figure on this site is held to, and it is the one we would rather be judged on.
Anonymity and review
You are granting access to a studio that publishes no names
That is a fair objection, and it is most of the reason this page exists. The answer is not a biography. It is that the work is visible while it is happening: the code is in your repositories from the first commit, every change goes through your review, and the weekly demo runs on your real data rather than on a chosen set.
The reason there are no names is not a security claim and it is written down plainly elsewhere. Most of the work runs inside other companies' systems under agreements that do not allow us to talk about it.
Removing us
You can end the engagement and keep the system running
A vendor you cannot remove is a risk of its own, so the handover is built for from the start rather than assembled at the end. The code is already yours. The eval suite and the gate are wired into your change process. The runbook is written for whoever is on call, not for a procurement file.
That is the test we hold the work to, and it is stated in the same words on the process page: you can end the monthly rate and keep running.
Ask the rest
If your security review has a question this page does not answer, put it in the first message. A straight no costs you a paragraph now instead of six weeks.
Start a project
Name the workflow. We will tell you if AI fits
One paragraph is enough. You get an honest read on whether this is an AI problem, where it is not, and what a first fixed-scope piece would cost. If the answer is that you do not need us, that is the answer you get.