Policy Concepts
Overview
This guide explains the fundamental concepts behind Ascend's policy engine. Understanding these concepts is essential for creating effective governance policies that balance security with operational efficiency.
Key Capabilities
- Policy Evaluation: How policies are matched and applied
- Pattern Matching: Wildcards, regex, and exact matching
- Condition Evaluation: Time-based, role-based, and context conditions
- Risk-Based Decisions: How risk scores influence policy outcomes
- Policy Inheritance: How policies combine and override
Core Concepts
Policy
A policy is a rule that defines how the governance platform should handle specific AI actions. Each policy contains:
- Identity: Name and description
- Match Criteria: Patterns that determine when the policy applies
- Conditions: Additional requirements that must be met
- Action: What happens when the policy matches (ALLOW, DENY, etc.)
- Priority: Order in which policies are evaluated
┌─────────────────────────────────────────────────────────────────────────────┐
│ POLICY STRUCTURE │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Policy: "production-database-protection" │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ IDENTITY │ │
│ │ Name: production-database-protection │ │
│ │ Description: Protect prod DB from modifications │ │
│ │ Priority: 50 │ │
│ │ Status: deployed │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ MATCH CRITERIA │ │
│ │ Namespace: database │ │
│ │ Verbs: insert, update, delete, alter │ │
│ │ Resources: production.*, prod.* │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ CONDITIONS │ │
│ │ Environment: production │ │
│ │ Risk Threshold: >= 40 │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ ACTION │ │
│ │ Decision: REQUIRE_APPROVAL │ │
│ │ Approval Level: 3 │ │
│ │ Timeout: 3600 seconds │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Policy Decision
A policy decision is the outcome of evaluating an action against policies:
| Decision | Description | Use Case |
|---|---|---|
| ALLOW | Action proceeds immediately | Low-risk, explicitly permitted actions |
| DENY | Action is blocked | High-risk, prohibited actions |
| REQUIRE_APPROVAL | Action queued for human review | Medium-risk actions needing oversight |
| ESCALATE | Action routed to senior approvers | Critical actions needing executive review |
| CONDITIONAL | Action allowed if conditions met | Context-dependent permissions |
Risk Score
A risk score is a 0-100 value representing the potential impact of an action:
┌─────────────────────────────────────────────────────────────────────────────┐
│ RISK SCORE BREAKDOWN │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Total Risk Score: 72/100 (HIGH) │
│ │
│ Category Breakdown: │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Security ████████████████████████████░░░░ 75/100 (35% weight) │ │
│ │ Data ██████████████████████░░░░░░░░░░ 65/100 (30% weight) │ │
│ │ Compliance ████████████████████████████████ 80/100 (20% weight) │ │
│ │ Financial ██████████████████░░░░░░░░░░░░░░ 55/100 (15% weight) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ Weighted Calculation: │
│ (75 × 0.35) + (65 × 0.30) + (80 × 0.20) + (55 × 0.15) = 72.0 │
│ │
│ Risk Factors: │
│ - security_high_risk: Credential access detected │
│ - compliance_high_risk: Production environment │
│ - data_medium_risk: Customer database access │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Evaluation Context
The evaluation context contains all information about an action being evaluated:
context = {
# User information
"user_id": "user-123",
"user_email": "analyst@company.com",
"user_role": "analyst",
# Action information
"action_type": "database_query",
"resource": "production.customers",
"namespace": "database",
# Environment information
"environment": "production",
"client_ip": "192.168.1.100",
"timestamp": "2026-01-20T14:30:00Z",
# Session information
"session_id": "sess-abc123",
"agent_id": "customer-support-bot"
}
Pattern Matching
Patterns determine when a policy applies to an action:
Exact Match
{
"namespace_patterns": ["database"]
}
Matches only namespace == "database"
Wildcard Match
{
"resource_patterns": ["production.*", "*.customers"]
}
production.*matchesproduction.users,production.orders*.customersmatchesprod.customers,staging.customers
Contains Match
{
"resource_patterns": ["*pii*", "*credential*"]
}
Matches any resource containing "pii" or "credential"
Multiple Patterns (OR Logic)
{
"verb_patterns": ["insert", "update", "delete"]
}
Matches if verb is "insert" OR "update" OR "delete"
Conditions
Conditions add requirements beyond pattern matching:
Time-Based Conditions
{
"conditions": {
"time_range": {
"start_hour": 9,
"end_hour": 17,
"timezone": "America/New_York"
}
}
}
Policy only applies between 9 AM and 5 PM Eastern
Role-Based Conditions
{
"conditions": {
"user_role": "admin"
}
}
Policy only applies to users with admin role
Environment Conditions
{
"conditions": {
"environment": "production"
}
}
Policy only applies in production environment
Combined Conditions (AND Logic)
{
"conditions": {
"environment": "production",
"user_role": "analyst",
"time_range": {
"start_hour": 18,
"end_hour": 6
}
}
}
All conditions must be met for policy to apply
Priority
Priority determines policy evaluation order:
┌─────────────────────────────────────────────────────────────────────────────┐
│ POLICY PRIORITY ORDER │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Evaluation Order (lowest priority number first): │
│ │
│ Priority 10: "emergency-block-all" │
│ ↓ (Checked first - if matches, stops here) │
│ Priority 25: "pii-data-protection" │
│ ↓ (Checked second) │
│ Priority 50: "production-database-protection" │
│ ↓ (Checked third) │
│ Priority 75: "standard-approval-workflow" │
│ ↓ (Checked fourth) │
│ Priority 100: "default-policy" │
│ ↓ (Checked last) │
│ No Match: Default decision (REQUIRE_APPROVAL) │
│ │
│ IMPORTANT: First matching policy wins - evaluation stops │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Policy Lifecycle
Policies go through defined states:
┌─────────────────────────────────────────────────────────────────────────────┐
│ POLICY LIFECYCLE │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌──────────┐ ┌──────────┐ │
│ │ DRAFT │ ───> │ TESTING │ ───> │ DEPLOYED │ ───> │ ARCHIVED │ │
│ └─────────┘ └─────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │
│ │ │ │ │
│ v v v │
│ Not active Dry-run only Active & enforced Inactive │
│ Editable Can modify Version locked Read-only │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
| State | Active | Editable | Description |
|---|---|---|---|
draft | No | Yes | Being created/modified |
testing | Dry-run | Yes | Testing with real traffic |
deployed | Yes | No | Active and enforced |
archived | No | No | Retired, kept for audit |
Risk Categories
Four categories assess different risk dimensions:
Security Risk
- What it measures: Access and privilege risks
- Indicators: Admin actions, credential access, permission changes
- Weight: 35% of total score
security_indicators = [
"admin", "privilege", "access", "credential",
"password", "token", "key", "certificate"
]
Data Risk
- What it measures: Data sensitivity and exposure
- Indicators: PII, customer data, confidential information
- Weight: 30% of total score
data_indicators = [
"pii", "personal", "private", "confidential",
"customer", "user", "sensitive"
]
Compliance Risk
- What it measures: Regulatory and policy risks
- Indicators: Audit requirements, policy violations
- Weight: 20% of total score
compliance_indicators = [
"audit", "compliance", "regulatory", "legal",
"sox", "hipaa", "gdpr", "pci"
]
Financial Risk
- What it measures: Business impact risks
- Indicators: Billing, payments, revenue, transactions
- Weight: 15% of total score
financial_indicators = [
"money", "payment", "financial", "billing",
"transaction", "purchase", "invoice"
]
Context Multipliers
Context factors modify base risk scores:
| Context | Multiplier | Description |
|---|---|---|
| Production environment | 1.5x | Higher impact |
| Staging environment | 1.2x | Medium impact |
| Development environment | 0.8x | Lower impact |
| Admin user | 1.4x | Elevated privileges |
| Service account | 1.3x | Automated access |
| External access | 2.0x | Outside network |
| After hours | 1.3x | Unusual timing |
| Bulk operation | 1.6x | Large-scale impact |
Approval Levels
Risk scores map to approval requirements:
| Risk Score | Level | Approvers | Typical SLA |
|---|---|---|---|
| 90-100 | L5 | Executive | 60 minutes |
| 80-89 | L4 | Senior Manager | 30 minutes |
| 70-79 | L3 | Manager | 15 minutes |
| 50-69 | L2 | Team Lead | 10 minutes |
| 25-49 | L1 | Peer Review | 5 minutes |
| 0-24 | L0 | Auto-approved | Immediate |
Advanced Concepts
Policy Conflict Detection
When multiple policies could apply, conflicts are detected:
┌─────────────────────────────────────────────────────────────────────────────┐
│ CONFLICT DETECTION EXAMPLE │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Policy A (Priority 50): │
│ Resource: production.customers │
│ Action: DENY │
│ │
│ Policy B (Priority 75): │
│ Resource: *.customers │
│ Action: ALLOW for role=admin │
│ │
│ CONFLICT DETECTED: │
│ Both policies match "production.customers" │
│ Policy A (DENY) would override Policy B (ALLOW) │
│ │
│ RESOLUTION: │
│ Policy A wins due to lower priority number (50 < 75) │
│ Admin users would be DENIED, not ALLOWED │
│ │
│ RECOMMENDATION: │
│ Add condition to Policy A to exclude admin role, or │
│ Lower Policy B priority to ensure admin access │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Natural Language Parsing
The engine can parse natural language policy descriptions:
Input:
"Block any agent from deleting customer data in production databases"
Parsed Output:
{
"decision": "DENY",
"namespace_patterns": ["database"],
"verb_patterns": ["delete"],
"resource_patterns": ["*customer*"],
"conditions": {"environment": "production"},
"confidence": 0.85
}
Caching Strategy
Policy evaluation results are cached for performance:
┌─────────────────────────────────────────────────────────────────────────────┐
│ CACHING STRATEGY │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Cache Key Format: │
│ SHA256(user_role:action_type:resource:namespace:environment) │
│ │
│ TTL Strategy: │
│ Standard risk (< 70): 300 seconds │
│ High risk (>= 70): 60 seconds │
│ │
│ Cache Invalidation: │
│ - Policy created/updated/deleted │
│ - Manual cache clear via API │
│ - TTL expiration │
│ │
│ Cache Bypass: │
│ - Emergency evaluations │
│ - Audit-mode evaluations │
│ - Force-refresh flag │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Fail-Closed Design
When errors occur, the engine defaults to safe behavior:
| Error Type | Default Behavior |
|---|---|
| Database unavailable | DENY (fail-closed) |
| Cache failure | Continue without cache |
| Policy parsing error | Skip policy, log error |
| Risk calculation error | Use maximum risk (95) |
| Timeout | REQUIRE_APPROVAL |
Best Practices
Policy Design
- Start with DENY by default: Create explicit ALLOW policies
- Use specific patterns: Avoid broad wildcards
- Layer policies: Multiple targeted policies > one catch-all
- Document intent: Use clear descriptions
- Test before deployment: Use dry-run mode
Priority Management
- Reserve low priorities (1-25): For critical security rules
- Use middle range (26-75): For business logic
- Default policies (76-100): For catch-all behavior
- Leave gaps: Allow room for new policies
Condition Usage
- Combine conditions carefully: All must match (AND logic)
- Test edge cases: Time zones, role changes
- Document conditions: Explain why each condition exists
- Review periodically: Conditions may become stale
Related
- Policy Engine Overview - Engine architecture
- Visual Policy Builder - UI-based creation
- Policy Templates - Pre-built templates
- Policy Testing - Testing and dry-run
- Risk Scoring - Scoring details
Compliance
Policy concepts support compliance with:
- SOC 2 CC6.1: Logical access security
- PCI-DSS 7.1: Access control policy
- NIST 800-53 AC-1: Access control policy
- HIPAA 164.312: Access control
- GDPR Article 5: Data processing principles