Content Scan Policies

What it is

content_scan is the fourth Aira policy mode, alongside rules, ai, and consensus. It runs in-process before the action executes and matches the action's details field against curated pattern libraries plus optional org-specific custom regex.

Severity decides the verdict:

The scanner is regex-based and pure-Python. It never calls an external service and never logs the matched secret in plaintext — every hit is redacted to first/last 4 characters before it touches an audit row, a webhook payload, or a UI surface.

Built-in libraries

pii

Credit cards are filtered through a Luhn checksum, so 4111111111111112 (a real-looking but invalid number) does not match. This eliminates the most common false-positive in PII scanning.

credentials

prompt_injection

The pattern set is curated to minimize false positives on benign user content. If you need stricter matching, use the custom patterns field on the policy.

Create a content_scan policy

Dashboard

Dashboard → Policies → New policy. Pick the Content scan mode. Toggle the libraries you want, optionally add custom regex rows, then save.

API

curl -X POST https://api.airaproof.com/api/v1/policies \
  -H "Authorization: Bearer aira_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Block PII in customer messages",
    "mode": "content_scan",
    "priority": 100,
    "scan_config": {
      "libraries": ["pii", "credentials"],
      "custom_patterns": [
        {
          "name": "internal_code",
          "regex": "INTERNAL-CODE-\\d+",
          "severity": "critical",
          "description": "Org-internal classification codes"
        }
      ]
    },
    "decision": "deny"
  }'

scan_config requires at least one library OR one custom pattern; an empty config is rejected with HTTP 422.

How it integrates with the policy engine

A content_scan policy is just another row in the priority-ordered policy list. When authorize() runs:

1. The action's details field (or its JSON serialization, if it's a dict) is fed through the scanner.
2. Every pattern in every enabled library plus every custom regex is matched.
3. The worst severity in the hit list decides the verdict (critical → deny, warning → require_approval, info → allow).
4. The scanner's hit list (with redacted samples) is persisted in the PolicyEvaluation.model_votes JSON column so the dashboard can render the evaluation later without re-scanning.

A deny from a high-priority content_scan policy stops the rest of the policy chain, exactly like a deny from any other mode.

What gets logged

For an SSN match in a customer message, the persisted model_votes looks like:

{
  "scan": [
    {
      "name": "us_ssn",
      "library": "pii",
      "severity": "critical",
      "matches": 1,
      "sample": "123...6789"
    }
  ],
  "worst_severity": "critical"
}

The sample is redacted. The full secret never appears in the database, in audit rows, in webhook payloads, or in the dashboard. There is no flag to disable redaction — if you need the full plaintext for forensics, you have to fetch it from the original action's details_storage_key (which is itself encrypted at rest).

When to use content_scan vs ai vs rules

content_scan is the right answer whenever the rule is "this byte sequence must never appear." It is faster and cheaper than ai mode, deterministic, and produces auditable output without an LLM round-trip.