A multi-agent pipeline has an orchestrator agent and three specialized sub-agents: a code-review agent, a documentation agent, and a deployment agent. Security policy requires that the documentation agent must never be able to invoke deployment-related MCP tools, even if the orchestrator delegates a task to it incorrectly. Which configuration approach best enforces this constraint?
Select an answer to reveal the explanation.
Short Explanation
Think of an allow list like a bouncer's VIP list — only the names on the list get in, period. No matter what the orchestrator says, a per-agent MCP allow list enforces tool boundaries at the tool-invocation layer itself, not in the agent's reasoning. You get a hard security boundary instead of hoping the agent behaves.
Full Explanation
When enforcing which tools a sub-agent can invoke in a multi-agent pipeline, you need a control that operates at the invocation layer rather than relying on the agent's decision-making. An MCP allow list configured per-agent accomplishes this: the MCP server or client runtime checks the incoming tool call against the allowed set and rejects any call not on the list, regardless of what the orchestrator instructed. The system-prompt reminder approach is wrong because system prompt reminders are part of the agent's reasoning layer, not a hard enforcement mechanism. An agent can misinterpret, ignore, or be adversarially prompted past a text instruction. This provides no actual security boundary. The per-agent MCP allow list that explicitly enumerates only permitted tool names is correct. Defining a per-agent allow list that enumerates only permitted tool names means the invocation itself is blocked at the infrastructure level. This is the pattern GitHub's agentic AI guidance recommends for least-privilege tool access in multi-agent workflows. The documentation agent literally cannot invoke deployment tools because the runtime refuses the call before it executes. The separate GitHub Actions runner with network segmentation approach is wrong because network segmentation addresses connectivity between services, not which MCP tools an agent can call. If both agents use the same MCP server, network rules won't differentiate between tool calls from different agents. It also adds operational complexity without addressing the root concern. The read-only GitHub token approach is wrong because a read-only GitHub token restricts repository API operations but doesn't govern MCP tool invocations broadly. Deployment MCP tools may not require GitHub write tokens specifically — they might call external CI/CD APIs, cloud providers, or infrastructure tools. The token scope is too narrow a control for this requirement.