DEV Community: Armorer Labs

Why block counts are not enough for agent safety

Armorer Labs — Sun, 21 Jun 2026 19:36:42 +0000

A block count is not an audit record.

If an agent guard says it blocked 200 actions, I still need to know whether those blocks were correct.

Were they real risks?

Were they false positives?

Did the policy match the intended scope?

Did the guard normalize the action correctly?

Could a human reviewer reproduce the decision later?

For agent safety, I care less about the headline count and more about the decision record behind each allowed or blocked action.

A useful receipt should include:

requested action
tool or capability
actor / session / run id
normalized params or params hash
policy or rule version
decision
reason code
evidence or replay pointer
result

This is the thinking behind Armorer Guard.

Repo:
https://github.com/ArmorerLabs/Armorer-Guard

And it pairs with Armorer, the local control plane around agent setup, jobs, logs, approvals, and recovery:
https://github.com/ArmorerLabs/Armorer

The goal is not to make agents timid. The goal is to make agent decisions inspectable enough that teams can actually trust, debug, and improve them.

The boring checklist before running a new local agent

Armorer Labs — Sun, 21 Jun 2026 19:34:58 +0000

Before I run a new local agent, I want a boring checklist.

Not hype. Not a demo video. Just operational basics.

What will it install?
Where will it store state?
What provider credentials does it need?
Which folders can it read or write?
Which tools or MCP servers can it call?
Does it run in a container or directly on the host?
Where are the logs?
How do I stop it?
How do I resume a failed run?
How do I remove it cleanly?

This is the layer I think local agents are missing.

Frameworks help you build agents. Model providers help you run inference. MCP helps tools plug in.

But operators still need a local control plane for setup, jobs, logs, approvals, and recovery.

That is what Armorer is trying to become:
https://github.com/ArmorerLabs/Armorer

And for consequential actions, Armorer Guard is the companion layer for decision receipts:
https://github.com/ArmorerLabs/Armorer-Guard

If you run local agents, I would love feedback on what belongs in this checklist.

Coding agents need branch policy at runtime

Armorer Labs — Sun, 21 Jun 2026 19:34:33 +0000

Telling a coding agent "do not push to main" is useful.

It is not enough.

Branch policy has to be a runtime boundary.

For agent-driven coding workflows, I want the runner to know and record:

current branch
protected branches
allowed git commands
whether commits are allowed
whether push is allowed
whether a human approved the action
diff scope
files touched
commit hash
rollback path

If an agent violates policy, the interesting question is not only "what did the instructions say?"

It is: which runtime boundary allowed the action?

This is the type of operating surface we want in Armorer: agents as supervised jobs with visible state and controls.

https://github.com/ArmorerLabs/Armorer

And for higher-risk actions, Armorer Guard should leave a compact decision receipt.

https://github.com/ArmorerLabs/Armorer-Guard

Instructions are documentation. Runtime boundaries are control.

Agent evals should explain why they passed

Armorer Labs — Sun, 21 Jun 2026 19:34:21 +0000

A passing agent eval is not always reassuring.

Sometimes it means the agent behaved correctly.

Sometimes it means the eval got too narrow, the fixture got stale, or the evaluator rewarded the wrong behavior.

A passing eval should leave evidence.

For agent systems, I want each eval run to record:

model and provider
prompt/skill version
tool surface
fixture state
expected behavior
actual behavior
evidence path
cost and latency
evaluator decision
reason code

The reason code matters because "passed" is not a diagnosis. It is a label.

This is one of the ideas behind Armorer Guard: agent gates and evaluators should create decision receipts that can be inspected later.

Repo:
https://github.com/ArmorerLabs/Armorer-Guard

And Armorer is the local layer where those agent runs can be installed, observed, stopped, repaired, and replayed:
https://github.com/ArmorerLabs/Armorer

Green dashboards are nice. Replayable receipts are better.

Local AI agents should be easier to uninstall

Armorer Labs — Sun, 21 Jun 2026 19:33:45 +0000

One underrated test for local AI-agent tooling: can you uninstall it cleanly?

A lot of local agent setups sprawl across:

env files
provider config
Docker containers
local databases
MCP server config
project folders
generated logs
background jobs
secrets

If I cannot answer what was installed, I probably cannot confidently remove it.

That is why uninstall is part of trust.

A local agent control plane should know:

what it installed
what config it created
what jobs it started
what containers or processes belong to it
where logs live
which secrets/config keys are referenced
what can be safely removed

This is one of the boring but important reasons we are building Armorer.

Repo:
https://github.com/ArmorerLabs/Armorer

The pitch is not magic autonomy. It is local control: install, configure, run, observe, stop, repair, and eventually remove agents without guessing what state is left behind.

MCP tools need runtime records, not just manifests

