Self-hosting changes where data is processed, but it does not remove risks built into the model’s weights, such as jailbreak susceptibility or embedded policy behaviour. Teams still need classification, logging, runtime controls, and restricted use cases. Infrastructure control is necessary, but it is not enough to make the model safe.
Why This Matters for Security Teams
Self-hosting is often treated as a governance shortcut, but that assumption is too narrow. Moving a model onto owned infrastructure improves control over data residency, monitoring, and change management, yet it does not eliminate model-level risk. Prompt injection, unsafe outputs, hidden capabilities, and misuse by authorised users can still occur even when the model never leaves the enterprise network. The real question is not where the model runs, but whether its behaviour is bounded by policy, review, and accountability.
This matters because security teams can easily over-rotate on infrastructure controls and underinvest in operational governance. A self-hosted deployment still needs clear use-case approval, logging, escalation paths, and restrictions on what data the model may process. The NIST Cybersecurity Framework 2.0 remains useful here because it treats governance, risk management, and continuous oversight as core security functions rather than optional extras.
In practice, many security teams discover model misuse only after an internal user has already exposed sensitive data or relied on an unreviewed output for a business decision, rather than through intentional governance design.
How It Works in Practice
Strict governance for self-hosted AI models starts with classifying the model as a controlled system, not a neutral tool. That classification should define approved use cases, prohibited data types, retention rules, human review thresholds, and the conditions under which the model can be connected to internal systems. If the model can retrieve documents, call tools, or trigger actions, those integrations need the same level of review as any other privileged service.
Operationally, teams should separate three layers:
- Model governance: approved weights, provenance, version control, and testing against harmful behaviour.
- Runtime governance: access controls, prompt logging, output filtering, and rate limits.
- Data governance: which sources the model can read, which outputs may be stored, and how sensitive content is masked.
That structure aligns with emerging guidance from the NIST AI Risk Management Framework, which emphasises mapping, measuring, and managing AI risks across the lifecycle. For adversarial behaviour, practitioners should also consider attack patterns catalogued in MITRE ATLAS, especially where prompt injection, data poisoning, or model manipulation could alter outputs or downstream actions.
For self-hosted systems that expose agent-like capabilities, governance must also extend to tool permissions. An AI model that can read files, send messages, or create tickets should be treated as an identity-bearing workload with constrained privileges, not as a general-purpose assistant. These controls tend to break down when teams connect internal tools to a model without mapping the model’s effective authority across production data, because the attack surface expands faster than the review process.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, requiring organisations to balance agility against the need for review, traceability, and exception handling. That tradeoff becomes more visible when teams want rapid experimentation, but the model is also being used on sensitive or regulated data.
Best practice is evolving for self-hosted agentic systems, and there is no universal standard for this yet. Some organisations apply strong governance only to production deployments, while others extend it to all internal testing because prompt logs, copied data, and model outputs can still create exposure during development. The right approach depends on data sensitivity, regulatory exposure, and whether the model can take action rather than merely generate text.
Edge cases usually appear in hybrid environments. A self-hosted model may still call external APIs, use cloud-based retrieval services, or rely on third-party embeddings and evaluation tools. In those situations, the governance boundary is wider than the local server. The OWASP Top 10 for Large Language Model Applications is helpful for identifying common failure modes such as insecure output handling, excessive agency, and prompt injection. For autonomous or semi-autonomous deployments, the CISA secure AI systems guidance helps teams think beyond hosting location and focus on resilient control design.
In mature environments, the practical answer is simple: self-hosting reduces dependency risk, but it does not replace governance, because model behaviour, tool access, and data handling remain security problems even inside the perimeter.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF covers lifecycle risk management for self-hosted model governance. | |
| MITRE ATLAS | ATLAS maps adversarial tactics like prompt injection and data poisoning. | |
| OWASP Agentic AI Top 10 | Agentic AI guidance fits models that can call tools or take actions. | |
| NIST CSF 2.0 | GV.RM | Governance and risk management are central to secure AI oversight. |
| NIST AI 600-1 | The GenAI profile adds practical guidance for generative model controls. |
Threat model the model with ATLAS tactics and test controls against realistic attack paths.
