Security review

Your data does not leave is a claim. A drawn boundary is an argument.

Most AI projects do not die in the build. They die in the review, on four questions nobody prepared for: what leaves our estate, who does the agent act as, what happens when a document tells it to misbehave, and what can we show an auditor a year from now. These are the answers, with the costs attached and with the parts your own counsel has to decide left to your own counsel.

Bring us your review questions The whole stack

The boundary

Draw the line first. Then mark every crossing.

Tenancy is the term for the slice of infrastructure that is yours alone — your cloud account, your database, your storage, your keys. Everything on the left of this line stays there. Everything on the right leaves it, and the honest work of a security review is naming those crossings rather than implying there are none.

Read the right-hand column first: it is the short list of things that actually cross, and it is what a reviewer will ask about. On your own build, check three things against this picture. One, whether the passages your search returns are the minimum needed to answer, or the whole document — the crossing is as wide as whatever you put in the prompt. Two, whether telemetry is content or counts; error reports that carry the failing prompt carry the data in it. Three, whether the crossing is a hosted model at all, because with a model running inside your own cloud the right-hand column shrinks to almost nothing and your operating burden grows to match.

The controls

Five decisions that a review actually turns on.

Each of these is a choice made once, early, and expensive to reverse later. Each is stated here with what it costs you and with the part of the problem it still does not solve, because a control described only by what it prevents is a sales claim.

Hosting choice

Vendor API, model deployed in your own cloud tenancy, or self-hosted weights on your own hardware

Where the model itself runs, which decides how far your data travels. Calling a vendor's hosted API means your prompt and the retrieved passages cross out of your estate to that vendor's infrastructure. Deploying a model inside your own cloud account — the major clouds all offer this — means the traffic stays within your tenancy and under your account's own network controls, at a higher standing cost and with a narrower choice of models. Self-hosting open-weight models on your own hardware means nothing leaves at all, and you have inherited a GPU fleet, an inference stack and the people to run both. This is the first decision because everything else is shaped by it, and it is a business decision rather than a technical one.

The choice gets made by default, usually by whichever key a developer had to hand during the prototype. The system reaches review with a data path nobody designed, and the answer to 'where does this go' is found by reading code in the meeting.

Access control

The agent inherits the calling user's permissions — RBAC enforced at retrieval, not after generation

RBAC means role-based access control: what a person may see is decided by the role they hold. The rule that matters here is that the AI system acts as the person asking, not as an administrator with sight of everything. In practice this means permissions are applied when the search runs, so a document the user could not open is never retrieved and never reaches the model. Filtering after the model has written its answer is not access control — the content has already been read, and a summary of a document you may not see is still a leak of that document. The cost is real: your permissions have to be legible to the search layer, and in many organisations that means fixing a permission model that had been quietly rotting in the source system for years.

The agent becomes a search engine over everything, wearing the badge of whoever configured it. The first incident is somebody in one department asking a reasonable question and receiving a correct answer drawn from a document they were never cleared to read.

Prompt injection defence

Untrusted content is data, never instruction; tool calls are allow-listed and consequential actions are confirmed

Prompt injection is the attack where text inside a document or an email tells the model to ignore its instructions and do something else — forward a record, call a tool, reveal what it has been told. It works because a language model reads instructions and content through the same channel, and there is no known way to make that separation perfect. So the defence is not a filter that catches bad text; it is architecture. Content retrieved from documents is marked and framed as material to reason about rather than orders to follow. The tools the agent may call are a fixed, short, allow-listed set rather than open access to your systems. Anything that writes, sends, pays or deletes goes to a person for confirmation. What this costs is autonomy: the agent asks more often, and the system is deliberately less impressive in a demonstration. What it does not do is make injection impossible, which is precisely why the blast radius is kept small instead.

A supplier emails an invoice with a paragraph of instructions buried in white text, and your obliging agent follows them. The failure is not that the model was fooled; it is that a fooled model had the authority to act unsupervised.

Audit trail

