Writing policy for coding agents: allow, steer or block

Three tiers

Allow. Actions that need no check: reading project files, running the test suite, formatting code.

Steer. Actions that are fine with guidance: writing new code that touches authentication, adding a dependency from an approved registry. Steering can mean instructions given to the agent before it writes, or a warning it must acknowledge.

Block. Actions that must not happen without a person: running install scripts from new packages, calling an unapproved MCP server, sending a file that holds secrets to a model, disabling the security control itself.

Snyk describes the same three verbs for Evo Agentic Development Security: it can evaluate, steer or block risky agent activity. Legit Security's VibeGuard 2.0 enforces commands by custom or built-in policy, and VibeGuard offers approve or block decisions for discovered assistants, models and MCP servers. Endor Labs' AURI applies policy at the moment of action.

What to write rules about

• Agents and models. Which coding agents and models are approved.
• MCP servers and skills. Which servers and skills an agent may call. Cycode's AI-BOM tracks MCP servers and rule files; an inventory like this is the starting point for an allow list.
• Commands. Shell commands that need approval, such as package installs and network tools.
• Packages. Registries, install scripts and new versions. npm v12 will not run dependency install scripts unless they are approved, which gives you a natural rule to mirror for agents.
• Secrets. What may never appear in a prompt or tool call.

Instruction files are guidance, not enforcement

Each agent has its own instruction file. GitHub Copilot reads .github/copilot-instructions.md; Cursor reads project rules in .cursor/rules. These steer the agent, but an agent can ignore them. Enforcement needs a control the agent cannot override, such as a Claude Code PreToolUse hook set through managed policy, or an endpoint control.

Exceptions and ownership

Every block rule needs a way to ask for an exception, a named owner who can grant it, and an expiry. Without that, developers route around the control. Log every block and every exception; the logs are your evidence that the policy works.

Start small

Begin with three block rules: unapproved MCP servers, install scripts from new packages, and secrets in prompts. Add steering rules once the blocks are stable.

Keep policy in version control

Store the rules where code lives, review changes to them through pull requests, and record who approved each change. Policy that sits only in a vendor console is hard to audit and easy to change by accident. When a rule changes, tell developers what changed and why, in the same channel you use for other platform changes. The next lesson covers how to roll the policy out.