u/Conscious_Chapter_93

Agent security for MCP-based setups goes beyond chatbot safety. When agents call tools, the attack surface expands to include prompt injection via context, credential forwarding via tool params, malicious skill chains, and runtime policy bypass.

Built a reference covering OpenClaw/Claw-style agent risks, hardening controls, evidence, and timelines. Looking for feedback from MCP operators and security folks:

• What risks are we not tracking?
• What hardening controls are most critical for MCP-based agents?
• What sources/events are we missing?

armorerlabs.com/threat-intel

For people running local agents via MCP — how are you thinking about threat modeling for tool access?

Traditional security assumes a human is in the loop. Agents break that assumption by taking actions autonomously. Looking to understand:

• What risks are you actually tracking?
• What hardening controls have you implemented?
• What's missing from current threat intel on agent security?

Built a reference covering OpenClaw/Claw agent risks, hardening options, and evidence. Looking for technical feedback on what's missing or oversimplified.

armorerlabs.com/threat-intel

I built Armorer Guard, a local Rust security layer for AI agents and MCP tool calls.

The newest release adds an MCP proxy:

armorer-guard mcp-proxy -- npx your-mcp-server

It sits between an agent and a stdio MCP server, gates tools/call arguments, and blocks prompt injection, credential leakage, exfiltration, and dangerous actions before the tool executes. It returns structured JSON reasons and makes no scanner network calls.

Live demo: https://huggingface.co/spaces/armorer-labs/armorer-guard-demo

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

Demo GIF: https://github.com/ArmorerLabs/Armorer-Guard/blob/main/docs/assets/armorer-guard-v023-mcp-demo.gif

I am looking for feedback from people building MCP servers and agents: where would you put this check, and what false positives would make it unusable?

Mobile PWA for controlling coding agents from phone — QR pairing, remote approvals, push notifications. Built with Rust/Tauri for performance. Star it if you want early access to the source release.

We just shipped a Rust-native learning overlay for Armorer Guard.

The idea: a scanner should be able to adapt from local feedback immediately, without silently mutating model weights or uploading prompts to a cloud service.

What changed:

• feedback-record / feedback-export / feedback-stats CLI modes
• stable scan IDs so teams can review findings without storing raw prompts
• local allow / block / review exemplars stored outside the repo
• no suppression for credentials, dangerous tool calls, or credential-disclosure policy reasons
• reviewed export path for later offline retraining

The claim we are trying to make precise is: live local learning, no silent cloud upload, no poisoning-by-default.

I am curious how people here would wire this into agent runtimes. Before the tool call? Around MCP/tool results? As a CI gate for agent evals?

A pattern keeps showing up in agent threads here: the first agent is not the hard part. The hard part starts when you have several agents running repeatedly, with tools, state, approvals, retries, and partial failures.

The questions become less glamorous:

• Which agent ran this task?
• Which tools or MCP servers were available?
• What did it change?
• Did it stop, fail, or wait for approval?
• Which verifier/test phase passed it?
• Can I replay or compare this run against the last good one?
• What do I do when context runs out mid-task?

I think a lot of agent reliability work is really agent operations work. Frameworks help build the agent, but teams still need an operating surface around runs, sessions, tools, approvals, and recovery.

Curious how others here are handling this today. Are you using LangSmith-style traces, custom dashboards, Temporal/workflows, git worktrees, spreadsheets, or just logs and vibes?

I added a browser-playable demo for Armorer Guard, a Rust-native local scanner for AI-agent prompt injection, exfiltration, sensitive-data requests, and risky tool-call text.

Demo: https://huggingface.co/spaces/armorer-labs/armorer-guard-demo

Screenshot: https://raw.githubusercontent.com/ArmorerLabs/Armorer-Guard/main/docs/assets/armorer-guard-demo-sensitive-data.png

The demo exposes the semantic classifier. The full CLI/runtime adds credential redaction, structured JSON context, and policy/tool-call lanes. It is meant to run where text becomes action: before tool execution, outbound sends, logging, or memory writes.

The runtime is Rust-first; Python support is a thin wrapper around the same binary.

Armorer Guard is a source-available GitHub project for local AI-agent runtime safety. It scans prompts, model outputs, retrieved text, and tool-call arguments for prompt injection, credential disclosure, exfiltration attempts, and dangerous tool calls.

It is Rust-native, runs locally with no scanner network calls, returns structured JSON, includes credential redaction, and has a Python wrapper for Python agent stacks.

Current selected classifier metrics in the README: about 0.0247 ms average classifier latency, 0.9833 macro F1, and 1.0 micro recall. Model artifacts are on Hugging Face: https://huggingface.co/armorer-labs/armorer-guard-semantic-classifier

Would love feedback on the CLI/API contract and packaging.