Core Concepts

Field	Value
Document ID	ASCEND-START-001
Version	1.0.0
Last Updated	December 19, 2025
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.

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	`langchain`, `mcp`, `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

# Source: sdk/ascend-sdk-python/ascend/models.py
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
# Source: services/workflow_service.py
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

# Source: services/immutable_audit_service.py
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

# Source: routes/smart_rules_routes.py
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 Commands

# Source: services/agent_control_service.py

# Suspend an agent
client.suspend_agent(
    agent_id="financial-advisor-prod",
    reason="Investigating anomalous behavior"
)

# Emergency block
client.emergency_block(
    agent_id="financial-advisor-prod",
    reason="Security incident - immediate block required"
)

# Selective block
client.block_action_types(
    agent_id="financial-advisor-prod",
    action_types=["database_delete", "file_delete"],
    reason="Blocking destructive operations during audit"
)

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: 1.0.0 | Last Updated: December 2025

Overview​

Agents​

Agent Properties​

Agent Lifecycle​

Actions​

Action Structure​

Action Types​

Risk Assessment​

CVSS (Common Vulnerability Scoring System)​

NIST 800-53 Controls​

MITRE ATT&CK Framework​

Combined Risk Score​

Approval Workflows​

Workflow Levels​

Workflow Configuration​

Decision Outcomes​

APPROVED​

DENIED​

PENDING​

Audit Logging​

Audit Entry Structure​

Audit Properties​

Smart Rules​

Rule Structure​

Rule Operators​

Kill-Switch​

Kill-Switch Levels​

Kill-Switch Commands​

Next Steps​