Create Your First Policy

This guide walks you through creating your first governance policy in ASCEND. Policies define the rules that control what your AI agents can and cannot do.

Prerequisites

Before creating policies, ensure you have:

• An ASCEND account with admin or manager role
• At least one registered agent (Register Your First Agent)
• Access to the ASCEND Console

Understanding Policies

Policies are rules that ASCEND evaluates when an agent requests to perform an action.

Policy Structure

Every policy has these components:

Component	Description	Required
Name	Human-readable identifier	Yes
Description	Explanation of the policy's purpose	Yes
Conditions	When this policy applies	Yes
Action	What to do when conditions match	Yes
Priority	Order of evaluation (higher first)	No (default: 0)

Policy Actions

Action	Behavior	Use Case
allow	Permit the action	Low-risk operations
deny	Block the action	Prohibited operations
require_approval	Route to human approvers	High-risk operations
flag	Allow but create alert	Monitoring specific patterns

Step 1: Access the Policy Editor

1. Log in to pilot.owkai.app
2. Navigate to Policies in the sidebar
3. Click Create Policy

Step 2: Define Basic Information

Start with the policy's identity:

Name: Choose a clear, descriptive name

High Value Refund Approval

Description: Explain what the policy does

Requires manager approval for refunds exceeding $500 to prevent
unauthorized financial transactions.

Step 3: Set Conditions

Conditions determine when the policy applies. ASCEND supports multiple condition types:

Simple Conditions

Match exact values:

{
    "action_type": "financial.refund",
    "resource": "stripe_api"
}

Comparison Operators

Use operators for complex matching:

Operator	Description	Example
$eq	Equal to	{"amount": {"$eq": 100}}
$ne	Not equal to	{"status": {"$ne": "test"}}
$gt	Greater than	{"amount": {"$gt": 500}}
$gte	Greater than or equal	{"amount": {"$gte": 500}}
$lt	Less than	{"risk_score": {"$lt": 50}}
$lte	Less than or equal	{"count": {"$lte": 100}}
$in	In array	{"type": {"$in": ["A", "B"]}}
$nin	Not in array	{"env": {"$nin": ["test"]}}
$contains	Contains substring	{"query": {"$contains": "DELETE"}}
$regex	Regex match	{"sql": {"$regex": "DROP.*TABLE"}}

Nested Conditions

Access nested fields with dot notation:

{
    "parameters.amount": {"$gt": 500},
    "context.environment": "production"
}

Logical Operators

Combine conditions with logical operators:

AND (implicit):

{
    "action_type": "financial.refund",
    "parameters.amount": {"$gt": 500}
}

OR:

{
    "$or": [
        {"action_type": "financial.refund"},
        {"action_type": "financial.transfer"}
    ]
}

NOT:

{
    "$not": {
        "context.environment": "development"
    }
}

Step 4: Define the Action

Choose what happens when conditions match:

Allow Action

Permit the action to proceed:

{
    "action": "allow",
    "reason": "Read-only data access is permitted"
}

Deny Action

Block the action:

{
    "action": "deny",
    "reason": "Production database modifications are not allowed"
}

Require Approval

Route to human approvers:

{
    "action": "require_approval",
    "approvers": ["finance-manager", "compliance-officer"],
    "timeout_hours": 24,
    "reason": "High-value transaction requires manager approval"
}

Flag Action

Allow but create an alert:

{
    "action": "flag",
    "alert_level": "warning",
    "reason": "Unusual query pattern detected"
}

Step 5: Set Priority

Priority determines evaluation order. Higher numbers evaluate first.

Priority 100: Deny all DROP TABLE queries        (Checked first)
Priority 75:  Require approval for > $500        (Checked second)
Priority 50:  Allow read-only SELECT queries     (Checked third)
Priority 0:   Default allow                      (Fallback)

Example Policies

Policy 1: High Value Refund Approval

Purpose: Require approval for refunds over $500

{
    "name": "High Value Refund Approval",
    "description": "Requires manager approval for refunds exceeding $500",
    "conditions": {
        "action_type": "financial.refund",
        "parameters.amount": {"$gt": 500}
    },
    "action": "require_approval",
    "approvers": ["finance-manager"],
    "timeout_hours": 24,
    "priority": 75
}

Policy 2: Block Destructive Database Operations

Purpose: Prevent DROP, TRUNCATE, and DELETE without WHERE

{
    "name": "Block Destructive Database Operations",
    "description": "Prevents destructive SQL operations in production",
    "conditions": {
        "action_type": "database.query",
        "resource": {"$contains": "production"},
        "$or": [
            {"parameters.sql": {"$regex": "DROP\\s+TABLE"}},
            {"parameters.sql": {"$regex": "TRUNCATE\\s+TABLE"}},
            {"parameters.sql": {"$regex": "DELETE\\s+FROM\\s+\\w+\\s*$"}}
        ]
    },
    "action": "deny",
    "reason": "Destructive database operations require manual execution",
    "priority": 100
}

