Microsoft Security Copilot Throttling: Why SCU Capacity Cannot Be Shared Across Workspaces

Security Compute Units come in two forms. Provisioned SCUs are committed capacity billed hourly whether used or not; they form the baseline ceiling for a workspace. Overage SCUs are on-demand and billed only when consumed, configurable anywhere from zero to 999 per workspace; they function as a burst buffer above the provisioned ceiling. Each workspace in a tenant gets its own independent allocation of both types, and that allocation does not interact with any other workspace in the same tenant.

Microsoft's FAQ documents this explicitly with a concrete example. If Workspace A has one provisioned SCU and three overage SCUs, it has a maximum of four SCUs available. Workspace B, with two provisioned and five overage, has seven. When Workspace A exhausts its four SCUs, it cannot borrow any of Workspace B's seven, and analysts hitting it will see throttling errors regardless of how much headroom Workspace B has at that moment.

The design rationale is predictability. If SCUs were pooled at the tenant level, a burst in one workspace from an autonomous agent sweep, a Logic Apps workflow, or a large promptbook run could starve a completely unrelated team in another workspace. By isolating capacity per workspace, Microsoft ensures each team's experience is bounded by its own allocation and cannot be disrupted by activity in other parts of the tenant.

For Azure Lighthouse deployments the picture differs in one specific way. When an MSSP uses Azure Lighthouse to access a customer's Microsoft Sentinel workspace, the MSSP partner tenant's own SCUs are consumed, not the customer's. An MSSP operating across many customer tenants needs to provision SCUs in its own tenant sufficient for all delegated workspace operations, and cannot rely on each customer's separate allocation to absorb that load. Customers using Azure Lighthouse access should account for this when sizing their own workspace SCUs for direct analyst use.

The first diagnostic step is confirming the error is throttling and not a permissions or connectivity issue. The specific messages analysts see when throttling occurs are 'over capacity' and 'usage limit exceeded.' An 'agent unavailable' banner usually indicates an autonomous agent hit the same throttling wall. Generic errors like 'unable to connect' or 'plugin failed' point to a different root cause: disabled plugins, expired OAuth tokens, or Sentinel connector configuration issues that are unrelated to SCU capacity.

Once confirmed as throttling, navigate to the Security Copilot in-product usage dashboard scoped to the specific workspace reporting errors. The dashboard shows SCU consumption over time, broken down by usage type. Look for three patterns:

Spikes at specific hours. Autonomous agents and Logic Apps connectors typically run on schedules, so a throttling event starting at 2:00 AM and lasting 90 minutes often points to a scheduled agent sweep rather than analyst activity. The timing is the tell.

Sustained baseline consumption. If the workspace is running near its provisioned SCU ceiling continuously, the capacity is simply undersized for the interactive workload. No amount of optimization fixes a persistent gap between provisioned allocation and actual demand.

Sudden jumps from a flat baseline. A usage pattern that is flat then spikes suggests a promptbook or Logic Apps workflow was triggered, possibly accidentally or by a misconfigured automation rule.

If the dashboard shows usage well below the provisioned SCU ceiling at the time of the throttling complaint, the error is probably not SCU exhaustion. In that case, skip ahead to the Known Failure Cases section, because adding SCUs will not resolve a permissions error or a token limit overflow.

Four levers are available once you have confirmed a workspace is hitting its SCU ceiling.

Option 1: Purchase additional provisioned SCUs for the throttled workspace. Navigate to the Azure portal, find the Security Copilot capacity resource, and increase the provisioned SCU count for the workspace in question. This is the most direct fix and takes effect within minutes. Use the SCU capacity calculator at securitycopilot.microsoft.com/calculator to estimate a sustainable allocation before committing to a tier you cannot easily walk back. The calculator takes inputs for number of analysts, Defender workloads, Intune usage, Purview usage, and Entra usage, and returns a recommended SCU-per-hour estimate based on expected workload.

Option 2: Increase the overage SCU limit. Overage SCUs function as a burst buffer above the provisioned ceiling. If throttling is intermittent rather than continuous, raising the overage limit from zero to a moderate number absorbs peak loads without committing to a higher provisioned baseline. Overage SCUs are billed per use, so the cost scales with actual consumption rather than reserved capacity. For teams with unpredictable but infrequent bursts, this is often more cost-effective than raising provisioned SCUs.

Option 3: Distribute the workload across two workspaces. If a single workspace is handling both interactive analyst prompts and autonomous agent workloads, separating them into two workspaces with their own SCU allocations gives each workload a dedicated budget. Analyst-facing workspaces get a tighter overage limit to bound costs; agent workspaces get higher overage headroom or more provisioned SCUs to handle burst sweeps without competing with live investigations.

