Security Layers Detail

Overview

This document provides detailed technical documentation for each of the 12 security layers in ASCEND's defense-in-depth architecture. Each layer is designed to operate independently while contributing to the overall security posture.

Layer 1: Rate Limiting

Purpose: Prevent abuse, DDoS attacks, and brute force attempts.

Implementation

# security/rate_limiter.py
RATE_LIMITS = {
    "auth_strict": {
        "login": "5/minute",
        "password_change": "3/minute"
    },
    "auth_moderate": {
        "register": "3/minute"
    },
    "api_standard": {
        "read": "100/minute",
        "write": "30/minute"
    },
    "default": "60/minute"
}

Configuration

Category	Endpoint Type	Limit	Window
Auth (Strict)	Login	5 requests	1 minute
Auth (Strict)	Password Change	3 requests	1 minute
Auth (Moderate)	Registration	3 requests	1 minute
API (Standard)	Read Operations	100 requests	1 minute
API (Standard)	Write Operations	30 requests	1 minute
Default	All Others	60 requests	1 minute

IP-Based Blocking

Trigger	Action	Duration
10 rate limit violations	Soft block	5 minutes
25 rate limit violations	Hard block	1 hour

Fail-Secure Behavior

If Redis (the rate limit backend) is unavailable, all rate-limited requests are DENIED. This prevents abuse during infrastructure issues.

---

Layer 2: Prompt Security

Purpose: Detect and block prompt injection attacks targeting AI systems.

Detection Patterns

ASCEND monitors for 20 prompt injection patterns:

Pattern ID	Category	Attack Vector	Severity
PROMPT-001	Injection	Direct instruction override ("ignore previous instructions")	CRITICAL
PROMPT-002	Injection	New instruction injection ("from now on")	CRITICAL
PROMPT-004	Jailbreak	Known jailbreak modes (DAN, STAN, etc.)	CRITICAL
PROMPT-008	Roleplay	Evil AI roleplay ("you are now an evil AI")	HIGH
PROMPT-016	Injection	Fake system/admin tags ([SYSTEM], [OVERRIDE])	HIGH
PROMPT-018	Exfiltration	System prompt extraction ("reveal your instructions")	HIGH
PROMPT-020	Chain Attack	LLM chain injection ("pass to next agent")	CRITICAL

Encoding Attack Detection

Encoding Type	Detection Method	Example
Base64	Pattern + decode verification	aWdub3JlIHByZXZpb3Vz
Unicode Escape	Sequence detection	\u0069\u0067\u006e\u006f\u0072\u0065
HTML Entities	Entity pattern matching	ignore
Zero-Width Characters	Character class detection	Invisible instruction injection

Multi-Signal Scoring (VAL-FIX-001)

To reduce false positives while maintaining security:

1. Critical patterns (PROMPT-001, 002, 004, 008, 016, 018, 020) always use full risk score
2. Multiple pattern matches confirm the threat and use maximum risk score
3. Single non-critical pattern is capped at medium risk (70) pending confirmation

Fail-Secure Behavior

If the prompt security detector fails or times out, prompts are BLOCKED by default.

---

Layer 3: Code Analysis

Purpose: Detect dangerous code patterns in AI-generated or AI-processed code.

Supported Languages

Language	Detection Categories
SQL	Injection, DDL modifications, privilege escalation
Python	Code execution, file operations, network calls
Shell/Bash	Command injection, privilege escalation
JavaScript	DOM manipulation, code injection
Go	Buffer overflow, unsafe operations

Pattern Categories

Category	CWE Mapping	MITRE Technique	Example
SQL Injection	CWE-89	T1190	'; DROP TABLE users; --
Code Execution	CWE-95	T1203	eval(), exec()
Command Injection	CWE-78	T1059	os.system(), backticks
Path Traversal	CWE-22	T1083	../../../etc/passwd
Insecure Deserialization	CWE-502	T1203	pickle.loads()
Buffer Overflow	CWE-119	T1203	Unsafe memory operations

Risk Score Calculation

# Risk score sources (in order of precedence):
# 1. Organization override (org_pattern_override.risk_score_override)
# 2. CVSS base score converted (cvss_base_score * 10)
# 3. Organization severity mapping (org_code_analysis_config.severity_scores)