Policy 3: Allow Read-Only Data Access

Purpose: Auto-approve SELECT queries

{
    "name": "Allow Read-Only Data Access",
    "description": "Permits SELECT queries without modification",
    "conditions": {
        "action_type": "database.query",
        "parameters.sql": {"$regex": "^\\s*SELECT"},
        "$not": {
            "$or": [
                {"parameters.sql": {"$contains": "INTO"}},
                {"parameters.sql": {"$contains": "FOR UPDATE"}}
            ]
        }
    },
    "action": "allow",
    "priority": 50
}

Policy 4: PII Access Control

Purpose: Flag all PII access and require approval for exports

{
    "name": "PII Access Control",
    "description": "Controls access to personally identifiable information",
    "conditions": {
        "$or": [
            {"parameters.columns": {"$in": ["ssn", "email", "phone", "address"]}},
            {"parameters.table": {"$in": ["customers", "employees", "users"]}},
            {"context.pii_involved": true}
        ]
    },
    "action": "flag",
    "alert_level": "info",
    "reason": "PII access detected - logged for compliance",
    "priority": 60
}

Policy 5: Production Environment Protection

Purpose: Require approval for all production modifications

{
    "name": "Production Environment Protection",
    "description": "Requires approval for any production data modification",
    "conditions": {
        "context.environment": "production",
        "action_type": {"$in": [
            "data_modification",
            "database.write",
            "database.delete",
            "system.config"
        ]}
    },
    "action": "require_approval",
    "approvers": ["ops-lead", "team-lead"],
    "timeout_hours": 4,
    "priority": 80
}

Creating Policies via API

You can also create policies programmatically:

REST API

curl -X POST https://pilot.owkai.app/api/policies \
  -H "X-API-Key: your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "High Value Refund Approval",
    "description": "Requires manager approval for refunds exceeding $500",
    "conditions": {
        "action_type": "financial.refund",
        "parameters.amount": {"$gt": 500}
    },
    "action": "require_approval",
    "approvers": ["finance-manager"],
    "priority": 75,
    "enabled": true
  }'

Response

{
    "id": "pol_abc123xyz",
    "name": "High Value Refund Approval",
    "status": "active",
    "created_at": "2026-01-20T10:30:00Z",
    "created_by": "admin@company.com"
}

Policy Best Practices

1. Start Restrictive, Then Relax

Begin with stricter policies and relax as you understand agent behavior:

Week 1: Require approval for all financial transactions
Week 2: Allow transactions under $100 automatically
Week 3: Allow transactions under $500 for trusted agents

2. Use Descriptive Names

Names should explain what the policy does:

Bad	Good
Policy 1	Block Destructive SQL Operations
Refund Policy	High Value Refund Approval ($500+)
Data Rule	PII Export Requires Compliance Review

3. Document Reasoning

Include clear reasons in your policies:

{
    "reason": "Refunds over $500 require finance manager approval per SOX compliance (Section 404)"
}

4. Test in Development First

Create policies in a development environment before production:

{
    "conditions": {
        "context.environment": "development",
        // ... other conditions
    }
}

5. Monitor Policy Effectiveness

After creating policies:

1. Check the Policy Analytics dashboard
2. Review matched vs. unmatched actions
3. Adjust conditions based on real traffic

Policy Evaluation Order

ASCEND evaluates policies in this order:

1. Priority Sort: Higher priority policies first
2. First Match Wins: First matching policy determines the decision
3. Default Behavior: If no policy matches, apply organization defaults

Action: financial.refund, amount=$750

Policy Evaluation:
  1. Priority 100: Block Suspicious Patterns    → No match
  2. Priority 75:  High Value Refund Approval   → MATCH! → require_approval
  3. Priority 50:  Allow Small Refunds          → Not evaluated
  4. Priority 0:   Default Allow                → Not evaluated

Result: require_approval (from Priority 75 policy)

Troubleshooting Policies

Policy Not Matching

If your policy is not matching expected actions:

1. Check Conditions: Verify exact field names and values
2. Check Priority: A higher-priority policy may be matching first
3. Check Syntax: Ensure JSON is valid
4. View Evaluation Logs: Check which policy matched in the Console

Policy Matching Too Broadly

If your policy matches unintended actions:

1. Add More Conditions: Make conditions more specific
2. Use Negative Conditions: Exclude certain patterns with $not
3. Check Operators: Ensure you are using the right comparison operator

Conflicting Policies

If policies conflict:

1. Review Priorities: Higher priority wins
2. Add Exclusions: Use $not to exclude specific cases
3. Consolidate: Combine similar policies

Next Steps

Your first policy is now active. Continue with:

1. Evaluate Your First Action: See your policy in action
2. Dashboard Tour: Monitor policy effectiveness
3. Policies API Reference: Advanced policy management

---

Last Updated: 2026-01-20