Bifrost vs Portkey shows the governance gap in AI gateways

At a glance

What this is: This is a vendor comparison of two AI gateways that find different balances between infrastructure ownership, observability, guardrails, and operational packaging.

Why it matters: It matters because AI gateway decisions now shape model, agent, and MCP governance, including how organisations control access, audit traffic, and manage the identity layer around AI workloads.

By the numbers:

• Bifrost reports 11 microseconds of overhead at 5,000 RPS in its own benchmarks, which it uses to argue for performance-focused self-hosting.
• Portkey’s Production plan costs $49 per month and includes 100,000 recorded logs, giving teams a published entry point for managed gateway operations.

👉 Read TruFoundry’s full comparison of Bifrost vs Portkey for AI gateway governance

Context

AI gateways sit between applications, models, and downstream tools, so they increasingly determine how traffic is authenticated, logged, budgeted, and governed. In practice, that makes the gateway part of the control plane for AI systems, not just a routing layer. The primary identity question is whether teams can govern model access, tool access, and auditability without fragmenting oversight across multiple products.

This comparison matters because the market is converging on gateways as policy enforcement points for AI workloads, including MCP-connected tools and agent workflows. The real gap is not whether a gateway can route requests, but whether it can support durable governance across identity, privilege, observability, and operational ownership. That is especially relevant when managed platforms and self-hosted gateways imply very different control boundaries.

Portkey’s acquisition also changes the buyer’s risk model. Once gateway capabilities sit inside a larger security platform, procurement, roadmap dependence, and integration assumptions can shift even if the immediate feature set remains unchanged.

Key questions

Q: How should teams govern AI gateways that route model and tool traffic?

A: Teams should treat the gateway as the control boundary for identity, spend, logging, and policy enforcement. That means registering each AI workload or agent, attaching a clear owner, and ensuring every significant model or tool call is traceable. The goal is not to slow AI down, but to make it accountable in production.

Q: Why do AI gateways create new access control decisions for IAM teams?

A: Because gateways can inject identity context, mediate tool use, and decide which requests reach models or downstream systems. That means IAM teams must think beyond user sign-in and consider machine-mediated access, runtime policy enforcement, and auditability across AI workflows. The governance problem shifts from who logged in to what the workload was allowed to do.

Q: What breaks when MCP tools are governed separately from model routing?

A: You get partial control. The model can be routed safely while the connected tool remains overexposed, under-audited, or unauthorised. That split leaves a blind spot for agent actions because the system that decides where traffic goes is not the same system that decides what tools the agent may invoke.

Q: When should organisations choose self-hosted AI gateways over managed ones?

A: Choose self-hosted gateways when deployment boundary, residency, and control over runtime behaviour are first-order requirements. Choose managed gateways when operational simplicity, packaged observability, and support matter more than direct infrastructure ownership. The right answer depends on whether policy needs to stay inside your environment or can be delegated.

Technical breakdown

How AI gateways separate routing from governance

An AI gateway is more than a proxy. It can enforce routing rules, log requests, apply budgets, inject identity context, and control access to models or tools. The technical difference between products often lies in where those controls run: inside your environment, in a managed cloud, or split across both. That placement matters because governance quality depends on how close enforcement sits to the workload and whether the gateway can observe both model traffic and tool invocation patterns.

Practical implication: map every gateway control to the environment where enforcement actually occurs, then decide whether self-hosted or managed operation better fits your governance boundary.

MCP support and agent tool control at the gateway boundary

Model Context Protocol, or MCP, links AI agents to tools and data sources. Once MCP is in the stack, the gateway becomes a policy chokepoint for tool use, not just prompt routing. A gateway that understands MCP can help teams centralise visibility over which tools are exposed, how requests are authorised, and whether agent actions remain inside approved boundaries. Without that, teams often end up governing model calls separately from tool access, which leaves a control gap.

Practical implication: treat MCP-aware gateway controls as part of your identity and access design, not as a separate integration concern.

Why ownership of the gateway changes the control model

Self-hosted gateways shift responsibility to the organisation, including scaling, hardening, monitoring, and patching. Managed gateways shift some of that burden to the vendor, but also reduce direct control over deployment boundaries, data residency, and operational response. For regulated AI workloads, the architectural question is whether governance needs to stay inside the customer VPC or whether a managed model still satisfies policy, audit, and residency expectations. That decision affects both security assurance and procurement risk.

Practical implication: require architecture review to cover deployment boundary, audit retention, and data residency before standardising on a gateway model.

NHI Mgmt Group analysis

