A self-hosted gateway is an intermediary layer that an organisation deploys and operates in its own environment. It centralises model access, routing, authentication, logging, and policy enforcement while keeping infrastructure ownership in-house. This approach is common when teams need stricter governance, private deployment, or custom control over AI traffic.
Expanded Definition
A self-hosted gateway is the control point an organisation runs inside its own infrastructure to mediate AI or model traffic. In NHI and agentic AI environments, it usually sits between applications, agents, and upstream model providers so that routing, authentication, logging, and policy checks happen under local control rather than in a vendor-operated plane. That distinction matters because the gateway becomes part of the trust boundary: it can enforce which identities may call which models, what data may pass through, and which actions must be blocked or approved.
Definitions vary across vendors, because some products describe a self-hosted gateway as a deployment pattern while others treat it as a management plane feature. The practical meaning is consistent: the organisation owns the runtime and the enforcement logic. This aligns closely with the governance focus of the NIST Cybersecurity Framework 2.0, especially where access control, logging, and protective architecture are concerned. The most common misapplication is treating a self-hosted gateway as a security control by itself, which occurs when teams deploy it without policy design, identity binding, or log review.
Examples and Use Cases
Implementing a self-hosted gateway rigorously often introduces operational overhead, requiring organisations to weigh tighter governance against added maintenance, latency, and patching responsibility.
- Routing internal agent requests to different model providers based on data sensitivity, tenant, or workload class.
- Enforcing authentication and token validation before an agent can reach a model endpoint or tool integration.
- Recording prompts, responses, and policy decisions for audit trails while keeping logs inside the organisation’s environment.
- Blocking unsafe data flows, such as a service account attempting to send secrets or regulated content to an external model.
- Supporting private deployment patterns where the organisation wants local control over model traffic without exposing the gateway to a vendor-managed control plane.
For teams building out NHI governance, the Ultimate Guide to NHIs is useful context because gateway policy is only as strong as the identities it brokers. It also helps to separate deployment convenience from actual control: a gateway can be self-hosted and still permit excessive access if service accounts are overprivileged or secrets are not rotated. That is why many organisations pair gateway enforcement with identity review and secrets hygiene rather than relying on the gateway alone.
Why It Matters in NHI Security
Self-hosted gateways matter because they concentrate enforcement for machine identities that often outnumber humans and are frequently overprivileged. NHIMG reports that 97% of NHIs carry excessive privileges and that only 5.7% of organisations have full visibility into their service accounts, which makes centrally governed traffic control especially valuable. A gateway can help reduce uncontrolled model access, but only if it is tied to identity, policy, and monitoring practices that actually reflect what service accounts and agents are allowed to do.
This is also a resilience issue. When agentic systems use long-lived credentials, secrets spread across code, CI/CD, and automation layers can be abused through a single weak integration point. The control value of a self-hosted gateway is that it creates a place to inspect, constrain, and log those flows before they become incidents. It is particularly relevant in zero trust programs where model access is treated as a continuously evaluated request rather than a blanket entitlement. Organisational teams typically encounter the real need for a self-hosted gateway only after an agent has exfiltrated data, abused a credential, or bypassed an unsafe path, at which point the gateway 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 Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Gateway mediation addresses agent access control and tool-use boundaries. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Gateway logs and routing are only effective when secrets and service accounts are governed. |
| NIST Zero Trust (SP 800-207) | SC-7 | Self-hosted gateways operationalize zero trust inspection and controlled data paths. |
| NIST CSF 2.0 | PR.AC-4 | This term centers on controlling access to systems and resources through enforced policy. |
| CSA MAESTRO | TR.3 | MAESTRO addresses agent orchestration controls that a gateway can enforce. |
Bind every agent call to policy, authentication, and auditable enforcement at the gateway.
Related resources from NHI Mgmt Group
- How should security teams decide between a lightweight gateway and a full identity provider for self-hosted apps?
- How should security teams budget for a self-hosted MCP gateway?
- What is the difference between a self-hosted AI gateway and a broader enterprise AI control plane?
- Why do on-prem LLM deployments need a gateway when models are already self-hosted?
