title: Multi-layered Defense-in-Depth Architecture

content: The system uses a multi-layered defense approach combining explicit intent declaration, real-time risk assessment, automated trust progression, and a Permission & Safeguard Engine (PSE) to balance capability with safety. This addresses the OpenClaw Permission Paradox by granting powerful capabilities incrementally without sacrificing real-time performance.


title: Capability-Based, Context-Aware, Risk-Tiered Permission System

content: Permissions are defined by Tool/Service, Operation Type (CRUD+), Resource Scope (Wildcard/Specific/Contextual), Risk Level (Tier 0-4), Context/Conditions, and Lease Duration. This allows granular control over what the agent can access and do.


title: Hybrid Static vs Dynamic Permission Approach

content: Base permissions are static and role-based, tied to agent maturity levels (L1-L4). Dynamic overlays allow contextual conditions (time, user request, previous actions) to modify permissions in real-time. This provides both stability and flexibility.


title: Constitutional Firewall as Absolute Veto Layer

content: The lowest-level, hardest-coded layer acts as circuit breakers with absolute vetoes: never delete more than N records without human confirmation, never expose PII without consent, never initiate financial transactions over $X without approval, never grant root SSH access.


title: Agent Intent Capability Checksum

content: Agents must propose actions in structured JSON format (e.g., { "tool": "PostgreSQL.delete", "args": {...} }) rather than natural language. The PSE validates this specific structured intent against permissions, preventing prompt injection bypass.


title: Maturity Progression Pathway L1 to L4

content: Agents progress through 4 maturity levels with increasing permissions and trust. Progression is based on quantifiable metrics including Successful Operation Count (SOC), Error Rate (ER), Safety Score (SS), Efficiency Score (ES), and Compliance Score (CS).

steps: L1 (Basic): 100 successful ops in Simulation, permissions: Browser.navigate, Qdrant.search, PostgreSQL.read

steps: L2 (Standard): SOC > 500, ER < 5%, SS = 100%, permissions: Browser.click, Browser.type, PostgreSQL.insert

steps: L3 (Domain Expert): SOC > 1000, ER < 2%, ES > 80%, permissions: Browser.form_submit, PostgreSQL.update, API.send_email

steps: L4 (Full Autonomous): SOC > 2000, ER < 0.5%, ES > 90%, permissions: PostgreSQL.delete, API.process_payment, SSH.execute


title: Pre-execution Validation Decision Flow

content: A 10-step decision flow for every agent action: Intent Capture -> Maturity Check -> Base Permission Check -> Contextual Policy Evaluation -> Risk Tier Assessment -> Constitutional Firewall Check -> Blast Radius Calculation -> Reversibility Enforcement -> Anomaly Detection -> Final Decision (ALLOW/ALLOW_WITH_LOGGING/ESCALATE/AUTO-BLOCK).

steps:
1. Agent Intent Capture (JSON format)
2. Maturity Check
3. Base Permission Check
4. Contextual Policy Evaluation
5. Risk Tier Assessment
6. Constitutional Firewall Check
7. Blast Radius Calculation
8. Reversibility Enforcement
9. Anomaly Detection
10. Final Decision


title: Permission Lease System Flow

content: When an agent needs elevated access, it sends a PermissionEscalationRequest to OpenClaw Orchestrator. PSE evaluates and either auto-approves (fast path for low-risk) or flags for human review (slow path). Leases are automatically revoked at expiration or if abuse is detected.

steps: Agent identifies need for elevated access

steps: Agent sends structured PermissionEscalationRequest with justification

steps: PSE evaluates against maturity, context, history

steps: Auto-Approval (Fast Path) for low-risk, short-duration

steps: Human Approval (Slow Path) for high-risk

steps: Lease automatically revoked at expiration or abuse detection


title: Permission Schema Structure

content: JSON schema defining permissions by tool with risk_tier (0-4), description, and conditions. Example: Browser.upload_file has risk_tier 3 with conditions for whitelist_domain and max_file_size_mb. PostgreSQL.delete has risk_tier 3 with conditions for table_whitelist, require_undo_mechanism, and max_rows_affected.


title: Risk Tier Classification System

content: Tier 0 (Informational): Read-only, low-impact (Browser.navigate, Qdrant.search). Tier 1 (Standard): Create/Update non-critical data (PostgreSQL.insert, API.webhook_trigger). Tier 2 (Sensitive): Create/Update critical data (PostgreSQL.update: customers.billing_info). Tier 3 (Dangerous): Delete operations, financial transactions (PostgreSQL.delete, Stripe.charge). Tier 4 (Critical): System-level changes, code execution (SSH.execute, VPS.reboot).


