Policy-as-Code

Policies define the automated actions Slim.io takes when sensitive data is detected. Written in YAML, policies follow a declarative model: you specify conditions and actions, and the policy engine evaluates them against scan findings.

Policy YAML Schema


apiVersion: slim.io/v1
kind: Policy
metadata:
  name: tokenize-financial-pii
  description: "Automatically tokenize credit card and bank account numbers"
  tags:
    - pci-dss
    - financial
spec:
  mode: enforced  # or "dry-run"
  scope:
    connectors:
      - connector-id-aws-prod
      - connector-id-gcp-prod
    file_types:
      - csv
      - json
      - parquet
    prefixes:
      - "data/financial/"
      - "exports/"
  conditions:
    - category: Credit Card
      min_confidence: 0.75  # tune for your environment, see Settings > Detection
    - category: Bank Account
      min_confidence: 0.75  # tune for your environment, see Settings > Detection
  actions:
    - type: tokenize
      config:
        algorithm: aes-256
        key_scope: tenant
    - type: alert
      config:
        channels:
          - slack://security-alerts
          - email://compliance@company.com
        severity: high

Schema Reference

metadata

Field	Required	Description
`name`	Yes	Unique identifier (kebab-case)
`description`	Yes	Human-readable description
`tags`	No	Labels for filtering and organization

spec.mode

Value	Behavior
`dry-run`	Evaluate conditions and log matches, but do not execute actions
`enforced`	Evaluate conditions and execute actions on matching findings

Always start with dry-run mode when creating new policies. Review the matched findings in the Governance dashboard to confirm the policy behaves as expected before switching to enforced.

spec.scope

Scope controls which findings the policy applies to:

Field	Description
`connectors`	List of connector IDs (empty = all connectors)
`file_types`	File extensions to include (empty = all types)
`prefixes`	Object key prefixes to include (empty = all paths)
`workspaces`	Workspace IDs to scope to (empty = current workspace)

spec.conditions

Conditions define which findings trigger the policy:

Field	Description
`category`	PII category to match (SSN, Email, Credit Card, etc.)
`min_confidence`	Minimum confidence score for the finding to qualify
`max_confidence`	Maximum confidence score (optional, for banding)
`risk_score_min`	Minimum file-level risk score

Multiple conditions use OR logic — a finding matching any condition triggers the policy.

spec.actions

Available action types:

Action	Description
`alert`	Send notifications via Slack, email, or webhook
`tokenize`	Replace sensitive values with AES-256 encrypted tokens
`mask`	Redact sensitive values in place (irreversible)
`quarantine`	Move the file to an isolation bucket
`tag`	Apply metadata tags to the file or finding
`webhook`	Send finding details to a custom HTTP endpoint

Deploying Policies

Via the Dashboard

Navigate to Governance > Policies in the Customer Dashboard.
Click Create Policy.
Paste or write your YAML definition.
Click Validate to check for errors.
Click Deploy to activate the policy.

Via the API


POST /api/v1/governance/policies
Content-Type: application/yaml
Authorization: Bearer $TOKEN
 
# YAML body here

Via Git Sync

Store policy YAML files in a Git repository alongside your classifier definitions:


slim-io-config/
  policies/
    tokenize-financial-pii.yaml
    alert-health-data.yaml
    quarantine-public-buckets.yaml

Enable Git sync under Settings > Integrations to automatically deploy policy changes on merge.

Policy Evaluation Order

When multiple policies match the same finding:

All matching policies execute (policies do not short-circuit)
Actions from all matching policies are combined
Conflicting actions use the most restrictive outcome (e.g., quarantine wins over alert-only)
Execution order within a policy follows the order of actions in the YAML

Auditing

Every policy evaluation is logged with:

Timestamp
Policy name and version
Finding ID and details
Conditions matched
Actions executed (or skipped in dry-run)
Outcome status (success, partial failure, error)

These logs are available in the Governance dashboard and via the API at GET /api/v1/governance/audit-log.