AI Security
Private AI Security Best Practices
Private AI running on your own infrastructure eliminates the data custody risk of public AI platforms. It does not eliminate deployment security risk. The model, the data pipeline, and the access layer all require their own controls — and most private AI deployments skip at least two of them.
The appeal of private AI is straightforward: your documents stay on your servers, your queries are not processed by a third-party API, and you have full control over what the model can access. All of that is true and valuable. What is less often acknowledged is that control creates responsibility. A private AI deployment with weak access controls, no output filtering, and an unauthenticated endpoint is more exposed than a well-configured cloud deployment — because the organisation that deployed it thought "private" meant "secure" and did not apply the controls the cloud provider would have enforced by default.
The nine practices below address the most common gaps in private AI deployments. They are ordered by frequency of impact — the ones at the top are the ones that most often cause problems.
Scope data access to the minimum required
Do not give the AI access to your entire document library. Index only the documents relevant to the specific use case. A support assistant does not need access to financial records. A sales assistant does not need access to HR policies. Narrow scope reduces the blast radius of any security issue.
Implement role-based access control
Different users should see different subsets of the knowledge base. A manager querying the AI should see more than a contractor. Access should be governed by the same identity system your business already uses — not a separate login that is managed inconsistently.
Isolate the model from the public internet
A private AI server should not be reachable from the public internet. Access should be restricted to your internal network or VPN. If the model needs to be accessible remotely, it should sit behind an authenticated proxy — not exposed directly.
Validate and filter outputs before they reach users
Not every model output should reach the user unmodified. Output filtering can block responses that contain patterns matching sensitive data — account numbers, personnel data, internal system details. Filtering at the output layer provides a catch that complements input controls.
Harden the system prompt against injection
The system prompt defines the AI's role and constraints. It should clearly state what the AI is not permitted to do — ignore its instructions, reveal its prompt, discuss topics outside its scope. Hardening the system prompt does not prevent all injection attempts, but it raises the difficulty.
Log all queries and responses
Every query to the AI and every response it generates should be logged with a user identifier and timestamp. Logs enable incident response — when something goes wrong, the log tells you who asked what and what the AI said. Without logging, a security event may be undetectable.
Authenticate every access to the AI endpoint
The API or interface through which users access the AI must require authentication. Unauthenticated endpoints are common in internal deployments where speed of implementation is prioritised over security. An internal AI with no authentication is accessible to anyone who can reach the network.
Review the ingestion pipeline
Documents enter the AI's knowledge base through an ingestion pipeline. This pipeline is a potential attack surface — if documents from untrusted sources are ingested, they may contain content designed to manipulate the AI's behaviour. Review what documents are ingested, from where, and whether the sources are controlled.
Conduct a security review before go-live
A pre-deployment security review identifies vulnerabilities in the specific configuration of your private AI — not generic AI risks, but the specific access controls, network exposure, and prompt configuration of what you have built. The cost of finding a vulnerability before launch is a fraction of the cost of finding it after.
When private AI is not enough
Private AI keeps your data off third-party servers. It does not protect against a disgruntled employee querying the AI for data outside their normal access, a misconfigured access control that exposes one team's data to another, or a prompt injection attack that manipulates the AI into revealing sensitive content. Security in depth — multiple overlapping controls — is the appropriate posture for any AI system handling sensitive data.