September 2026 Summaries

AI agent governance is becoming increasingly complex as organizations adopt many products, interfaces, and license tiers with inconsistent administrative controls, prompting Speakeasy to track 816 documented combinations across 34 agent surfaces, eight governance functions, and three tiers. Unlike conventional chat assistants, agents can execute local commands, edit files, use MCP-connected tools, and access sensitive data outside the visibility of network proxies, making governance dependent on controls embedded in agents or provided through vendor platforms. The article identifies managed settings, MCP allowlists, lifecycle hooks, telemetry and compliance exports, plugin distribution, usage reporting, and inference-time controls as key governance capabilities, but notes that their availability differs substantially by vendor, product surface, and subscription plan. Hooks introduced by Claude Code and subsequently adopted in varying forms by Cursor, Codex, GitHub Copilot, Gemini CLI, VS Code, and OpenCode can intercept or record tool actions, though event formats, coverage, and failure behavior remain incompatible and change frequently. Anthropic’s beta Inference Hooks offer a vendor-hosted alternative for Claude Enterprise by allowing an external security server to approve or deny prompts and tool responses, while a future common hook standard could reduce technical fragmentation. Speakeasy argues that organizations using multiple agents may benefit from managed governance services because maintaining integrations requires continuous monitoring, testing, deployment, and adaptation to vendor changes.

Model Context Protocol gateways can serve as centralized control points between AI agents and the tools and data they access, addressing risks created when agents combine private-data access, exposure to untrusted content, and external communication capabilities. The post argues that gateways can enforce directory-backed, per-server and per-tool role-based access; inspect tool requests and responses for sensitive information through data loss prevention controls; and scan tool descriptions and outputs for prompt-injection or tool-poisoning attempts before models consume them. It emphasizes starting DLP and injection detection in log-only mode to reduce false positives before applying warnings, denials, or session quarantines, while pairing detection with least-privilege access to limit potential damage. However, gateways cannot control direct APIs, local tools, shell commands, unproxied model calls, or the agent’s internal reasoning loop, and therefore must be part of a broader security architecture and treated as highly sensitive infrastructure. The overview also describes offerings from Speakeasy, Microsoft, IBM, and other vendors, recommending that organizations first route sanctioned servers through a gateway with read-only defaults, then progressively tune monitoring and enforcement.

MCP gateways are presented as a centralized infrastructure layer for AI enablement teams connecting employees’ agents to third-party and internal data across multiple clients and servers. They reduce repetitive authentication by integrating with a company identity provider, managing upstream OAuth tokens or shared API credentials, and potentially extending Enterprise Managed Auth to systems that do not natively support it. Gateways can also provide curated, role-based catalogs of approved servers and tools, simplifying onboarding, revoking access automatically, and limiting permissions to read-only or tool-level access where appropriate. To address context-window costs from large tool catalogs, gateways can use dynamic tool discovery or code mode, although both approaches introduce trade-offs involving latency, reliability, auditability, and sandboxing. The post distinguishes enablement from related security and governance functions while noting that all rely on shared identity and inventory data, and it surveys Speakeasy’s offering alongside Microsoft, IBM, and other gateway products. It recommends beginning with a small set of commonly requested servers, identity-provider sign-in, directory-based roles, and measurement of tool-definition token costs before expanding deployment.

MCP gateways can support AI agent governance by acting as a control point for sanctioned tool calls, enabling organizations to link agent activity to individual users, enforce role-based permissions per call, and create centralized audit records of which clients, servers, tools, data, and policies were involved. Unlike identity-provider, downstream application, or AI-vendor logs, gateway records can connect a specific user to an agent’s tool use, helping answer compliance questions about access to sensitive systems and data. Effective implementations should integrate roles with identity providers through SCIM, log policy and configuration changes as well as runtime calls, export telemetry to existing SIEM or GRC systems, and carefully manage the privacy, retention, and access risks of storing tool inputs and outputs. Gateways can also reduce shadow MCP usage through curated server catalogs and access-request workflows, but they cannot observe agents or servers that bypass them, requiring complementary discovery controls such as endpoint agents, coding-agent hooks, or MDM configurations. They are therefore a useful runtime control rather than a complete compliance solution, which still requires broader policies, risk assessments, identity management, inventory, and organizational oversight.

