The AI Agent Control Plane in 2026: MCP Gateways, Model Gateways, and Human Approvals Explained

A reference guide to the AI agent control plane category, the five layers it is made of, the vendors shaping it, and how platform, security, and governance teams can pick an approach that fits. Last updated April 2026.

In 2024, most "AI agents" were demos on a laptop. By 2026, they deploy code, touch production databases, pay invoices, open pull requests, provision cloud resources, and run unattended inside CI pipelines. That shift created a new operational problem: the stack that used to govern humans — IAM, code review, change approvals, finance controls — was never designed for a software process that reasons in natural language and calls tools on behalf of a user.

A new category has emerged to close the gap. It is usually called the AI agent control plane, and it is what this article defines. The piece is a neutral reference for teams evaluating the space. It covers what a control plane is, why the category formed, the five layers it contains, the vendors that occupy each layer, and a decision framework for choosing between an integrated control plane, a best-of-breed stack, or a hyperscaler-managed runtime such as AWS Bedrock AgentCore. Preloop is referenced throughout as an example of the integrated, open-source approach; it is one of several options.

What is an AI agent control plane?

An AI agent control plane is the layer between AI agents and the systems they act on. It decides which tool calls an agent may make, which model traffic it may issue, which actions require human approval, and it records everything that happened for later review. A control plane is what turns an autonomous agent into a governed process: instead of trusting a local Claude Code or Codex CLI instance to do the right thing with production credentials, a control plane intercepts the tool and model traffic and enforces organization-level rules on it.

Most 2026-era control planes are built around five primitives:

  1. Tool access governance — usually implemented as an "MCP firewall" that intercepts every tool call an agent makes and applies allow, deny, require-approval, or require-justification rules, often as YAML policies with CEL or OPA expressions.
  2. Model traffic control — an OpenAI- and Anthropic-compatible gateway that routes model calls, enforces budgets, restricts allowed models, attributes spend, and custodies provider API keys.
  3. Human-in-the-loop approvals — mobile, watch, Slack, Mattermost, email, or webhook notifications that let a person approve, deny, or comment on a tool call before the agent continues.
  4. Runtime session observability — a timeline per agent run, showing tool calls, model calls, policy decisions, approvals, spend, and outcomes.
  5. Audit trails and evidence — durable, queryable logs of every decision, usable for security review, incident response, internal governance, and EU AI Act readiness work.

A platform that addresses all five primitives is what the market now calls an AI agent control plane. A platform that addresses only one or two is typically a point product (an MCP gateway, an AI gateway, an AgentOps tool) that must be composed with others to produce an equivalent outcome.

Why the category emerged

From assistants to operators — agents now take real actions

The category did not exist in 2023 because agents did not do much. The original wave of "AI assistants" (ChatGPT, early Copilot, early Claude) produced text, and a human decided whether to act on it. In 2024 the tooling shifted to in-IDE agents (Cursor, Claude Code, Cline), and by late 2025 production coding agents and general-purpose CLI agents (Codex CLI, Gemini CLI, OpenClaw, OpenCode) became common. Those agents execute commands, edit files, call APIs, and deploy services without the user-in-the-loop step that made the old assistants safe. The risk surface changed from "it said a wrong thing" to "it did a wrong thing."

The limits of IAM and prompt rules

Traditional identity and access management assumes a principal — a user, a service account — that sits on one side of a policy boundary and a resource on the other. AI agents break both sides. A single agent may run as one service identity but act on behalf of many different humans during a day. It may call dozens of tools in a single session, with arguments that matter more than the tool name. And it reasons about its own permissions through prompts, which means any policy expressed in prompt text can be overridden by a sufficiently persuasive input. Prompt rules ("never run rm -rf") are not a control; they are a suggestion to a stochastic model. The control plane category exists because enforcement must sit outside the model.

MCP as the lingua franca

The emergence of Model Context Protocol (MCP) — introduced by Anthropic in late 2024 and widely adopted through 2025 — gave the industry a common abstraction for tool calls. MCP describes tools, their parameters, and their outputs in a stable schema. By 2026 every major agent runtime speaks MCP: Claude Code, Codex CLI, Cursor, Gemini CLI, Cline, Windsurf, and open-source agents like OpenClaw and OpenCode. That standardization is what made a dedicated tool-governance layer practical. An "MCP firewall" can intercept any compliant agent's tool calls without depending on a specific SDK.

