This is post #7 of the on Google's A2A protocol. A malicious agent advertises exaggerated capabilities in its agent card (/.well-known/agent.json). The host agent picks it for tasks based on those fake capabilities. Sensitive requests get routed through the attacker.
The beauty (from the attacker's perspective): the A2A protocol trusts agent cards by default. There's no built-in verification that the capabilities advertised are real.
Agent Session Smuggling
Palo Alto's Unit 42 discovered where adversarial instructions are embedded directly within an agent card's metadata. When a host agent reads the card to understand capabilities, the injected instructions influence its behavior. Prompt injection, but at the protocol discovery layer.
MCP Descriptor Poisoning
The pattern repeats with MCP. A malicious MCP endpoint advertises spoofed agent descriptors or false capabilities. When trusted, it routes sensitive data through attacker infrastructure. Multiple CVEs in 2025 documented this exact pattern.
Why Traditional Network Security Doesn't Help
You might be thinking: "I'll just put my agents in a VPC and encrypt the traffic." That helps with transport security. But it doesn't solve the core problem.
The messages themselves are the attack vector. Even over encrypted, authenticated channels, a compromised agent can send perfectly valid-looking messages that manipulate the receiving agent. The message is well-formed. The credentials are valid. The content is malicious.
Agent-to-agent security needs to happen at the semantic layer, not just the transport layer. You need to validate what is being said, not just who is saying it.
Mitigating Inter-Agent Communication Risks on AWS
Here's how to build secure agent-to-agent communication on AWS. The principle: validate structure, authenticate identity, verify intent, and contain blast radius.
1. EventBridge Schema Registry for Message Validation
gives you something agents talking directly to each other never will: a single,
auditable, centrally controlled entry point for every inter-agent message, with schema validation bolted to the front door.
I want to be careful with my words here, because this is where a lot of "secure multi-agent" write-ups quietly cheat. Step Functions is not a type system. It will not magically validate
your payloads. What it gives you is a chokepoint. One place every message has to pass through. And a chokepoint is only worth something if you actually force the traffic through it.
Hold that thought, because it is the whole point of this section.
So instead of agents invoking each other directly, you route every request through a state machine.
{
"Comment": "Secure multi-agent orchestration",
"StartAt": "ValidateRequest",
"States": {
"ValidateRequest": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:validate-agent-message",
"Next": "RouteToAgent",
"Catch": [
{ "ErrorEquals": ["ValidationError"], "ResultPath": "$.error", "Next": "RejectAndLog" },
{ "ErrorEquals": ["States.ALL"], "ResultPath": "$.error", "Next": "RejectAndLog" }
]
},
"RouteToAgent": {
"Type": "Choice",
"Choices": [
{ "Variable": "$.task_type", "StringEquals": "process_payment", "Next": "PaymentAgent" },
{ "Variable": "$.task_type", "StringEquals": "check_inventory", "Next": "InventoryAgent" }
],
"Default": "RejectAndLog"
},
"PaymentAgent": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:payment-agent",
"InputPath": "$.validated_params",
"ResultPath": "$.payment_result",
"TimeoutSeconds": 30,
"Retry": [
{ "ErrorEquals": ["Lambda.TooManyRequestsException", "Lambda.ServiceException"],
"IntervalSeconds": 2, "MaxAttempts": 3, "BackoffRate": 2.0 }
],
"Catch": [
{ "ErrorEquals": ["States.ALL"], "ResultPath": "$.error", "Next": "RejectAndLog" }
],
"Next": "Done"
},
"InventoryAgent": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:inventory-agent",
"InputPath": "$.validated_params",
"ResultPath": "$.inventory_result",
"TimeoutSeconds": 30,
"Retry": [
{ "ErrorEquals": ["Lambda.TooManyRequestsException", "Lambda.ServiceException"],
"IntervalSeconds": 2, "MaxAttempts": 3, "BackoffRate": 2.0 }
],
"Catch": [
{ "ErrorEquals": ["States.ALL"], "ResultPath": "$.error", "Next": "RejectAndLog" }
],
"Next": "Done"
},
"RejectAndLog": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:log-rejected-message",
"ResultPath": "$.log_result",
"Next": "Rejected"
},
"Rejected": {
"Type": "Fail",
"Error": "MessageNotProcessed",
"Cause": "Message failed validation, routing, or agent execution and was never forwarded."
},
"Done": {"Type": "Succeed"}
}
}
Let me walk through what that buys you.
- One front door. Every message enters at ValidateRequest. Nothing reaches an agent until it has been validated and explicitly routed. There is no side entrance.
- Least-privilege payloads. InputPath: $.validated_params means the payment agent receives only the parameters it needs. It never sees the full envelope, the routing metadata, or the
nonce. If that Lambda gets popped, it has less to work with.
- Fail closed, and fail loud. Validation errors, unknown task_type values, and dead agents all funnel to RejectAndLog and then to a Fail state. This matters. In the naive version a
rejected message ends in Succeed, which means a malicious payload produces a green, successful execution and your CloudWatch alarm on failed executions never fires. Do not do that. A
rejection is a failure. Make it look like one.
- Retries for the honest failures. Agents throw transient errors. Lambda.TooManyRequestsException is not an attack, it is a Tuesday. The Retry block backs off and tries again before
giving up.
- A full audit trail. Every transition, with input and output, lands in the execution history. When something goes sideways at 3am you have a complete, replayable record of exactly what
happened. (Execution history is kept for 90 days, so if you need audit that outlives that, turn on CloudWatch Logs or ship it to S3. And remember the message contents sit in that
history, so mind what you log.)
Now about those timeouts, because the word "timeout" lies to you a little.
TimeoutSeconds: 30 does not kill your Lambda. Let me say that again, because I got this wrong myself the first time. When the timer fires, Step Functions stops waiting and marks the
task failed. The Lambda underneath keeps right on running, burning money and holding connections, until it finishes or hits its own function timeout. So set the Lambda's timeout too.
The state machine timeout protects the orchestrator. The function timeout protects your wallet and your downstream.
And here it comes. The part that actually makes this secure.
A state machine that routes through an orchestrator does not stop an agent from picking up the phone and calling another agent directly.
Read that again. The JSON above is necessary. It is not sufficient. If your payment agent's execution role has lambda:InvokeFunction on the inventory agent, then the moment someone
compromises the payment agent your beautiful orchestrator becomes optional. The attacker just calls the next agent directly and skips validation, routing, and logging. All of it.
The chokepoint is only a chokepoint if IAM makes it the only road.
So two rules, and they are not optional.
Rule 1: Only the orchestrator may invoke the agents. The state machine's execution role gets lambda:InvokeFunction, scoped to exactly these functions and nothing else.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvokeOnlyTheseFunctions",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": [
"arn:aws:lambda:us-east-1:123456789012:function:validate-agent-message",
"arn:aws:lambda:us-east-1:123456789012:function:payment-agent",
"arn:aws:lambda:us-east-1:123456789012:function:inventory-agent",
"arn:aws:lambda:us-east-1:123456789012:function:log-rejected-message"
]
}
]
}
Rule 2: The agents may not invoke each other. At all. Look closely at a typical agent role. Notice what is not there.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PaymentAgentDataAccessOnly",
"Effect": "Allow",
"Action": ["dynamodb:GetItem", "dynamodb:PutItem"],
"Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/payments"
}
]
}
No lambda:InvokeFunction. Anywhere. The payment agent can touch its payments table and that is the entire list. It has no ability, none, to call the inventory agent or any other
function. If it needs something done elsewhere, it returns a result to the orchestrator and the orchestrator decides what happens next. That is what "no direct agent-to-agent
communication" actually means, and you will notice it lives in IAM, not in the state machine.
Want to go one step further? Put a resource-based policy on each agent function that grants invoke permission only to the orchestrator role, then use an SCP to deny
lambda:InvokeFunction on those ARNs for every other principal in the account. Now even an over-privileged admin role cannot accidentally wire two agents together. Belt, suspenders, and
a second belt.
The state machine gives you the shape. IAM gives you the guarantee. Most people ship only the first one and call it secure.
### 3. SQS Message Signing for Integrity
If your agents communicate via queues, [SQS](https://aws.amazon.com/sqs/?trk=d76afd77-bb62-46ac-b0a3-9dbf5ecde253) with message attributes and HMAC signing prevents tampering:
python
import hashlib
import hmac
import json
import time
import uuid
import boto3
sqs = boto3.client("sqs")
secrets = boto3.client("secretsmanager")
Pull the shared signing key from Secrets Manager, never from source control.
SECRET_KEY = secrets.get_secret_value(SecretId="agent-hmac-key")["SecretString"].encode()
MAX_AGE_SECONDS = 60 # freshness window; bounds the replay surface
class IntegrityError(Exception):
"""Raised when a message fails signature, freshness, or replay checks."""
class InMemoryNonceStore:
"""Example only. In production use a SHARED store (DynamoDB with a TTL
attribute, or Redis). An in-memory dict does NOT stop replays across
concurrent Lambda instances, because each instance has its own copy."""
def init(self):
self._seen = {}
def exists(self, nonce: str) -> bool:
now = time.time()
self._seen = {n: exp for n, exp in self._seen.items() if exp > now}
return nonce in self._seen
def add(self, nonce: str, ttl: int):
self._seen[nonce] = time.time() + ttl
def _signing_bytes(source_agent: str, nonce: str, timestamp: str, body: str) -> bytes:
"""Canonical, unambiguous representation of everything we sign. This covers
the body AND the security-relevant attributes, so none of them can be
tampered with independently of the signature."""
return json.dumps(
{"source_agent": source_agent, "nonce": nonce, "timestamp": timestamp, "body": body},
sort_keys=True,
separators=(",", ":"),
).encode()
def send_signed_message(queue_url: str, message: dict, source_agent: str):
"""Sign the body together with the attributes, then send."""
body = json.dumps(message, sort_keys=True, separators=(",", ":"))
nonce = str(uuid.uuid4())
timestamp = str(int(time.time()))
signature = hmac.new(
SECRET_KEY, _signing_bytes(source_agent, nonce, timestamp, body), hashlib.sha256
).hexdigest()
sqs.send_message(
QueueUrl=queue_url,
MessageBody=body,
MessageAttributes={
"source_agent": {"DataType": "String", "StringValue": source_agent},
"signature": {"DataType": "String", "StringValue": signature},
"nonce": {"DataType": "String", "StringValue": nonce},
"timestamp": {"DataType": "String", "StringValue": timestamp},
},
)
def _attr(attrs: dict, name: str) -> str:
"""Fetch a required string attribute, or fail closed."""
try:
return attrs[name]["StringValue"]
except (KeyError, TypeError):
raise IntegrityError(f"missing required attribute: {name}")
def verify_message(msg: dict, nonce_store) -> dict:
"""Verify a single message. Returns the parsed body or raises IntegrityError.
nonce_store must expose .exists(nonce) and .add(nonce, ttl)."""
body = msg["Body"]
attrs = msg.get("MessageAttributes") or {}
source_agent = _attr(attrs, "source_agent")
signature = _attr(attrs, "signature")
nonce = _attr(attrs, "nonce")
timestamp = _attr(attrs, "timestamp")
# 1) Integrity + binding: recompute over body AND attributes, constant-time compare.
expected = hmac.new(
SECRET_KEY, _signing_bytes(source_agent, nonce, timestamp, body), hashlib.sha256
).hexdigest()
if not hmac.compare_digest(signature, expected):
raise IntegrityError(f"signature check failed (claimed source: {source_agent})")
# 2) Freshness: reject stale or future-dated messages (allow a little clock skew).
try:
age = int(time.time()) - int(timestamp)
except ValueError:
raise IntegrityError("unparseable timestamp")
if age > MAX_AGE_SECONDS or age < -MAX_AGE_SECONDS:
raise IntegrityError(f"stale/future-dated message (age {age}s)")
# 3) Anti-replay: each nonce is accepted exactly once.
if nonce_store.exists(nonce):
raise IntegrityError(f"replay detected (nonce {nonce})")
nonce_store.add(nonce, ttl=MAX_AGE_SECONDS * 2)
return json.loads(body)
def receive_and_process(queue_url: str, nonce_store, handler):
"""Long-poll, verify each message, process + delete on success. On failure
we alert and leave the message for SQS to redrive to a dead-letter queue
(configure a redrive policy with maxReceiveCount on the source queue)."""
response = sqs.receive_message(
QueueUrl=queue_url,
MessageAttributeNames=["All"],
MaxNumberOfMessages=10,
WaitTimeSeconds=20,
)
for msg in response.get("Messages", []):
try:
payload = verify_message(msg, nonce_store)
except IntegrityError as e:
print(f"[REJECTED] {e}") # emit a CloudWatch metric / alarm here
continue # do NOT delete -> redrive policy sends it to the DLQ
handler(payload)
sqs.delete_message(QueueUrl=queue_url, ReceiptHandle=msg["ReceiptHandle"])
HMAC uses a shared symmetric key, so this authenticates the group, not the individual agent. Signing source_agent stops an attacker who can write to the queue but does not hold the key.
It does not stop a compromised agent that does hold the shared key from forging a message as any other agent. If your threat model includes a compromised agent (and this whole post says it does), you need per-agent keys or asymmetric signatures — each agent signs with its own private key, verifiers hold the public keys, and now source_agent is genuinely provable. Don't let "prevents tampering" imply "proves who sent it," because with one shared key it doesn't.
### 4. API Gateway with Mutual TLS for Agent-to-Agent Calls
For agents that communicate via HTTP APIs, [API Gateway](https://aws.amazon.com/api-gateway/?trk=d76afd77-bb62-46ac-b0a3-9dbf5ecde253) with mutual TLS ensures both sides prove their identity:
- Each agent gets its own client certificate
- API Gateway validates the cert before forwarding the request
- You know exactly which agent sent which message
- No certificate = no communication. Period.
Combined with request validation (OpenAPI schema enforcement at the gateway), you get both identity verification AND structural validation before the message reaches the target agent.
### 5. VPC Security Groups for Network-Level Isolation
Defense in depth means layering. [VPC security groups](https://aws.amazon.com/vpc/?trk=d76afd77-bb62-46ac-b0a3-9dbf5ecde253) restrict which agents can even *attempt* to communicate:
- Payment agent only accepts inbound from the orchestrator
- Inventory agent only accepts inbound from the orchestrator
- No agent can talk directly to any other agent
- All traffic must flow through the validated path
If an agent gets compromised, it can't laterally move to other agents because the network itself prevents it.
### 6. PrivateLink: Network-Level Agent Isolation
If your agents communicate across VPCs or accounts, [AWS PrivateLink](https://aws.amazon.com/privatelink/?trk=d76afd77-bb62-46ac-b0a3-9dbf5ecde253) ensures that traffic never traverses the public internet. Each agent exposes its API as a VPC endpoint service. Other agents connect via interface endpoints in their own VPC.
Why this matters for inter-agent security:
- Traffic stays on the AWS backbone, no internet exposure
- You control exactly which VPCs (and therefore which agents) can connect
- Combined with security groups, you get network-level allowlisting of agent-to-agent communication paths
- An attacker who compromises one agent can't reach other agents unless the PrivateLink connection explicitly exists
Think of it as the network equivalent of "deny by default" - agents can't even *see* each other unless you've explicitly wired up the endpoint.
### 7. Amazon Verified Permissions: Semantic Authorization Between Agents
Network-level controls tell you *which* agents can connect. [Amazon Verified Permissions](https://aws.amazon.com/verified-permissions/?trk=d76afd77-bb62-46ac-b0a3-9dbf5ecde253) (Cedar) tells you *what* they're allowed to ask for once connected.
cedar
// Agent A (customer-service) can ask Agent B (payments) to look up orders
// but NOT to issue refunds
permit(
principal == Agent::"customer-service",
action == Action::"invoke",
resource == Tool::"payments/lookup-order"
);
// Only the refund-approver agent can invoke the refund tool
permit(
principal == Agent::"refund-approver",
action == Action::"invoke",
resource == Tool::"payments/process-refund"
);
This stops the confused deputy problem cold. Even if Agent A gets compromised and tries to tell Agent B "process a refund," the Cedar policy rejects it because Agent A doesn't have `invoke` permission on `payments/process-refund`. The authorization check happens independently of whatever the message *says*.
## The Architecture: Secure Multi-Agent Communication
Layer these together:
1. **Network** - VPC security groups + PrivateLink restrict who can talk to whom
2. **Transport** - Mutual TLS proves identity on every connection
3. **Structure** - EventBridge schema registry / API Gateway request validation rejects malformed messages
4. **Integrity** - HMAC signing detects tampering
5. **Authorization** - Verified Permissions (Cedar) controls what agents can ask each other to do
6. **Orchestration** - Step Functions controls the flow, filters inputs, enforces timeouts
7. **Audit** - Every message logged in CloudWatch/CloudTrail
An attacker needs to bypass *all seven layers* to successfully inject a malicious inter-agent message. That's the point.
## Key Takeaway
**Don't let your agents talk to each other unsupervised.** Route inter-agent communication through a validated, schema-enforced, auditable orchestration layer. Validate structure, verify identity, sign for integrity, and restrict the network paths. The same zero-trust principles that saved microservices will save multi-agent systems.
## Up Next
[**Post 8: Cascading Failures (ASI08)**](https://dev.to/aws/cascading-failures-when-one-agents-mistake-takes-down-the-whole-system-asi08-5b3j) - One hallucination, ten downstream agents acting on it. How Step Functions error handling, circuit breakers, and CloudWatch composite alarms keep a single agent failure from taking down your entire system.
I would be very interested to hear your thoughts or comments, so please feel free to ping me on [LinkedIn](https://www.linkedin.com/in/maishsk/) or [Twitter](https://x.com/maishsk), or drop them below. If you're building multi-agent systems and have solved the communication security problem differently, I genuinely want to hear about it.
Onward!!
SOCIAL SHARE CARD GENERATOR