Can Security Copilot agents run across Lighthouse-connected customer tenants?

Reviewed by ContraForce team · Updated 2026-09-04

> A Security Copilot workspace is a scoped, tenant-bound environment where users, automations, and agents operate, and security compute units cannot be shared between workspaces. Under the provisioned capacity model each tenant must provision a minimum of one SCU. Security Copilot is not documented as a capability of Defender multitenant management.

What is the unit of licensing and where does it apply?

Microsoft Security Copilot is licensed in security compute units. Under the provisioned capacity model, Microsoft states that each tenant must provision a minimum of one SCU to use Security Copilot. There is a separate path where eligible customers do not need to manually provision SCUs, so confirm which model applies before assuming a per-tenant purchase is mandatory.

The binding constraint for a service provider is not the minimum, it is the boundary. Microsoft states that SCUs, whether provisioned or overage, cannot be shared between workspaces. A workspace is described as a scoped, tenant-bound environment where users, automations, and agents operate.

So capacity bought in one tenant does not serve another, and an agent configured in one workspace does not operate in another.

What does that mean for a hundred-customer book of business?

The economics are per tenant by construction, and they do not consolidate.

There is a second effect that matters more than the first. Because Security Copilot is not surfaced in Defender multitenant management, a use case that is inherently cross-customer, such as confirming a setting is configured identically across every tenant, has no place to run. The capability is present in each tenant and absent between them.

Is there a documented path for Foundry agents across delegated tenants?

Microsoft documents no support for an agent executing across multiple customer Sentinel workspaces connected through Azure Lighthouse. That is a statement about the public reference rather than about what is technically possible: an absence of documentation, not a documented prohibition.

For a provider making an architectural commitment, the distinction is thin comfort. Building on an undocumented cross-tenant path means building on behaviour that carries no support statement and no compatibility guarantee.

What does provider-licensed AI change?

The constraint above is a licensing and workspace boundary rather than a technical ceiling, which means it is solved by where the AI is licensed rather than by how it is deployed.

ContraForce licenses agent capability to the provider and runs it across every connected customer workspace, so cost tracks the work rather than the customer count, and a cross-customer question has somewhere to execute. Incidents from every connected tenant land in one multitenant control plane, and Security Delivery Agents work them under Gamebooks that are defined once and applied everywhere.

Sources

• Microsoft Security Copilot, manage capacity
• Get started with Microsoft Security Copilot
• Microsoft Defender multitenant management requirements