Feature: Cortex Agent Node Phase 3 - Sandbox & Capability Guardrails #7

Goal: Implement restrictive execution environments and user consent prompts.\n\n### Tasks:\n- [ ] Implement Command Whitelisting Policy Engine\n- [ ] Add Interactive Consent Prompt for 'Sensitive' commands\n- [ ] Enforce Directory Isolation (Workspace Root Jail)\n- [ ] Report Manifest-based Capabilities during Handshake

Status: In Progress\nImplementing the Sandbox Policy Engine at the Agent Node layer.

🔄 Update: Expanded Sandbox Policy Logic\n\nBased on architectural feedback, I have optimized the Sandbox Engine to support Multiple Governance Modes:\n\n STRICT Mode (Whitelist): Block all except explicitly allowed. Best for remote/untrusted deployments.\n PERMISSIVE Mode (Blacklist): Allow all except explicitly denied. Best for local power users.\n\n#### 🛡️ Cross-Mode Enforcements\nRegardless of the mode, the following are ALWAYS BLOCKED for core security:\n1. Sudo/Privilege Elevation: Prevents un-audited root access.\n2. Path Traversal: Blocking .. ensures the agent stays within the defined workspace jail.\n\n#### 🧪 Verification (PERMISSIVE Mode)\n df -h (Non-whitelisted): ✅ ALLOWED\n sudo apt update: ⛔ BLOCKED (Explicit Deny)\n cat ../.env: ⛔ *BLOCKED (Traversal Path Guard)

⚡ Update: Binary Data & File Support Complete\n\nI have extended the gRPC protocol and the Agent Node to support returning Binary Artifacts.\n\n#### 📁 Capabilities Added\n Multi-Artifcat Returns: The now includes a field.\n Binary Integrity: Files (Images, PDF, Binary logs) are returned as raw byte streams, suitable for browser automation screenshots.\n Scalability: The architecture now supports returning multiple files for a single task (e.g., a recording + a test log).\n\n#### 🧪 Verification (Task-006-BINARY)\n Command: screenshot\n Result: ✅ SUCCESS\n Payload: Received screenshot_001.png (1040 bytes) via the gRPC stream.\n\nThis completes the data plane for Phase 3 and Phase 4.

🏢 Distributed Architecture: Manager/Worker Pattern Complete\n\nI have evolved the Agent Node into the requested 'Company' structure.\n\n#### 🛡️ Architectural Hierarchy\n1. Company Boss (Server): Orchestrates distributed work through a Global Work Pool (Claim-based pulling).\n2. Dept Manager (Node): A single orchestrator per machine that handles mTLS, JWT verification, and Local Worker threads.\n3. Workers (Sub-threads): Isolated execution units for tasks (Shell, Binary, Browser).\n\n#### 🤝 Cross-Node Collaboration\n- Nodes now perform Work Discovery to see shared tasks.\n- A Task Claiming Mechanism ensures items in a pool are only processed once by the first available manager.\n- Department Health Monitoring: Heartbeats now include CPU, Memory, and Worker utilization (Current/Capacity).\n\n#### 🧪 Proof of Concept (Verified)\n- Node discovered shared-001, claimed it, and executed via a sub-worker.\n- Parallel status reports verified the node's 'Healthy/Busy' state based on thread occupancy.

🛡️ Secure Dynamic Configuration & Multi-Channel gRPC Complete\n\nI have evolved the communication layer to be Server-Authoritative and Modular.\n\n#### 📡 Multi-Channel Architecture\nRather than a single catch-all stream, the node and server now communicate over three dedicated gRPC channels:\n1. Config Channel (Unary): Used for the initial handshake and Dynamic Policy Sync. The node NO LONGER has hardcoded permissions; it fetches them from the server during registration.\n2. Health Channel (Bidirectional Stream): A dedicated ping-pong pipe for heartbeats. This ensures status reporting is never blocked by heavy task execution.\n3. Task Channel (Bidirectional Stream): For work discovery, claiming, and reporting results.\n\n#### 🎯 Dynamic Sandbox Enforcement\n- Permissions are now centrally managed on the Boss (Server).\n- Nodes fetch their ALLOWED/DENIED list during handshake.\n- Verified: A trial task with unauthorized command uptime was correctly rejected by the node using the policy it had just received from the server.