Model Context Protocol gateways enable AI agents to access tools while governing authentication, identity, authorization, auditing, distribution, and private-network connectivity. The comparison evaluates 11 products across enablement features such as session management, connectors, client distribution, and internal-network access, and governance features including directory-linked identity, client admission, granular tool permissions, shadow-server discovery, and SIEM-ready audit exports. It groups offerings into dedicated governance platforms such as Speakeasy, Runlayer, MintMCP, and Willow; API or model-routing extensions from Kong, TrueFoundry, LiteLLM, and Bifrost; and infrastructure-oriented options including AWS AgentCore Gateway, Microsoft MCP Gateway, and Docker MCP Gateway. The analysis argues that existing Kong or AWS users may start with their bundled tools for limited deployments, while Docker and Microsoft suit narrow proof-of-concepts, and dedicated governance products become more relevant when organizations need identity-based controls, endpoint visibility, shadow MCP detection, or broad audit coverage. Key trade-offs include whether principals resolve directly to enterprise directories or platform-specific accounts and keys, whether deployments can be self-hosted or air-gapped, and whether products govern only traffic passing through the gateway or can detect agent activity elsewhere. It recommends proof-of-concepts test offboarding, approved-client enforcement, least-privilege permissions, session expiration, unmanaged server detection, and departmental attribution before wider deployment.

Speakeasy has introduced support for Client ID Metadata Documents (CIMD) to let MCP clients identify themselves through verifiable URL-based metadata rather than Dynamic Client Registration (DCR), which relies on self-asserted client names and redirect URIs, creates separate registrations per installation, and offers no reliable client allowlisting. Under CIMD, a client vendor publishes metadata at an HTTPS URL it controls, which Speakeasy’s AI Control Plane fetches and validates before authenticating users through an identity provider and allowing MCP tool calls. Organizations can use an open policy that accepts valid CIMD URLs or a presets mode that permits only exact URLs from Speakeasy’s vendor catalog or administrator-defined custom entries, with policy controls applied separately to each MCP server issuer and recorded in audit logs. CIMD, adopted by MCP and now preferred over DCR in the specification, improves client admission control but does not verify the local client binary or replace user authentication. DCR remains supported for older clients without a planned retirement date, while the release currently focuses on public clients and leaves confidential-client support as future work.

MITRE ATLAS is a monthly updated, ATT&CK-style knowledge base for threats against AI systems that, in version 2026.09, includes 16 tactics, 120 techniques, 88 sub-techniques, 40 mitigations, and 73 case studies. Originally focused on machine-learning risks such as adversarial examples, training-data poisoning, model inversion, and model extraction, it now places substantial emphasis on agentic AI, with 139 of 208 technique entries tagged for agents and 57 of those classified as realized in real incidents. The article distinguishes ATLAS from MITRE ATT&CK by explaining that ATLAS addresses attacks that exploit AI systems through prompts, data, tools, and model interfaces rather than conventional compromises of hosts or networks, while the two frameworks can describe different stages of the same intrusion. It highlights prompt injection, context and retrieval poisoning, malicious agent tools and supply-chain rug pulls, and inference-based data or model theft as key enterprise concerns, using reported cases involving a compromised MCP email tool and misuse of a coding agent. ATLAS is presented as a threat-modeling and detection reference rather than a compliance framework or complete defensive architecture, with the article arguing that practical controls should focus on agent-to-tool boundaries through permission scoping, tool validation, curated registries, credential management, human approvals, monitoring, and audit logging.