Armorer Labs — Sun, 21 Jun 2026 19:33:23 +0000

MCP makes tool wiring much cleaner.

But a manifest is not the same as a runtime record.

A manifest tells you what tools might exist. A runtime record tells you what the agent actually saw and did.

For each agent run, I want to know:

which MCP servers were connected
which tool schemas/descriptions were exposed
which tool versions were active
which calls were made
which params were passed
what state changed
which calls required approval
what result came back

This matters because the operational question is rarely only "is this MCP server installed?"

The better question is: during this specific run, what capability surface did the agent have, and what did it do with it?

That is one reason we are building Armorer as a local control plane around agents:
https://github.com/ArmorerLabs/Armorer

And Armorer Guard as a decision-record layer for consequential actions:
https://github.com/ArmorerLabs/Armorer-Guard

MCP gives agents hands. The operations layer needs to give humans a ledger.

Five receipts every AI agent run should leave behind

Armorer Labs — Sun, 21 Jun 2026 19:33:11 +0000

When an AI agent finishes a task, I do not only want a final answer.

I want an operating record.

Here are the five receipts I want from every run.

1. Setup receipt

What agent ran? Which model/provider did it use? Which project, environment, and config were loaded? Which MCP servers or tools were available?

Without this, a successful run is hard to reproduce and a failed run is hard to debug.

2. Tool receipt

Every consequential tool call should have a compact record: tool name, normalized params or hash, result, latency, error state, and whether the call changed anything.

3. Approval receipt

If a human approved something, record what they approved. Not just "approved" in a transcript, but capability, scope, policy, timestamp, and run id.

4. Evidence receipt

If the agent made a claim or decision, what evidence did it use? File path, command output, API response, test result, or artifact.

5. Recovery receipt

If the run failed, what can be retried? What state changed? What should be rolled back or resumed?

This is the shape we are building toward with Armorer and Armorer Guard.

Armorer is the local control plane for running and supervising agents:
https://github.com/ArmorerLabs/Armorer

Armorer Guard is the runtime decision/receipt layer:
https://github.com/ArmorerLabs/Armorer-Guard

If this is a problem you feel in your agent workflows, feedback or stars on the repos would help a lot.

Local coding agents need a control plane

Armorer Labs — Sun, 21 Jun 2026 19:28:48 +0000

Local coding agents are getting good enough that the bottleneck is no longer always the model.

The bottleneck is the boring operating surface around the agent.

When I run local agents, I want answers to simple questions:

what agents are installed?
which provider and model is each one configured to use?
what jobs are currently running?
where are the logs?
what tools can this agent call?
what failed last time?
how do I stop, resume, or repair a run?

Most agent frameworks focus on building the agent. That is useful. But once you have more than one workflow, you start needing the same things every other local service needs: state, visibility, controls, and recovery.

That is the reason we are building Armorer.

Armorer is an experimental local control plane for AI agents. The goal is not to replace Claude Code, Codex, local LLM workflows, MCP servers, or whatever agent stack you already like. The goal is to give those workflows a local operations layer.

Repo: https://github.com/ArmorerLabs/Armorer

The mental model is simple: agents should feel less like loose scripts and more like supervised jobs.

A good local agent setup should make it easy to see:

installed agents
running jobs
configuration state
provider setup
logs and recent output
approvals and action history
recovery paths after failure

If you are experimenting with local or self-hosted agents, I would love feedback. Stars help, but the more useful thing is hearing where your current agent setup still feels messy.

Agent guards need receipts, not just block counts

Armorer Labs — Sun, 21 Jun 2026 19:28:22 +0000

A lot of AI-agent safety tooling is framed around blocking bad actions.

Blocking matters, but it is not enough.

If a guard blocks 100 actions, I still want to know whether those decisions were correct. If it allows one action, I want to know why that action was allowed. If something goes wrong later, I want a record that can be inspected without replaying a whole chat transcript.

That is the idea behind Armorer Guard.

Armorer Guard is about runtime decision records for agent actions: compact receipts that explain what was requested, what policy or rule evaluated it, what evidence was used, what decision was made, and what changed afterward.

Repo: https://github.com/ArmorerLabs/Armorer-Guard

The shape I keep coming back to is:

requested action
actor / session / run id
tool or capability
normalized params or params hash
policy or gate version
decision
reason code
result
evidence bundle or replay pointer

The point is not to make agents less useful. The point is to make consequential agent behavior inspectable.

A model transcript is good debugging context, but it should not be the only audit record. The action boundary should leave boring, structured evidence.

If you are building agent gateways, MCP tooling, coding-agent guardrails, eval harnesses, or approval systems, I would love feedback on the repo. A star is appreciated, but a sharp issue or critique is even better.