Fail-Secure Behavior

If the code analyzer fails or times out, code execution is BLOCKED.

---

Layer 4: Action Governance

Purpose: Evaluate AI actions in real-time before execution.

Evaluation Flow

AI Agent Request
       |
       v
  +----------+
  | Policy   |     Smart Rules
  | Engine   | <-- Risk Scoring
  +----------+     Multi-Signal
       |
       v
  +-----------+
  | Decision  | --> ALLOW / DENY / REQUIRE_APPROVAL
  +-----------+
       |
       v
  +----------+
  | Audit    |
  | Log      |
  +----------+

Decision Types

Decision	Description	Audit
ALLOW	Action permitted, proceed immediately	Logged
DENY	Action blocked, return error	Logged with reason
REQUIRE_APPROVAL	Action held pending human approval	Queued for review

Kill Switch Capability

Agent Control Service provides immediate agent control:

Command	Effect	Latency Target
BLOCK	Stop all actions from agent	<500ms
UNBLOCK	Resume agent operations	<500ms
SUSPEND	Pause agent temporarily	<500ms
RESUME	Resume suspended agent	<500ms
RATE_LIMIT	Throttle agent actions	<500ms
QUARANTINE	Isolate agent for review	<500ms

Fail-Secure Behavior

If the action governance evaluator fails, the action is DENIED.

---

Layer 5: JWT Authentication

Purpose: Verify user identity via cryptographic token validation.

Token Validation

Check	Description	Failure Response
Signature	RS256 verification against JWKS	401 Unauthorized
Issuer (iss)	Must match Cognito issuer URL	401 Unauthorized
Audience (aud)	Must match app client ID	401 Unauthorized
Expiration (exp)	Token must not be expired	401 Token Expired
Not-Before (nbf)	Token must be valid now	401 Unauthorized
Token Use	Must be "id" token	401 Unauthorized

Multi-Pool Support (RBAC-001)

ASCEND supports two-pool JWT validation:

Pool	Purpose	Token Claims
Platform Pool	Ascend internal staff	scope='platform', org_id=null
Per-Org Pools	Tenant users	scope='org', org_id=[tenant_id]

Token Revocation

• Token JTIs are tracked in cognito_tokens table
• Revoked tokens return 401 immediately
• Revocation is logged with reason

Fail-Secure Behavior

Any JWT validation failure results in 401 Unauthorized (DENY).

---

Layer 6: API Key Validation

Purpose: Authenticate SDK and CI/CD integrations.

Security Features

Feature	Implementation	Benefit
SHA-256 Hashing	Keys stored as salted hashes	Prevents plaintext exposure
Constant-Time Comparison	secrets.compare_digest()	Prevents timing attacks
32-Character Prefix	First 32 chars for lookup	Prevents collision attacks
Usage Tracking	Per-request logging	Audit trail and analytics

Supported Headers

# Option 1: Bearer token
Authorization: Bearer owkai_admin_xxxxx...

# Option 2: X-API-Key header
X-API-Key: owkai_admin_xxxxx...

Rate Limiting

API keys have per-key rate limits configured via api_key_rate_limits table:

Tier	Max Requests	Window
Free	100	1 hour
Standard	1,000	1 hour
Enterprise	10,000	1 hour
Unlimited	No limit	-

Fail-Secure Behavior

If API key validation fails for any reason, the request is DENIED with 401.

---

Layer 7: RBAC Authorization

Purpose: Enforce role-based permissions with separation of duties.

6-Level Role Hierarchy

Level	Role	Description
0	RESTRICTED	Suspended/probationary users - no access
1	BASIC	Standard users - dashboard view only
2	POWER	Power users - analytics + alerts
3	MANAGER	Managers - authorization capabilities
4	ADMIN	Administrators - full system access
5	EXECUTIVE	Executives - all privileges + critical overrides

Permission Categories

• Dashboard: view, export
• Analytics: view, reports, export
• Alerts: view, acknowledge, correlate, dismiss
• Rules: view, create, modify, delete
• Authorization: view_pending, approve_low/medium/high/critical, emergency_override
• Users: view, create, modify, delete, reset_password, manage_roles
• Audit: view, export, delete
• System: config, backup, maintenance

Separation of Duties (SoD)