Speakeasy’s comparison presents Rippling AI Governance and the Speakeasy AI Control Plane as products with overlapping MCP gateway and agent-identity capabilities but different governance scopes and identity foundations. Rippling centers controls on its employee graph, using dynamic Supergroups, default-deny tool assignments, immediate offboarding revocation, and its first-party Code Mode MCP server to securely govern AI access to workforce data, while offering live agent identity management and spend analysis tied to productivity signals. Speakeasy centers on corporate directories such as Okta and Microsoft Entra, combining gateway-level access control and traffic inspection with endpoint hooks that monitor and enforce policies on prompts, shell commands, file edits, and local tool calls within coding-agent sessions. The comparison argues that Rippling is most suitable for organizations already using its HR and IT platform and seeking tightly integrated controls for AI interactions with Rippling data, whereas Speakeasy is aimed at company-wide runtime governance across internal APIs, third-party MCP servers, and developer tools, including SIEM exports, session monitoring, sensitive-data detection, and budget enforcement. It notes that several Rippling features, including its AI Gateway and Shadow AI Detection, were waitlisted as of September 2026, while also acknowledging Rippling’s broader certifications, sandboxed Code Mode execution, structural exclusion of sensitive workforce fields, and possible complementary use of both products.

Dynamic Client Registration (DCR) and Client ID Metadata Documents (CIMD) both enable previously unknown MCP OAuth clients to connect to authorization servers, but they differ fundamentally in how client identity is established. DCR, an established RFC, lets clients submit self-declared metadata to receive a new, server-specific client ID per installation, creating persistent registration records but offering no durable identity for allowlisting, auditing, or revocation. CIMD instead uses an HTTPS URL on the client vendor’s domain as the client ID, allowing servers to retrieve vendor-controlled metadata such as the client name and authorized redirect URIs; this produces a stable, portable identifier that organizations can govern across installations and authorization servers. Current MCP guidance recommends CIMD as the preferred approach while retaining DCR for backward compatibility, with pre-registration remaining appropriate where client and server already have an established relationship. CIMD does not authenticate the local software process or prevent loopback redirect impersonation, and it introduces requirements to securely fetch remote metadata, including SSRF protections, caching, and URL validation. The article argues that organizations needing client allowlists, auditability, and revocation should implement CIMD first while maintaining DCR until existing client demand declines, and notes that Speakeasy’s authorization platform supports both mechanisms with configurable client-admission policies.

Speakeasy has introduced an MCP kill switch in its AI Control Plane that allows organization administrators to temporarily block an individual’s MCP tool calls to selected or all MCP servers without disabling their account, ending sessions, or changing standing server permissions. Administrators can activate blocks immediately or schedule them, define fixed or open-ended durations, include a public explanation shown to the user, and manage the feature through an identity Access tab or management API, with changes recorded in version history and audit logs. The gateway enforces the switch before calls reach Speakeasy-hosted, private remote, or tunneled servers and fails closed if it cannot verify the switch’s status, while users remain authenticated and can still view available tools. The feature is intended for cases such as investigating a potentially compromised device or pausing a contractor’s access to a specific server, and it differs from session revocation, account disabling, session quarantine, and controls over prompts, model inference, or endpoint agent hooks.

Speakeasy’s AI Control Plane has introduced streaming data feeds that consolidate telemetry from multiple AI clients into standardized OpenTelemetry records and export them via OTLP/HTTP to existing observability tools such as Langfuse, Grafana Cloud, Datadog, or an OpenTelemetry Collector. The feeds cover agent sessions, MCP gateway traffic that providers may not expose, and correlated risk findings, using shared organization and project attributes to simplify tracking across vendors with differing schemas and identities. Administrators configure one destination and project-specific routes through the dashboard, while sensitive prompts, model content, tool payloads, and user identifiers are redacted by default unless explicitly enabled; risk findings never include matched content and are re-evaluated before delivery to avoid sending out-of-scope data. The release focuses on live streaming rather than archival exports, although batch delivery to S3-compatible storage, additional destination types such as warehouses and SIEMs, and analysis guidance are planned, with collectors currently serving as the supported intermediary for unsupported endpoints.

