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

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

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.

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

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.