Policy Engine

The Policy Engine is the brain of EnforceCore. It evaluates every tool call against a set of declarative rules to decide whether to allow, deny, or modify the execution.

Policy Structure

Policies are defined in YAML files. This separation of code (agent logic) and policy (security rules) allows security teams to update rules without changing application code.

A minimal policy looks like this:

version: "1.0"
mode: "strict"  # or "monitor"

rules:
  - name: "allow-safe-tools"
    action: "allow"
    resource: "tool"
    pattern: "search_web|calculator"

  - name: "deny-dangerous-tools"
    action: "deny"
    resource: "tool"
    pattern: "execute_shell|delete_file"

on_violation: block

Rule Components

Each rule consists of four key parts:

1. Name: A descriptive identifier for logs (e.g., allow-s3-read).
2. Action: What to do if the rule matches (allow or deny).
3. Resource: The type of resource being accessed (tool, filesystem, network, api).
4. Pattern: A regex or glob pattern matching the resource target.

Example: Filesystem Access

Control which files an agent can read or write.

rules:
  - name: "allow-data-read"
    action: "allow"
    resource: "filesystem"
    pattern: "read:./data/*.csv"
    
  - name: "deny-root-access"
    action: "deny"
    resource: "filesystem"
    pattern: "*:/etc/*"

Advanced Configuration

PII Redaction

The Policy Engine integrates with the Redactor to sanitize data before it leaves the secure boundary.

pii_redaction:
  enabled: true
  categories:
    - email
    - credit_card
    - ssn
    - phone
  strategy: placeholder  # Replaces with [EMAIL], [PHONE], etc.

Resource Limits

Prevent denial-of-service (DoS) and cost overruns by enforcing limits per execution.

limits:
  max_duration_seconds: 30
  max_memory_mb: 512
  max_cost_usd: 0.05

Inheritance

Policies can extend other policies, allowing you to build a hierarchy of rules (e.g., a global organization policy extended by a project-specific policy).

extends: "./global-policy.yaml"

rules:
  - name: "project-specific-override"
    action: "allow"
    resource: "tool"
    pattern: "internal_api_tool"

Best Practices

1. Start with monitor mode: Run your agent in production with mode: monitor to gather logs without breaking functionality.
2. Use specific patterns: Avoid wildcards like * unless absolutely necessary.
3. Layer your policies: Keep common rules (like PII redaction) in a base policy and extend it for specific agents.
4. Audit regularly: Use the Auditor to review policy decisions and tune your rules.