AI gateways are becoming identity enforcement points, not just routing infrastructure. Once model traffic, tool calls, budgets, and logs converge in one layer, the gateway starts to function like an access control plane for AI workloads. That makes identity, authorisation, and auditability part of the same design conversation. The practical conclusion is that teams should govern gateways as security controls, not platform plumbing.

Named concept: gateway governance gap. This is the disconnect between a gateway that can route requests and a gateway that can actually enforce policy across models, tools, and runtime behaviour. The article shows why feature checklists miss the real issue. A team can have logs, traces, and guardrails yet still lack a coherent control boundary for AI agent actions. Practitioners should evaluate whether their gateway closes that gap or merely observes it.

Portkey’s acquisition illustrates how quickly control assumptions can move when AI security platforms consolidate. When a specialist gateway becomes part of a broader security suite, buyers inherit new roadmap dependencies, packaging changes, and possible policy alignment benefits. That does not automatically improve governance, but it does alter the procurement and lifecycle risk around the platform. The right response is to reassess vendor dependence and exit options before standardising.

Self-hosted performance and managed operations solve different problems, and neither is sufficient on its own. A fast gateway can still be weak on enterprise lifecycle control, while a packaged gateway can still leave identity and policy decisions too distributed. The article reflects a broader market shift toward gateways as operational control points for AI. Practitioners should judge them by governance fit, not throughput alone.

Identity-aware AI control will increasingly depend on the intersection of IAM, MCP, and runtime observability. As agents call tools directly, the access model moves from user-centric sessions to machine-mediated decisions. That pushes organisations to connect model routing, tool authorisation, and audit trails into one lifecycle. The implication for practitioners is clear: gateway selection is now an IAM-adjacent decision, not only an AI platform choice.

What this signals

Gateway governance now needs to be evaluated as runtime identity control. As AI systems gain direct tool access, the gateway becomes the most practical place to apply policy, logging, and behavioural constraints. That makes AI gateway choice a governance decision that should sit alongside IAM and application security review, not after it.

AI gateway teams should expect policy pressure to move down the stack. The more agents and MCP tools become standard, the more organisations will ask where authorisation is enforced, how requests are attributed, and whether logs are sufficient for investigation. The teams that can answer those questions cleanly will have a stronger operating model for shared AI infrastructure.

Model Context Protocol changes the governance surface of AI systems. Once tool access is exposed through MCP, the boundary between application control and identity control narrows. Practitioners should plan for policy evaluation at the gateway, not only at the application or provider layer, and validate that their control model can follow the agent across tools and sessions.

For practitioners

• Define the gateway control boundary Document which enforcement points belong in the gateway, which belong in IAM or PAM, and which remain application-side. Use that boundary to decide whether self-hosted or managed operation matches your policy and audit requirements.
• Validate MCP tool exposure controls Test whether the gateway can consistently govern tool access, not just model calls, and verify how authorisation is applied to MCP-connected workflows. This is where many AI control designs break down in practice.
• Review deployment and residency assumptions Check whether the gateway must remain inside your VPC, whether logs can stay under your retention rules, and whether a managed cloud option changes your compliance posture.
• Reassess vendor dependency after acquisition If a gateway vendor is absorbed into a larger platform, revisit roadmap dependence, migration paths, and support commitments before extending the rollout.

Key takeaways

• AI gateways now sit at the intersection of routing, policy, and identity control, which makes them a governance decision rather than a pure infrastructure choice.
• The article’s real tension is not feature count but control placement, because self-hosted and managed gateways shift accountability in different ways.
• As MCP and agentic workflows expand, teams will need gateways that enforce access boundaries, not just observe traffic.

Key terms

• AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Gateway Governance Gap: The mismatch between request-level enforcement and actual identity governance. A gateway can inspect traffic and block calls, but it cannot by itself determine standing privilege, lifecycle status, or whether the caller is entitled across the broader enterprise environment.

What's in the full article

TruFoundry's full analysis covers the operational detail this post intentionally leaves for the source:

• Pricing table context for open-source, production, and enterprise tiers that informs procurement decisions
• Detailed feature-by-feature notes on guardrails, logs, traces, budgets, and MCP support across the two platforms
• Additional explanation of the acquisition context and how it may affect roadmap ownership and support expectations
• Practical buyer guidance for choosing between self-hosted control and managed operations in production AI environments

👉 TruFoundry’s full article includes the pricing, feature, and acquisition details behind the comparison.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and agentic AI identity. It helps practitioners connect identity controls to the broader AI and security programmes they are responsible for.