Private LLM security: controls and acceptance tests

Private LLM security starts with the surrounding system. Identify users, administrators, applications, documents, logs and connected tools. State permitted access and the consequence of misuse for each. A user allowed to submit a question is not necessarily allowed to see every document the application can retrieve. The design must preserve that distinction before content reaches the model.

Consider internal mistakes, compromised credentials, malicious external content and operational failure. A useful threat model does not need every imaginable attack; prioritise paths that exist in the architecture. The data-flow guide identifies where controls belong. Evaluate those boundaries rather than limiting review to the inference endpoint.

Use synthetic data and authorised test accounts. Record configuration, expected result, observed result and date. A control without evidence remains pending. A failed test needs an owner and a resolution or explicit decision before production use.

The application should decide what a user can access before supplying context. Asking a model not to reveal another department's information is insufficient when that information is already in its input. Apply permissions in retrieval and tools using the caller's identity and the scope of the operation. A model's answer is not an access-control decision.

OWASP describes prompt injection arising from direct inputs or content a system processes. Treat a document as information rather than authority to grant privileges. Reduce tool capabilities to the task and require approval outside the model for sensitive actions. This limits the consequences when model behaviour is influenced.

Model output becomes input to the next component. Validate schemas and allowed values before storing structured fields. Treat generated text as untrusted content when rendering it in a web application. If a model proposes an action, the application must recheck permissions and business conditions. Generating a plausible command or identifier does not authorise its use.

An illustrative example is a request classifier returning a category outside the approved list. Route the task for review rather than automatically creating a new category with downstream effects. Record the failure without retaining unnecessary content. The pilot guide includes invalid and missing-information cases as well as favourable examples.

Supply only the information required for the task. Separating identifiers from content or using synthetic examples during testing can reduce exposure. Review errors, traces and support tooling too: an exception that prints a full prompt can expose more data than the serving engine. Specify which events are logged and who can read them.

OWASP's sensitive information disclosure guidance notes that instruction-based restrictions can be bypassed. Combine minimisation, permissions and output validation instead of relying on those restrictions alone. Keep passwords out of system prompts and do not treat the prompt as a secret store.

An authorised request can consume disproportionate resources. Bound input, output, concurrency and duration according to the service. Define queues and saturation responses so a batch cannot block every interactive user. Ensure monitoring distinguishes overload from model errors and dependency failures. Otherwise the operator may respond to a capacity problem by making an unnecessary model change.

Track the origin and version of model artefacts, containers and libraries. Retain reproducible configuration and a rollback procedure. Repeat affected tests after changes to the model, engine, permissions or tools. The operations plan should name owners for incidents, patches and recovery rather than leaving that work implicit.

Provide the component inventory, trust boundaries, controls, test evidence, corrected failures and accepted risks. Distinguish a point-in-time observation from a contractual commitment. State which changes invalidate tests and who must review them. The record is useful when someone else can reconstruct why the system was approved for its particular use.

Use the vendor assessment matrix to request this evidence. Private inference services define controls and tests for the engagement's scope. Private deployment is not immunity from attack or automatic compliance with a standard; acceptance remains tied to the system and conditions actually evaluated.