The 1,000+ permutations of agent governance

We keep a spreadsheet at Speakeasy. Each row is an agent surface a company might need to govern, each column is a governance primitive the vendor exposes to an administrator, and each cell holds the per-license status. It is now 34 rows, 8 columns, and 3 tiers. To spare readers the math, that's 816 unique governance capabilities that we're tracking, and the list is only growing as the number of AI products teams are using explodes. It will be over a thousand capabilities before the end of the year.

This is the reality of governing agents in 2026: an ever-growing number of AI products with limited standardization when it comes to security server integration. Here is the matrix as it stands today. It shows what each vendor documents as possible on each surface and tier.

What makes AI agents hard to govern?

A chat assistant takes a prompt and returns text, and the whole exchange passes through one HTTP call that a company can route through a proxy, log, and inspect. An agent takes a goal and then acts on it in a loop. Given "fix the failing test," a coding agent reads the repository, runs the test suite, edits three files, runs the tests again, opens a pull request through an MCP server, and posts a summary. Each of those steps is an action with side effects, and the model call that decided on the step is the only part of it that leaves the machine.

The rest happens in the agent's own execution environment. The shell command runs on the employee's laptop. The file edit lands on a local disk. The MCP tool call goes from the agent process to whichever server the developer configured, whether the security team knows about that server or not. In a cloud session, the same actions run inside a sandbox the vendor operates. In every case, a network proxy or an LLM gateway sees the prompt and the completion and misses the command, the file, and the tool.

The consequences show up in three places:

• Data leaves through tool output. A cat .env or a database query returns secrets and records into the agent's context, and from there into the next model call. Nothing on the network path saw the read happen.
• Actions are irreversible. A destructive shell command, a force push, or a write to a production system completes before any log line about it exists.
• Tools multiply without approval. Every MCP server a developer adds is a new integration with its own credentials, and none of them registered anywhere a security team looks by default.

Only two places can see those actions in time to do anything about them. One is inside the agent, through the settings, hooks, and telemetry the agent itself exposes. The other is at the vendor, through the admin console, compliance exports, and inference-time checks the vendor runs on its own infrastructure. Agent governance is the work of using whichever of those a given product offers, and the offering differs by product, surface, and plan.

Three things then multiply the work:

• Surfaces. One product ships as several. Claude Code is a CLI, a desktop app, a VS Code extension, a web app, and cloud sessions, and each one runs in a different place with different integration points.
• License tiers. The same surface exposes different controls on Personal, Team, and Enterprise plans. Personal accounts on work laptops are a common form of shadow AI, and they sit in the tier an admin console reaches least.
• Primitives. A governance program needs eight things from a surface: a way to push managed settings, an MCP allowlist, lifecycle hooks, telemetry export, usage reporting, a compliance export, plugin distribution, and a hook before inference. Each surface exposes a different subset, and some expose almost none.

Every square in the matrix is one combination of the three, and each one needs an answer that is still true after the next vendor release.

How did agent governance start?

Anthropic was the first vendor to give security teams a supported integration point inside the agent. Claude Code hooks arrived in June 2025 as user-defined handlers that fire at fixed points in the agent lifecycle: when a session starts, when a user submits a prompt, before a tool runs, and after it returns. Each handler receives structured JSON about the event, and a PreToolUse handler can allow, deny, or modify the action before it executes.

Agent hooks (as they generally became known) changed what governance could see. The command an agent was about to run, the file it was about to edit, and the MCP tool it was about to call all became events a company could log and act on, with no proxy or certificate involved.

Speakeasy built on that interface. We shipped our first hooks integration in March 2026 to capture tool calls, and full Claude Code session capture followed a month later. Sessions landed in the AI control plane, where the same events drive policy checks and the audit trail.

How is agent hooks support going across vendors?

Hooks spread across the major agent vendors within about a year. Cursor added them in version 1.7 on September 29, 2025, and Gemini CLI added them in v0.26.0 on January 28, 2026. Codex, GitHub Copilot, and OpenCode now expose the same kind of interception point.

The idea spread faster than any agreement on the details. The table below shows how each agent exposes the hook that fires before a tool call, and a limit each vendor documents.

