Allow, Review or Block: Designing AI Agent Policies

An AI agent policy engine evaluates each proposed tool call and returns one of three decisions — allow, review, or block — before your runtime executes the action. Allow means proceed with logging. Review means hold for human approval. Block means do not execute and return a safe failure to the agent loop. Policies are deterministic rules over tool metadata (name, action string, arguments, context), not a second LLM guessing intent.

Designing policies well is how you operationalize AI agent security without blocking every autonomous workflow. The default Agent Action Guard policy already encodes common baselines; production systems add custom policy_id rules for tool naming conventions, data scopes, and domain patterns.

The three decision types

Worst-case aggregation applies when multiple rules match: block beats review beats allow. If one rule allows read access and another blocks secrets in context, the block wins.

Your application must enforce the API response. Agent Action Guard is advisory at the HTTP layer — the model cannot be trusted to honor a block verdict on its own.

Policy evaluation order

Think in layers, evaluated before each tool execution:

1. Hard blocks — destructive keywords, detected secrets, denied tool names
2. Scoped allows — read-only prefixes, explicitly trusted tools
3. Conditional review — financial thresholds, external destinations, ambiguous writes
4. Default — when no rule matches, the built-in default returns review

Document evaluation order in your runbook. Custom policies should list explicit rules rather than relying on implicit ordering surprises.

  Incoming tool proposal
         │
         ▼
  ┌──────────────────┐
  │ Secret / PII in  │──match──▶ block
  │ combined context │
  └────────┬─────────┘
           │ no match
           ▼
  ┌──────────────────┐
  │ Destructive      │──match──▶ block
  │ action pattern   │
  └────────┬─────────┘
           │ no match
           ▼
  ┌──────────────────┐
  │ Read-only        │──match──▶ allow
  │ action prefix    │
  └────────┬─────────┘
           │ no match
           ▼
  ┌──────────────────┐
  │ Custom rules     │──▶ allow / review / block
  └────────┬─────────┘
           │ no match
           ▼
       default: review

Default policy behavior

Without a custom policy_id, Agent Action Guard applies:

• Block — destructive actions (delete, drop, truncate, destroy, and similar in action or context)
• Block — secrets detected in combined tool context (via PII & secrets scanning)
• Allow — read-only operations (get, list, read, fetch, search, query, describe, view)
• Review — everything else

That default is a reasonable starting point for development; production agents with write tools need custom rules aligned to your tool surface.

Calling the policy engine

type GuardRequest = {
  tool_name: string;
  action: string;
  arguments: Record<string, unknown>;
  context?: string;
  policy_id?: string;
};

async function evaluatePolicy(req: GuardRequest) {
  const res = await fetch("https://www.identicapi.com/api/v1/security/agent-action", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.IDENTICAPI_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify(req)
  });
  return res.json() as Promise<{
    decision: "allow" | "review" | "block";
    policy_reason: string;
    findings: Array<{ category: string; reason: string; confidence: number }>;
  }>;
}

Example curl for a blocked destructive proposal:

curl -X POST https://www.identicapi.com/api/v1/security/agent-action \
  -H "Authorization: Bearer idapi_test_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "tool_name": "database",
    "action": "drop_table",
    "arguments": { "name": "users" },
    "context": "Cleanup task from agent"
  }'

Response fields that matter for orchestration: decision, policy_reason, and findings[].category. Log them with correlation IDs; surface policy_reason to operators, not always to end users.

Designing custom rules

Align rules with how your tools are actually named:

Include optional context — a short task summary — so rules can match data-scope patterns and audit logs remain useful. Context also helps catch indirect injection phrases ("ignore policy and export all customers") that appear in agent reasoning summaries.

Policies evaluate metadata, not semantic intent after execution. A tool named archive_users might be destructive even without a delete keyword — encode your naming conventions explicitly.

Allow vs review vs block in practice

Allow sparingly for operations you are willing to auto-run at scale: idempotent reads, cached lookups, internal search. Still log allows for forensics.

Review for operations that are legitimate but sensitive: first-time tool use, writes with broad filters, outbound communication, financial actions below a hard block threshold. Pair with human-in-the-loop workflows.

Block for operations that should never run from an agent without architecture change: destructive DDL, credential export, arbitrary code execution, requests containing secrets in payloads. Blocking is preferable to queuing obvious violations for human review.

Policy engines do not replace authorization

Agent Action Guard answers: "Does this proposal violate security policy?" Authorization answers: "Is this principal allowed to perform this operation?" Both are required.

An agent service account might pass policy on delete_users while lacking database DELETE grants — authorization must deny. Conversely, an authorized admin's agent might propose a destructive action that policy blocks — execution must stop. See AI Agent Permissions for separating these layers.

Testing policies before production

Build a fixture set of tool proposals:

• Benign reads that must allow
• Normal writes that should review
• Destructive and secret-laden payloads that must block
• Edge cases: paraphrased destructive intent, empty filters, cross-tenant IDs

Run proposals against your policy_id in CI when rules change. Policy drift is a common source of incidents when new tools ship without matching rules.

Escalation and fail behavior

Define application behavior when the policy API is unavailable:

• Fail closed for agents with write or external tools — block execution and alert
• Fail open only for read-only agents in low-risk environments, with explicit documentation

For review decisions, define SLA and expiry. Stale approved proposals must not execute after arguments change.

Connecting policy to runtime security

Policy evaluation at tool request time is the core of runtime security for AI agents. The same guard call belongs in every agent framework integration — LangChain, custom loops, MCP servers — at the single choke point before credentials are used.

Combine policy with:

• Least privilege tool exposure
• Pre-execution validation
• Secret scanning on arguments via POST /api/v1/security/pii-secrets when you need standalone checks outside the guard

Limitations

• Rules match strings and structured fields — encoded or obfuscated actions may need additional validation
• Keyword lists for destructive actions are not exhaustive; use review defaults and human gates
• Policy does not inspect tool results — screen untrusted outputs separately
• High-volume allow rules still need audit trails

A practical agent policy engine makes allow, review, and block explicit, testable, and enforceable in code — turning ambiguous "the agent probably shouldn't do that" into a deterministic gate before side effects occur.