Core Concepts

Field	Value
Document ID	ASCEND-START-001
Version	2026.04
Last Updated	April 2026
Author	Ascend Engineering Team
Publisher	OW-KAI Technologies Inc.
Classification	Enterprise Client Documentation
Compliance	SOC 2 CC6.1/CC6.2, PCI-DSS 7.1/8.3, HIPAA 164.312, NIST 800-53 AC-2/SI-4

Reading Time: 8 minutes | Skill Level: Beginner

Overview

This guide explains the fundamental concepts you need to understand when working with ASCEND. These concepts are the foundation for configuring governance policies and understanding how decisions are made.

note

Risk scores, trust levels, and policy decisions are the three pillars of ASCEND governance. Understanding how they interact is essential before configuring policies or integrating agents.

Agents

An Agent is any AI system that performs actions requiring governance. This includes:

• LangChain agents
• MCP (Model Context Protocol) servers
• Custom AI applications
• Automated scripts with AI decision-making
• Boto3 operations in AI pipelines

Agent Properties

Property	Description	Example
agent_id	Unique identifier	financial-advisor-prod
agent_name	Human-readable name	Financial Advisor Bot
agent_type	Category of agent	supervised, autonomous, advisory, mcp_server, custom
owner	Responsible team/person	ai-team@company.com
environment	Deployment stage	production, staging, sandbox

Agent Lifecycle

┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐
│          │     │          │     │          │     │          │
│ REGISTER │────▶│  ACTIVE  │────▶│ SUSPEND  │────▶│ ARCHIVE  │
│          │     │          │     │          │     │          │
└──────────┘     └────┬─────┘     └────┬─────┘     └──────────┘
                      │                │
                      │    ┌───────────┘
                      │    │
                      ▼    ▼
                 ┌──────────┐
                 │          │
                 │ BLOCKED  │ (Kill-switch)
                 │          │
                 └──────────┘

Actions

An Action is any operation an agent wants to perform that requires governance evaluation.

Action Structure

# Action structure (illustrative)
action = {
    "action_type": "database_write",      # Category of action
    "description": "Update user profile", # Human-readable description
    "parameters": {                        # Action-specific details
        "table": "users",
        "operation": "UPDATE",
        "affected_rows": 1
    },
    "context": {                           # Additional context
        "user_id": "user_123",
        "session_id": "sess_abc",
        "ip_address": "192.168.1.1"
    }
}

Action Types

ASCEND recognizes these standard action types:

Category	Action Types	Risk Range
Database	database_read, database_write, database_delete, database_schema	Low - Critical
File System	file_read, file_write, file_delete, file_execute	Low - Critical
Network	http_request, api_call, email_send, webhook_trigger	Low - High
System	process_spawn, config_change, credential_access	Medium - Critical
AI	model_inference, prompt_injection, data_extraction	Low - High

Risk Assessment

ASCEND evaluates every action using three industry-standard frameworks:

CVSS (Common Vulnerability Scoring System)

Scores from 0.0 to 10.0 measuring potential impact:

Score	Severity	Example Action
0.0 - 3.9	Low	Read public data
4.0 - 6.9	Medium	Send notification email
7.0 - 8.9	High	Access customer PII
9.0 - 10.0	Critical	Delete production database

NIST 800-53 Controls

Maps actions to security controls:

Action: "database_delete" on "customers" table

NIST Mapping:
├── AC-3: Access Enforcement
├── AU-12: Audit Generation
├── CP-9: Information System Backup
└── SC-28: Protection of Information at Rest

MITRE ATT&CK Framework

Identifies potential adversarial techniques:

Action: "credential_access" on "api_keys" table

MITRE Mapping:
├── T1552: Unsecured Credentials
├── T1555: Credentials from Password Stores
└── TA0006: Credential Access (Tactic)

Combined Risk Score

ASCEND combines all three frameworks into a unified risk assessment:

# Example risk assessment response
{
    "risk_score": 7.8,
    "risk_level": "HIGH",
    "cvss": {
        "score": 7.5,
        "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N"
    },
    "nist_controls": ["AC-3", "AU-12", "SC-28"],
    "mitre_techniques": ["T1552", "T1555"],
    "factors": [
        "Accesses sensitive data classification: PII",
        "Affects production environment",
        "No prior similar actions from this agent"
    ]
}

Approval Workflows

Based on risk assessment, actions follow different approval paths:

Workflow Levels

┌─────────────────────────────────────────────────────────────────────────┐
│                      APPROVAL WORKFLOW MATRIX                            │
├─────────────────┬───────────────┬───────────────────────────────────────┤
│   Risk Level    │   Workflow    │              Approvers                │
├─────────────────┼───────────────┼───────────────────────────────────────┤
│   LOW (0-3.9)   │  Auto-approve │  None required (logged only)          │
│                 │               │                                        │
│   MEDIUM (4-6.9)│  Single       │  Any team member with approve rights  │
│                 │               │                                        │
│   HIGH (7-8.9)  │  Multi        │  2+ approvers, including team lead    │
│                 │               │                                        │
│   CRITICAL (9+) │  Escalation   │  Manager + Security team required     │
└─────────────────┴───────────────┴───────────────────────────────────────┘

