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 and Infographic
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. This is the exam's preferred pattern for hard security boundaries in multi-agent systems.
Full explanation below image
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.
Option A 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.
Option B 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.
Option C 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.
Option D 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. A token scope is too narrow a control for this requirement.