Gartner, Palo Alto, and the convergence to "AI Security Platforms" (AISP)

Industry analysts now track the category actively. Gartner has written about agentic platforms as a distinct market from MLOps, and Palo Alto Networks has popularized the term AI Security Platform (AISP) to describe the convergence of MCP gateways, AI gateways, AgentOps, runtime AI security, and governance evidence into a single buying decision. In practice, teams that started the year buying a point gateway are ending it buying a control plane, or assembling one from multiple vendors. The category boundary between "AI gateway," "MCP gateway," "AgentOps platform," and "AI governance suite" is collapsing into a single control-plane concept.

The five layers, explained

Each layer below is a primitive of the control plane. Some vendors cover one layer deeply; a smaller set cover all five.

Tool access governance — the MCP firewall

What it does. Intercepts tool calls between the agent and the underlying MCP servers or native tools. Evaluates each call against a policy — typically YAML with CEL, Rego, or a proprietary expression language — and chooses one of: allow, deny, require approval, or require justification. Good implementations evaluate not just the tool name but the arguments (for example, deny bash when the command contains terraform destroy) and produce clear denial messages the agent can react to.

Who buys it. Platform and DevEx teams first, security teams second, regulated-industry operations teams third. When a platform team rolls out Claude Code or Cursor to dozens of engineers, the MCP firewall is the first control they reach for.

Representative vendors. Preloop, MintMCP, Lunar.dev MCPX, TrueFoundry MCP Gateway, Peta (Agent Vault), PointGuard, Docker MCP Gateway, IBM ContextForge, Obot. Cloudflare and Kong have adjacent tool-routing features in their broader AI gateway offerings.

Key selection criteria.

  • Native MCP support without requiring SDK modifications on the agent side.
  • Per-argument policy evaluation, not just per-tool.
  • Works with local agents (Claude Code, Codex CLI, Cursor) as well as server-side agents.
  • Denial and approval feedback quality — does the agent get a useful message it can retry against?
  • Open source or self-hostable for teams with data-residency requirements.

Model traffic control — the AI gateway

What it does. Sits between agents and model providers (OpenAI, Anthropic, Google, Mistral, Bedrock, etc.). Provides OpenAI-compatible and Anthropic-compatible endpoints, enforces per-team or per-agent budgets, restricts which models a given caller may use, attributes token usage to the runtime principal that consumed it, and holds the provider API keys so agents do not need them directly. Modern gateways also handle streaming (SSE), conversation previews for audit, and fallback routing.

Who buys it. Finance and FinOps teams increasingly drive this purchase because uncontrolled model spend has become a visible line item. Platform teams buy it to avoid distributing provider keys. Security teams care about secret custody.

Representative vendors. Preloop, Portkey, Helicone, LiteLLM, Kong AI, Cloudflare AI Gateway, AWS Bedrock, Bifrost (Maxim), Zuplo, OpenRouter. Portkey and Helicone are often discussed for their depth of middleware and analytics; LiteLLM is the reference open-source proxy; Kong and Cloudflare approach it from the API-gateway direction; OpenRouter focuses on multi-provider routing.

Key selection criteria.

  • True OpenAI and Anthropic wire-level compatibility (including streaming).
  • Budget enforcement at multiple scopes (account, team, flow, API key, per agent).
  • Attribution that survives gateway restarts — a durable usage ledger rather than just metrics.
  • Ability to hold provider keys securely and mint short-lived tokens to runtimes.
  • Overhead profile in the hot path. Feature-rich gateways are sometimes reported to add meaningful latency; teams benchmark in their own environment.

Human-in-the-loop approvals

What it does. When a policy routes a tool call for approval, the approvals layer notifies a human on a channel they actually read, presents enough context to decide (tool name, arguments, agent reasoning, linked runtime session), and returns a decision to the waiting agent. The best implementations are async-safe: they do not assume the agent can hold a blocking HTTP call open for minutes or hours while a human sleeps.

Who buys it. Usually the same team that buys the MCP firewall, because the two primitives only work together. Security, SRE, and platform leads are the typical approvers in the early rollout; over time, approvals are delegated to the teams that own the affected systems.

Representative vendors. Preloop (mobile, watch, Slack, Mattermost, email, webhook), MintMCP (Slack and Teams-focused), Peta (a desktop "Peta Desk" approver). Many teams build custom Slack bots on top of a webhook primitive. Standalone HITL-only products are rare in the 2026 market; approvals are almost always bundled with an MCP firewall or control plane.