Speakeasy and Google have partnered to open source Speakeasy’s API client-generation tooling after Google needed to replace a vendor whose shutdown threatened its SDK pipeline for the Interactions, Agents, and Webhooks APIs. The collaboration migrated Google’s SDK generation to Speakeasy while preserving language-specific types, error handling, streaming behavior, and internal build-system integration, and it expanded into tools intended to improve both developer experience and AI agent experience. Released under the AGPL-3.0 license, the suite includes SDK generators for TypeScript, Python, Go, Java, C#, PHP, and Ruby; generators for CLIs and Model Context Protocol servers; and a hosted documentation MCP server that lets agents search current markdown-based API documentation and encourages use of official SDKs. Speakeasy positions the release as a way to ensure long-term availability of essential API tooling while supporting its broader goal of building an enterprise AI control plane for governed, secure, observable agent access to real systems.

Claude Cowork, launched in 2026 as an agentic work assistant for nontechnical business functions, can access local files, enterprise connectors, plugins, browsers, cloud sessions, and scheduled tasks to execute multistep work across Claude applications. The article argues that these capabilities create governance risks including prompt injection in untrusted documents, excessive read and write permissions, unattended automation, unapproved custom MCP connectors, and limited audit visibility. Anthropic provides Team and Enterprise controls such as role-based access, connector and plugin management, approval settings, OpenTelemetry exports, and, for Enterprise, compliance transcripts and Inference hooks that can submit prompts to external security services for allow-or-deny decisions. It presents Speakeasy as a complementary security layer: Inference hooks inspect prompts, attachments, and tool responses for sensitive data and malicious instructions, while an MCP gateway evaluates tool calls before execution, restricts tools by role, logs activity, and identifies unmanaged “shadow MCP” servers. The recommended rollout begins with visibility, role and connector configuration, telemetry and shadow-mode monitoring, followed by policy tuning and eventual enforcement once approved services and false-positive rates are understood.

Speakeasy has introduced an ungated beta integration with Anthropic Inference Hooks that provides Claude Enterprise organizations with pre-inference security controls for Claude Chat, Claude Design, and Claude Code Web. By routing prompts and tool calls through Speakeasy’s AI Control Plane, the service applies existing risk policies, personally identifiable information and prompt-injection classifiers, and allow-or-deny decisions before requests reach Claude’s models, while recording sessions for later compliance review. The company positions the feature as an inline alternative or complement to conventional DLP tools, emphasizing unified policy enforcement and auditable conversation records across supported Claude surfaces. Setup requires connecting a Speakeasy webhook in Claude’s organization settings, exchanging a signing secret, and enabling enforced verdicts with a blocking failure posture. Current limitations include no prompt rewriting, no inspection or blocking of assistant or tool responses, no inspection of image-only attachments, and no coverage for personal or Max plans, Bedrock, Vertex, the Claude API, voice, endpoint shadow-AI discovery, or MCP distribution.

Speakeasy describes an enterprise identity and access-control model for deploying Claude Tag and other AI agents across tools such as Slack, Linear, Jira, and GitHub without relying on shared service accounts. Its approach creates a dedicated agent principal with a human owner, separate permissions, independently revocable credentials, and audit records that distinguish the agent as actor, the requesting user as operator, and the credential approver as authorizer. Each tool call is authorized using the intersection of the agent’s policy, the operator’s current permissions, and the credential’s approved ceiling, preventing users from gaining authority through the agent while allowing organization-wide deployment with user-specific access. For autonomous agents running in CI systems, Kubernetes, or cloud environments, workload identity federation exchanges short-lived platform-issued tokens for agent-bound access tokens instead of storing long-lived secrets. These checks, audit trails, DLP scanning, and policy enforcement are centralized in an MCP gateway, which also integrates with identity providers such as Okta or Entra while keeping agents distinct from human directory accounts.

