Hosted or self-hosted model for security work: how to choose

Choose by what data the model will see, how much control you need, whether you can run it well, and what evidence your customers or regulators expect. Hosted models are easier to run and usually stronger. Self-hosted models keep data inside your boundary but make you responsible for patching, capacity and behavior.

What is the real difference?

With a hosted API, a provider runs the model, and your prompts travel to its service under its terms. With a self-hosted model, you run weights on infrastructure you control. A middle option is a private deployment of a hosted model in your own cloud account, where the provider's terms and your network boundary both matter.

None of these is secure by label. The UK NCSC's guidelines for secure AI development are aimed at providers of systems using models hosted by an organisation or external APIs, and treat security as a requirement through design, development, deployment and operation. The location of the model changes who does which part.

Which questions decide it?

Data. What will the model read: source code, vulnerability reports, customer configurations, secrets? Read the provider's published terms on retention and training use, and have legal confirm them. If you cannot accept the terms for that data class, that data stays in a boundary you control.

Control. A self-hosted model lets you pin the version, so behavior does not change under you. A hosted alias may change. If your triage results must be reproducible, pin and record the exact version either way.

Capability. Task quality matters for security work such as code review or report analysis. Test candidates on your own sample set before deciding, since general benchmarks may not predict your results.

Operations. Self-hosting means GPUs or capacity planning, patching the serving stack, access control to the endpoint and monitoring. If nobody owns that, the model will rot.

Evidence. Some customers and frameworks ask where data is processed and by whom. A diagram of the data path, whichever option you choose, answers most questions.

What risks stay the same?

Prompt injection, excessive agency and information disclosure apply wherever the model runs. Model artifacts for self-hosting add supply chain risk, such as loading unsafe serialization formats from untrusted sources. Hosting location does not remove the need to treat inputs as untrusted and to limit what the model may do.

A constructed example

A security team wants a model to read internal penetration test reports and propose remediation tickets. The reports contain customer environment details. Legal reviews the hosted provider's terms and finds them acceptable for source code but not for these reports. The team runs a self-hosted model on a private subnet for the report task, and uses a hosted model for public documentation questions. Each route has its own logging and its own owner.

Checklist

1. Classify the data the model will see, task by task.
2. Read provider terms on retention and training, with legal, for each data class.
3. Test two or three candidates on a sample of your real tasks.
4. Pin and record the model version used for each decision.
5. For self-hosting, assign owners for patching, capacity, endpoint access and monitoring.
6. For hosted use, document the data path and the contract basis.
7. Limit tools and permissions the same way in both cases.
8. Draw one diagram of data flow you can hand to a customer or auditor.
9. Revisit the choice each year, since models and terms change.

Safeguard supports Full AI, Zero AI and bring your own model modes, so the choice need not be locked in by the product you use for security work.

Quick check

Sources

• UK NCSC, Guidelines for secure AI system development
• OWASP GenAI, LLM02 Sensitive Information Disclosure
• Hugging Face Hub, pickle scanning

Last reviewed: 18 October 2026.