SignalGuard

SignalBridge/SignalGuard is a guardrail for agentic action: a safety layer that sits between an LLM's tool-call decisions and real-world hardware execution, catching the failure mode where an agent misresolves an ambiguous instruction into a wide-blast-radius action with no confirmation — before that action actually fires. The demo A Qwen3 model runs fully locally via Qualcomm AI Hub's GenieX on a Snapdragon X Elite NPU. It's connected over MCP (Model Context Protocol) to a small set of real tools exposed by an Arduino UNO Q: get_board_status, flash_heart, and trigger_alert(target, duration_ms). trigger_alert can scope its blast radius from a single built-in LED to the whole LED matrix — exactly the kind of parameter an agent can silently get wrong. How the guardrail works - risk_registry.py assigns each tool a static tier — SAFE or CONFIRM_REQUIRED. Unknown tool names default to CONFIRM_REQUIRED, never SAFE. - guardrail.py runs an async check (reusing the same local GenieX client/model already in the loop) that summarizes the action's blast radius and flags ambiguity — e.g. "trigger the alert" with no scope specified. - client.py wires this in at one call site: SAFE tools execute immediately with zero added friction; everything else prints a blast-radius summary and requires explicit y confirmation. - Any guardrail error — timeout, malformed JSON — fails closed to CONFIRM_REQUIRED. It never silently allows an unverified action. Why it matters As agents get real tool access — robotics, IoT, infrastructure — the risk isn't the model being malicious, it's the model being confidently wrong about scope. SignalGuard demonstrates a lightweight, model-agnostic pattern for catching that: classify blast radius statically, ask the model itself to flag ambiguity, and default to safe-refusal on any uncertainty. It runs entirely offline/on-device (Snapdragon NPU + local Arduino MCP server), so the guardrail has no cloud dependency either.