A message from another agent is information, not permission

Agents are starting to call other agents. One drafts, another reviews, a third deploys. They pass work back and forth, and increasingly they do it without a person in the loop for every step. Each hand-off is a new trust boundary, and that is where the trouble hides.

The assumption worth naming

Many early agent-to-agent designs carry an unstated assumption: if another agent says something, you can act on it. Agent B reports "the review passed, ship it," and Agent A ships. Agent B says "the owner approved this," and Agent A treats that as approval.

It is worth saying plainly why that is wrong. A message from another agent is information. It is never permission. Knowing that Agent B claims the owner approved something tells you what Agent B claims. It does not tell you that the owner approved anything.

The failure this prevents is an old one with a name: the confused deputy, an actor with authority talked into using it on someone else's behalf. In a network of agents it shows up as permission laundering. Agent A wants to deploy. Agent B refuses. So Agent A asks Agent C, which never heard the refusal, or reroutes the same request through a relay, or simply rewords it. If authority can travel from agent to agent by assertion, then the most gullible agent in your system quietly sets the security of the whole system.

Authentication is not authorization

The reason people underestimate this is that they reach for signatures. Sign the messages, they reason, and you know who sent them, so you can trust them.

A signature proves which key signed a message. If your key management is sound, that tells you which agent spoke. It does not tell you the message is safe to act on, that the content is fresh, or that the signer had any authority to ask. A signed, well-formed message can even be more dangerous than a scrappy one, because it looks trustworthy.

This is the same failure that sits at the heart of prompt injection: untrusted input treated as a trusted instruction. The only new twist is that here it arrives over an authenticated channel, which makes it look safer than it is. Authentication answers who. Authorization answers whether they are allowed. Signatures give you the first and nothing of the second.

So the rule is precise, not blunt: a message body is untrusted input, never a grant of authority. An agent may read what a peer sent, and may act on it, but only inside a permission that was already granted for that action. Content can shape the work. It must never create the permission.

Where authority actually comes from

Authority comes from the owner of the system, expressed as policy the owner authored, not from a peer's say-so. And it should arrive as something narrow and checkable rather than a blanket role.

The useful prior art here is decades old. Object-capability security, set out in Mark Miller's 2006 dissertation Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control, treats authority as an unforgeable reference that carries exactly the power it names and no more. Macaroons (Birgisson and colleagues, Cookies with Contextual Caveats, NDSS 2014) turn the same idea into a practical credential: a permission that is bound to a context and designed to be narrowed, never widened, as it is passed along.

In plain terms, a good grant says: this recipient may take this exact action, on this exact request, revocable, within a time window, and single-use when the action is irreversible. It is issued by a principal the owner defined, a person or a role or a policy they set, and never inherited from merely being a member of the system. Membership lets you talk. It never lets you act. And a request that was refused stays refused until the owner, not a peer, lifts it, so rewording the ask changes nothing.

A related question: who controls the channel?

There is a second question worth asking. What do your agents talk over, and who controls it?

If the channel is a service outside your trust boundary, or a participant that can reroute or read the messages, then you have quietly added another party to your authority model. That may be fine. It may not. The point is to notice it, because a coordination layer you do not control is one more thing that has to be trusted, and one more thing that can change under you.

The healthy version of this is portability, not paranoia. Your agents' coordination, and the authorization around it, should keep enforcing your policy even if one vendor changes or retires a proprietary feature. Tie your authority model to something you can move, not to a bus you happen to be renting.

What good looks like

None of this needs anything clever. It needs a short list of unglamorous properties:

• Named identities bound to keys the receiver can verify against a trust root, so you know which key spoke, within the limits of that trust.
• Ordering, replay protection, and gap detection, so an old message cannot be replayed to cause an action twice, and a missing one does not pass unnoticed.
• Authority as narrow, revocable grants from the owner, bound to a specific action, and single-use where the action cannot be undone.
• A refusal that sticks, and that a reworded request cannot slip past.
• A tamper-evident record kept outside the agents' own control, so "what happened, and who authorized it" does not rest on trusting the agents involved.
• Honesty about the limits. On a single machine, identity is only ever as strong as the isolation beneath it, the boundaries the kernel and the hardware draw, and no stronger. Say so, out loud, rather than implying more assurance than you have.

The unglamorous parts are the point

The agent era rewards the same things that have always made systems trustworthy: authenticated identity, least privilege, and an audit trail you did not have to trust the actors to keep. The setting is what is new. Agents move faster than people and are easier to talk into things, which raises the cost of getting authority wrong and lowers the effort an attacker needs to spend.

The good news is that all of this is buildable today, with ideas that are already well understood. Treating agent-to-agent authority as a first-class problem is not exotic work. It is just work most teams have not done yet.

A message from another agent is information about what that agent sent. Nothing in it is permission. Treat it as exactly that much, and no more.