Why capabilities first
Prompt filters try to guess intent from text. Capability rules look at what the agent is about to do, which is easier to reason about and harder to talk around. An instruction hidden in a web page can change what an agent wants; it cannot change the fact that the next step is a command that reads a key file.
Vendors describe capability rules at different levels of detail. Bay lists rules for shell execution, code execution, process spawning, package installation, cloud CLIs, containers, Kubernetes, browser automation and system changes. Bloom Security describes defining what agents can access, execute and transmit, and enforcing policies on packages across npm, the Chrome Web Store and Open VSX. Harmonic Security describes permissions for which systems agents can read, write to and act on. Lasso Security describes controlling which users and teams can connect to which MCP servers. Noma Security keeps a registry of allowed agents, MCP servers and skills.
A first set of rules
The verdicts below are a starting point; adjust them to your teams.
- Shell commands that delete, overwrite or change permissions outside the project folder. Ask a person. The user usually knows whether it was intended.
- Reading credential files and tokens (cloud credentials, SSH keys, browser cookie stores). Block by default, with a named exception list.
- Package installs from public registries. Allow from approved registries; ask or block for packages published in the last few days or from unknown sources.
- Cloud CLI commands that change infrastructure (create, delete, apply). Ask a person, and log the full command and account.
- Connections to MCP servers. Allow only servers on an approved list; block the rest and send the request to the security team.
- Browser automation on internal applications. Warn first, then decide per application.
- Changes to the agent's own settings (permission rules, hooks, plugin sources). Lock them through managed settings where the agent supports it. Bay describes this for Claude Code, Codex and Claude Desktop.
Write rules per agent, not per product
The same rule may need different wiring on different agents, because each exposes different hooks and settings. Keep one written policy and map it to each agent you support. When a new agent arrives, the policy is already written; only the mapping is new.
Start in simulation
Every rule above will catch legitimate work on its first day. Run new rules in a mode that records would-be decisions before enforcing them, review a week of results with the teams affected, then switch on enforcement. Bay describes a Simulation Mode for this; with other products, ask how to run a rule without enforcing it. The next lesson describes the full staged rollout.