Armorer vs Armorer Guard: control plane and runtime boundary

[armorer-labs]

Recent community threads are making the product split clearer.

Armorer and Armorer Guard should not be described as one blob called "agent safety." They solve different parts of the same operational problem.

Armorer: local control plane

Armorer is the layer around agents:

• which agents are installed
• which MCP servers/tools exist locally
• which provider configs and secrets are available
• what jobs are running or stuck
• what sessions happened yesterday
• what changed between turns
• what needs approval
• where recovery should start

This is the "operate five agents without losing the plot" layer.

Armorer Guard: hot-path runtime boundary

Guard is the layer at the action/content boundary:

• inspect model inputs, tool outputs, and proposed actions
• detect suspicious prompt/tool instructions
• classify action risk
• allow, warn, redact, block, or require review
• emit a decision record for later review
• stay fast enough to run inline

This is the "do not let risky content or actions become the next step silently" layer.

Why the split matters

A control plane without hot-path checks can observe bad runs too late.

A hot-path guard without a control plane can block one call but still leave operators without setup state, run history, health, recovery, or cross-agent context.

The useful architecture is:

Armorer
  inventory / setup / jobs / sessions / approvals / recovery

Armorer Guard
  inline checks / policy decisions / redaction / block / require review

Run records
  evidence connecting the two: what was attempted, what was allowed, what was blocked, what changed, and what can be resumed

The next product work should keep this split visible in docs, examples, and UI language. Armorer should feel like local agent operations. Guard should feel like the fast runtime boundary inside that operations layer.