Sources: Claude Code hooks, Cursor hooks, Codex hooks, GitHub Copilot hooks configuration, VS Code hooks, Gemini CLI hooks, and OpenCode plugins.

Hook support is uneven in three ways

The differences fall into three groups:

• Vocabulary. Event names, casing, input schemas, and decision formats differ by vendor, so a rule written for one agent has to be rewritten for the next.
• Coverage. Support varies by surface within a single product. A hook that fires in a CLI may not fire in the IDE extension, web app, or cloud agent from the same vendor.
• Enforcement. Vendors differ on what happens when a hook fails and on which tools a hook can see. The Codex documentation is direct about it: "Treat tool hooks as a useful guardrail, not a complete enforcement boundary."

The contracts also keep moving. The comparison table in our agent hooks guide, published in May 2026, listed six Codex hook events. The Codex documentation lists 12 today.

Each agent was a separate integration

Our own release history follows the same path. After Claude Code, Speakeasy added hooks support for Cursor in April 2026 and Codex in May, replaced the per-agent senders with a single hooks binary in July, and added OpenCode and GitHub Copilot in August. We continue to scale out supported agents every week.

Where is agent governance going? Inference hooks and hook standards

Two developments could shrink the matrix. One is already in beta, and the other doesn't exist yet.

Inference hooks move enforcement to the vendor

Anthropic announced Inference hooks on August 5, 2026, in beta for Claude Enterprise. A Claude Enterprise organization names one AI security server, and Anthropic holds each prompt and tool response until that server returns an allow or deny verdict.

For the products it covers, this model takes the surface out of the equation. There is nothing to install on a device, and one configuration applies to every covered surface, including web and mobile apps where no device hook can run. Speakeasy integrated with Inference hooks in September as the security server for Claude Enterprise organizations.

Inference hooks have limits today:

• Coverage is Claude Enterprise only, so Personal and Team accounts are outside it.
• The protocol returns a verdict and has no path for rewriting a prompt.
• Anthropic is the only vendor we track that offers them so far.

If other vendors adopt the same model, agent governance gets simpler for every surface a vendor hosts. Until then, Inference hooks are one more integration method to maintain, for one vendor.

A unified hooks standard would fix the vocabulary

The vendors have started to converge without a specification. VS Code and Codex use the Claude Code event names, GitHub Copilot accepts both casings, and Cursor can load hooks written for Claude Code. A formal standard for hook events and decision formats would finish that work. MCP set the precedent for tool connections, and it now has a neutral home at the Agentic AI Foundation.

No hooks standard exists today. A standard would also leave two problems in place, because it can't decide which license tier a vendor puts a control behind or which surfaces a vendor chooses to instrument.

Should you build or buy agent governance?

We strongly recommend buying. Building works for one kind of company: a team that has standardized on a single agent, on a single enterprise tier, can govern it with managed settings, a few hook scripts, and an OpenTelemetry collector.

Every additional agent adds rows to the matrix, and having coding agents write the integrations doesn't remove them. An agent can write a hook handler for a new vendor in minutes. Keeping that handler compatible is the expensive part, and it is a pain even with agents doing the typing:

• Noticing changes. Vendors rename events, add surfaces, and move controls between tiers on their own release schedules, and nothing notifies the team that depends on them.
• Testing every cell. Verifying a change means running it on each surface under each license tier, which requires accounts and devices for all of them.
• Catching silent failures. Most hooks fail open, so a broken integration stops producing data without raising an error, and a dashboard with a gap in it looks the same as a quiet week.
• Reaching every laptop. A handler only governs the machines it is installed on, so distribution and drift become a second project.

This is the work the Speakeasy AI control plane takes on. The device agent installs managed configuration for each supported agent and re-applies it every 60 seconds, so it survives tool updates and account switches. Hook events from every agent land in one Agent Sessions view, and the same risk policies apply to all of them. The company owns the policy, and Speakeasy owns translating it into the mechanism each vendor provides and keeping that translation current.

Is our support perfect? No, but we add capabilities daily and our team are experts at adding new agents to the support matrix.

If you're deciding how to govern more than one agent, get in touch and we'll walk through the matrix for the agents your teams run.