Skip to main content

12-Layer Security Architecture

ASCEND implements a defense-in-depth security model with 12 distinct security layers. Every layer is designed with fail-secure behavior, meaning any error condition defaults to DENY.

Security Layer Overview

REQUEST → L1 → L2 → L3 → L4 → L5 → L6 → L7 → L8 → L9 → L10 → L11 → L12 → BUSINESS LOGIC
│ │ │ │ │ │ │ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
Rate Prmt Code Gov JWT API RBAC BYOK Aud Val Sec Hdr
Lim Sec Anly Auth Key Log Inp Mgmt

Layer Details

Layer 1: Rate Limiting

Purpose: Protect against DDoS attacks and abuse

AspectDetail
ImplementationRedis-backed token bucket
Fail-SecureDENY on Redis unavailable
ConfigurationPer-user, per-org, per-endpoint

Layer 2: Prompt Security

Purpose: Detect and block prompt injection attacks

AspectDetail
ImplementationPattern matching + ML analysis
Fail-SecureBLOCK on detector failure
DetectionsInjection, jailbreak, data exfiltration

Layer 3: Code Analysis

Purpose: Scan code for security vulnerabilities and secrets

AspectDetail
ImplementationSAST + pattern matching
Fail-SecureBLOCK on analyzer error
DetectionsSecrets, credentials, dangerous patterns

Layer 4: Action Governance

Purpose: Evaluate AI agent actions against policies

AspectDetail
ImplementationPolicy engine + CVSS scoring
Fail-SecureDENY on evaluator error
DecisionsALLOW, DENY, REQUIRE_APPROVAL

Layer 5: JWT Authentication

Purpose: Verify user identity

AspectDetail
ImplementationAWS Cognito + RS256
Fail-SecureDENY on invalid/expired token
FeaturesMFA, token refresh, session management

Layer 6: API Key Validation

Purpose: Authenticate API clients

AspectDetail
ImplementationConstant-time comparison
Fail-SecureDENY on validation failure
FeaturesScoped permissions, expiration

Layer 7: RBAC Authorization

Purpose: Enforce role-based access control

AspectDetail
Implementation6-level role hierarchy
Fail-SecureDENY on permission check failure
RolesPlatform Admin, Enterprise Admin, Org Admin, Policy Admin, Analyst, Viewer

Layer 8: BYOK Encryption

Purpose: Customer-managed encryption keys

AspectDetail
ImplementationAWS KMS envelope encryption
Fail-SecureFAIL on key unavailable
AlgorithmAES-256-GCM

Layer 9: Audit Logging

Purpose: Immutable audit trail

AspectDetail
ImplementationHash-chained WORM logs
Fail-SecureBLOCK if audit write fails
Retention7 years

Layer 10: Input Validation

Purpose: Sanitize and validate all input

AspectDetail
ImplementationPydantic models + sanitization
Fail-SecureREJECT malformed input
CoverageAll API endpoints

Layer 11: Secrets Management

Purpose: Secure storage for sensitive configuration

AspectDetail
ImplementationAWS Secrets Manager
Fail-SecureBLOCK on secrets fetch failure
FeaturesRotation support

Layer 12: Security Headers

Purpose: Browser security protections

AspectDetail
ImplementationFastAPI middleware
HeadersCSP, HSTS, X-Frame-Options, etc.
DefaultRestrictive configuration

Fail-Secure Design

Every security layer implements fail-secure behavior:

# Example: Rate Limiting Layer
async def check_rate_limit(request):
try:
result = await redis.check_limit(request.user_id)
return result
except RedisError:
# FAIL SECURE: Deny on Redis unavailable
logger.error("Redis unavailable, denying request")
return RateLimitResult(allowed=False, reason="Service unavailable")

Multi-Tenant Isolation

Security isolation is enforced at multiple levels:

LevelMechanism
Databaseorganization_id on all tenant tables
AuthenticationPer-organization Cognito user pools
Authorizationorganization_id in JWT claims
APIAll endpoints scoped to organization
EncryptionPer-organization BYOK keys
AuditOrganization-filtered audit logs

Verification

All 12 security layers have been verified through automated testing:

  • 36 fail-secure tests validating DENY behavior on error
  • 29 multi-tenant isolation tests ensuring data separation
  • 16 authentication tests verifying identity management
  • 21 authorization tests confirming access control