5.3.1. Workspaces, Permissions, and Roles
💡 First Principle: Security Copilot's access to sensitive security data means its permission model has to be as deliberate as any other security tool covered in this guide — a workspace scopes what data and capabilities are available, and roles determine who can use or configure that workspace.
Configuring workspaces for Security Copilot establishes the boundary for which data sources, plugins, and capabilities are available within that workspace — organizations may use multiple workspaces to segment access by team or sensitivity level. Managing permissions and roles controls who can interact with Copilot at all, and separately, who can configure its settings, plugins, and connected sources — a distinction similar to the Sentinel Reader/Contributor split covered in 5.2.1.
⚠️ Exam Trap: Having access to the underlying data source (say, full Sentinel Contributor access) doesn't automatically grant equivalent access through Security Copilot — Copilot's own workspace permissions govern what's queryable through it, independent of the underlying source system's own RBAC.
Reflection Question: Why might an organization want Security Copilot workspace permissions to be more restrictive than a given analyst's direct Sentinel access?
