Control Policy Framework
This topic describes the control policy framework for Workforce AI Security. It explains the recommended policy structures for common control scenarios, why each policy is used, and which rule settings must be explicitly defined to achieve the intended behavior.
This topic focuses on policy intent and structure rather than step-by-step rule creation. For detailed instructions on creating and editing rules in the portal, see Manage Interactions.
Pattern 1 - Allowlist Access Policy
Goal
Approve only explicitly trusted AI applications.
Policy Benefit
Use an allowlist when you want maximum control and predictability. Only applications that are explicitly approved are accessible; everything else is blocked by default.
This approach is typically used when:
-
AI adoption is tightly governed.
-
Only a small number of tools are approved (for example, ChatGPT, Claude, Microsoft Copilot).
-
Shadow AI must be prevented from the outset.
Design Principle
-
Access is denied by default.
-
Only applications explicitly allowed by policy can be used.
Essential Parameters
This rule is a safety net: if traffic does not match any higher rule, it is blocked.
-
From the left menu, select Workforce AI > Manage Interactions > Access.
-
On the toolbar, click Create new.
-
On the right pane, edit the new rule:
-
Enter the rule name, for example, Block all apps - cleanup.
-
Select Entire organization to apply the rule for all users.
-
Select Any for the destination, so no filtering applies, and all applications are included.
-
Set Block as the rule action.
-
Optionally, in Comments, enter a description, such as Default cleanup rule – block all apps not explicitly allowed.
-
Click Save.
-
|
|
Important - Place this rule at the bottom of the Access rule list. |
Define which apps are allowed to bypass the “block all” rule.
-
On the toolbar, click Create new.
-
On the right pane, edit the new rule:
-
Enter the rule name, for example, Allow 3 major LLM.
-
Select Entire organization to apply the rule for all users.
-
For Destination, select Applications and then add only approved AI, for example, ChatGPT, Claude, and Microsoft Copilot.
-
Set Allow as the rule action.
-
Optionally, in Comments, enter a description, such as Allow GPT / Claude / Copilot.
-
Click Save.
-
What this policy does not cover
-
It controls which apps can be accessed, not what data can be sent.
-
Combine with Chats (DLP) policies to control content inside allowed apps.
Pattern 2 - Blocklist Access Policy
Goal
Block only known high-risk applications.
Policy Benefit
Use a blocklist when you want to allow most AI usage but block specific applications that are known to be risky or non‑compliant.
This approach is typically used when:
-
AI usage is already widespread
-
Only a small number of tools are explicitly disallowed
-
You want minimal disruption to users
Design Principle
-
Everything is allowed by default.
-
Only explicitly blocked applications are restricted.
Essential Parameters
-
From the left menu, select Workforce AI > Manage Interactions > Access.
-
On the toolbar, click Create new.
-
On the right pane, edit the new rule:
-
Enter the rule name, for example, Allow all apps - cleanup.
-
Select Entire organization to apply the rule for all users.
-
Select Any for the destination, so no filtering applies and all applications are included.
-
Set Allow as the rule action.
-
Optionally, in Comments, enter a description, such as Default cleanup rule – allow all apps not explicitly blocked.
-
Click Save.
-
|
|
Important - Place this rule at the bottom of the Access rule list. |
Define which apps are blocked.
-
On the toolbar, click Create new.
-
On the right pane, edit the new rule:
-
Enter the rule name, for example, Block specific LLM apps.
-
Select Entire organization to apply the rule for all users.
-
For Destination, select Applications and then add forbidden AI, for example, DeepSeek or Poe.
-
Set Block as the rule action.
-
Click Save.
-
Ensure Block specific LLM apps appears above the Allow all apps - cleanup.
-
Drag and drop the Block rule above the Allow rule.
-
Confirm the change.
Important consideration
Blocklist policies do not prevent sensitive data exposure on allowed apps.
They should almost always be combined with Chats (DLP) policies.
Pattern 3 - Managed vs. Unmanaged Application Control
Goal
Have same platform, maintain different trust levels.
Why it is Needed
The same AI platform can represent very different risk levels depending on whether it is used:
-
with a corporate (managed) account, or
-
with a personal (unmanaged) account
Risk is determined by data ownership and contractual control, not by the application name itself.
To define the managed account, see Managed Applications.
Design principle
-
Allow the platform only when it is managed.
-
Restrict or block the same platform when it is unmanaged.
Policy Structure
This scenario is implemented using two Chats (DLP) policy rules, both referring to the same AI platform, but with different scope and action.
Prerequisite: Make sure the Access policy for this application is Allow.
Create a Chats policy rule with these key settings:
-
Destination: Managed platforms
Select the platform and its Organization ID
Example:
-
Platform: ChatGPT
-
Organization ID: Corporate ChatGPT tenant
-
-
Action: Allow
This rule allows usage only when the platform (ChatGPT) is accessed through a managed corporate account (Corporate ChatGPT tenant).
Create a second Chats policy rule with these key settings:
-
Destination: Selected platforms
Select the same platform again
Example: ChatGPT
-
Action: Block or Prevent (depends on enforcement preference)
This rule applies to all remaining instances, which effectively means unmanaged (personal) usage.
Rule Order
-
Place the Allow managed platform rule above the Block/Prevent unmanaged platform rule.
-
Managed platforms match only corporate accounts.
-
Selected platforms match all instances.
-
The overlap between the two rules is intentional; rule order determines which one applies.
Pattern 4 - Discovery Mode
Goal
Observe usage before enforcing restrictions.
Policy Benefit
Discovery mode is designed for organizations that do not yet understand how AI is used internally. It helps you answer questions such as:
-
Which AI applications are in use?
-
What types of data are being shared?
-
Where does real risk actually exist?
Design principle
-
An Access policy rule allows access.
-
One or more Chat (DLP) policy rules with Detect action create visibility.
Essential Parameters
Create an Access policy rule with these key settings:
- Destination: Any
-
Action: Allow
This rule ensures that users can access AI applications while discovery data is collected.
Create one or more Chats policy rules with these key settings:
-
Destination: Any platform (or selected platforms)
-
Data Types: Select high-value categories relevant to your organization.
Examples: Credentials, Personal Data, Financial Data
-
Action: Detect
These rules log events only and do not block user activity.
Using Context Data Types
Context Data Types are used when:
-
Data does not follow a strict format.
-
You want to detect broad categories (for example, credentials in general).
-
You are in an exploratory phase and want wide visibility.
They are especially effective in discovery mode because they prioritize coverage over precision. For more information on Context Data Types, see Context Data Type.
What comes next
After reviewing detected events, convert selected rules from Detect to Ask, Block, or Prevent to begin enforcement.
Pattern 5 - Agent Policy Design
Goal
Controlling automated actions
Why agent policies are different
Agent policies control what actions AI agents can perform, not just which apps they access or what data they send.
Risk increases when agents:
-
invoke external tools
-
perform create/update/delete operations
-
operate autonomously at scale
Essential Parameters
-
Tool and operation scope - Which tools or CRUD operations are allowed
-
Action - Allow or Block
-
Platform context - Which agent platforms or MCP servers are affected
Agent policies should be designed conservatively and refined based on discovery data.