MintMCP is presented as a managed enterprise Model Context Protocol gateway that provides SSO-based connector access, a self-service MCP store, and laptop-level monitoring for supported coding agents, but organizations may seek alternatives for stronger directory-native identity, declarative and testable security policies, self-hosting, broader agent coverage, longer logging, ISO 27001 certification, or integrated LLM traffic management. The comparison, published by Speakeasy with an explicit disclosure of its commercial interest, evaluates Speakeasy, Runlayer, Kong, LiteLLM, and Willow across governance, infrastructure, deployment, identity, security, and enablement capabilities. Speakeasy emphasizes an AI control plane with directory-synced identities, policy testing, API-generated MCP servers, and SOC 2 Type 2 and ISO 27001 certifications; Runlayer offers a similar gateway-plus-endpoint model with ML-based threat detection but uses native agent accounts and AWS-only deployment. Kong extends existing API management into LLM and MCP routing, though its MCP features remain in technical preview, while LiteLLM offers an open-source, self-hostable LLM proxy and MCP gateway governed through keys, teams, and organizations rather than directory identities. Willow most closely mirrors MintMCP’s marketplace and endpoint-monitoring approach while offering SaaS, self-hosted, and air-gapped deployments, though it also maintains its own user-token model.

Bifrost is an Apache 2.0-licensed, Go-based AI gateway from Maxim AI that routes requests across more than 20 model providers through an OpenAI-compatible API, offering fallbacks, load balancing, semantic caching, and an integrated MCP gateway, while reserving features such as SSO, SCIM, RBAC, audit logs, and guardrails for its Enterprise tier. Organizations may consider alternatives when they need directory-based identity rather than virtual keys, managed deployment, a more mature gateway ecosystem, or controls that extend into agent sessions and devices. The comparison identifies Speakeasy as a governance-oriented AI control plane for directory-resolved identities, policy enforcement, and API-generated MCP servers, though it lacks LLM routing; LiteLLM as an established open-source proxy supporting over 100 providers; Kong as an AI and MCP extension for existing API-management users; TrueFoundry as a commercial gateway for routing more than 250 LLMs with governance and self-hosting options; and MintMCP as a managed, compliance-focused MCP service with hosted connectors and agent monitoring. The appropriate choice depends on whether a team primarily needs model routing, MCP governance, managed operations, or a combination of these capabilities.

Kong’s MCP Gateway, available through its Enterprise AI Gateway, converts REST APIs into MCP tools using an OpenAPI-based configuration process and applies Kong’s existing authentication, rate-limiting, logging, and access-control plugins to MCP traffic. The comparison argues that organizations may consider alternatives when they need directory-based person or agent identities, AI-specific guardrails and threat detection, session or endpoint monitoring, less dependence on a full API management platform, or self-hosted model-and-tool routing. It categorizes five alternatives by architecture: Speakeasy as a hybrid AI control plane that generates and governs MCP servers with identity-provider integration and agent/device controls; MintMCP as a managed governance gateway with hosted connectors and laptop monitoring; Runlayer as a security-focused platform providing tool and session analysis plus MDM integration; LiteLLM as an open-source, self-hosted LLM proxy with MCP support, virtual-key controls, and multi-provider routing; and Bifrost as a Go-based, self-hosted AI gateway combining LLM routing and MCP access with a focus on low latency. The appropriate option depends on whether a team prioritizes gateway infrastructure, dedicated governance, security monitoring, generated and hosted servers, or integrated LLM traffic management, while the publisher discloses that it develops Speakeasy.