Every question, retrieved source, model version, tool call and human decision written to append-only storage

A record, held inside your tenancy, of what was asked, which passages were retrieved to answer it, which model version answered, which tools were called, and what a human then approved or rejected. Append-only means entries are added and never edited, so the record can be trusted about the past. This is the control that turns an incident from an argument into an investigation, and it is the one most often left until after launch, when the interesting month has already gone unrecorded. The cost is storage, a retention decision, and the discipline of treating the log as a system with an owner rather than as debug output. Note also what it creates: the log now contains the sensitive text of the questions and the passages, so it inherits the same access rules as the documents themselves.

Someone reports a wrong answer from three weeks ago and there is no way to establish what the system saw when it gave that answer. You cannot show it was right, you cannot show it was wrong, and you cannot show it has stopped.

Retention and residency

Stated lifetimes per data class; region-pinned storage and inference; deletion that reaches the index and the logs

Retention is how long each kind of data is kept before it is deleted. Data residency is the requirement that data be stored, and often processed, within a particular country or region. Both have to be decided per class of data rather than for the system as a whole: source documents, the search index, conversation history and audit logs can each carry a different lifetime, and only the audit log usually wants a long one. Residency has to include inference, not only storage — a database pinned to a region and a model call routed elsewhere is a boundary crossing that a diagram of the database will not show. The hard part is deletion: when a record is deleted at source, it must also be removed from the search index and considered in the logs, or you have built a system that remembers what your business has forgotten. Whether your particular obligations require any of this, and in what form, is a question for your counsel or data protection officer rather than for us.

A deletion request is honoured in the source system and quietly ignored by the index, so the AI system keeps answering from a record the business believes no longer exists.

Hosting

Three places the model can run. The trade is the same each time.

Control, capability and burden move against each other. Read down the column that matches your constraint, then read the last row, which is the only one that answers the question you are actually asking.

	Vendor API	In your cloud	Self-hosted
What leaves your tenancy	The prompt, the retrieved passages, the response, and usage telemetry	Nothing to a third party; traffic stays inside your own cloud account and region	Nothing. The weights and the traffic are both on hardware you control
Control over data	Governed by the vendor's contract and settings — read them, do not assume them	Your cloud account's own network rules, keys, logging and region controls apply	Total, and entirely your responsibility to configure and prove
Model quality available	The strongest models, the day they are released	A good and growing subset, usually a release or two behind	Open-weight models only; excellent for many tasks, behind the frontier on the hardest
Operating burden	Close to none. Capacity, upgrades and uptime are someone else's problem	Moderate. You manage a deployment, its scaling and its version upgrades	Heavy. GPUs, an inference stack, capacity planning and the people who understand all three
Cost shape	Per token. Nothing at rest, and it scales with use in both directions	Mostly reserved or provisioned capacity — you pay for the floor, not the traffic	Capital up front, then power, cooling and staff, whether the system is busy or idle
When it is the right call	Most of the time — and especially before volumes and requirements are known	A residency or contractual constraint that a vendor's terms cannot satisfy	Genuine air-gap requirements, or volumes high enough that per-token cost dominates

In shortFor most organisations the vendor API is the right answer, and it is worth saying that plainly rather than treating it as the compromise you settle for. Under an enterprise agreement with the terms actually read, it gives you the best models, the lowest operating burden and a cost that follows use — and the crossing it involves is narrow, specific and drawable, which is what a review needs. Move into your own cloud when a residency or contractual requirement makes the crossing unacceptable, not because self-hosting feels safer; a badly run private deployment is less secure than a well-governed vendor call. Self-host when you are genuinely air-gapped or when volume has made per-token cost the largest line, and go in knowing you have taken on a platform to operate as well as a system to build.

The review itself

What gets waved through. What gets sent back.

Security reviewers are not obstructive and they are not impressed by architecture diagrams. They are checking whether anyone has thought about the failure cases, and they can tell within a few questions. These are the two shapes that arrive in that meeting.

