Lesson 36 — Governance and Access Control
Security Copilot can surface sensitive security evidence, connect to powerful plugins and become embedded across everyday SOC workflows.
That makes governance an operational requirement—not an administrative afterthought.
This lesson explains how to design access around Owner and Contributor roles, underlying service permissions, least privilege, plugin governance, auditing, acceptable use and accountable human decision-making.
What you will learn
Build a controlled and auditable Security Copilot operating model.
Security Copilot governance workflow
↓
Identify users and required data
↓
Assign minimum Copilot platform role
↓
Assign minimum service permissions
↓
Approve plugins and file-upload rules
↓
Define prompt and acceptable-use policy
↓
Configure audit and review responsibilities
↓
Train users before production access
↓
Review roles, plugins and exceptions regularly
↓
Remove obsolete access
Governance control model
| Control area | Mechanism | Question |
|---|---|---|
| Platform | Owner and Contributor | Who can use or administer Copilot? |
| Security data | Product-specific RBAC | Which evidence may they access? |
| Plugins | Availability and custom-plugin settings | Which integrations are trusted? |
| Data | Prompts, responses, files and sharing controls | What information may enter the workflow? |
| Audit | Purview audit and DSPM for AI | Can important activity be reconstructed? |
| Accountability | Owners, approvals and review cycles | Who remains responsible? |
Learning objectives
Understand Owner and Contributor roles; separate platform and data access; apply least privilege; govern plugins and uploads; use audit capabilities; define acceptable use and periodic reviews.
What is Security Copilot governance?
Governance defines who may use Security Copilot, which data and plugins they can access, what actions are permitted, how activity is audited and who remains accountable.
Platform access versus data access
Security Copilot roles control Copilot capabilities, while Defender, Sentinel, Intune, Purview and other services continue to enforce their own permissions.
Security Copilot Owner
Owners administer Security Copilot workspace settings and governance capabilities.
Security Copilot Contributor
Contributors can use the platform and create sessions but do not automatically receive access to security data.
Copilot roles are platform roles
Owner and Contributor are Security Copilot roles, not Microsoft Entra directory roles.
Keep at least two owners
Security Copilot retains at least two owners to reduce the risk of losing administrative access.
Use least privilege
Give users only the Copilot and service permissions required for their duties.
Do not grant Global Administrator for convenience
Highly privileged directory roles should not be assigned solely to provide Copilot access.
Underlying permissions remain in force
Security Copilot does not bypass product-specific RBAC.
Sentinel example
A Contributor still needs an appropriate Sentinel role before Copilot can access workspace incidents and data.
Intune example
Intune data remains governed by Intune RBAC and scope controls.
Defender example
Defender XDR data remains governed by Defender permissions and unified RBAC where configured.
Purview example
Purview data remains subject to appropriate Purview roles and access.
Separate administration from investigation
Most analysts need investigation access, not platform-wide administration.
Create an access matrix
Map each job function to Copilot role, required products, plugins, actions and approval requirements.
Use groups
Role-assignable groups can simplify joiner, mover and leaver processes.
Review privileged access
Owner and high-impact service roles deserve more frequent review.
Use Conditional Access
Protect Copilot access with organisational Conditional Access controls where appropriate.
Strong authentication
Security operations identities should use strong authentication consistent with organisational policy.
Joiner process
New analysts should receive only the access required for their starting responsibilities.
Mover process
Role changes should trigger review of Copilot, plugin and service access.
Leaver process
Departing users should lose Copilot and connected service access promptly.
Plugin governance
Plugins expand the data and capabilities available to Security Copilot and therefore require governance.
Owners control plugin settings
Owners can control who may add custom plugins and which preinstalled plugins are available.
Custom plugins
Custom plugins should be reviewed for authentication, data access, actions, reliability and security before wider use.
Test at limited scope
Validate custom plugins with a restricted audience before organisation-wide availability.
Preinstalled plugin restrictions
Owners can restrict preinstalled plugin availability, including impact on embedded experiences.
Document plugin dependencies
Promptbooks, agents and workflows should record the plugins they depend on.
Review third-party data handling
Understand what data a non-Microsoft plugin receives, stores and processes.
Protect plugin credentials
API keys, OAuth connections, service principals and secrets should be governed and rotated.
Control file uploads
Owners can configure whether Contributors and Owners may upload files for Copilot to reference.
Treat uploads as sensitive
Investigation files can contain malware, credentials, customer data, personal information and regulated content.
Define upload rules
Specify which files and classifications may be uploaded and for what purpose.
Use minimum necessary data
Only provide the information needed to complete the security task.
Define prompt data rules
Document what analysts may and may not include in prompts.
Protect secrets
Passwords, tokens, API keys and private keys should not be casually included in prompts.
Acceptable use
Define approved tasks, prohibited uses, validation requirements and escalation rules.
Evidence validation
Generated answers should not automatically be treated as authoritative evidence.
High-impact decisions
Account disablement, device isolation, blocking and regulatory decisions require approved human review.
Govern promptbooks
Production promptbooks should have owners, versions, audiences, required sources and review dates.
Govern agents
Agents require clear ownership, permissions, triggers, plugin dependencies and monitoring.
Auditability
Security Copilot activity should be reviewable for security, operations and compliance.
Purview Unified Audit Log
Purview can provide visibility into Security Copilot administrative events and activity metadata when configured.
DSPM for AI
DSPM for AI can provide additional visibility into Security Copilot prompt and response pairs.
Admin events
Audit records can cover changes to tenant settings, plugins, agents, triggers and promptbooks.
User activity metadata
Audit records can show user interactions and activity timing.
Restrict audit access
Prompt and response content may contain highly sensitive security data and should be tightly controlled.
Define audit retention
Retention should align with organisational investigation and compliance requirements.
Review anomalous use
Look for unusual plugin changes, sensitive-data access or activity outside normal operating patterns.
Create a governance register
Track Owners, Contributors, groups, plugins, promptbooks, agents, settings, approvals and review dates.
Assign accountable owners
Every major governance object should have a named business or technical owner.
Separation of duties
Where practical, separate those who build powerful integrations from those who approve production use.
Document exceptions
Temporary elevated access should include justification, owner, expiry and review.
Review after incidents
Incidents involving Copilot or privileged access should trigger targeted governance review.
Review after platform changes
New agents, plugins and platform capabilities may change the risk profile.
Data-sharing settings
Owners should understand and document the organisation's Security Copilot data-sharing configuration.
Customer Data
Prompts, retrieved information, responses, pinned items and file uploads can form part of Security Copilot Customer Data.
Privacy principles
Use only the security information required for a legitimate operational purpose.
Transparency
Reports and investigations should make it clear where Copilot materially contributed.
Train users before access
Users should understand prompting, validation, sensitive-data handling and acceptable use.
Train Owners separately
Owners need deeper knowledge of plugin, audit, upload and data-governance settings.
Final governance principle
Security Copilot should follow the same disciplined identity, least-privilege, data-protection and accountability principles as the rest of the security environment.
Example Security Copilot access matrix
| Job function | Copilot role | Typical access | Governance note |
|---|---|---|---|
| Tier 1 SOC analyst | Contributor | Assigned Defender/Sentinel investigation data | No platform-wide administration. |
| Tier 2 investigator | Contributor | Broader investigation and hunting data | Plugins only where approved. |
| Threat hunter | Contributor | Approved hunting workspaces and telemetry | Scope aligned to duties. |
| SOC platform owner | Owner | Administrative access plus required data | Controls governance settings. |
| Audit reviewer | As required | Purview audit/DSPM visibility | Prompt content tightly restricted. |
Training note: This is an illustrative governance model, not a Microsoft role-assignment prescription.
Example governance review prompt
Agent Foskett investigation: “Everyone Was an Owner”
↓
All four were made Owners because it was easy
↓
The pilot expanded to eighteen analysts
↓
The original access pattern was copied
↓
Nearly everyone became an Owner
↓
A custom plugin was added for testing
↓
It was accidentally made available more broadly than intended
↓
No malicious activity occurred
↓
But the governance review exposed the real problem
↓
Analysts who only needed investigation access could change platform settings
↓
Plugin administration and analyst duties had been mixed together
↓
Agent Foskett rebuilt the access matrix
↓
Investigators became Contributors
↓
Only designated platform administrators remained Owners
↓
Defender and Sentinel access was reviewed separately
↓
Custom plugins gained approval and testing controls
↓
The SOC lost no useful capability
↓
It stopped confusing convenience with permission
Governance checklist
| Area | Question | Control |
|---|---|---|
| Platform | Who needs Owner versus Contributor? | Assign the lowest sufficient role. |
| Data | Which security products are required? | Apply product RBAC separately. |
| Plugins | Which integrations are approved? | Restrict and vet plugin availability. |
| Files | Who may upload artefacts? | Configure upload permissions and handling rules. |
| Prompts | What sensitive information may be used? | Define acceptable-use policy. |
| Audit | Can important activity be reconstructed? | Enable and review appropriate logging. |
| Review | Are roles and plugins still required? | Run periodic access reviews. |
| Ownership | Who is accountable? | Maintain named owners and a governance register. |
Key takeaways
- Owner and Contributor roles control Security Copilot platform access, not automatic access to security data.
- Underlying Defender, Sentinel, Intune and Purview permissions remain in force.
- Least privilege should be applied to both Copilot and every connected service.
- Owners can govern plugins and file-upload settings.
- Custom plugins should be vetted before wider use.
- Prompts, responses and uploaded files may contain sensitive Customer Data.
- Purview audit capabilities can provide visibility into Security Copilot activity.
- Prompt and response visibility requires strong privacy and access controls.
- Acceptable-use policy should define validation, data handling and approval requirements.
- Human accountability remains the final control for consequential decisions.
Related Agent Foskett resources
Continue Module 4 — Operational Security Copilot
Security Copilot governance and access control
Security Copilot uses Owner and Contributor platform roles while underlying Microsoft security products continue to enforce their own data permissions. Governance should combine least privilege, plugin controls, audit logging, acceptable use and accountable human oversight.