Scenario	Requirement
High-Risk Approval (70-89)	2 approvers, cannot approve own
Critical Risk Approval (90-100)	2 EXECUTIVE from different departments
User Role Changes	MANAGER + ADMIN approval
Emergency Override	Dual EXECUTIVE + mandatory justification

Fail-Secure Behavior

If RBAC check fails, the request is DENIED with 403 Forbidden.

---

Layer 8: BYOK Encryption

Purpose: Protect data at rest with customer-managed keys.

Architecture

                    +----------------+
                    |  Customer's    |
                    |  Master Key    |
                    |  (CMK in KMS)  |
                    +-------+--------+
                            |
                            v
                    +-------+--------+
                    |  Data          |
                    |  Encryption    |
                    |  Key (DEK)     |
                    +-------+--------+
                            |
                            v
+-------------------+-------+--------+-------------------+
|                   |  Encrypted     |                   |
|   Plaintext  ---> |  Data          | --->  Plaintext   |
|   (input)         |  (storage)     |       (output)    |
+-------------------+----------------+-------------------+

Specifications

Property	Value
Algorithm	AES-256-GCM (authenticated encryption)
Nonce	96 bits, randomly generated per encryption
Key Caching	5-minute TTL with auto-expiry
Key Rotation	Customer-controlled via KMS

Fail-Secure Behavior

If the customer's CMK is unavailable, all encryption/decryption operations FAIL and operations are blocked.

---

Layer 9: Audit Logging

Purpose: Maintain immutable compliance trail for all security events.

WORM (Write-Once-Read-Many) Implementation

# Immutable audit entry structure
{
    "id": "uuid",
    "sequence_number": 12345,          # Prevents deletion gaps
    "previous_hash": "sha256...",      # Hash chain integrity
    "content_hash": "sha256...",       # Entry integrity
    "event_type": "authorization",
    "actor_id": "user-123",
    "resource_type": "agent_action",
    "action": "approve",
    "outcome": "success",
    "risk_level": "high",
    "compliance_tags": ["SOC2-CC6.1", "HIPAA-164.312"],
    "timestamp": "2026-01-20T10:30:00Z"
}

Audit Event Types

Event Type	Description	Retention
authentication	Login, logout, token refresh	365 days
authorization	Permission checks, approvals	365 days
data_access	Read/write operations	365 days
configuration	System settings changes	365 days
security_event	Detected threats, blocks	7 years

Fail-Secure Behavior

If audit log write fails, the operation is BLOCKED to maintain compliance trail integrity.

---

Layer 10: Input Validation

Purpose: Sanitize and validate all inputs before processing.

Validation Methods

Method	Implementation	Example
Type Validation	Pydantic models	int, str, EmailStr
Length Constraints	Field validators	min_length=1, max_length=255
Pattern Matching	Regex validators	Email, UUID, phone
Enum Validation	Literal types	status: Literal["active", "suspended"]
Cross-Field Validation	Custom validators	Password confirmation

Fail-Secure Behavior

Malformed input is REJECTED with 422 Validation Error.

---

Layer 11: Secrets Management

Purpose: Securely store and access sensitive credentials.

Implementation

• AWS Secrets Manager for credential storage
• Automatic rotation support
• Encryption at rest and in transit
• IAM-based access control

Fail-Secure Behavior

If secrets cannot be retrieved, dependent operations are BLOCKED.

---

Layer 12: Security Headers

Purpose: Prevent common web attacks through HTTP headers.

Headers Applied

Header	Value	Protection
X-Frame-Options	DENY	Clickjacking
X-XSS-Protection	1; mode=block	XSS (legacy browsers)
X-Content-Type-Options	nosniff	MIME sniffing
Content-Security-Policy	Strict defaults	XSS, injection
Strict-Transport-Security	max-age=63072000; includeSubDomains; preload	Downgrade attacks
Referrer-Policy	strict-origin-when-cross-origin	Information leakage
Permissions-Policy	camera=(), microphone=(), geolocation=()	Feature access

Fail-Secure Behavior

Headers default to most restrictive settings even if configuration is unavailable.

---

Next Steps

• Fail-Secure Behaviors - Complete fail-secure documentation
• Authentication Overview - Authentication methods
• Authorization Overview - RBAC and permissions