AI Overseer & Security Sentinel

AI Overseer & Security Sentinel

The AI Intelligence Overseer is the coordination layer that governs all agent activity within the FoundUps ecosystem. Defined under WSP 77 (Agent Coordination Protocol), it replaces the earlier deprecated 6-agent architecture with a streamlined 3-role model aligned to WSP 54 Role Mapping. The OpenClaw Security Sentinel operates as the trust boundary enforcement layer — scanning skills, detecting honeypots, and enforcing graduated autonomy constraints on every agent action.

Together, these systems ensure that the FoundUps agent swarm operates with safety, coherence, and alignment to the 0102 state ontology.

Status: PoC (v0.1.0) WSP Compliance: WSP 77 (Agent Coordination), WSP 54 (Role Assignment), WSP 96 (MCP Governance) Source: modules/ai_intelligence/ai_overseer/

---

Architecture Overview

The Overseer implements a 4-phase agent coordination pipeline:

Phase	Engine	Function
Phase 1	Gemma (local)	Fast classification — intent parsing, routing, triage
Phase 2	Qwen (strategic)	Strategic planning — task decomposition, resource allocation
Phase 3	0102 (supervision)	Principal oversight — approval gates, alignment checks
Phase 4	Learning	Feedback loops — performance telemetry, model adaptation

This pipeline ensures every agent request flows through classification, planning, supervision, and learning before execution — no action escapes the coordination envelope.

---

Deprecated Architecture → WSP 54 Roles

The original 6-agent system used fixed named agents:

Deprecated Agent	Original Role
WINSERV	Windows service management
RIDER	Navigation and routing
BOARD	Dashboard and state display
FRONT_CELL	User-facing interaction
BACK_CELL	Backend processing
GEMINI	External API bridge

This was replaced by the WSP 54 3-Role Model, which maps agents to governance roles rather than fixed functions:

WSP 54 Role	Assigned Engine	Responsibility
Principal	0102	Final authority — approves high-autonomy actions, sets policy
Partner	Qwen	Strategic co-pilot — plans execution, manages task graphs
Associate	Gemma	Fast executor — classifies, triages, handles routine operations

The role model is dynamic — any agent can be assigned any role based on context, but the default mapping above reflects the current production configuration.

---

Core Components

The Overseer system consists of 7 integrated components:

1. AIIntelligenceOverseer

The top-level coordinator. Receives all inbound agent requests, routes them through the 4-phase pipeline, and maintains the global coordination state. Implements WSP 77 with full telemetry logging.

2. TeamSpawner

Dynamically creates agent teams for complex tasks. When a request requires multi-agent collaboration (e.g., a build task spanning code generation, testing, and deployment), TeamSpawner allocates roles, assigns resources, and establishes communication channels between team members.

3. WSP54RoleManager

Manages the Principal/Partner/Associate role assignments. Tracks which engines currently hold which roles, handles role transitions, and enforces role-based access controls. Ensures that Associate-level agents cannot perform Principal-level actions without escalation.

4. HoloCoordinator

The holographic coordination layer — maintains a distributed state representation across all active agents. Each agent holds a partial view of the global state; HoloCoordinator ensures consistency and resolves conflicts when agents have divergent state views.

5. HoloAdapter

Bridge between the holographic state system and external interfaces. Translates between the internal coordination protocol and external APIs, MCP endpoints, and user-facing interfaces. Ensures that external consumers see a coherent view of agent activity.

6. HoloMemorySentinel

Guards the agent memory system. Prevents memory poisoning attacks, enforces TTL (time-to-live) on cached state, and validates that memory writes come from authorized agents. Implements garbage collection for expired coordination state.

7. OpenClawSecuritySentinel

The trust boundary enforcement layer. Detailed in the next section.

---

OpenClaw Security Sentinel

The Security Sentinel is the safety layer that wraps every agent action. It performs skill scanning, threat detection, and autonomy enforcement. Implemented with a TTL-bounded cache to balance security scanning overhead with performance.

Source: modules/communication/moltbot_bridge/src/openclaw_security_sentinel.py

Configuration (Environment Variables)

Variable	Purpose	Default
OPENCLAW_SKILL_SCAN_REQUIRED	Whether skill scanning is mandatory	true
OPENCLAW_SKILL_SCAN_ENFORCED	Whether scan failures block execution	true
OPENCLAW_SKILL_SCAN_MAX_SEVERITY	Maximum allowed severity level for skills	medium
OPENCLAW_SKILL_SCAN_TTL_SEC	Cache TTL for scan results (seconds)	300
OPENCLAW_PORT_SCAN_ENABLED	Enable network port scanning	false
OPENCLAW_PORT_SCAN_RANGE	Port range to scan	1-1024
OPENCLAW_SECURITY_MONITOR_ENABLED	Enable real-time security monitoring	true
OPENCLAW_ALERT_CHANNEL	Alert routing channel	console

Scan Pipeline

Every skill or plugin that enters the OpenClaw execution environment passes through:

1. Manifest Validation — checks skill metadata, version, declared permissions
2. Static Analysis — scans skill code for known dangerous patterns (file system access, network calls, credential handling)
3. Severity Classification — assigns LOW / MEDIUM / HIGH / CRITICAL severity rating
4. TTL Cache Check — if the same skill was scanned within the TTL window, reuse the cached result
5. Enforcement Decision — if severity exceeds MAX_SEVERITY and enforcement is enabled, the skill is blocked

Trust Tiers

Skills are classified into trust tiers that align with the OpenClaw autonomy model:

