Insecure Inter-Agent Communication | Agentic Security

What Is Insecure Inter-Agent Communication?

Modern AI systems increasingly rely on multi-agent architectures where specialized agents collaborate — a planner agent delegates tasks to a coder agent, which calls a database agent, which reports back to an analyst agent. Each handoff is a potential attack surface.

Insecure inter-agent communication occurs when agents exchange messages, delegate authority, or share data without proper authentication, integrity verification, or access controls. Unlike human-to-service communication where decades of TLS, OAuth, and RBAC patterns exist, agent-to-agent protocols are often built ad hoc — with security as an afterthought.

Planner Agent → Coder Agent:

"Execute this database migration on production"

Coder Agent: ✓ Received from "Planner Agent" — executing...

✗ But was the message actually from the Planner Agent? Was it tampered with in transit? Does the Planner even have authority to request production changes?

Attack Vectors

Inter-agent communication vulnerabilities fall into four primary categories, each exploiting a different trust assumption in multi-agent systems:

Spoofed Agent Identities

Without cryptographic identity verification, any process can claim to be any agent. An attacker can impersonate a trusted agent — sending instructions that appear to come from a privileged orchestrator, a compliance checker, or a human supervisor. Most agent frameworks identify peers by string name alone, making impersonation trivial.

Message Tampering

Agent messages typically flow over HTTP, WebSockets, or message queues without per-message integrity checks. A man-in-the-middle can modify task instructions, alter data payloads, or inject additional commands between agents. Without message signing, the receiving agent has no way to detect modifications.

Unauthorized Delegation

Agent orchestration systems allow agents to delegate tasks to sub-agents. Without proper authorization chains, a low-privilege agent can delegate tasks to high-privilege agents, effectively escalating its own permissions. This is the agent equivalent of privilege escalation — the "confused deputy" problem applied to multi-agent workflows.

Cross-Tenant Data Leakage

In multi-tenant agent platforms, agents serving different organizations may share infrastructure — message buses, tool registries, memory stores. Without strict tenant isolation, one organization's agent can observe or influence another's communications. Shared MCP server instances are a particularly common leak point.

The Inter-Agent Attack Chain

Inter-agent attacks are especially dangerous because they exploit trust relationships that are often implicit and unverified:

1

Reconnaissance

Attacker maps the agent topology — discovering which agents exist, what protocols they use, and how they authenticate (if at all). Agent discovery endpoints and MCP server listings often expose this information freely.

2

Impersonation

Attacker creates a rogue agent that claims the identity of a trusted peer. Without DID-based identity or mutual TLS, the receiving agent accepts the connection based on the claimed name alone.

3

Injection

The rogue agent sends crafted messages — modified task instructions, poisoned context data, or malicious tool calls — that the receiving agent processes as legitimate. The injected content flows through the agent pipeline, influencing decisions and actions.

4

Lateral Movement

The compromised agent's trust relationships become the attacker's access paths. If Agent A trusts Agent B, and the attacker controls B, the attacker can reach everything A can reach — including other agents, databases, APIs, and user data.

5

Exfiltration

Data flows out through the agent communication channels themselves. Since agents routinely exchange data, exfiltration traffic blends with normal operations — making detection far harder than traditional data theft.

How KYM Mitigates This

KnowYourModel's architecture addresses inter-agent communication security at every layer — from identity to message integrity to delegation control:

DID-Based Agent Identity

Every agent on KYM is identified by a Decentralized Identifier (DID) backed by Ed25519 key pairs. Agent identity isn't a string — it's a cryptographic assertion. When Agent A receives a message from Agent B, it verifies B's DID signature against the registry's published DID document at /.well-known/did.json. Spoofing requires compromising the private key, not just knowing the name.

HMAC-Signed Compliance Decisions

Every compliance decision issued by KYM is HMAC-signed with a server-side secret. When an agent receives a compliance verdict — "this agent is EU AI Act compliant" — it can verify the signature to confirm the decision hasn't been tampered with in transit. Modified verdicts fail signature verification immediately.

Ed25519 Verifiable Credential Proofs

Agent credentials (capabilities, compliance status, trust scores) are issued as W3C Verifiable Credentials with Ed25519 cryptographic proofs. These credentials are self-verifying — any agent can validate them without contacting the issuer. This creates a decentralized trust fabric where agents can verify each other's claims without a central authority being online.

Federation SSRF Protection

KYM's NANDA federation protocol validates all peer URLs before establishing connections. This prevents a compromised agent from directing KYM to connect to internal services, localhost endpoints, or attacker-controlled servers. URL validation includes scheme whitelisting, private IP range blocking, and DNS rebinding protection.

Tenant-Isolated Data Access

All database queries in KYM are scoped by entity ownership. Drizzle ORM enforces tenant isolation at the query level — there's no query path that can return another tenant's data. Cross-tenant data leakage would require bypassing the ORM entirely, which the V8 isolate sandbox prevents.

Defense Checklist

Essential Defenses

Use cryptographic identity: Authenticate agents with DIDs, mutual TLS, or signed JWTs — never trust string-based agent names as identity assertions
Sign every message: Use HMAC or digital signatures on all inter-agent messages. Verify signatures before processing any received instruction or data payload
Implement delegation policies: Define explicit delegation rules — which agents can delegate to which, what capabilities can be delegated, and the maximum depth of delegation chains
Encrypt in transit: Use TLS 1.3 for all inter-agent communication. For sensitive workloads, add message-level encryption on top of transport encryption

Common Mistakes

Trusting the network: Assuming internal network traffic is safe. Agent communication should be treated as untrusted regardless of network topology
Implicit trust chains: Assuming that because Agent A trusts Agent B, and B trusts C, then A should trust C. Trust is not transitive — verify each relationship independently
Shared infrastructure without isolation: Running multiple tenants' agents on shared message buses, tool registries, or memory stores without strict namespace isolation

Insecure Inter-Agent Communication: When Agents Can't Trust Each Other

What Is Insecure Inter-Agent Communication?

Attack Vectors

The Inter-Agent Attack Chain

How KYM Mitigates This

Defense Checklist

Further Reading

Cascading Failures: When One Agent's Problem Becomes Everyone's Crisis