A runaway Copilot agent entered an infinite loop after a bug caused its loop-termination condition to never be satisfied. In 90 minutes, it made 47,000 GitHub API calls through an MCP tool, exhausted the organization's rate limit, and blocked all human developers from using GitHub. Which control would have prevented this impact?

The root cause of this incident is an agentic loop with no circuit breaker at the tool-call layer. The fix must intercept the runaway behavior before it exhausts shared infrastructure. Implementing per-agent rate limits in the MCP server layer is the correct prevention: each agent session is tracked by its credential or session ID, the MCP server maintains a counter of tool calls within a sliding window (e.g., max 100 calls per 5 minutes), and when the limit is reached the server returns a rate limit error and optionally sends an alert, halting the agent's ability to continue until the window resets or a human intervenes. This control provides multiple benefits: blast radius containment, because the agent cannot consume the organization's shared rate limit budget; early incident detection, because a sudden spike to the per-agent rate limit ceiling is an anomaly signal; and graceful degradation, because other agents and humans retain their API quota. Deploying the agent to a separate GitHub organization so its rate limit exhaustion does not affect the main organization adds operational complexity and cost, and doesn't fix the root cause—a bug that loops forever. Adding a try/catch block around the agent's loop that catches rate limit errors and implements exponential backoff only kicks in after the damage is done, because the rate limit is already exhausted, and it actually prolongs the incident by retrying indefinitely. Configuring the agent to run in GitHub Actions with a maximum job timeout of 6 hours is a safety net but allows 188,000 calls before intervening—far too late to prevent impact. The per-agent circuit breaker at the MCP layer is the correct prevention.