Hermes Agents

Your agent can hold a wallet. A malicious skill shouldn't be able to drain it.

A fail-closed spend gate for Hermes agents. Cap how much your agent can pay per transaction, how much over any rolling 24 hours, and which rails it can use: your agent checks every spend against a mandate you signed, and anything outside it is denied. One command to install. Open source.

The Problem

The attack isn't breaking in. It's convincing your agent to act.

$175,000
Lost by an agent named Bankrbot in May 2026. No key stolen. No smart-contract bug. No system breached. An attacker granted the agent a permission token, then posted an instruction encoded in Morse code. The agent's language model decoded it, and the agent executed the transfer. As the security firm that analyzed it put it: neither piece did anything wrong by its own logic. The agent was authorized, and it did exactly what it was asked.[1]

That's the threat that's actually emerging: not someone breaking into your agent, but a skill or an instruction convincing your authorized agent to move money as a legitimate, signed transaction. And the skill layer is where it's coming from.

13.4%
of nearly 4,000 community agent skills audited contained critical security issues[2]
100%
of malicious skills in that audit used prompt injection, meaning any defense that lives in the prompt layer is, by construction, the thing the attack defeats
111
skills in a single coordinated campaign targeted crypto wallets directly, out of 341 malicious skills planted in one ecosystem[3]

The next set of losses won't come from stolen API keys. They'll come from perfectly secured agents executing perfectly valid instructions that no one thought to limit.

The Gap

The layer no framework closes yet

Agent frameworks have done real work on operational security. Hermes ships seven layers of it: user authentication, dangerous-command approval, container isolation, credential filtering, context scanning, cross-session isolation, input sanitization.[4] OpenClaw ships its own cascading policy and device pairing.[5]

None of them govern what an authorized agent is allowed to spend. No spend limits, no counterparty restrictions, no per-transaction policy. That's not a Hermes shortcoming: the authority layer is absent across every agent framework.[6] The industry is hardening the host and leaving the authority surface open. That's the layer we build.

The Solution

A spend gate that fails closed

hermes-gate sits between your agent and its wallet. Your agent asks to spend; the gate checks the request against a spend mandate you signed, and allows or denies, fail-closed, meaning anything it can't verify is denied, not waved through.

Install
$npx @observer-protocol/hermes-gate bootstrap generate $npx @observer-protocol/hermes-gate bootstrap provision $npx @observer-protocol/hermes-gate bootstrap verify
Installation
One command
Install, generate your keys, set your limits: your agent's wallet is gated. No account, no domain, no service to phone home to. Verifies offline.
Authority
You're the principal
You anoint your own agent with your own key and sign your own spend mandate. Your agent operates under it and cannot rewrite it: a mandate signed by the agent's own key is rejected.
Enforcement
The key is out of reach
Your agent can't read the wallet key: it lives in a separate user account, so the agent never holds the material that signs. The gate checks every spend it is asked to authorise against your mandate and defaults to deny. It still trusts the agent to route payments through it in the first place — the boundary section below is precise about what that does and does not stop.
Ownership
Open source, Apache-2.0
Self-hosted, yours, no lock-in. The mandate, the key, the gate: all local, all yours. Nothing leaves your machine to authorize a transaction.
View the Repo → Developer Guide
What It Covers

What it protects against, and what's next

We'd rather you know the boundary than discover it.

Live now
Protection from malicious skills
A hostile skill, a prompt injection, a poisoned MCP server trying to make your agent overspend through its normal payment flow: checked against your mandate and denied, fail-closed. This is the threat the community has been burned by, and this closes it. Binding enforcement is live for EVM stablecoins (USDT, USDC); Lightning support is advisory in this version.
Honest boundary
What this tier does and doesn't stop
Today the gate works by your agent calling it before each spend — it's a check a compliant agent runs against a mandate it can't rewrite. What that means: it protects against skills trying to push an honest agent past your limits, but it trusts the agent to route payments through the gate in the first place. An agent that's been compromised deeply enough to bypass the gate, or one that misreports what it's about to do, isn't stopped by this tier. Closing that — making the check unbypassable, enforced in the call path itself — is the enforcement tier below.
Coming next
Unbypassable enforcement
Today's gate is a check your agent calls and trusts itself to route through. The next tier moves enforcement into the call path itself — every payment intercepted and checked against your mandate whether or not the agent cooperates, and against the actual transaction rather than what the agent says it's doing. That closes both the bypass gap and the compromised-or-misreporting-agent gap, and it brings binding Lightning enforcement with it.
Coming next
Counterparty controls
Today the gate caps amount (per-transaction and rolling 24-hour) and restricts which rails your agent can use. Allow/block lists for who it can pay are on the roadmap.
Coming next
A verifiable identity for your agent
A portable record your agent carries: the mandates it was granted, the decisions recorded against them, and the attestations that resulted — independently verifiable by anyone it transacts with, without asking us. The thing that turns a gated wallet into an agent whose authority a counterparty can check.

Help us build it

This is early, and we're building it with the community that needs it. We want your feedback, your feature requests, and the failure modes you're worried about that we haven't named yet. Tell us what would make this safe enough for you to let your agent transact.

Sources
1 Cequence · Encoded Prompt Injection at the Action Layer (Bankr/Grok, $175K). cequence.ai ↗
2 Snyk · ToxicSkills: Malicious AI Agent Skills on ClawHub (534 of 3,984 critical; 100% of malicious used prompt injection). snyk.io ↗
3 Koi Research · ClawHavoc: 341 Malicious Skills (111 targeting crypto wallets). koi.ai ↗
4 Hermes Agent · Security Documentation (seven operational layers; no transaction-level policy). hermes-agent.nousresearch.com ↗
5 getclaw.sh · OpenClaw vs Hermes Security Model Comparison. getclaw.sh ↗
6 Direct reading of Hermes and OpenClaw security documentation, June 2026: neither enforces spend limits, counterparty restrictions, or transaction-level policy.