Skip to main content
Note: This is a user-friendly guide to writing AIP policies. For the formal specification, see AIP v1alpha1.
Complete reference for AIP policy YAML files (agent.yaml).

Table of Contents

Overview

AIP policies are declarative YAML files that define what tools an agent can use and under what conditions. The policy is loaded at proxy startup and evaluated for every tools/call request. Design principle: Default deny. If a tool is not explicitly allowed, it’s blocked.

Schema

Metadata

Example:

Spec Fields

mode

Controls whether policy violations are enforced or just logged.
Use case for monitor mode: Test new policies in production before enforcement.

allowed_tools

Allowlist of tool names that the agent can invoke. Tool names must exactly match what the MCP server reports.
Important: If a tool is not in this list AND not in tool_rules with action: allow, it will be blocked.

Tool Rules

Fine-grained control over individual tools. Each rule can specify an action and argument validation.

Structure

Actions

Block Action

Explicitly deny a tool:

Ask Action (Human-in-the-Loop)

Require user approval for sensitive operations:
When triggered:
  1. Native OS dialog appears: “Allow tool ‘run_training’?”
  2. User clicks “Allow” or “Deny”
  3. If no response in 60 seconds: auto-deny

Argument Validation

Use allow_args to validate tool arguments with regex patterns:
Rules:
  • Regex must match the entire argument value (implicit ^...$)
  • If any allow_args pattern fails, the request is blocked
  • Arguments not in allow_args are not validated

Rate Limiting

Limit how often a tool can be called:
Format: <count>/<period> where period is second, minute, or hour. When rate limit is exceeded:
  • Request is blocked with JSON-RPC error code -32003
  • Audit log records RATE_LIMITED event

Identity Configuration (v1alpha2)

Configure agent identity and session management.

Fields

Session Binding Modes

Server Configuration (v1alpha2)

Configure the built-in HTTP server for remote validation.

Fields

DLP Configuration

Data Loss Prevention scans tool responses for sensitive patterns and redacts matches.

Structure

Built-in Pattern Library

Redaction Output

Matched content is replaced with: [REDACTED:<RuleName>]

Examples

Read-Only Policy

GPU/ML Policy

Prompt Injection Defense

Monitor Mode (Testing)

Validation

Policy File Validation

AIP validates policies at startup. Common errors:

Common Error Codes

Testing Policies

  1. Dry run with monitor mode:
  2. Check audit logs:
  3. Verbose logging:

Best Practices

  1. Start restrictive: Begin with minimal allowed_tools, expand as needed
  2. Use monitor mode first: Test policies before enforcement
  3. Review audit logs: Regularly check for unexpected tool usage
  4. Version your policies: Use semantic versioning in metadata
  5. Document decisions: Add comments explaining why tools are blocked
  6. Separate policies per agent type: Different agents need different permissions