Fail-Secure Architecture

ASCEND follows the principle of fail-secure (also called fail-closed): when errors occur, access is denied rather than granted.

Source: Enterprise Requirement #7 - "If permission check errors, deny access. Never default to allow."

Gateway Integrations

All ASCEND gateway integrations default to DENY on error:

Gateway	Default Behavior	Configuration
Lambda Authorizer	DENY on error	Not configurable
Kong Plugin	DENY on error	Not configurable
Envoy ext_authz	DENY on error	FAIL_OPEN=false (default)

Lambda Authorizer

Source: /ow-ai-backend/lambda-authorizer/src/handler.py:127-231

All error paths return DENY:

Error Condition	Result
Configuration error	Deny
Request mapping error	Deny
ASCEND API timeout	Deny
Authentication error	Deny
Unexpected error	Deny

# From handler.py - All errors return Deny policy
except Exception as e:
    logger.error(f"Authorization check failed: {str(e)}")
    return generate_policy("user", "Deny", event["methodArn"])

Envoy ext_authz

Source: /ow-ai-backend/ascend-envoy-authz/internal/config/config.go:78

FailOpen: getEnvBool("FAIL_OPEN", false), // FAIL SECURE by default

The Envoy sidecar defaults to FailOpen=false, meaning:

• If ASCEND API is unreachable, requests are denied
• If authorization check times out, requests are denied
• If any error occurs, requests are denied

BYOK Key Revocation

When a customer revokes their Customer Managed Key (CMK), ASCEND blocks all operations requiring encryption/decryption.

Source: /ow-ai-backend/services/encryption/byok_service.py:130-155

Scenario	Behavior
CMK access revoked	All encrypted operations blocked
CMK deleted	All encrypted operations blocked
KMS unavailable	All encrypted operations blocked

See BYOK Fail-Secure Behavior for details.

Unregistered Agents

While unregistered agents are not rejected, they receive stricter thresholds as a fail-secure measure:

Threshold	Registered	Unregistered
Auto-approve below	50	30
Max risk threshold	80	70

This ensures unknown agents receive more human oversight by default.

See Unregistered Agent Handling for details.

Why Fail-Secure?

ASCEND is designed for enterprise environments where:

1. Security incidents are costly - A single unauthorized action can cause significant damage
2. Audit requirements are strict - Regulators require demonstrable access controls
3. Availability can be recovered - Temporary denials are preferable to unauthorized access

Compliance: SOC 2 CC6.1, NIST 800-53 AC-3, PCI-DSS 7.1

Monitoring Fail-Secure Events

All fail-secure events are logged to the audit trail:

{
  "event_type": "FAIL_SECURE_TRIGGERED",
  "reason": "ASCEND API unreachable",
  "gateway": "lambda-authorizer",
  "action_taken": "DENY",
  "timestamp": "2025-01-07T10:30:45Z"
}

Monitor these events in:

• Dashboard: Activity Feed > Filter by "fail_secure"
• SIEM: Forward logs via Splunk/Datadog integration
• Alerts: Configure Smart Rules to alert on fail-secure events

Configuration

While ASCEND defaults to fail-secure, some behaviors can be configured:

Setting	Default	Notes
Lambda Authorizer	Deny on error	Not configurable
Envoy FAIL_OPEN	false	Can override to true (not recommended)
API timeout	30s	Configurable per gateway

Warning: Setting FAIL_OPEN=true on Envoy bypasses authorization when errors occur. This is strongly discouraged for production environments.

Next Steps

• Data Encryption - Encryption architecture
• Security Overview - Complete security documentation
• Gateway Integration - Gateway configuration