Rate-Limiting Bulk Issue and Pull Request Changes by AI Agents on the GitHub MCP Server

Why bulk agent writes need their own limits

The GitHub MCP server gives an agent tools that create, update, comment on, label, close and merge issues and pull requests. A human performs these actions at human speed. An agent can perform them in a tight loop. A misprompted agent, a looping agent, or one steered by injected instructions can produce hundreds of changes before anyone notices.

The consequences are operational. Repositories fill with noise, CI runs and notifications multiply, and the API budget of the shared credential is consumed, which affects other automation using it. Some changes, such as closed issues or merged pull requests, are hard to reverse in bulk. Asynchronous coding agents already produce commits and pull requests without a developer present in real time, so human attention cannot be the only rate limiter.

Native controls address part of this. Token permissions decide what is possible, and GitHub's API limits bound total request volume. Neither is designed to express how many times a particular agent may call a particular write tool against a particular repository in a given window. That gap is what a tool-call limit fills.

Choosing limit dimensions

Four dimensions cover most bulk-change scenarios. Per agent identity limits contain a single misbehaving agent without affecting others. Per tool limits reflect risk: commenting and labeling can tolerate higher volume than closing or merging. Per repository limits stop one agent from flooding one project, and they allow stricter ceilings on critical repositories. Per time window limits turn a total into a rate, typically with a short window to catch loops and a longer one to catch slow, sustained drift.

Combine dimensions rather than choosing one. A useful rule has the form: agent A, tool T, repository R, N calls per window. NIST notes that the correct limit is contextual and depends on the organization and application, and its example of five calls per minute is an illustration, not a recommendation. Set initial values from observed agent traffic, then tighten.

Keep rate limits distinct from quotas. A rate limit applies over a short window to protect availability and repositories. A quota covers an extended period, often tied to billing. Agent write limits are rate limits. Add concurrency limits and a cap on how many downstream calls a single agent task may trigger, since NIST recommends combining rate limits with timeouts, circuit breaking and anomaly detection.

Evidence and where Trussed fits

Each decision should generate a record: agent identity, tool, target repository, the limit that applied, the count at decision time, the outcome (allowed, blocked or escalated), and the approver and response for escalations. Without this, a team can say a limit existed but cannot show what the agent was allowed to do and what it did. NIST observes that explicit policies such as rate limits are well suited to automated enforcement, which also makes them straightforward to record against.

Trussed enforces policy on individual MCP tool calls in the execution path, including rate limiting and escalation for human approval. Limits are enforced at runtime, not reviewed after the fact, and enforcement produces audit-ready evidence that regulated enterprises can use to show what their AI was allowed to do. Trussed runs self-managed in the customer cloud, with configurable retention and data residency. Teams that build this layer themselves need to meet the same requirements: enforcement before the call executes, per-tool behavior, and durable decision records.