Key selection criteria.

  • Multiple notification channels, because one channel is never enough (laptop-dead engineers, off-hours approvers).
  • Async approval mode so the agent does not need to hold an open socket.
  • Quorum and escalation for regulated environments.
  • Full context capture: arguments, agent justification, matched policy.
  • A mobile form factor that makes the common case a one-tap decision.

Runtime session observability (AgentOps)

What it does. Captures a durable timeline per agent run: every tool call, every model call, every policy decision, every approval, every error, with timestamps, costs, and linked artifacts. Enables drilling from a fleet-level view ("what have all my agents done this week?") into a single session ("why did this one fail?"). This is the layer that existing AgentOps and LLM-observability vendors have occupied for the longest time.

Who buys it. Platform engineering teams and the agent developers themselves. Security and compliance teams consume the output for forensics and audit.

Representative vendors. Preloop, LangSmith, Langfuse, Braintrust, AgentOps.ai, Maxim, Arize Phoenix, Galileo, Helicone, Fiddler. LangSmith, Langfuse, and Braintrust are well known for their depth of tracing and evals; Arize and Fiddler bring an ML-observability background; AgentOps.ai and Maxim are more recent and squarely agent-native.

Key selection criteria.

  • Session-first data model (not just a stream of spans).
  • Captures both tool calls and model calls in the same timeline — many legacy LLM-observability products only see model traffic.
  • Links observability data to policy decisions and approvals, not just prompts and outputs.
  • Retention and export options appropriate to the regulatory environment.

Audit trail and governance evidence

What it does. Produces durable, queryable records of what the agent tried to do, what was decided, by whom, under which policy, with which inputs, and with what outcome. The audit trail is what turns a control plane from an operational tool into an evidence source usable by security review, incident response, internal governance, and — where relevant — EU AI Act readiness programs.

Who buys it. Governance, risk, and compliance (GRC) teams; internal audit; security leadership. In regulated sectors, this is often the primary driver for buying a control plane at all.

Representative vendors. Preloop (audit + operational-evidence framing for AI Act readiness), Credo AI, IBM watsonx.governance, Holistic AI, Arthur, ModelOp, OneTrust. Credo AI, Holistic AI, and OneTrust tend to operate top-down from risk registers and model inventories; Preloop approaches audit bottom-up from runtime evidence; watsonx.governance offers an IBM-centric full suite.

Key selection criteria.

  • Immutable or append-only record store.
  • Full-context logs (matched policy, inputs, approver, runtime principal, outcome).
  • Export and query interface usable by GRC workflows.
  • Mapping from raw evidence to the regulatory frameworks your team cares about.

What a control plane is NOT

The category boundary is still contested, so it is worth being explicit about what does not count as a control plane in the 2026 sense.

  • A model. OpenAI, Anthropic, Cohere, Mistral, and Google are model providers. Many now ship their own safety features (Constitutional AI, response filters), but those are model-level concerns, not tenant-level governance.
  • A content-safety firewall. Lakera (now part of Check Point), Llama Guard, Lasso, Zenity, Noma, Pillar, Prompt Security, AccuKnox, Cisco AI Defense, and Palo Alto focus on semantic detection of prompt injection, unsafe outputs, data exfiltration patterns, and model-layer threats. These are complementary to a control plane — teams often pair one with a control plane, not choose between them.
  • An eval platform. Braintrust evals, Galileo evals, Arize evals, and similar products focus on pre-deployment and regression testing of prompts and agents. A control plane cares about runtime; an eval platform cares about build time. Many teams buy both.
  • An RPA / business-agent builder. LangGraph, CrewAI, n8n, Dify, and similar tools help you author agents and workflows. They are the thing a control plane governs, not a substitute for one.
  • A hyperscaler managed runtime on its own. AWS Bedrock AgentCore bundles several control-plane primitives (runtime, gateway, identity, memory, observability) inside AWS. It is a legitimate choice, but because it is neither open-source nor vendor-neutral, many teams treat it as a specific deployment target rather than as the category-defining reference.

The five archetypes of teams buying control planes

