An agent is deployed to both a development environment and a production environment. In production, it must not execute any database schema migrations autonomously. Which approach best enforces this environment-specific constraint?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Production constraints need hard stops, not soft suggestions. The right approach is a two-layer defense: a prod-specific MCP allow list that removes the migration tool entirely (so the agent can't even see it), plus a GitHub Actions environment protection rule that requires a human to approve before the prod agent job runs at all. Relying on the model to self-restrain in prod is like leaving the vault combination in plain sight and trusting people to forget they saw it.
Full explanation below image
Full Explanation
Environment-specific constraints are a critical aspect of safe agent deployment. The safest architecture enforces constraints at multiple layers:
Layer 1 — MCP Allow List (tool-level): The production agent profile is configured with an MCP allow list that explicitly excludes the run_migration tool. Even if the agent's reasoning concludes a migration is needed, the tool simply does not exist in the prod environment's tool registry. This is a hard technical block, not a behavioral nudge.
Layer 2 — GitHub Actions Environment Protection (workflow-level): GitHub Actions supports "Environments" (Settings → Environments) that can require manual approvals before a job targeting that environment can run. A required reviewer approval for the production environment means a human explicitly authorizes the agent job before it executes. This provides a human-in-the-loop gate independent of the agent's decisions.
Together, these two layers provide defense in depth: even if one layer were misconfigured, the other would catch unsafe actions.
Option A is incorrect because natural-language instructions in a system prompt are probabilistic guardrails. The model may misinterpret context, follow a chain of reasoning that overrides the instruction, or be manipulated via prompt injection in tool outputs. System prompts are not access control mechanisms.
Option C is incorrect because security through obscurity is not reliable. The agent explores available tools by calling the server's tool manifest; a renamed tool would still appear in the manifest unless actually removed from the allow list. Renaming does not block invocation.
Option D is incorrect because allowing the migration to fail at the database level means the agent has already attempted to make a change, potentially locking tables or leaving the database in a partial state. Letting operations fail at the infrastructure level is a last-resort safety net, not a designed constraint. The goal is prevention, not recovery from failure.
Option B is correct. Separate environment-specific profiles with tool allow lists plus environment protection rules is the designed, multi-layer approach.