Español

Another Agent's Message Is Not Your Approval

The moment your agent sessions can message each other, a question appears that's worth asking before you need the answer. If one of them says the human already signed off on this, does the other one believe it?

The answer is no, by design

When one session messages another, the receiving agent is told the message came from another session, not from you. Several things follow from that, and they're the whole security model:

• It can't approve anything. A message from another session never counts as your consent, so it cannot answer a pending permission prompt on your behalf.
• It can't change configuration. The receiving agent is instructed never to change permission settings, rules files, or other configuration because another session asked it to.
• Commands don't run. A slash command in the message text arrives as plain text. It is read, never executed.
• Permission prompts still fire. If acting on the message needs a permission the receiving session doesn't have, you see the same prompt as for any other work.

Read those together and the shape is clear: a peer agent is an untrusted input that can ask, not an authority that can authorize. Which is the correct default the moment more than one agent can reach your machine.

Why this matters more than it sounds

Without that boundary, multi-agent setups would offer a trivial way around your own permission decisions. Session A gets denied an action, mentions to session B that it's fine and approved, and B does it. Every permission prompt you answered would be worth only as much as the least careful agent in the pool.

It also cuts the other way, and this is the part worth internalizing: an agent should never ask a peer to do something that was denied in its own session. Permission boundaries are per-session, so routing blocked work sideways is laundering your decision, not respecting it. The right move is to bring it back to you.

Tightening it further

The defaults are sensible, but you can be stricter. Inbound messages have three settings:

• accept — each message is delivered.
• hold — a notice appears and nothing is delivered until you approve it.
• refuse — messages are dropped without delivery.

When no value is set, the behavior is decided per message from the two sessions' permission modes, and it leans conservative in the direction you'd hope: a session that bypasses permission prompts holds incoming messages for your approval, and delivers one only when the sender also identifies as bypassing.

Separately, a setting exists to require your explicit approval before any message reaches a session beyond this machine — and it applies even in a mode that otherwise skips permission prompts. A stricter value from any settings scope wins, so a checked-in project file can turn the requirement on but not off.

If you want messaging off entirely, receiving and sending are separate controls: refuse inbound, and deny the messaging and listing tools to stop this session sending or enumerating.

The takeaway

Your agents can talk to each other. That doesn't make them each other's boss. A peer's message can carry information and ask for work, but it can't consent on your behalf, rewrite your configuration, or run a command — and if you want a human in that loop for every inbound message, that's one setting away.