Edge Connector
Local AI agent security enforcement for Linux edge devices, with optional Fleet escalation over MQTT.
The Edge Connector is a C-language enforcement engine for Linux edge devices. It evaluates tool calls locally with policy and content inspection, then can escalate undecided actions to a DefenseClaw Fleet gateway over MQTT. Measure size, memory use, and latency for your own target and build profile; TLS libraries and compiler flags change those values.
The Edge Connector is designed for IoT and edge devices — Raspberry Pi, Jetson, industrial SBCs, and similar Linux platforms. For desktop AI coding agents (Claude Code, Codex, Cursor, etc.), use the standard connectors.
Why a separate engine?
Desktop connectors intercept tool calls via hooks or proxy and delegate evaluation to the Go gateway sidecar. That architecture assumes reliable networking, plentiful memory, and a human at the keyboard. Edge devices have none of those:
| Constraint | Desktop | Edge |
|---|---|---|
| Binary size | Go gateway plus Python CLI | C engine plus any linked TLS libraries; measure the target build |
| Memory | Desktop resources | Profile-dependent; measure under the expected workload |
| Latency | Local gateway call | Local C evaluation; benchmark on the target hardware |
| Network | Always-on | Intermittent or absent |
| Consequences of failure | Bad file on disk | Physical world action |
The Edge Connector runs local guards before its verdict cache and can request a verdict from the Fleet gateway over MQTT when local policy cannot decide. The current gateway evaluates those requests by tool hash; its default result for an unknown hash is BLOCK.
What it does
Content scanning
Detects secrets, PII, credentials, data exfiltration, prompt injection, and dangerous commands in tool arguments and LLM responses.
SSRF validation
Blocks requests to private/internal IP ranges and cloud metadata endpoints before they reach the network.
Sequence correlation
FSM-based detection of dangerous multi-step capability patterns (e.g., net_fetch → exec_shell).
Rate limiting
Built-in token buckets for tool calls, network requests, and physical actuations. OTA cannot change their rates in this release.
Verdict caching
In-memory Fleet verdict cache keyed by tool hash; local guards still run before each cache lookup.
Fleet escalation
Sends undecided requests via MQTT 3.1.1 to the Fleet gateway's verdict cache; unknown tool hashes block by default.
Evaluation path
The engine runs these seven checkpoints in order, stopping on a local BLOCK verdict. A cache hit avoids a new Fleet request while the earlier local guards still run. The C engine has no local hash deny-list lookup or policy YAML hash feed.
1. Input validation → Reject malformed requests at the IPC boundary
2. Rate limiting → Three token buckets (tools, network, actuations)
3. Content scanning → Secrets, PII, credentials, exfil, injection, commands
4. Destination filter → Public-IP allowlist + SSRF validation
5. Sequence correlation → Multi-step pattern detection via DFA
6. Verdict cache → Tool-hash lookup with monotonic TTL
7. Fleet escalation → MQTT 3.1.1 on a cache miss; gateway verdict uses tool hashBuild profiles
| Profile | Features | Use case |
|---|---|---|
MINIMAL | No MQTT | Constrained builds, without Fleet connection |
STANDARD | MQTT and content inspection | Raspberry Pi, Jetson, SBCs |
EDGE | MQTT, content inspection, bloom filter | Edge gateways |
See the install guide for production TLS, signing keys, and the Linux service unit.