A review this will pass

The data path is drawn, with every crossing named and each one traceable to a specific call in the code
The agent acts as the person asking, permissions are applied when the search runs, and someone can demonstrate a user being correctly refused
Consequential actions — anything that writes, sends, pays or deletes — stop at a person, and the confirmation is recorded with the identity of who gave it
The audit trail existed before launch, is append-only, is held in your tenancy, and answers 'what did the system see' for any answer it has ever given
Retention is stated per data class, deletion reaches the index as well as the source, and the open legal questions are already with the DPO rather than being discovered in the meeting

A review this will fail

'Your data does not leave' asserted as a property of the product, with no diagram behind it and no name for what the model call sends
One service account with broad read access doing the retrieving, and per-user permissions promised for a later phase
The injection question answered with 'we filter for malicious instructions', which is a claim about a problem no filter has solved
Logs that are application debug output — no retained record of retrieved sources, model version, or who approved what
A compliance answer that names a framework instead of describing an architecture, and a supplier who volunteers legal conclusions rather than pointing at the customer's own counsel

Asked in every review

The five questions that come up without fail.

Does the model vendor train on our data?: This is a contractual question, not an architectural one, and it is the single most important thing to establish before you send a byte. Do not take a general answer from a supplier, including from us, and do not rely on what is true of a consumer product being true of the business API. Read the terms of the specific model and the specific plan you are on, and look for four things: whether inputs and outputs may be used to train or improve models, whether there is an opt-out or whether the business tier excludes it by default, how long the vendor retains what you send and for what purpose, and whether human reviewers may see it. Those four answers, in writing, are what the review wants. Where the terms cannot satisfy your constraint, that is the signal to move the model inside your own cloud rather than to negotiate the constraint.
What about personal data inside the documents themselves?: Assume it is there, because in operational documents it usually is, in the free-text fields nobody thinks of. There are three postures and they are not exclusive. You can exclude: keep documents and fields that carry personal data out of the index entirely, which is clean and loses whatever value they held. You can redact or pseudonymise before indexing, replacing identifiers with tokens — this reduces exposure, and be clear-eyed that redaction over free text is imperfect and that a person is often re-identifiable from the surrounding detail. Or you can permit it and control it, by keeping the crossing narrow, applying the user's own permissions at retrieval, treating the audit log as sensitive because it now contains the same text, and pinning residency. Which posture is required for your data is a decision for your DPO. What we can do is build to whichever they choose and show them exactly where the data goes under it.
Can we use this under GDPR, or the EU AI Act?: We will not tell you that an architecture is compliant, because compliance is a determination about your organisation, your purpose and your data, and it is made by your counsel or your data protection officer. What we can do is build a system that is possible to assess, which is where most projects fail long before they reach a lawyer. Broadly, data protection regimes such as the GDPR ask about lawful basis, purpose limitation, minimisation, transfers outside the region, retention, and the rights of the individual including deletion — and every one of those is easier to answer when the boundary is drawn, retrieval is minimised, residency is pinned and deletion propagates. The EU AI Act, again broadly, places obligations that vary with the risk category of the use, with heavier duties for high-risk applications around documentation, human oversight and record-keeping. Our part is the record-keeping, the oversight points and the documentation of what the system does. Your counsel's part is the categorisation and the legal conclusion, and we would rather hand them a clear architecture than an opinion.
What about India's DPDP Act?: The same division of labour applies, and the same warning against taking legal conclusions from a supplier. India's Digital Personal Data Protection Act, 2023 sets out obligations for organisations handling the personal data of individuals in India, with themes a security review will recognise: a basis for processing that generally rests on notice and consent, purpose limitation, obligations around accuracy and security, breach notification, and the rights of the individual including correction and erasure. Rules and enforcement detail have continued to develop, so the current position should be checked with counsel rather than assumed from any summary — including this one. For an AI system the practical consequences are familiar: know what personal data is in the index, be able to delete it from the index and not only from the source, be able to say where it is processed, and keep the record that shows both. If you operate across India and the EU, build to the stricter constraint rather than maintaining two architectures.
Who can see the logs?: Fewer people than can see the application, and the number should be written down before launch. The audit trail contains the questions people asked and the passages retrieved to answer them, which makes it as sensitive as the documents it draws from and sometimes more revealing, because a question discloses intent. So it gets its own access rules, and reading it is itself logged. In practice we separate two things that are usually conflated: an operational log of latency, errors and token counts, which engineers need routinely and which should carry no content, and the content-bearing audit record, which is restricted to named roles — typically security, compliance and a small number of system owners — and read on cause rather than by habit. Where an engineer needs content to debug a specific failure, that is an access request with a reason attached, not a default. Who those named roles are is your decision, and it belongs in the review pack rather than in a configuration file discovered later.

