Endpoint, IDE, hook or pull request: where to enforce agent policy

Four places to enforce

The developer endpoint. A control installed on the machine where agents run can see several agents at once. Legit Security's VibeGuard 2.0 discovers coding agents on the endpoint, monitors and enforces commands by custom or built-in policy, secures MCP use and adds anti-tampering, so a developer cannot simply switch it off. The trade-off is that it is another agent on the developer's machine to deploy and manage.

The IDE. A plugin or guardrail in the editor sees prompts, file context and tool calls as they happen. Cycode's IDE guardrails intercept secrets, file context, prompts and tool calls before they reach AI services. The IDE point is close to the developer's work, but it covers only agents that run inside a supported editor.

Hooks inside one agent. Some agents expose hooks. Claude Code documents a PreToolUse hook that can block a tool call before it runs, and managed policy settings that an organization can enforce. Semgrep Guardian uses hooks on every file write in Claude Code, Cursor and Windsurf. A hook is precise, but it covers one agent at a time, and each agent's hook model is different.

The pull request. Everything that reaches the repository passes here, whatever wrote it. GitHub's Copilot coding agent runs CodeQL, the Advisory Database and secret scanning on its own changes. The pull request cannot see commands the agent ran or packages it installed on the way.

Before or after the code exists?

There is also a fifth option that acts before code is written. OX Security's VibeSec analyzes the developer's prompt and sends security guidance to the agent before it generates code. Guidance changes what the agent writes; it does not block what it does, so it pairs well with an enforcement point.

How to choose

Ask three questions:

1. How many different agents do your developers run? Several agents favor the endpoint; one standard agent makes hooks practical.
2. Can a developer turn the control off? Ask each vendor what happens when they do.
3. What must be blocked, and what only logged? Commands and installs need blocking before they run. Style and quality issues can wait for the pull request.

A common pattern is endpoint or IDE enforcement for actions, plus pull request scanning for code.

What to test before you commit

In a trial, run the same risky action through each enforcement point you are considering: an install of a package that is not on your approved list, a call to an MCP server nobody approved, and a prompt that contains a test secret. Record which point caught each one, how the developer was told, and whether the action could be repeated after a restart. The results show the real coverage better than a feature list. The next track turns to the agents inside AppSec platforms.