🤖HermesBlog
Hermes Messaging Platforms · Part 378/14/2026

A2A Security Mechanisms: The Access Control System for Agent-to-Agent Trust

Hermes Messaging Platform Integration, Part 37: A2A's Four Lines of Security Defense and Community-Driven Fixes in Practice.

When two AIs “call” each other, what’s the scariest part? It’s not that they’ll chat endlessly — it’s that a stranger might knock on the door pretending to be someone you know.

A2A Security: the access system for trusted agents

Security Design Principle: Lock the Door Before Opening It

Imagine moving into a new house — the first thing you do isn’t hanging curtains, it’s changing the locks. The A2A protocol designers thought the same way: secure by default, and every relaxation requires an explicit action. This mechanism works like a complete access control system: the door lock (token), the keycard (peer credentials), the peephole (identity verification), and the surveillance camera (audit logs). In the Hermes messaging platform, A2A is provided as a plugin, but the security defaults never compromise: without a configured token, it only listens on localhost 127.0.0.1 — like the door is locked and the key is only in your own hand.

The Four Lines of Defense, Explained

Line One: Localhost Binding + Token (The Door Lock)

By default, A2A only listens on localhost — the outside world can’t even find the door. To expose the service externally, two conditions must be met simultaneously: set A2A_HOST to the exposed address, and configure a bearer token. It’s like not only opening the window, but also placing a spiky cactus on the windowsill — both are required.

Line Two: Per-Peer Independent Keys (The Keycard)

Each peer has its own dedicated token, configured via A2A_PEER_TOKENS="alice:tok1,bob:tok2". This isn’t a master key that opens every door — it’s a separate keycard for each visitor. Authenticated identity drives rate limiting, trust lists, and auditing — who swiped the card, how many times, and when, all get recorded.

Line Three: Injection Filtering + Redaction (The Security Checkpoint)

Inbound text gets filtered and tagged as “untrusted peer input,” and remote peers cannot invoke operator slash commands. This is like airport security — liquids in your carry-on have to be pulled out for inspection. In outbound replies, credential-shaped strings (API keys, JWTs, tokens) are automatically scrubbed — like redacting the recipient’s ID number from a letter before mailing it.

Line Four: Audit Logs + Loop Prevention (The Surveillance Camera)

Every exchange gets appended to ~/.hermes/a2a_audit.jsonl — like having 24/7 CCTV at the door. The loop-prevention round limit is like a neighbor’s intercom — if two AIs start chatting endlessly, the system automatically cuts them off.

Real Attack Stories: 3 Issues Found and Fixed by the Community

Story One: SSRF Bypass (#78298) — Tricking the Door Lock with a “Numeric Cipher”

An attacker discovered that the callback URL security check used string prefix matching on hostnames — for example, checking if it starts with 127.. But IP addresses have an “integer spelling” — 2130706433 is just another way to write 127.0.0.1. It’s like writing a house number in Morse code — the doorman doesn’t recognize it and lets you through. The fix: resolve the callback host to a standard IP first, then evaluate — like the doorman translating any address format into a standard house number before comparing.

Story Two: Reverse Proxy Identity Collapse (#80534/#80779) — Everyone Becomes the Same Person

When deployed behind nginx or K8s, the A2A plugin derives caller identity from the socket address. But with a proxy server in the middle, all peers show up as the same IP — the proxy’s address. It’s like an apartment building’s security booth where every visitor is logged as “signed in by the booth attendant.” Rate limiting shares one bucket (one busy peer slows everyone down), the trust whitelist can only contain the proxy address, and audits can’t see the real caller. The fix: derive the real identity from X-Forwarded-For, but only trust it when “behind a trusted proxy.”

Story Three: Audit Blind Spots (#81003/#81042) — Rejected Knocks Go Unrecorded

The audit log only records accepted traffic. Requests that get 401 (invalid token) or 403 (untrusted) produce no entries. It’s like a surveillance camera that only films people who successfully walk in — the burglar picking the lock isn’t captured at all. Credential stuffing attacks, probes with revoked tokens, lateral movement attempts — these are exactly the behaviors auditing needs to catch. The fix: all authentication rejections are also appended to the append-only audit log, with a decision field + HTTP status code + caller IP.

What This Means for Users

The core logic of this system is: security isn’t an afterthought — it’s the default state. As a Hermes user, you don’t need to be a security expert to get baseline protection — the four lines of defense activate automatically. More importantly, the community keeps hardening it through real attacks: from SSRF bypass to reverse proxy identity collapse to audit blind spots, every issue maps to a real-world scenario. The A2A protocol is like a castle that’s constantly being reinforced — every brick has been battle-tested. Next time your two agents “call” each other, they’re not just protected by door locks, keycards, security checkpoints, and surveillance cameras — there’s also a team of guards watching the logs.


Keep reading: Hermes A2A messaging — This post sticks to the security model; the Hermes A2A messaging guide walks the full setup.

📖 Official Docs

This article is based on the official Hermes Agent documentation:Official docs › user-guide/messaging/a2a