Policy Configuration
Define governance policies with full CRUD and inline testing. Control what runs immediately and what requires human approval.
QuoxCORE enforces safety policies at two layers: a server-side Policy Gate that screens every request before execution, and a browser-side Safety Context that provides kill switch, dry-run mode, and DEFCON-based operation approval.
Policy Gate (Server-Side)
The Policy Gate (policyGate.js) is the L3 layer in the AOCL stack. Every query passes through three checks in sequence. If any check fails, the request is rejected before it reaches an agent.
1. Rate Limiting
In-memory token-bucket rate limiting with hardcoded thresholds:
| Window | Limit |
|---|---|
| Per minute | 30 queries |
| Per hour | 300 queries |
Buckets reset automatically when their window expires. When a limit is exceeded, the response includes resetIn (seconds until the bucket resets). Rate limit state is in-memory and resets on server restart.
2. Content Safety
Regex-based screening that blocks or flags queries matching dangerous patterns.
Blocked patterns (request is rejected):
| Category | Pattern |
|---|---|
| SQL injection | DROP TABLE, DELETE FROM, TRUNCATE |
| Dangerous commands | rm -rf, sudo rm, format c: |
| Credential exposure | password:, secret=, api_key= |
Warning patterns (request proceeds, but flagged in response):
| Category | Pattern |
|---|---|
| Elevated privilege | sudo, chmod 777, eval() |
| Production destructive | production + delete/remove/drop |
Blocked patterns cause an immediate rejection. Warning patterns are appended to the response's warnings array but do not prevent execution.
3. Agent Scope Authorization
Each agent has a list of allowed topic scopes. When a query mentions a topic outside the current agent's scope, a warning is emitted (but the request is not blocked).
Scope assignments:
| Agent | Allowed Scopes |
|---|---|
| quox (orchestrator) | infrastructure, monitoring, chat, memory, files, security, network, deployment |
| sentinel | security, monitoring, audit, infrastructure, network |
| cipher | network, connectivity, dns, infrastructure |
| nova | deployment, containers, orchestration, infrastructure, monitoring |
| atlas | infrastructure, deployment, monitoring |
| metrics | monitoring, infrastructure |
| beacon | monitoring, infrastructure, network |
| archivist | files, documents, search, memory |
Agents not listed fall back to the orchestrator's full scope set. Scope detection uses keyword matching against the query text (e.g., the security scope triggers on words like "firewall", "vulnerability", "intrusion").
Error Handling
The Policy Gate fails closed by default. If an error occurs during any check, the request is blocked and a security alert is emitted. This behavior can be overridden with the VITE_POLICY_GATE_FAIL_OPEN=true environment variable, but this is not recommended for production.
AOCL Integration
All policy decisions are recorded as L3 layer events in the AEE envelope trail when a correlation ID is present. Events include L3:start, L3:reject (with reason and failing check), and L3:complete (with check count and duration).
Safety Context (Browser-Side)
The Safety Context (SafetyContext.jsx) provides React components with operation-level safety controls. It manages four mechanisms:
Kill Switch
A global halt that blocks all operations immediately.
- Activate:
Ctrl+Shift+Kor programmatically viaactivateKillSwitch() - Deactivate: Requires entering the correct deactivation code (a
SAFE-XXXXcode generated at activation time) - Persistence: Kill switch state is persisted in
localStorageand survives page reloads - Effect: When active,
requestOperation()returns{ allowed: false }for every request regardless of DEFCON level
Dry-Run Mode
When enabled, all operations are logged but never executed. The response includes dryRun: true and the DEFCON level that would have applied.
DEFCON Levels
Each operation is classified into a DEFCON level based on regex pattern matching against the query text and a target host count:
| Level | Name | Approval | Triggers |
|---|---|---|---|
| 5 | GREEN | None | Read-only queries, safe operations |
| 4 | BLUE | Log only | Single-host status checks, informational queries on many hosts |
| 3 | AMBER | Human confirm | Service restarts, config changes, multi-host (>5) non-read operations |
| 2 | ORANGE | Two-step verify | Production operations, mass operations (>20 targets) |
| 1 | RED | Authorization code | Destructive operations (rm -rf, qm destroy, pct destroy, mkfs, VM/container deletion) |
GREEN and BLUE operations proceed automatically. AMBER, ORANGE, and RED operations return requiresApproval: true and must be explicitly confirmed by the user before execution.
The DEFCON classifier also integrates with an intent detector (detectIntent) to distinguish informational queries from action requests. Asking "what VMs are running?" is GREEN even if it mentions infrastructure keywords, while "destroy the VM" is RED.
Health-Aware DEFCON
The Safety Context subscribes to the Health Context. When services go down, DEFCON automatically escalates:
- Any service down and current level is GREEN/BLUE --> raises to AMBER
- Any service degraded and current level is GREEN --> raises to BLUE
- All services recovered --> returns to GREEN
Future Plans
The current policy engine uses hardcoded rules in JavaScript. A future release will introduce declarative policy configuration supporting:
- User-defined allow/deny rules
- Time-based and host-scoped policies
- Multi-approver workflows
- External notification channels
See Also
- DEFCON Levels - Detailed DEFCON level documentation
- Safety Overview - Safety design principles