Best AI Security markBest AI Security

NOTE · 9 SEPTEMBER 2026

Allow, ask or deny: how to write a policy for AI agent actions

The verdict

Write the policy around actions, not tools: shell commands, package installs, cloud CLIs, file and credential access, MCP server use and outbound network calls. Allow low-risk actions, ask the user before sensitive ones, and deny the few that should never run. Test every rule in a monitoring or simulation mode first, and make sure the record shows whether a person or an agent took each action.

A policy for AI agents is a list of actions and answers. Getting the middle answer, "ask", right is what lets a company approve agents widely.

By Best AI Security editors · 9 September 2026 · 5 min read

Why write policy around actions rather than tools?

Approving or banning a tool is too coarse. The same coding agent that edits a README can also run a shell command against production. The OWASP GenAI Security Project's 2026 Top 10 for LLM Applications, announced on 1 September 2026, ranks Excessive Agency third. Bay's research write-up on indirect prompt injection puts the underlying problem as "broad tools, broad credentials, weak approval", and calls the attack "an authorization problem disguised as a prompt problem." Both point to the same fix: limit what an agent may do at the moment it tries to do it.

The MCP specification says the same for tools: there should always be a human in the loop with the ability to deny tool invocations, and clients should prompt for confirmation on sensitive operations.

Which action categories should the policy cover?

Bay's public material lists the capability areas its rules address, which make a useful starting outline for any policy: shell execution, code execution, process spawning, package installation, cloud CLIs, containers, Kubernetes, browser automation and system changes. Add two more that apply to every tool on this site:

  • MCP server use: which servers an agent may load, and which tools on them it may call.
  • Data movement: reading credential files, sending data to outside destinations, and writing to shared systems.

What should each answer mean?

  • Allow: runs without interruption and is logged. Use it for read-only work inside the project, such as reading source files and running tests.
  • Ask: pauses and asks the user to confirm, with the exact command or tool input shown. Use it for actions that are usually legitimate but costly when wrong: installing a package, running a cloud CLI against a production profile, or calling an MCP tool that writes to a shared system.
  • Deny: blocked, with a message that says why. Keep this list short: reading SSH keys or cloud credential files outside an approved flow, loading an MCP server that is not on the approved list, disabling the policy itself.

Vendors name their answers differently. Bay returns Allow, Ask or Deny. Onyx Security lists "alert, block, mask, steer, or ask". Harmonic Security uses block, warn and log. Lasso Security uses block, alert or sanitize. Zenity says it can block or modify a dangerous tool call before it executes. When comparing products, map each vendor's actions onto these three answers and note which ones add masking or modification.

What context should a decision use?

A rule that looks only at the command will either block too much or too little. The tools on this site describe using more context. Bay says its decisions weigh identity, prior actions and data accessed. Noma Security describes runtime inspection of the event, the session, the identity behind the agent and the data it reaches. Useful context for a rule:

  • Who started the agent, and on which device.
  • Whether a human prompted this action or the agent chose it after reading outside content, such as a web page, an issue or an email.
  • What the agent did earlier in the session.
  • Which data or credentials the action touches.

How do you test rules before enforcing them?

  1. Run every new rule in monitoring or simulation mode first. Bay documents a Simulation Mode for this; ask other vendors whether they offer the same (question 11 in our buyer's checklist).
  2. Review what the rule would have asked or denied for a week of real work with a pilot team.
  3. Move rules to "ask" before "deny". If users approve an "ask" almost every time, it may belong in "allow".
  4. Publish an exception path: who a developer contacts when a rule blocks legitimate work, and who approves the change.

Where should the policy be enforced?

Close to the action. For coding agents, several vendors enforce inside the agent through its lifecycle hooks or managed settings: Bay describes managed settings for Claude Code, Codex and Claude Desktop that lock permission rules, preserve managed hooks and restrict MCP servers; Lasso Security connects to Claude Code's lifecycle hooks. Gateways enforce on traffic routed through them. EDR stays in place for malware and intrusion; an agent policy layer works alongside it and decides whether a trusted agent's action should run. Our guide to AI agent security and EDR covers that split.

What should the log show?

Every allowed, asked and denied action should be recorded with the user, the agent, the device and the outcome, and the record should separate what a person did from what an agent did on their behalf. The MCP specification asks clients to log tool usage for audit purposes. Send the record to your SIEM so agent activity sits next to the rest of your security data.

Related

Sources