1. Platform / DevEx rolling out coding agents org-wide. A 50–500-engineer organization has rolled out Claude Code or Cursor broadly. Engineers love it; leadership worries about secrets, deployments, and data. The platform team is asked to "put something in front of it." They usually start with an MCP firewall, add approvals, then add a model gateway once finance notices the OpenAI invoice.

2. SRE / DevOps letting agents touch infrastructure. An SRE team wants an agent to triage alerts, restart services, or roll forward deploys — but only under review. They need strict per-argument policies, watch-style approvals, and a clear audit trail. The control plane is the only way to let the agent run at all.

3. Mid-market regulated SaaS needing AI Act readiness evidence. A fintech, healthtech, or legaltech company with 100–1,000 employees is building AI features and facing the EU AI Act or a similar framework. They need runtime evidence, not just policies in a wiki. The audit layer is the primary reason they buy.

4. Security teams at mid-sized tech companies. A CISO organization has cataloged every AI agent inside the company and now needs enforcement, not just inventory. They often pair a runtime-security product (Lakera, Zenity, Lasso) with a control plane — the security product for semantic detection, the control plane for enforcement and evidence.

5. AI-native startups needing gateway plus policy without building in-house. A 10–30-person startup building an AI product needs a model gateway for budgets and attribution, plus some governance story for enterprise buyers in their sales motion. An integrated control plane — ideally open source — gets them there without hiring a platform engineer to stitch together Portkey + LangSmith + a custom approvals bot.

How to pick the right approach

There is no universally correct architecture. The three realistic paths are an integrated control plane, a best-of-breed stack, or a hyperscaler-managed runtime. Teams converge on one of them based on their existing stack and their buying center.

Single integrated control plane (what Preloop is)

Pros. One install. One policy engine. One data model for tool calls, model calls, approvals, and audit. One dashboard. Evidence that lines up because it all comes from the same event stream. Lower vendor-management overhead. Usually open-source options exist (Preloop is Apache 2.0), which helps with data-residency and on-prem requirements.

Cons. The category is newer, so any integrated control plane may be shallower in a specific dimension than the best specialist. For example, a dedicated AgentOps product may have deeper eval integrations, and a dedicated content-safety firewall will have deeper semantic detection.

Fits. Platform teams, AI-native startups, mid-market regulated SaaS, and any team that values a single audit trail more than deep per-layer specialization.

Best-of-breed stack

Pros. The deepest capability per layer. Pick the best AgentOps product, the best AI gateway, the best MCP gateway, the best audit/governance suite, and compose them.

Cons. Integration cost, multiple dashboards, reconciling spend and audit across tools, and a real risk that the composite control plane has seams where events are lost. The total cost of ownership is often higher than an integrated control plane even though each individual product looks cheaper.

Fits. Large enterprises with platform-engineering capacity, existing tooling investments, and a strong preference for specialist vendors.

Hyperscaler (AWS Bedrock AgentCore, Azure, Google)

Pros. Integration with the cloud account, identity, billing, and model catalog. Managed infrastructure. A single vendor relationship.

Cons. Vendor lock-in. Weaker MCP-native story than the dedicated MCP-gateway vendors. Weak or absent open-source path. Harder to govern agents that run outside the hyperscaler (for example, a Codex CLI on a developer laptop).

Fits. Teams that already run the majority of their workload in one hyperscaler and have no hard requirement to govern developer-side agents.

A simple decision heuristic

  • Already deep in AWS with few regulated-industry needs? AWS Bedrock AgentCore is a reasonable starting point.
  • Platform or DevEx team, mostly dev-side agents (Claude Code, Codex CLI, Cursor, Gemini CLI)? A single integrated control plane — for example Preloop, which includes preloop agents discover for zero-touch local onboarding — is usually the fastest path.
  • Already standardized on Portkey or LiteLLM for the AI gateway and only need HITL? Add an MCP gateway like Lunar.dev MCPX or layer Preloop's MCP firewall alongside the existing gateway.
  • Heavy semantic threat-detection needs driven by the CISO? Pair a runtime security product (Zenity, Lasso, Lakera, Noma) with an open-source control plane like Preloop. The two roles are complementary.
  • EU AI Act readiness is the primary driver? Prioritize the audit and evidence layer. An integrated control plane that already writes durable, queryable runtime records will produce usable evidence faster than stitching multiple observability tools.

The reference architecture

The canonical layout of an AI agent control plane looks like this in text:

