- Agent identity verified via AgentIdentity.isValidAgent() on all task inputs
- Task signatures verified via MessageSigning before execution
- Self-loop prevention: from !== to on all inter-agent tasks
- Override signatures require physical approval file (.secure/override-approval.json)
- A2A Bearer token required for HTTP inter-agent calls
- PostgreSQL RLS policies enforce per-agent data isolation
- Security enforcement is CODE-based (IronClaw gateway, RLS, MessageSigning) — NOT agent-based
- ZOE is a sandboxed technical assistant (Linux only) — NOT a security agent. Security is code-enforced
only.
## Port & Process Security (MANDATORY)
Every service MUST claim a port before binding to it. Unknown processes on unregistered ports
are treated as security threats.
| Action | Tool |
|--------|------|
| Reserve a new port | node core/port-registry.js suggest "Name" "Description" |
| Check what's on a port | curl
http://localhost:3000/api/ports/enriched |
| Investigate a SUSPECT entry | Check category: 'SUSPECT' in Port Registry UI — process PID is in
description |
| Kill unauthorized listener | taskkill /PID <pid> /F after confirming it's not legitimate |
Port Registry rules:
- Reservations are permanent logs — persist even when a service is idle/down
- PortProcessMonitor auto-registers PM2 services and alerts on squatters
- MPRO Hub Port Registry (localhost:3000) shows SUSPECT entries (red) for unregistered listeners
- Docker containers (category: docker) and external services (category: external) are exempt from squatter
checks
- "Unknown" label = null pm2Name + no description → INVESTIGATE before accepting
If Port Registry UI (localhost:3000) is down:
1. Check PM2: pm2 list — look for MPROHub
2. Restart: pm2 restart MPROHub
3. Check raw registry: node core/port-registry.js list
4. Emergency netstat: netstat -ano | findstr LISTENING (manual SUSPECT scan)
## Web Application Security (web / ecommerce surfaces)
These ADD to the checks above for any public/web/ecommerce surface (WooCommerce, WordPress, the
Node/Postgres storefronts and APIs). They do NOT replace the pre-commit credential scan or the
security-scanning-harness.md 16 FP rules - they extend them.
### LIKE / wildcard-injection escaping (HIGH - applies to our search boxes)
Parameterized queries stop SQL injection, but they do NOT neutralize the `LIKE` wildcards `%` and
`_` inside the parameter VALUE. An attacker who types % or _ (or \) into a search box makes
the pattern match far more than intended - a real scan / data-exposure / algorithmic-DoS vector (a
leading %...% on an unindexed column forces a full scan). So on ANY LIKE/ILIKE built from user
input, escape the pattern metacharacters BEFORE composing the pattern, even though the query is
parameterized. Technique: the standard escapeLikePattern - escape \ FIRST (so you do not
re-escape the escapes you add), then % and _.
Reference technique (generic, from the Exposed ORM escapeLikePattern pattern):
```
// escape order matters: backslash first, then the wildcards
escapeLikePattern(s) = s.replace("\\","\\\\").replace("%","\\%").replace("_","\\_")
```