You're not building a multi-agent system. You're building a wire protocol. Here's how to stop.

Posted by rupayanc@reddit | LocalLLaMA | View on Reddit | 18 comments

Every multi-agent project hits the same wall around day 3. Agents need to talk to each other, and suddenly you're not building your product anymore. You're building a wire protocol.

Here's what no one tells you upfront:

Your agents have no identity

Agent B has no proof the request came from agent A. You need Ed25519 signing, key storage, a well-known URL to publish keys, and signature verification on every inbound request. \~2-3 days.

Signed messages can still be replayed

An attacker captures a valid request and replays it later. Without a nonce store + timestamp window, agent B executes the same action twice. Silent corruption that's hell to debug. \~1-2 days.

Per-sender rate limiting is not a quick add

You need sliding window logic per sender (not just global limits), daily token budgets for LLM cost protection, and it needs to run before your handler, not after. A single agent with a retry bug will take down your whole network if you skip this. \~1 day if you get it right first time.

There's no discovery standard

How does agent A know what skills agent B offers, what keys to verify against, what rate limits to expect? Without a standard, every new agent in your network is a custom integration built from scratch. Doesn't scale. \~1-2 days per agent.

A rogue caller can invoke skills it was never meant to touch

If trust is all-or-nothing, any agent that discovers your URL can attempt anything. You need tiered enforcement (public / authenticated / trusted-peers) running before the handler on every request. \~1-2 days.

Delegation chains get complicated fast

Agent A → agent B → agent C on A's behalf. You need signed tokens with scope restrictions and depth limits. RFC 8693 describes it. Implementing it is another matter. \~2-3 days.

Your agents can be prompted against you

A compromised peer sends a payload designed to hijack your LLM. If you're scanning input before verifying sender identity, you're running untrusted content through your system before auth. The ordering matters. \~1-2 days to get right.

Total: 2-3 weeks of work that has nothing to do with your actual product.

---

Got tired of rebuilding this on every project so I put together a reference implementation. Happy to share it if useful.

More interested in whether anyone's solved #3 differently — per-sender rate limiting always takes longer than it should.

Which of these caught you off guard? Drop it in the comments.

[-]

Ok_Helicopter_2294@reddit

The more references, the better.
Thank you for sharing.

And to be honest, I think the people who really need it are probably already developing their own solutions.

[-]

Bigboymoves17@reddit

I depend on technical ppl so I disagree The amount of repos and skills I have installed that have helped me is insane I’m so glad for them tbh

[-]

Ok_Helicopter_2294@reddit

I respect your opinion.
I believe that if security measures are necessary, there are probably already people working on them.
From a security standpoint, I think this technology serves as a valuable reference.

[-]

Bigboymoves17@reddit

I’m sorry as well for misunderstanding what you actually meant

[-]

rupayanc@reddit (OP)

Reference implementation if anyone wants to see how these 7 fit together as a working system: https://github.com/w3rc/samvad (TypeScript + Python SDKs)

[-]

Bigboymoves17@reddit

Looks cool bro

[-]

DeltaSqueezer@reddit

Agents communicate on a secure channel. Completely transparent to the agent. Problem solved.

[-]

rupayanc@reddit (OP)

Transport security handles confidentiality in transit. It doesn't prove who sent the message. If agent B accepts anything that arrives on its endpoint, any caller who knows the URL can claim to be agent A.

TLS says "this connection is encrypted." It says nothing about whether the sender is who they claim. That's what signing solves.

[-]

BobbyL2k@reddit

You are looking for mTLS.

[-]

rupayanc@reddit (OP)

mTLS solves mutual auth at the connection level. It doesn't give you per-message signing.
With mTLS, once the connection is authenticated, any message sent over it is implicitly trusted. There's no individual message you can extract, verify, store, and audit independently. You also need to manage certificates and a PKI, which is a real overhead when you have hundreds of agents spinning up dynamically.

SAMVAD uses signed envelopes so each message carries its own proof of origin. You can verify a single message in isolation, months later, without any connection context. That's a different trust model, and for agent workflows with audit trails, delegation chains, and async task queues, it's a better fit.

mTLS is great for service-to-service infra. Signed messages are better for agent-to-agent protocols.

[-]

BobbyL2k@reddit

You’re operating with a zero trust mindset. Sure, if you want to be sure that the other side isn’t manipulating your messages, or have some way to verify the authenticity of a particular message sent across some untrusted agents in the middle.

My question to you: is why is your agent connecting and talking to another agent running on infrastructure you don’t trust?

[-]

rupayanc@reddit (OP)

Actually the bigger picture here is what the protocol unlocks beyond just security.
You build an agent. You give someone your agent's URL. They fetch your AgentCard, register your public key, and now they can call your agent from anywhere in the world, from any framework, with verified identity and rate limits enforced automatically.

That's it. You've just published an agent as a service.

No API gateway to set up. No custom auth layer to build. The protocol handles identity, replay protection, and rate limiting out of the box. You can charge per-token, per-call, whatever model you want, because the rate limiting and trust tiers are already wired in.

The vision is basically: agents become first-class services on the internet. Anyone can build one, publish it, and let other agents (or people running agents) pay to use it. Same way you'd publish an npm package, except it's a running agent with a verifiable identity.

That's what SAMVAD is trying to be.

To make it concrete: you can have two OpenClaw agents running on separate machines, anywhere in the world, communicating with each other asynchronously right now.

Each agent publishes an AgentCard with its public key. The other agent fetches it, registers the key, sends a signed task, and moves on. The response comes back whenever it's ready, verified, no polling, no shared infrastructure.

There's already an OpenClaw agent with SAMVAD installed, hosted on samvad.dev/registry. You can spin one up, point it at another, and have them talking in under an hour.

That's the actual demo. Two agents. Any framework. Any location. Async. Verified identity on every message/

[-]

Bigboymoves17@reddit

Dude is this open source?

[-]

DeltaSqueezer@reddit

Unless you made your agents impersonate each other, that's not an issue.

[-]

rupayanc@reddit (OP)

This is exactly the gap SAMVAD solves. Any two agents, regardless of framework or language, can talk to each other securely out of the box.

Each agent publishes a card at /.well-known/agent.json advertising its public key and capabilities. The other agent fetches that, registers the key, and from that point every message is Ed25519 signed with a nonce and replay protection. No shared secrets, no central registry, no broker in the middle.

So agent A built in Python can call agent B built in TypeScript, verify the signature, check the nonce window, enforce rate limits, and trust the payload came from who it says it did. The whole thing is peer-to-peer.

Reference impl: github.com/w3rc/samvad

Still early but the core protocol is working. Happy to answer questions if you're building something multi-agent.

[-]