Speakeasy’s comparison presents Bifrost as an open-source, self-hosted AI gateway focused on routing requests across more than 20 model providers with failover, load balancing, semantic caching, virtual-key-based access controls, and an integrated MCP gateway, while Speakeasy positions itself as a hosted AI control plane centered on enterprise identity and runtime governance of agent behavior. Both products can govern MCP tool traffic, apply guardrails, audit activity, and enforce budgets, but Bifrost primarily controls traffic routed through its gateway and supports inference-level cost management, whereas Speakeasy uses managed hooks in coding agents to inspect and potentially block prompts, shell commands, file edits, local tool calls, and other actions that may bypass a gateway. Bifrost is presented as the stronger choice for organizations needing high-performance multi-provider model routing, open-source deployment, self-hosting, air-gapped environments, and external classifier integrations, while Speakeasy is framed as better suited to teams requiring directory-principal authorization on each tool call, governance across complete agent sessions, API-to-MCP server generation, and per-person spend controls. The post acknowledges its vendor perspective, notes that Bifrost’s performance figures are vendor claims, and concludes that the products can potentially operate together because Bifrost governs model-provider traffic while Speakeasy governs agent actions and tool access.

Runlayer is presented as a security-focused Model Context Protocol gateway that authenticates, authorizes, scans, and logs AI agent tool calls through single-tenant AWS deployments, supplemented by endpoint and browser controls. The vendor-authored comparison identifies four common reasons organizations may evaluate alternatives: stronger or more customizable security controls, architectures beyond AWS and closed-source deployment, integrated LLM gateway capabilities, and protocol-level governance that does not depend on specific agent frameworks or client hooks. It compares Speakeasy, MintMCP, Kong, LiteLLM, and Willow across governance, infrastructure, identity, endpoint coverage, deployment options, and model-routing features. Speakeasy is positioned as a hybrid AI control plane with directory-based identity and API-generated MCP servers; MintMCP as a similar managed governance service; Kong as an extension of existing API management; LiteLLM as an open-source LLM proxy with MCP access controls; and Willow as a governance platform emphasizing endpoint sensors, browser policies, and multi-cloud deployment. The recommended choice depends on whether an organization prioritizes security governance, existing gateway infrastructure, open-source self-hosting, endpoint visibility, or integrated management of both model and MCP traffic.

Speakeasy has introduced end-to-end Microsoft integrations that connect Entra ID identity management, Intune device deployment, and Microsoft Graph inventory data to its AI governance platform. Users authenticate through Entra ID via SAML or OIDC, with MFA, conditional access, SCIM directory synchronization, role mapping, and deprovisioning linking AI-agent sessions and tool actions to individual directory identities. Its Device Agent can be deployed through Intune on Windows and macOS, where it applies and continually restores managed configurations for AI tools such as Claude Code, Codex, and Cursor, while using system-level protections and signed update mechanisms. A Graph-based inventory integration compares Intune-managed devices with agent heartbeats to identify active, stale, missing, or unattributable agent coverage, and can export device-level compliance evidence to platforms including Drata and Vanta. Available through the Microsoft commercial marketplace, the integration is intended to let Microsoft-centered organizations govern AI usage through their existing identity, endpoint-management, and offboarding processes.

Cisco began rolling out MyAgent, a supervised AI agent for 90,000 employees, in August 2026 after developing Circuit, a secure internal AI platform designed to govern access to models, enterprise data, tools, and audit records. Circuit, which Cisco says reached 90% employee adoption after several years of development, provides the controls that allow MyAgent to work across systems such as Outlook, Webex, Jira, and SharePoint while keeping employees responsible for approving and overseeing actions. The account argues that Cisco built the platform to offer a safer alternative to unsanctioned consumer AI use and describes similar in-house governance efforts at Uber and JPMorgan as evidence that large-scale enterprise AI deployment requires centralized identity, policy, access, and monitoring systems. It contrasts Cisco’s multi-year, resource-intensive approach with Speakeasy’s commercial AI control plane, which it says can provide comparable governance capabilities—such as MCP tool gateways, identity integration, policy enforcement, threat detection, and audit logging—within weeks rather than years.