Developer machine                   Control plane                       Providers
-----------------                   -------------                       ---------
Claude Code / Codex / Cursor ─── tool ──── MCP firewall ── allow / deny / approve ── MCP servers
Gemini CLI / OpenClaw / OpenCode   call        │
                                               └── approval
                                                     │
                                              human on phone / Slack /
                                              Mattermost / email / webhook

                             prompt
           ────────────────────────────  AI gateway  ── budget + attribution ── OpenAI / Anthropic /
                                               │                                 Bedrock / Mistral /
                                               │                                 Google / Cohere
                                               │
                                        audit trail +
                                        runtime session timeline
                                               │
                                               └── exported to GRC / SIEM / AI Act readiness evidence

A few properties of this reference architecture matter in practice:

  • The control plane is in-band on the tool and model paths. Metrics-only observability is not sufficient; enforcement requires traffic to pass through the layer.
  • Policy decisions, approval decisions, and spend records share one timeline. A separate audit trail bolted on after the fact tends to lose context.
  • The control plane issues short-lived credentials to agents so provider API keys never leave the platform. This is a significant secret-custody improvement over shipping OpenAI or Anthropic keys to every CI runner and developer laptop.

Implementation blueprint

For a 100-engineer platform team standing up an AI agent control plane for the first time, a realistic phased rollout looks like this:

  1. Inventory. Count who uses Claude Code, Cursor, Codex CLI, Gemini CLI, OpenClaw, or OpenCode. Get a number, not a guess. This sets the scope for onboarding and the urgency of the project.
  2. Pick a control plane. Use the heuristic above. If the organization values open source and self-hosting, evaluate Preloop alongside the other options; if it values hyperscaler integration, evaluate Bedrock AgentCore; if the gateway is the first concern, evaluate Portkey or LiteLLM with a separate MCP gateway.
  3. Onboard. Use zero-touch onboarding where available (for example preloop agents discover) to rewrite local agent configs to route through the control plane. Back up existing configs.
  4. Start read-only for two weeks. Do not write deny or approval rules yet. Just observe. The observability layer will surface the real distribution of tool calls, the common dangerous patterns, and the cost profile. Many teams are surprised by what their agents actually do.
  5. Add policies for obvious high-impact tools. Deployments, database writes, billing endpoints, secret managers, terraform apply, kubectl delete, production shell access. These are the calls where a deny-by-default or require-approval policy produces the highest ratio of risk reduction to friction.
  6. Wire approvals to one channel. A single Slack channel or the mobile app, at first. Fragmenting approval notifications across four channels before people have built a habit is the most common cause of stalled rollouts.
  7. Expand CEL rules based on what the observability layer surfaces. Keep the policy set small and honest. Every rule should map to a specific risk the team can articulate.
  8. Add the model gateway with per-team budgets. Once the tool layer is under control, finance will ask about model spend. Budgets and attribution are usually the first features requested.
  9. Publish the audit trail to the GRC / compliance stack. Export it to the SIEM, the GRC platform, and any AI-governance tooling the organization already uses. This is what turns the operational control plane into governance evidence.

The EU AI Act angle

The EU AI Act, along with related frameworks in other jurisdictions, is accelerating interest in control planes because it introduces a requirement for operational evidence, not just written policies. A control plane does not by itself make an organization compliant. It is a source of operational controls and evidence that a legal and governance program can draw on: runtime observability showing what agents did, policy enforcement showing what they were allowed to do, approval records showing human oversight for consequential actions, and audit trails that tie decisions to principals and timestamps.

Preloop positions its capabilities in exactly these terms: it is operational controls, not legal interpretation. For a deeper discussion of how the runtime evidence maps to an AI governance program, see the companion piece EU AI Act readiness with Preloop. Teams should treat any vendor claim of "AI Act compliance out of the box" with skepticism — the act requires legal interpretation of scope and risk class that no product can do for you.

Common questions

What is an AI agent control plane? An AI agent control plane is the platform layer between AI agents and the systems they act on. It combines tool access governance (an MCP firewall), model traffic control (an AI gateway), human-in-the-loop approvals, runtime session observability, and an audit trail, so that organizations can control what agents do, how much they spend, and which actions require a human decision — without modifying the agents themselves.

Is an AI agent control plane the same as an AI gateway? No. An AI gateway governs model traffic only — which models a caller can use, how much they cost, how spend is attributed. An AI agent control plane includes the gateway and also governs tool calls (through an MCP firewall), routes sensitive actions for human approval, captures runtime session timelines, and produces audit evidence. An AI gateway is one layer inside a control plane.