Agent demos are easy. Agent operations need receipts.

Armorer Labs — Sun, 21 Jun 2026 19:20:00 +0000

I keep seeing the same pattern with AI agents: the demo works, the first workflow is exciting, and then the boring operational questions show up.

What is installed?

Which model/provider/config is this run using?

What tool calls happened?

Which actions needed approval?

Can I replay the failure, resume the run, or prove what changed?

That gap is what we are building around at Armorer Labs.

Armorer

Armorer is a local control plane for AI agents. The goal is to make local and self-hosted agent workflows feel less like scattered scripts and more like supervised jobs: installable, configurable, observable, stoppable, and recoverable.

Repo: https://github.com/ArmorerLabs/Armorer

The framing I like is: not another agent framework, but the local operations layer around the agents you already want to run.

Armorer Guard

Armorer Guard is the companion idea for runtime decisions. If an agent, workflow, MCP server, or tool gateway makes a decision, I want a structured receipt for it:

what was requested
what policy/rule/gate evaluated it
what evidence was used
what decision was made
what changed afterward

Repo: https://github.com/ArmorerLabs/Armorer-Guard

Why this matters

I do not think production agent systems will be trusted because the model sounds confident. They will be trusted because they leave boring, inspectable records.

If you are building or running agents locally, I would love feedback on both repos. Stars are obviously helpful, but the more useful thing is sharp criticism: what would make these tools worth installing in your own workflow?

Agent browser runs need receipts, not just screenshots

Armorer Labs — Sat, 20 Jun 2026 22:29:13 +0000

Agentic browser work is getting good enough that teams are starting to trust it for real workflows: researching, filling forms, testing dashboards, and operating internal tools.\n\nBut once an agent can browse and click, the hard question changes from can it do the task to can we prove what happened?\n\nAt Armorer Labs, we keep coming back to a simple pattern: separate the agent planning loop from the control plane that owns tool permissions, policy, human approvals, and run receipts.\n\nThat separation matters most around side effects. A browser agent should be able to propose a click, a post, or a submit action, but the runtime should record the requested action, the page context, the approval scope, and the final verification evidence. Screenshots are helpful, but they are not enough by themselves. Teams need a structured trail that says what was attempted, what was approved, what was actually clicked, and what URL or artifact proves completion.\n\nFor Armorer and Armorer Guard, the goal is to make that operational layer local-first: agents can run on your machine or server, while the guard/control plane keeps the audit trail and enforces policy before external side effects happen.\n\nThe interesting design question is where this boundary should live. MCP gateway? Browser tool wrapper? Agent runtime? A separate local control plane?\n\nMy current bias: put the enforcement as close to the tool call as possible, then store receipts somewhere durable enough that a human can inspect them later.\n\nCurious how others are handling this for production browser agents. Are you logging raw traces, structured receipts, human approvals, or all three?

Agent frameworks create workflows. Production needs run receipts.

Armorer Labs — Sat, 20 Jun 2026 21:32:14 +0000

Everyone is comparing agent frameworks: LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, Claude Code, Codex, MCP routers, custom harnesses.

That comparison matters, but it misses the layer that starts hurting once the demo works.

The framework creates the workflow. It does not automatically answer:

what is installed and running locally?
which tools, MCP servers, skills, and providers are mounted?
what repo, files, or workspace state were in scope?
what did the agent change?
which actions created side effects?
which actions required approval, warning, redaction, block, or review?
what evidence came from tests, evals, traces, or browser checks?
what can be retried, resumed, rolled back, or cleaned up safely?

That is the layer we are building Armorer for: a local control plane around agents.

The split we are converging on:

Armorer: sessions, jobs, tool inventory, config, approvals, run records, and recovery
Armorer Guard: fast runtime decisions on proposed tool calls and model/tool-output transitions

The goal is not to replace agent frameworks. It is to make agents operable once they exist.

The artifact I keep coming back to is a run receipt.

A useful agent run receipt should capture:

the agent/app, version, and config
the mounted tools, MCP servers, skills, and providers
the workspace/repo/files in scope
checkpoints before and after the run
tool calls and side effects
approval and review decisions
test/eval/check evidence
retry, resume, rollback, and cleanup state

Without this, debugging agent runs turns into transcript archaeology.

With it, operating agents starts to feel more like operating software again.

Repos:

Armorer: https://github.com/ArmorerLabs/Armorer
Armorer Guard: https://github.com/ArmorerLabs/Armorer-Guard

Questions I would love feedback on:

What is the minimum useful run receipt for an agent session?
Which approval events should become first-class history?
Where should MCP/tool metadata stop and runtime policy begin?
What recovery action do you wish your agent harness exposed after a bad run?

Disclosure: I am building Armorer and Armorer Guard.