deny vs instruct for ai coding agent policies

A Decision Table

How Each One Reaches the Agent

In enforce mode, a deny blocks the call on events and harnesses that support blocking, and the agent receives the reason. An instruct lets the action continue and delivers the reason as guidance where the harness supports it. On Hermes, for example, the call runs and the guidance is placed at the start of its result. Failproof’s own docs say it plainly: do not use instruct() for a safety boundary. The pack’s warn-* policies, such as warn-destructive-sql and warn-global-package-install, are ready-made instructs.

import { customPolicies, allow, instruct } from "failproofai";

customPolicies.add({
  name: "right-size-instances",
  description: "Steer agents away from very large instance types",
  match: { events: ["PreToolUse"] },
  fn: async (ctx) => {
    if (ctx.toolName !== "Bash") return allow();
    const cmd = String(ctx.toolInput?.command ?? "");
    if (!/run-instances|instance_type|instance-type/.test(cmd)) return allow();
    // Largest GPU and memory sizes only: p5, p5e, p5en, p4d, p4de, big x2iedn, u-*tb.
    if (/\b(p5\w*\.48xlarge|p4de?\.24xlarge|x2iedn\.(16|24|32)xlarge|u\d*-\d+tb\d*\.\w+)\b/.test(cmd)) {
      return instruct("That instance type costs hundreds to thousands of dollars a day on demand. Use m7i.large for dev work unless the engineer asked for this size.");
    }
    return allow();
  },
});

Test Cases

Make It Robust with a Decision-Model Check

Sizing is a judgment the instance list can only approximate: it knows a few AWS types and nothing about the task. An instruct-mode check asks the decision model whether the request is clearly larger than the task needs, and only ever warns.

We write custom checks like this one for your own rules: talk to us and tell us what should never happen on your machines. Jev comes with Failproof; turn it on whenever you choose, with failproofai jev setup or a Cloud machine key that carries jev:evaluate.

import { semanticPolicies } from "failproofai";

semanticPolicies.add({
  name: "oversized-compute",
  title: "Requested far more compute than the task needs",
  appliesTo: ["shell", "write"],
  mode: "instruct",           // only ever warns: a nudge, not a block
  userCanOverride: true,
  probes: [
    {
      id: "provisions_compute",
      instructions: "Does this call create or resize cloud compute, such as instances, node groups, clusters or GPU jobs, directly or in infrastructure code?",
    },
    {
      id: "larger_than_needed",
      instructions: "Is the requested size clearly larger than what the user's request needs?",
    },
  ],
  guidance: "This looks larger than the task needs. Use the smallest size that works, such as m7i.large for dev work, unless the engineer asked for this size.",
});

• A Terraform file the agent writes with instance_type = "p5.48xlarge".
• gcloud compute instances create --machine-type a3-highgpu-8g, and other clouds the AWS-only list does not cover.
• A large size the engineer actually asked for: the check is user-overridable, so the request clears the warning.

Specific Guidance Beats Generic Caution

In Failproof’s FIRE study, interrupting an agent at the right moment with a generic “reconsider” or “verify your work” barely moved results. The targeted instruction did. Write instruct text the way you would brief a colleague: the one fact they are missing. More results in do guardrails slow agents down.

Write the Reason for the Agent That Must Recover

• Say what was detected: “This changes Route 53 records.”
• Say what to do instead: “Put the change in the dns/ module and open a PR.”
• Avoid vague refusals. “Not allowed” makes a capable agent try another route, which is exactly the bypass behavior you do not want.
• Keep it short. The reason lands in the agent’s context on every match.

Ambiguous Cases Are Where Decision Models Help Most

Over-provisioning, “is this the production database” and “did the user actually ask for this” are judgments, not string matches. The semantic checks in the FailproofAI/jev-policies pack come in two modes that mirror this split. Deny-mode checks such as production-infra-change and destructive-deletion can block on strong evidence and warn on moderate evidence. Instruct-mode checks such as system-modification and read-outside-workspace never deny on their own, but when one fires and the user did not ask for the call, the deny it reviews stands.

Observe Is a Third Option During Rollout

Before enforcing either decision, deploy the policy in observe mode, as a Cloud deployment or a pack published with --effect observe. It evaluates and records what it would have done without affecting the agent. Reading a week of those records is how you find denies that should have been instructs, and instructs that should have been denies.