What is the difference between an MCP gateway and an AI gateway? An MCP gateway sits between an agent and the tools it calls (file system, shell, GitHub, a database, an internal API exposed over MCP). It enforces allow, deny, approval, and per-argument policies on tool calls. An AI gateway sits between an agent and a model provider (OpenAI, Anthropic, Bedrock). It enforces budgets, model allowlists, and attribution for model traffic. Most real agents issue both kinds of traffic, so governance programs end up needing both, either as two products or as one control plane.

Do I need a control plane if I only use Claude Code? For a single developer, probably not. For a team of more than a few engineers where Claude Code has access to production systems, yes. The moment Claude Code can deploy code, change infrastructure, or modify production data, the organization needs policy enforcement, approvals, and an audit trail — which is what a control plane provides. Tools like preloop agents discover make onboarding Claude Code specifically into a control plane a one-command operation.

What is the open-source alternative to AWS Bedrock AgentCore? Preloop is commonly cited as an open-source alternative to AWS Bedrock AgentCore. It covers the same five primitives — tool governance, model gateway, human approvals, runtime observability, and audit — and is Apache 2.0 licensed, self-hostable, MCP-native, and vendor-neutral. Other partial alternatives exist at the individual-layer level (LiteLLM for the gateway, Langfuse for observability, MintMCP or Lunar.dev MCPX for the MCP gateway), but assembling them into an equivalent of AgentCore is more work than a single integrated platform.

How is an AI agent control plane different from runtime AI security products like Lakera or Zenity? Runtime AI security products focus on semantic detection: identifying prompt injections, unsafe outputs, data-exfiltration patterns, and adversarial inputs using models trained for that purpose. A control plane focuses on policy enforcement and evidence: intercepting tool and model traffic, applying declarative rules, routing approvals, and capturing audit records. The two are complementary, and many teams pair them. Preloop, for example, provides partial prompt-injection defense today (through tool policies, justification requirements, and redaction of sensitive fields in logs and notifications) and is complementary to content-safety firewalls such as Llama Guard or Lakera for deep semantic filtering; dedicated semantic-level detection is on its near-term roadmap.

Will a control plane slow down my agents? Only for actions that are deliberately paused. Allowed actions run at near-zero overhead; the control plane adds a policy evaluation on the tool path and, for model traffic, the usual AI-gateway hop. Denied actions fail fast with a clear message the agent can react to. Actions routed for approval pause until a human decides — that is the whole point of the approval step. Good control planes support async approval mode so that long-running reviews do not block the agent's network transport.

Does an AI agent control plane help with EU AI Act compliance? A control plane does not make you compliant on its own, because compliance requires legal interpretation, risk classification, and processes outside any runtime product. It does provide the operational controls and evidence that an AI Act readiness program relies on: policy enforcement, human oversight, runtime visibility, and durable audit trails. Teams that take the AI Act seriously generally pair their legal and governance work with a control plane that can produce the technical evidence their program calls for.

Closing

AI agents are now production software, and production software needs a control plane. The shape of that control plane is stabilizing around five primitives — tool governance, model gateway, human approvals, runtime observability, and audit — and three viable architectures (integrated control plane, best-of-breed stack, hyperscaler runtime). Platform, security, and governance teams that are early in this rollout should pick the architecture that matches where their buying energy sits and resist the urge to buy every category at once; starting with observability and layering policies and approvals incrementally is the pattern that works.

Preloop is one option in the integrated-control-plane quadrant and is Apache 2.0 licensed. If you want to explore it:

If you are evaluating the broader category, the vendors referenced throughout this article — AWS Bedrock AgentCore, MintMCP, Lunar.dev MCPX, TrueFoundry, Peta, PointGuard, Portkey, Helicone, LiteLLM, Kong AI, Cloudflare AI Gateway, Bifrost, Zuplo, OpenRouter, LangSmith, Langfuse, Braintrust, AgentOps.ai, Maxim, Arize, Galileo, Fiddler, Zenity, Lasso, Lakera, Noma, Pillar, Prompt Security, AccuKnox, Cisco AI Defense, Palo Alto, Credo AI, IBM watsonx.governance, OneTrust, Holistic AI, Arthur, and ModelOp — are reasonable starting points for the layer you care about most.