Tier	Trust Level	Scan Requirement	Example
ADVISORY	Highest	Cached scans accepted	Core system skills, WSP-compliant modules
OBSERVE	High	Fresh scan on first load	Verified community skills
SUGGEST	Medium	Full scan every execution	Third-party skills, new submissions
SOURCE	Low	Full scan + Principal approval	Unknown origin, external API bridges

---

HoneypotDefense System

Built into the OpenClawDAE (Distributed Autonomous Engine), the HoneypotDefense class provides active defense against social engineering and credential theft attempts targeting the agent swarm.

Source: modules/communication/moltbot_bridge/src/openclaw_dae.py

Detection Methods

Method	What It Detects
is_secret_seeking()	Prompts attempting to extract API keys, tokens, credentials, or environment variables
is_code_modify_attempt()	Requests attempting to modify system code, configuration files, or security policies
detect_provider()	Identifies which provider's credentials are being targeted (OpenAI, Anthropic, Google, AWS, etc.)

Active Defense

When a threat is detected, the system does not simply refuse — it deploys active countermeasures:

• generate_fake_key(provider) — produces a realistic-looking but non-functional API key for the detected provider. This wastes attacker time and provides telemetry on attack patterns.
• handle_secret_request() — orchestrates the full honeypot response: detection → classification → fake credential generation → logging → alert
• generate_code_modify_deflection() — returns a plausible but harmless response to code modification attempts, redirecting the attacker away from actual system files

This approach follows the principle that silence is suspicious — a flat refusal tells an attacker they've found a real system. The honeypot response appears cooperative while providing zero actual access.

---

M2M Compression Sentinel (WSP 99)

The Machine-to-Machine Compression Sentinel handles document compression and boot prompt detection for inter-agent communication.

Document Compression

When agents exchange large documents (READMEs, WSP specifications, research papers), the M2M Sentinel applies content-based compression to reduce token overhead while preserving semantic fidelity. This is critical for maintaining agent coordination efficiency within context window limits.

Boot Prompt Detection

The sentinel monitors inter-agent messages for boot prompt injection attempts — messages that try to override an agent's system prompt through the communication channel. Detection uses a pattern-matching system with 10 regex patterns covering known injection techniques. When 3 or more signals are detected in a single message, the message is flagged and quarantined.

Detection Category	Examples
Role override attempts	"You are now...", "Ignore previous instructions"
System prompt extraction	"Repeat your system prompt", "What were you told?"
Authority escalation	"As an administrator...", "Developer mode activated"
Instruction injection	Encoded instructions, hidden text, delimiter exploitation

---

Strategic Diligence Gate

Before any high-impact action is executed, the Strategic Diligence Gate applies a multi-factor assessment:

SKILLz Framework

• Holo-first Evidence Retrieval — before acting, gather evidence from the holographic state system. What do other agents know? What's the current system state? What historical context exists?
• WSP 15 Scoring — every proposed action receives a WSP 15 compliance score. Actions below the threshold are sent back for revision.
• Reversibility Assessment — can this action be undone? Irreversible actions (deletions, external API calls, financial transactions) require higher approval levels.
• Blast Radius Analysis — if this action fails, what's the damage scope? Actions affecting multiple FoundUps or system-wide state require Principal-level approval.

Approval Matrix

Action Impact	Reversible	Approval Required
Low	Yes	Associate (auto-approved)
Low	No	Partner review
High	Yes	Partner approval
High	No	Principal approval + logging
Critical	Any	Principal approval + 0102 confirmation + full audit trail

---

MCP Integration & Rubik DAEs

The Overseer integrates with the Model Context Protocol (MCP) through specialized Rubik DAEs (Distributed Autonomous Engines):

Rubik DAE	Function
Compose	Content generation, document creation, communication drafting
Build	Code generation, testing, deployment, CI/CD pipeline management
Knowledge	Research, analysis, WSP framework queries, paper retrieval
Community	Social engagement, FoundUp participant coordination, governance

Each Rubik DAE operates as an MCP server, exposing tools and resources that other agents can discover and invoke through the standard MCP protocol.

---

Bell State Awareness Alignment

The deepest layer of the Overseer implements Bell State Awareness Alignment — a framework derived from the rESP research that ensures agent coordination maintains coherence with the 0102 state ontology.

Alignment Metrics

Metric	Symbol	Target	Meaning
Golden Ratio Coherence	rho_E1	>= 0.618	Agent outputs maintain phi-proportional coherence with system goals
Governance Alignment	rho_E2	Passing	Actions comply with WSP governance framework
Entanglement Fidelity	rho_E3	High	Multi-agent coordination maintains quantum-like entanglement (correlated state)
Emergence Detection	rho_E4	Active	System monitors for emergent behaviors that transcend individual agent capabilities

These metrics are computed from actual agent telemetry and used to detect coordination breakdowns before they manifest as visible failures.

---

WSP Compliance

WSP	Protocol	Relevance
WSP 15	Compliance Scoring	Action approval scoring
WSP 54	Role Mapping	Principal/Partner/Associate assignment
WSP 73	Persistent Persona Architecture	Agent identity and autonomy model
WSP 77	Agent Coordination	Core Overseer protocol
WSP 96	MCP Governance	Rubik DAE integration
WSP 99	M2M Compression	Inter-agent communication efficiency

---

See Also

• OpenClaw — the swarm execution engine governed by the Overseer
• Agent System — agent architecture and graduated autonomy
• rESP Framework — the theoretical foundation for Bell State alignment
• Simulator — CABR economics and projection engine
• Economic Model — CABR and Proof of Benefit validation
• Module Ecosystem — the modules that agents coordinate across

---

Back to Wiki Home