In practice

Bring the drawing. Not the assurance.

The projects that clear security review are not the ones with the strongest claims. They are the ones that arrive with the boundary already drawn, the crossings already named, the permission model already inherited from the systems that own it, and a log that was running before anyone asked for it. Everything on this page is cheaper to decide at the start than to retrofit, and access control and audit are the two that are genuinely painful to add late.

We hold no compliance opinion on your behalf and we will not offer one. What we will do is build the system so that the people who do hold that opinion — your counsel, your DPO, your security team — can look at it and reach one. If you have a review coming and a list of questions you cannot yet answer, that list is a good place for a conversation to start.

Send us your review questions How we run an engagement

How a machine answers from your own documents

How does a language model answer from your documents, and where does that go wrong?

Read

The last mile into your systems

What has to be true for a system to write into your ERP, HRMS or CRM — and why this is the layer that decides whether any of it was worth building.

Read

From prototype to production

You have a demo that works. What is actually between that and a system your business can depend on?

Read

Loading…

FAQs

Frequently Asked Questions

Industrial AI, robotics conversion and adoption, Industry 4.0 automation and test automation, and the software those systems run inside: enterprise systems (ERP, HRMS, CRM, inventory and production management), web applications, AI agents and automation, and native mobile apps for iOS and Android.

A focused first release typically ships in 8–12 weeks. Multi-module enterprise platforms run 4–9 months, delivered module by module so you are using working software long before the final release rather than waiting on a single big-bang launch.

Both. A well-defined scope gets a fixed price against a signed specification. Longer or evolving builds run as a dedicated team on a monthly retainer. Either way you get a written estimate with every assumption listed before a contract exists, so you can see exactly what moves the number.

Discovery and scoping, then UI/UX design, then two-week build sprints that each end in a working demo. You get a staging environment from the first week, and QA, security review and deployment run inside the sprint instead of being bolted on at the end.

You do, in full, on final payment. Source code, design files, infrastructure and documentation are handed over in your own repositories and cloud accounts. We keep no licence over your product and there is no lock-in to our hosting.

Yes. We connect to MES and the equipment already on the line, accounting, HR and CRM platforms, payment gateways, WhatsApp Business, and legacy in-house databases. Where no API exists we build a sync layer and migrate historical records with reconciliation reports your finance team can check line by line.

Every project closes with a handover: documentation, team training, and a warranty period covering defects at no cost. After that you can run support in-house or keep us on a monthly plan covering monitoring, security patches, and an agreed block of enhancement hours.

We sign your NDA before the first technical conversation. Builds ship with role-based access, encryption in transit and at rest, and audit logging as standard. Production data stays inside your infrastructure and access is limited to the engineers assigned to your project.

Start a project

Didn’t find what you were looking for?

Tell us what you are building. You get scope, a timeline and a realistic cost — not a brochure.

Tools

The stack we build on

We design, build, and evaluate with a modern AI stack—LLMs, vector search, orchestration, and observability—so your features are fast, reliable, and secure.

OpenAI

Anthropic

Gemini

xAI

Hugging Face

Kimi

LangChain

NVIDIA

Pinecone

Databricks