How should AI agents authenticate to each other?

Use mTLS with per-agent certificates issued by an internal CA (e.g., HashiCorp Vault PKI). Each agent has a unique identity and the receiver cryptographically verifies it before processing any message.

What are capability tokens in multi-agent AI?

Capability tokens are cryptographically signed authorization tokens that specify exactly what an agent is allowed to do. Like macaroons, they can be delegated but never escalated — a sub-agent can only receive a subset of the delegating agent's permissions.

How do I prevent replay attacks between AI agents?

Include a unique nonce and timestamp in every message. Reject messages older than 5 minutes or with previously seen nonces. Store nonces in a fast in-memory cache (Redis) with TTL matching your replay window.

"Not a Pentest" Notice: These patterns are for securing your own multi-agent systems. Defensive use only.

Moltbot AI Security

Secure AI Agent Communication Patterns 2026

Multi-agent systems introduce a new attack surface: agent-to-agent communication. One compromised sub-agent can pivot to the entire swarm. These patterns give you cryptographic trust between agents — not just perimeter security.

Why This Matters in 2026

As AI orchestration grows (LangGraph, CrewAI, Moltbot multi-agent), the internal bus between agents becomes critical attack surface. Traditional network security doesn't help here — you need identity-based, cryptographically enforced trust at the message level.

Security Patterns

Pattern 1: Signed Message Envelopes

PROBLEM

How do you know a message from AgentB actually came from AgentB and wasn't tampered with?

SOLUTION

Every agent message is cryptographically signed with the sending agent's private key. Receivers verify before acting.

Without this: any process can impersonate an agent.

// Agent sends signed message
const payload = { action: "read_file", path: "/data/report.json", agentId: "agent-b", ts: Date.now() }
const signature = await signMessage(JSON.stringify(payload), AGENT_B_PRIVATE_KEY)
const envelope = { payload, signature, publicKey: AGENT_B_PUBLIC_KEY_ID }

// Receiver verifies
const valid = await verifySignature(JSON.stringify(envelope.payload), envelope.signature, getPublicKey(envelope.publicKey))
if (!valid) throw new Error("INVALID_AGENT_SIGNATURE — rejecting message")

Pattern 2: Capability Tokens

PROBLEM

An orchestrator agent should only be able to grant capabilities it already has — not escalate its own permissions.

SOLUTION

Use macaroon-style capability tokens with explicit scope lists. Agents can delegate a subset of their capabilities, never more.

Without this: agent privilege escalation across multi-agent pipelines.

// Issue capability token
const token = issueCapabilityToken({
  agentId: "orchestrator-1",
  capabilities: ["read:logs", "write:reports"],  // explicit allowlist
  delegatable: ["read:logs"],  // can only delegate read access
  expires: Date.now() + 3600_000,
  issuedBy: "auth-service"
})

// Sub-agent uses delegated token
const subToken = delegateCapability(token, {
  to: "sub-agent-2",
  capabilities: ["read:logs"],  // subset only
  expires: Date.now() + 1800_000
})

Pattern 3: mTLS for Agent-to-Agent

PROBLEM

HTTP calls between agents are interceptable and spoofable without mutual authentication.

SOLUTION

Issue each agent a TLS certificate. Enforce mTLS for all inter-agent communication.

Without this: man-in-the-middle attacks on internal agent traffic.

# Issue per-agent certificates via internal CA
vault write pki/issue/agents \
  common_name="agent-orchestrator.moltbot.internal" \
  ttl="24h" \
  alt_names="agent-orchestrator,localhost"

# Agent HTTP client config (Node.js)
const agent = new https.Agent({
  cert: fs.readFileSync('/certs/agent.crt'),
  key: fs.readFileSync('/certs/agent.key'),
  ca: fs.readFileSync('/certs/internal-ca.crt'),
  rejectUnauthorized: true  // NEVER set false in production
})