Option 4: Throttle or disable autonomous agents. Agents, Promptbooks invoked via Logic Apps, and scheduled Copilot Studio workflows all consume SCUs from the workspace they run in, drawing from the same pool as interactive prompts. If an autonomous agent sweep is exhausting the workspace budget before analysts start their shift, disable or reduce the agent's run frequency in the agent configuration, or move the agent workload to a dedicated workspace with its own SCU allocation.

One constraint to be aware of: you cannot transfer SCUs from one workspace to another at runtime. Reallocation requires editing the capacity resource in Azure, which affects the workspace's total ceiling, not the distribution of a shared pool.

After adjusting SCU allocation, do not declare the problem solved based on analyst reports alone. The in-product usage dashboard shows near-real-time consumption; monitor it for at least 30 minutes after the change while analysts run their standard investigation workflows.

Specific validation steps:

1. Have at least two analysts run prompts concurrently in the affected workspace immediately after the allocation change. Single-user testing does not reproduce contention, since throttling is a capacity-ceiling problem that depends on simultaneous demand.

2. If a promptbook or Logic Apps workflow was identified as the consumption spike source, trigger it manually in the adjusted workspace and confirm the usage dashboard shows it staying within the new SCU ceiling without throttling. Watch the dashboard during the trigger, not after.

3. Check the error messages directly by having analysts attempt the workflows that previously produced throttling errors. The 'over capacity' and 'usage limit exceeded' banners should not appear. If they do, check whether a new autonomous agent run coincided with the validation window and suppress it temporarily to isolate the interactive workload.

4. If autonomous agents run on a schedule, wait for the next scheduled run time and monitor the dashboard through that window. Confirm the new provisioned allocation or overage headroom absorbs the agent burst without producing throttling errors during the overlap with analyst activity.

If validation passes for a full business day without throttling reports, the allocation change is stable. Continue monitoring the usage dashboard weekly for the first month, since team usage patterns often shift as analysts discover new prompts, promptbooks, and agent capabilities.

Not every 'over capacity' or 'agent unavailable' error indicates a true SCU shortage. Several conditions produce identical or similar error messages without being capacity problems.

Token context limits, not SCU limits. Security Copilot uses large language models that have limits on how much content they can process in a single session, known as the token limit. Long sessions, verbose plugin output, or very large script analysis requests can hit the token ceiling and produce a session error that resembles throttling. The difference: token errors typically occur mid-session on a specific complex prompt rather than affecting all analysts simultaneously. The fix is to break large prompts into smaller steps or reduce the amount of plugin data the model is asked to process at once. Adding SCUs does not expand the token context window.

Plugin authentication failures. If a plugin's OAuth token has expired or its API key has rotated without being updated in Security Copilot, the plugin will fail and may surface a generic availability error. Check each enabled plugin's authentication status under the plugin settings and re-authenticate any that show errors. This is a common cause of 'agent unavailable' errors that are misdiagnosed as throttling.

Microsoft Entra permission mismatches. If an analyst is accessing a workspace their Security Copilot role does not cover, or if the workspace configuration lacks the necessary Microsoft Entra permissions for the plugins it uses, access errors can appear as availability errors. Verify the analyst's Security Copilot role assignment and confirm the workspace's plugin permissions are correctly scoped.

Overage SCUs set to zero with active agent traffic. If overage SCUs are set to zero and the workspace regularly runs autonomous agents, the provisioned SCU ceiling is an absolute cap with no burst headroom. Any agent invocation that pushes usage above the provisioned level fails immediately without a grace period. The fix is to either raise the overage limit above zero or disable agents in that workspace and move them to one with a dedicated allocation.

Escalate to Microsoft support when throttling errors persist after you have confirmed all of the following:

• The throttled workspace's SCU allocation, both provisioned and overage, has been increased to a level the usage dashboard shows is not being reached.
• Autonomous agents in that workspace have been audited and their schedules adjusted to avoid overlap with peak analyst hours.
• Overage SCUs are set above zero to handle burst traffic.
• The error messages are specifically 'over capacity' or 'usage limit exceeded,' not plugin failures, token limit overflows, or permission errors.
• The workspace is not in the middle of a planned Microsoft maintenance window for the Security Copilot backend.

If throttling continues despite adequate SCU headroom shown in the usage dashboard, there may be a backend capacity issue on Microsoft's end that requires engineering investigation. This scenario is uncommon but documented.

When opening a support case, collect the following before submitting:

• The workspace ID, found in Security Copilot settings or the Azure portal.
• Screenshots of the usage dashboard showing the consumption pattern before and after the allocation change.
• The exact error message text that analysts are seeing, including any error codes displayed.
• Timestamps of specific throttling incidents correlated to analyst activity.
• A list of active autonomous agents in the workspace and their configured run schedules.

Microsoft's support SLA for capacity issues depends on your support tier. Premier and Unified support customers receive faster initial response times. For production-impacting throttling where analyst workflows are blocked, classify the case as severity B or higher when opening the ticket.