Speakeasy vs Fiddler AI: Which control plane decides what agents can do?
Nolan Sullivan
A support agent sends a refund request with no personal data and no secrets in it. Should it go through? Content safety does not answer the permission question. Speakeasy checks the agent's tool access and its human owner's current permissions, then records a denial against the agent if either check fails. Fiddler adds content guardrails and tracing to an existing gateway; authorization stays with that gateway or the application. An AgentGateway deployment can deny the refund too, but the team maintains that access policy separately from Fiddler.
Choose Speakeasy when access to tools should follow your identity provider, for people and for the agents they own. Below, we compare the two on tool delivery, access control, and runtime protection.
MoonPay runs Speakeasy in production across more than 200 MCP servers and 60,000 agent sessions. A 30-day proof of concept led to a company-wide rollout, with Okta-backed permissions by team, server, and tool, and unsanctioned MCP servers blocked by default. Read the MoonPay case study.
Speakeasy vs Fiddler AI comparison
Five tests for an enterprise AI control plane
Enterprise readiness and track record
Speakeasy's gateway runs in production at companies with large, security-sensitive MCP estates. MoonPay's security operations team describes the change directly:
"Employees were connecting MCP servers we had no inventory of. Now every server runs behind the gateway, scoped by team and role, and anything unsanctioned is blocked by default."
Thierry Dang, Security Operations, MoonPay
Google, Fivetran, PlanetScale, LaunchDarkly, and Polar run MCP servers built on Speakeasy:
- Google moved the Gemini API SDKs to Speakeasy after its previous generation vendor was acquired and shut down, then built the Gemini Docs MCP server with Speakeasy on the same foundation. Google chose Speakeasy for continuity, on the commitment that Speakeasy would open source its generators so the tooling behind Gemini's SDKs and MCP server could not disappear again. The Docs MCP server gives coding agents current Gemini API documentation instead of stale training data, and ships pre-bundled in Antigravity.
- Fivetran exposed its Connector SDK and platform APIs as a hosted MCP server without spending weeks on infrastructure, an OAuth server, and client compatibility testing. Fivetran's Eli Davis calls Speakeasy's AI control plane "indispensable in enabling Fivetran's AI transformation."
- PlanetScale grew usage of its MCP server 44 times over in five months.
- LaunchDarkly built an MCP server that lets agents create feature flags, configure targeting rules, and manage rollouts.
- Polar moved from a local MCP server to a hosted one that turns a plain-language pricing description into a working billing setup.
Support is measured against service-level commitments rather than best effort. Speakeasy has met every response-time commitment across its support tiers, and 90% of support requests are answered in under 24 minutes.
Why choose Speakeasy as your AI control plane over Fiddler AI?
Deliver approved tools by role
A rollout needs GitHub, Notion, and an internal customer API in Claude Code, Cursor, and a backend agent. Each team should get only the servers it needs. Speakeasy puts those servers behind one MCP gateway endpoint with one sign-in and delivers them to people's AI clients as plugins assigned to directory groups. Fiddler adds tracing and guardrails to the gateway you already run, so getting tools to each team stays your job.
Employees also connect MCP servers on their own. Speakeasy's shadow MCP inventory finds them, and an access review shows each one's users and declared tools before you approve it for the people and roles that need it. Fiddler's Claude Code integration traces the MCP tool calls in each session.
The review adds authentication and requested scopes, domain and registry history, published advisories, and a frozen evidence snapshot for each decision. Approved servers are rechecked daily for permission-relevant changes, with new tools or broader scopes sent back for review. Blocked employees can request a scoped exception from the tool output or a device-agent notification. This makes a trace of a new server the start of an access decision, not just another event to inspect.
Role-based delivery requires configured marketplaces and clients, or enrolled devices using the device agent. Plugin assignments gate managed device delivery, not marketplace installation; server permissions still control the calls. Fiddler supplies tracing and guardrail integrations while the existing gateway and client-management system handle those connection and distribution decisions.
Bound agents by their owner's permissions
When an engineer loses access to a tool, the agents they own should lose it too. Every Speakeasy agent request has to pass both the agent's own permissions and its owner's current permissions. Removing a permission from the owner takes effect on the agent's next request. Fiddler's RBAC covers access to Fiddler itself: its projects, applications, and the MCP server that acts with each user's own permissions.
The gateway around Fiddler can impose its own tool restrictions. AgentGateway, for example, supports policies combining a verified JWT subject with a tool name. Speakeasy brings the directory grant, the agent's owner, and the gateway check into one permission model. Where Authorization Challenges are enabled, an administrator opens a denied call, sees the missing permission, and grants it to a role. A payload scanner and a separate gateway policy do not provide that owner-bound access-resolution workflow by themselves.
Upstream credentials follow the same boundary: when a gateway combines several servers, Speakeasy records which member each OAuth grant belongs to and never forwards a token issued for one member to another. Fiddler's LLM Gateway stores provider API keys for AI features such as custom evaluators inside Fiddler.
Enforce policies specific to your business
Security teams need rules for risks that no detector catalog covers, such as a delete against production or an exfiltration attempt through curl. In Speakeasy, they write each rule as a plain-language guardrail, replay it on recent sessions, and mark each verdict right or wrong before it enforces anything. Fiddler's guardrails check for safety, faithfulness, PII, and secrets.
When a session policy fires, Speakeasy can quarantine the session, holding further prompts and tool calls until an administrator releases it. The block reason shows in Tool Logs. MCP-scoped policies instead log or deny the individual request or result; they do not quarantine a session. Fiddler's inline adapters block or redact the inspected request or response, with decision logging dependent on the gateway. AgentGateway guardrail decisions leave no record in Fiddler itself.
Error handling is part of that deployment choice. Fiddler's Kong adapter fails open on detector errors. Speakeasy's MCP-scoped checks also allow calls through on scan timeout or content exceeding the 50 KiB scan limit, while session prompt-based policies separately offer a fail-open or fail-closed choice on judge errors. Speakeasy combines those checks with identity-bound permissions, policy authoring, replay, and session response.
Beyond guardrails: operate an enterprise governance program
Investigate exposure, not only answer quality
Fiddler's agent traces, experiments, evaluators, and model-drift monitoring help application teams understand why an agent produced a poor answer or a workflow failed. Speakeasy's Agent Sessions serve the security and platform team investigating who used which tool, what the surrounding conversation was, and which access or content policy applied.
Watchdog turns repeated findings into ranked signals with affected people and teams. Evidence is redacted until revealed, and every reveal is audited. Transcript access requires a separate permission and opening one is also audit-logged. Investigators can suppress a one-off finding, create an exclusion for recurring noise, or respond to real exposure by restricting a role or blocking a server. That connects the incident evidence to the controls that change the next request.
Logging controls leave session capture and tool-payload storage off until an administrator enables them. Stored tool logs and sessions have 90-day retention. OTLP exports separate product telemetry, risk findings, and gateway tool logs, with sensitive content excluded from new destinations by default. Fiddler helps teams investigate application quality. Speakeasy gives security teams the organizational identity, access decision, and policy response around the incident.
Control changes to the instructions agents follow
Speakeasy's Skills give platform teams a lifecycle for instructions distributed with approved tools. Each content change creates an immutable version. Teams can compare versions, pin a plugin distribution, restore earlier content, and review adoption, sampled efficacy, cost, and agent feedback by version.
If a new instruction causes an agent to choose a destructive tool, the team can identify and roll back the distributed artifact as well as change tool access. Fiddler's experiments and custom evaluators measure agent behavior and answer quality. Speakeasy additionally manages the package of instructions and servers deployed into employees' coding agents, so the team can act on the version that actually reached them.
Join provider evidence with endpoint activity
Speakeasy's AI integrations import Anthropic and OpenAI compliance data and Cursor usage and spend alongside instrumented sessions. Compliance imports support investigation after the event; Anthropic inference hooks and LiteLLM integrations add separate pre-inference policy points. Configured Claude Code web and Cursor Cloud environments can also send session activity through the device agent, using dedicated enrollment identities for shared environments.
This gives security a broader evidence set than the requests passing through one MCP gateway. It also gives platform owners per-person budgets, matched to department, role, or cost center, that can block over-budget coding-agent requests. Budgets are in preview with organization enablement, evaluate spend roughly every 30 seconds, and allow requests if a rule cannot be evaluated. Fiddler's token and spend views help monitor usage; Speakeasy connects that usage to directory identity and an enforceable allowance.
Speakeasy vs Fiddler AI feature comparison
Connect and distribute
| What you need | Speakeasy | Fiddler AI |
|---|---|---|
| Put many MCP servers behind one URL | Gateway endpoints, with one sign-in and on-demand tool discovery | Traces MCP calls that pass through AgentGateway or LiteLLM |
| Reach a private MCP server | An outbound tunnel that forwards signed caller identity | Handled by the gateway and network you already run |
| Build tools for internal APIs | Generate them from OpenAPI, or write TypeScript functions | Traces the agent or application that calls the API |
Access control
| What you need | Speakeasy | Fiddler AI |
|---|---|---|
| Sign in with company SSO | Yes, and directory groups decide tool access | Yes, for access to Fiddler projects and applications |
| Restrict a single tool | Tool-scoped grants and deny rules | Configured in the surrounding gateway, such as AgentGateway's per-tool authorization |
| Limit an agent to its owner's permissions | The agent can never do more than its owner | Fiddler's MCP server acts with the user's Fiddler permissions |
Guardrails
| What you need | Speakeasy | Fiddler AI |
|---|---|---|
| Detect secrets and personal data | Yes, with detectors for financial, government ID, and healthcare data | Yes, PII/PHI and secrets at Kong, LiteLLM, or AgentGateway |
| Write a policy for a business-specific risk | Plain-language guardrails, replayed on past sessions first | Custom LLM-as-judge evaluators for evaluation; inline guardrails cover four categories |
| Contain a risky session | Quarantine: further tool calls are held and security is alerted | Blocks or redacts the single request or response |
Observe
| What you need | Speakeasy | Fiddler AI |
|---|---|---|
| Review a full agent session | Yes, with transcript, tool calls, tokens, and cost | Yes, with traces grouped into sessions |
| Investigate a blocked tool call | Tool Logs show the user, client, and block reason | Depends on the gateway: AgentGateway records no guardrail decision in Fiddler |
| Know a caller's roles at the time of a call | Each tool call records the caller's groups, attributes, and roles at that moment | Sessions carry the attributes your code sets, such as a user ID |
| Break down AI spend by department or cost center | Group costs by department, cost center, or role | Token and spend views by developer, team, or model |
Enterprise deployment and assurance
Speakeasy is SOC 2 Type II audited and ISO 27001 certified. For private systems, internal MCP tunnels create an outbound connection from your network and forward signed caller identity to your server. On the client side, Tailscale private access puts selected MCP endpoints on your tailnet. Setting an endpoint to Private only closes its public route, with no automatic public fallback. New OTLP export destinations exclude sensitive data by default.
When Fiddler AI may fit
Fiddler is a reasonable choice for a narrower set of needs:
- AI application quality: Its experiments test prompt changes against a dataset, its agent traces help debug a failing multi-agent workflow, and its evaluators measure answer faithfulness.
- Model monitoring: It detects ML data drift in production models.
- Guardrails on an existing gateway: It adds PII and secrets checks to Kong, LiteLLM, or AgentGateway without changing application code.
If the priority is delivering approved tools by role, bounding agents by their owners, and enforcing policies specific to your business, the sections above show where Speakeasy is stronger.
Why Speakeasy is the better choice
- Access follows the identity provider you already run. Roles come from directory groups, and agents can never do more than the people who own them.
- Approved tools reach people's AI clients. Put servers in a plugin, assign it to a directory group, and members get them in Claude Code, Cursor, and Codex.
- Unapproved MCP servers go through a review. Each review shows who calls the server and which tools it declares, and an approval can cover specific people or roles.
- Your own rules are tested before they block anything. Write guardrails in plain language and replay them against recent sessions to check each verdict.
- Spend follows the org chart. Per-person budgets, matched by department or cost center, block requests once someone is over budget.
Speakeasy brings tool delivery, owner-bound access, policy testing, incident response, and instruction lifecycle into one control plane. Fiddler adds tracing, evaluation, and content protection to the application and gateway infrastructure your team already operates.
Ask the refund question on your own tools
Book a demo to connect one of your MCP servers, give a test agent the lookup tool but not the refund tool, and see the refund call denied and recorded against the agent.
Book a demo