Agent Orchestration
Multi-agent systems that call each other
A supervisor agent delegates to specialists that in turn invoke one another’s tools over an agent-to-agent (A2A) protocol. Authority has to survive every hop without inflating.
Real example — shipping today
source →Google / Linux Foundation · Agent2Agent (A2A) protocol
A2A standardizes how autonomous agents delegate work to one another — which is exactly where identity and authority get muddled as a call propagates hop to hop.
The danger without a gate
A downstream agent inherits privileges it was never granted, or an injection propagates a destructive call several agents deep — with no single place recording who authorized the final action.
How MCPIP handles it, step by step
Read it top to bottom. Each step shows the real command and exactly what MCPIP returns — the same allow / step-up / denied envelope every time.
A specialist acts on its own verified identity
When a delegated agent calls a tool, MCPIP authorizes that hop on the agent’s own verified JWT — not on whatever the caller upstream claimed.
$ mcpip --json authorize skill_generate_report --arg quarter=2026-Q2{
"decision": "allow",
"status": "executed",
"transaction_ref": "txn_3b71fd",
"executed_target_class": "rest",
"worm_sequence": 48219,
"correlation_id": "44c8e1a2"
}attackThe attack: authority smuggled through the arguments
A downstream call carries role=admin and approved_by=supervisor in its payload, trying to launder privilege from upstream. Identity-shaped arguments are a hard deny — identity comes only from the JWT at this hop, and a role claim authorizes nothing.
$ mcpip --json authorize skill_delete_namespace --arg role=admin --arg approved_by=supervisor{
"error": "denied",
"correlation_id": "9f2e44b1"
}The result
Authority re-checked at every hop, and the whole chain auditable end to end.
The same flow, at a glance
Every command above runs against a local sandbox in one line.
run it yourself — curl … | bash && mcpip up →