Workflow Configuration

# Example workflow configuration (illustrative)
workflow_config = {
    "low_risk": {
        "auto_approve": True,
        "log_only": True
    },
    "medium_risk": {
        "required_approvers": 1,
        "approver_roles": ["team_member", "team_lead", "admin"]
    },
    "high_risk": {
        "required_approvers": 2,
        "must_include_roles": ["team_lead"],
        "timeout_hours": 24,
        "escalation_on_timeout": True
    },
    "critical_risk": {
        "required_approvers": 3,
        "must_include_roles": ["manager", "security_team"],
        "timeout_hours": 4,
        "block_on_timeout": True
    }
}

Decision Outcomes

Every action results in one of three decisions:

APPROVED

The action can proceed:

{
    "decision": "APPROVED",
    "action_id": "act_abc123",
    "approved_by": "auto" | ["user@company.com"],
    "approved_at": "2025-12-16T10:30:00Z",
    "valid_until": "2025-12-16T11:30:00Z",  # Optional time limit
    "conditions": []  # Optional conditions
}

DENIED

The action is blocked:

{
    "decision": "DENIED",
    "action_id": "act_abc123",
    "denied_by": "policy" | "user@company.com",
    "denied_at": "2025-12-16T10:30:00Z",
    "reason": "Action violates Smart Rule: No database deletes after hours",
    "rule_id": "rule_xyz789"
}

PENDING

The action is awaiting human approval:

{
    "decision": "PENDING",
    "action_id": "act_abc123",
    "pending_since": "2025-12-16T10:30:00Z",
    "pending_approvers": ["lead@company.com", "security@company.com"],
    "timeout_at": "2025-12-16T14:30:00Z",
    "approval_url": "https://dashboard.owkai.app/approve/act_abc123"
}

Audit Logging

Every action and decision is recorded in an immutable audit log:

Audit Entry Structure

# Audit entry structure (illustrative)
audit_entry = {
    "entry_id": "aud_xyz789",
    "timestamp": "2025-12-16T10:30:00.123Z",
    "action_id": "act_abc123",
    "agent_id": "financial-advisor-prod",
    "action_type": "database_read",
    "risk_assessment": {
        "score": 4.5,
        "level": "MEDIUM"
    },
    "decision": "APPROVED",
    "decision_by": "auto",
    "execution_result": "SUCCESS",
    "hash": "sha256:abc123...",  # Integrity verification
    "previous_hash": "sha256:xyz789..."  # Chain link
}

Audit Properties

Property	Description
Immutable	Entries cannot be modified after creation
Chained	Each entry references the previous (blockchain-like)
Verifiable	Hash-based integrity checking
Searchable	Full-text search and filtering
Exportable	CSV, PDF, and API access

Smart Rules

Custom governance rules that supplement risk assessment:

Rule Structure

# Smart rule example (illustrative)
smart_rule = {
    "rule_id": "rule_001",
    "name": "Block after-hours database changes",
    "condition": {
        "all": [
            {"field": "action_type", "operator": "starts_with", "value": "database_"},
            {"field": "action_type", "operator": "not_equals", "value": "database_read"},
            {"field": "context.time_hour", "operator": "gte", "value": 18}
        ]
    },
    "action": "DENY",
    "reason": "Database modifications are blocked after 6 PM",
    "priority": 100,  # Higher = evaluated first
    "enabled": True
}

Rule Operators

Operator	Description	Example
equals	Exact match	action_type equals "database_delete"
not_equals	Not equal	environment not_equals "production"
contains	Substring match	description contains "PII"
starts_with	Prefix match	action_type starts_with "database_"
gte, lte	Numeric comparison	risk_score gte 7.0
in	List membership	action_type in ["delete", "drop"]

Kill-Switch

Emergency mechanism to block agent actions:

Kill-Switch Levels

Level	Effect	Use Case
Suspend	Block new actions, allow in-flight	Scheduled maintenance
Block	Block all actions immediately	Security incident
Selective	Block specific action types	Targeted control

Kill-Switch Usage

The SDK provides three primitives for participating in the kill-switch:

import sys

# Monitor for kill-switch signals
client.start_kill_switch_polling(interval_seconds=5)

# Check before each governed action whether this agent has been blocked
if client.is_blocked():
    print("Agent is blocked — stopping execution")
    sys.exit(0)

# Stop polling when the agent shuts down cleanly
client.stop_kill_switch_polling()

Operators trigger the kill-switch from the dashboard (Agent Registry → emergency suspend) or via the management API. The SDK's start_kill_switch_polling() keeps a background watcher that flips is_blocked() to True within the polling window, letting your agent loop exit on the next iteration.

Next Steps

Now that you understand the core concepts:

• Your First Action — Put these concepts into practice
• Smart Rules — Create custom governance rules
• Approval Workflows — Configure approval chains

---

Document Version: 2026.04 | Last Updated: April 2026