Speakeasy has introduced private network ingress for its MCP gateway through Tailscale tailnets, allowing organizations to host MCP endpoints at stable private hostnames without exposing them to the public internet. Private-only servers return 403 responses to public requests, fail closed during outages or misconfigurations, and use Tailscale identities such as users, devices, and tags in audit logs alongside tool calls. Access is governed through existing tailnet ACLs rather than separate IP allowlists, eliminating the need for fixed egress IP addresses and supporting IPv6. The integration uses Tailscale’s Kubernetes operator to provision isolated, highly available per-organization services, while an attestor verifies workloads, forwards approved MCP and OAuth paths, and attaches request identity metadata. Organizations can configure individual servers as public-only, dual-access for migration, or private-only, with setup involving a scoped Tailscale OAuth client, ACL configuration, and server exposure settings. The feature is rolling out per organization, with other overlay-network integrations planned.

Speakeasy’s Gateway endpoints consolidate multiple Model Context Protocol (MCP) servers behind one URL, reducing client configuration overhead and preventing agents from loading every server’s full tool catalog into the context window before work begins. Instead, agents receive four gateway tools that let them list accessible servers, inspect a selected server’s tool descriptions, retrieve schemas only for tools they intend to use, and execute those tools through the member server’s existing path. This staged discovery model aims to reduce context use, simplify tool selection, and avoid validation failures caused by guessing tool arguments. Member servers retain their own authentication, permissions, audit logs, and execution behavior, meaning users connected to the same endpoint may see different available servers based on access rights. Gateway endpoints support Speakeasy-hosted, third-party, and privately tunneled MCP servers, require user sign-in by default, and can be created through the dashboard by naming an endpoint, adding and ordering members, and connecting clients to the resulting URL.

Speakeasy’s comparison of its AI Control Plane with Willow, formerly Webrix, argues that both platforms provide MCP gateways for authenticating sessions, applying access controls, scanning routed requests and responses, and maintaining audit logs, but differ substantially in coverage beyond the gateway. Willow is presented as an MCP-focused enablement platform with a large connector marketplace, endpoint sensors, a Chrome browser policy extension, an organization-wide kill switch, and SaaS, self-hosted, on-premises, and air-gapped deployment options; it uses Willow-issued credentials and group-based permissions. Speakeasy describes its main distinction as managed agent hooks for coding tools such as Claude Code, Cursor, Codex, and OpenCode, which can inspect and block prompts, shell commands, file edits, and directly configured or local MCP tools that do not pass through a gateway, while tying authorization to enterprise identity providers such as Okta and Microsoft Entra ID. The post positions Willow as better suited to rapid connector-based enablement, browser governance, endpoint inventory, and isolated deployments, while positioning Speakeasy as stronger for session-wide enforcement, directory-native identity, policy replay and custom rules, API-derived MCP servers, and per-user AI spending controls.

Agent observability in 2026 is presented as two distinct functions: engineering telemetry for debugging and improving agent behavior, and security audit for recording identity-bound tool access and policy decisions. LangSmith, Datadog, Arize AX/Phoenix, and Fiddler AI primarily provide trace-based observability, including model and tool-call traces, evaluations, quality metrics, and framework or OpenTelemetry integrations, with differing strengths in LangChain support, APM correlation, open-source deployment, and model-risk management. The post argues that these application-emitted traces cannot substitute for audit evidence because they may omit uninstrumented or malicious activity and rely on application-supplied identity metadata. It positions Speakeasy, the author’s product, as an MCP gateway-based audit layer that logs tool calls on the access path, associates them with identity-provider-verified users or services, enforces policies, and exports records to security systems, while acknowledging it does not provide tracing or evaluation capabilities. The recommended approach is to select a tracing platform for agent quality and debugging needs, an access-path audit platform for compliance and governance needs, or both for production deployments, while treating OpenTelemetry as useful for telemetry but insufficient for security auditing.