Who should own the decision to allow provider-specific AI features through a gateway?

Who should make the call on provider-specific AI features at the gateway?

Ownership should sit with a shared decision group rather than a single team, because the choice is not just a routing preference. Provider-specific features can change how prompts, tools, metadata, and responses are handled, which affects security review, platform stability, and AI behaviour. The practical question is who has authority to approve the feature, who understands the failure modes, and who can enforce the controls after it is enabled.

NIST’s control guidance is useful here because the decision combines access control, system monitoring, and configuration management. See NIST SP 800-53 Rev 5 Security and Privacy Controls for the kind of governance and logging expectations that should surround this approval. In practice, many security teams encounter provider-specific gateway features only after a product team has already adopted them informally, rather than through intentional governance.

What changes technically when a gateway allows provider-specific features?

A gateway is often treated as a neutral control point, but provider-specific features make that assumption weaker. Once enabled, the gateway may pass through vendor extensions, special headers, model-specific parameters, tool-calling behaviours, or response formats that do not exist in the common baseline. That can be useful when a team needs a feature from one model family, but it also means the gateway is no longer just translating requests. It is now making selective trust decisions about which capabilities are permitted, how they are passed, and whether they are logged in a way that supports later review.

That is why ownership should be explicit. Platform engineering usually understands the transport path, policy enforcement point, and rollout mechanics. AI engineering understands whether the feature changes model behaviour, output handling, or SDK assumptions. Security needs to judge whether the feature creates a new path for data exposure, weakens inspection, or bypasses a baseline approval process. A useful operating model is:

• Platform owns gateway configuration, release gating, and rollback mechanics.
• AI engineering validates model compatibility, prompt and tool behaviour, and failure conditions.
• Security approves the policy boundary, logging requirement, and access scope.
• A named governance owner resolves disputes when the feature crosses team boundaries.

The key implementation detail is that approval should be feature-specific, not provider-general. A team that has approved one vendor’s extension should not assume another extension is equivalent, even if both are exposed through the same gateway. The control objective is to prove the feature does not undermine data handling, policy enforcement, or auditability before it is broadly enabled.

Where this guidance breaks down is when the gateway is only a thin proxy and the actual feature decision is being made inside the application or SDK, because then gateway ownership alone cannot control the risk.

Where governance gets harder when providers do not behave the same way

Tighter feature approval often slows adoption, and that tradeoff is real. Teams gain stronger control over exposure and consistency, but they may also lose some provider flexibility, release speed, and experimentation latitude. That tension becomes sharper when one provider’s feature has no close equivalent elsewhere, or when the gateway must normalise different request and response semantics. In those cases, the decision should be treated as a governance exception, not a routine configuration change.

There is also a genuine consensus gap in the market on where this ownership should formally sit. Some organisations place the final approval with platform teams because they operate the gateway. Others require security sign-off because the same feature can change inspection and logging. NHI Management Group’s view is that final authority should follow the risk, not the implementation layer. If the feature can change trust boundaries, data exposure, or downstream controls, it needs a shared decision and a clear exception path rather than an informal product choice.

Another edge case appears when a provider-specific capability is needed for a narrow use case but should not become the default for all traffic. In that situation, the safest pattern is to scope approval tightly, define what is allowed, and treat expansion as a new decision. A feature that is acceptable for one workload may be unacceptable for another if the data sensitivity, user population, or audit requirement changes.

Practitioner Guidance

What to prioritise: Treat the approval as a governance decision about trust boundaries, not a technical preference. The first question is whether the feature changes data handling, tool execution, or observability in a way that alters your risk posture.

Decision rule: If the feature affects routing only, platform can usually own the operational change with security oversight. If it changes model behaviour, metadata flow, or logging fidelity, require joint approval and a named exception owner before rollout.

What to verify: Confirm that the gateway can still enforce the intended policy after the feature is enabled. Teams should be able to show what was approved, which traffic is in scope, and how the feature can be disabled without breaking other workloads.

Practitioner takeaway: The decision should sit with the team set that can answer both “can we operate this safely?” and “can we defend this later?”; when those answers are split across teams, shared ownership is the right control structure.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• Who should own the decision when an MDR provider uses AI to drive response?
• What is the difference between routing AI requests through a gateway and integrating each provider directly?
• What makes agentic AI an NHI governance issue?