A self-hosted AI interface is a user-facing application that lets people chat with one or more AI models from an organisation’s own environment. It improves control over deployment and data flow, but it is still only the presentation layer and does not automatically govern models, tools, identities, or audit requirements.
Expanded Definition
A self-hosted AI interface is the front-end layer an organisation controls inside its own environment for interacting with one or more AI models. It may improve data locality, branding, and deployment control, but it does not by itself establish model governance, tool authorization, identity proofing, or audit-grade logging.
In NHI security, the distinction matters because the interface is often mistaken for the control plane. Guidance varies across vendors, but the consistent security view is that the interface should be treated as presentation and routing, while policy enforcement remains separate in identity, secrets, and tool-access layers. That separation aligns with least-privilege expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls and with the NHI risk patterns described in DeepSeek breach.
The most common misapplication is treating a self-hosted chat app as a complete security boundary, which occurs when organisations assume local deployment automatically governs model access, secrets, and downstream tool actions.
Examples and Use Cases
Implementing a self-hosted AI interface rigorously often introduces operational overhead, requiring organisations to weigh tighter data control against the cost of maintaining identity, logging, and model-routing discipline.
- An internal assistant is hosted on company infrastructure so employee prompts never leave the tenant, while separate policy services decide which models can be reached and which prompts are logged.
- A regulated business uses a private chat interface for case workers, but all sensitive retrieval calls are mediated through approved service accounts and explicit NHI controls rather than the UI itself.
- A software team deploys an on-premises AI portal to reduce vendor exposure, yet still integrates external model endpoints under NIST SP 800-53 Rev 5 Security and Privacy Controls-aligned access checks.
- Security teams review a private interface after a prompt incident and discover the issue was not the UI, but over-permissive tool credentials exposed to the backend.
- Engineering groups use a self-hosted interface as a staging layer for model experimentation, then require approval before any connector can touch production data or secrets.
NHIMG research on the DeepSeek breach shows how exposed data and embedded secrets can turn an AI-facing environment into a broader security event when controls are not separated from the interface layer.
Why It Matters in NHI Security
A self-hosted AI interface can create a false sense of containment. Teams often assume that keeping the application in-house reduces NHI risk, but the real exposure usually sits in the connected identities, service tokens, prompt history, retrieval paths, and administrative backends. If those elements are not governed, the interface can become a convenient path for secret leakage and unintended tool execution.
This matters because secrets are rarely managed as a single clean system in practice. NHIMG research in The State of Secrets in AppSec found that organisations maintain an average of 6 distinct secrets manager instances, which fragments control and makes it harder to enforce consistent policy. That fragmentation is especially dangerous when a self-hosted interface is granted broad backend reach without clear NHI ownership.
Organisations typically encounter the security relevance of a self-hosted AI interface only after a prompt leak, token abuse, or unauthorized model action, at which point the interface’s true role in the incident becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Self-hosted interfaces often expose secret handling and backend trust gaps. |
| NIST CSF 2.0 | PR.AC-4 | Access enforcement must govern identities behind the interface, not the UI itself. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust requires backend requests to be verified regardless of self-hosted placement. |
| NIST SP 800-63 | IAL2 | Human access to admin functions depends on identity assurance, not local hosting. |
| OWASP Agentic AI Top 10 | A-01 | Agentic systems often fail when UI convenience hides tool and privilege boundaries. |
Treat every interface-to-model and interface-to-tool call as untrusted until explicitly authorized.