title: Maturity Level Permission Bundles

content: L1: Browser.navigate, Qdrant.search, PostgreSQL.read: customers.leads. L2: Browser.click, Browser.type, PostgreSQL.insert: leads, API.get_customer_info. L3: Browser.form_submit, PostgreSQL.update: customers, API.send_email, File.read: config/*.json. L4: PostgreSQL.delete: leads_archive, API.process_payment (max_amount: 500), SSH.execute (whitelisted commands only).


title: Minimum Stays and Probationary Periods

content: L1: Minimum 1 day or 100 successful low-risk ops in sandbox/dev. L2: Minimum 3 days with 24h probation. L3: Minimum 7 days with 24h probation. L4: Minimum 14 days with 48h probation. Any significant error during probation leads to immediate demotion.


title: Canary Deployment for High-Risk Operations

content: For L3/L4 agents or new high-risk features, use shadow mode where risky operations execute in a non-production canary environment in parallel. Results are compared - if canary would cause error, real action is blocked/escalated. Part of maturity progression with X canary tests required.


title: Maturity-Based Trust Earning System

content: The system creates a defensible competitive advantage through quantified trust progression. Agents must earn permissions through demonstrated competence (SOC, ER, SS, ES, CS metrics) rather than receiving blanket access. This creates a high barrier to entry for competitors and ensures predictable, safe behavior.


title: Constitutional Firewall as Irreversible Safety Net

content: Hard-coded absolute vetoes (never delete N records without human confirmation, never expose PII without consent, never process financial transactions over $X without approval) provide safety guarantees that are difficult for competitors to replicate without similar architectural investment.


title: Telnyx WebRTC to AIVA Connection

content: Telnyx WebRTC handles Voice Input/Output and connects bidirectionally to AIVA (Agent Core) which uses Claude/Gemini/LLM. This is the primary voice interaction channel for the Genesis system.


title: AIVA to OpenClaw Orchestrator (MCP) Connection

content: AIVA (Agent Core) connects to OpenClaw Orchestrator via MCP (Model Context Protocol). OpenClaw is the Primary Decision Point handling Permission & Safeguard Engine (PSE), Maturity Manager (MM), and Constitutional Firewall.


title: OpenClaw to Tool Service Layer Connection

content: OpenClaw Orchestrator connects to Tool Service Layer which includes Tool-Specific Validators. This layer handles external system calls to Browser, DB, API, and SSH services.


title: Tool Service Layer to External Systems

content: Tool Service Layer connects to: PostgreSQL/Qdrant (Data/Memory), Elestio VPS (Filesystem/SSH), Stripe/GoHighLevel (APIs), AIVA's Mac Mini (SSH/Remote Code). These are the actual resources the agent can access.


title: Human Oversight Console Integration

content: Human Oversight Console connects to the main architecture for dashboards, alerts, and approvals. Agents can escalate to this console for human confirmation on high-risk operations, and the console provides monitoring of all agent activities.


title: Granularity Progression Strategy

content: Start coarse-grained (tool level: Browser, PostgreSQL) at L1, then refine to method level (Browser.click, Browser.type) at L2, then to argument-level conditions (Browser.click: button_id='submit_order') at L3/L4. This matches the maturity progression and prevents over-permissioning early on.


title: Self-Adjustment and Demotion Logic

content: The RLM (Reinforcement Learning from Memory) framework feeds performance data into the Maturity Manager. Anomaly-triggered demotion occurs on sudden spike in error rate or unusual permission requests. Catastrophic incidents cause instant demotion to L1 or quarantined state. Probationary failures cause automatic demotion.


title: Maturity Progression Rubric Criteria

content: L1 advancement: 100 successful operations in Simulation. L2: SOC > 500, ER < 5%, SS = 100%, CS = 100%. L3: SOC > 1000, ER < 2%, SS = 100%, ES > 80%, CS = 100%. L4: SOC > 2000, ER < 0.5%, SS = 100%, ES > 90%, CS = 100%.


title: Permission Dependencies Resolution

content: The PSE implicitly resolves dependencies - if PostgreSQL.update is requested, PostgreSQL.read for the target resource is implicitly assumed/granted for the agent's internal reasoning, but read is not separately permissioned unless explicitly stated. The system tracks effective permissions.