Policy Configuration

Policies are the core enforcement mechanism in Noxys. They define which AI interactions are allowed, coached, or blocked based on real-time conditions.

Policy Fundamentals

A policy consists of:

Component	Purpose	Example
Name	Human-readable description	"Block PII on ChatGPT"
Description	Optional context	"Prevents sensitive data sharing on US-based services per policy #20260315"
Conditions	When the rule applies (AND logic)	platform_id == "chatgpt" AND risk_score > 0.8
Action	What happens on match	Block / Coach / Log
Priority	Execution order (lower = first)	10
Enabled	Active or disabled toggle	On / Off

Creating Policies

Step 1: Access Policy Creation

1. Go to Policies in the sidebar
2. Click + New Policy
3. Fill out the form

Step 2: Basic Information

Field	Required	Notes
Name	Yes	Unique, max 200 chars. Example: "Block PII on ChatGPT"
Description	No	Max 500 chars. Include compliance reference if applicable
Enabled	No	Defaults to off. Toggle on to enforce immediately
Priority	No	0-1000 (default: 100). Lower = evaluated first

Step 3: Add Conditions

Conditions determine when a policy applies. All conditions must match (AND logic).

To add a condition:

1. Click + Add Condition
2. Select a field from dropdown
3. Choose an operator
4. Enter a value
5. Click Add

Repeat to add multiple conditions (all must be true for policy to trigger).

Step 4: Choose Action

Select one of three actions:

Action	Behavior	When to Use
Block	Interaction is prevented	For high-risk or non-compliant scenarios
Coach	Warning appears, user can send anyway	For educational nudges
Log	Silently logged, no UI shown	For monitoring and audit trails

Step 5: Review & Create

1. Review all details
2. Click Create Policy

The policy is created but disabled by default (good for testing).

3. Toggle Enabled to activate

Policy Conditions Reference

Available Fields

Platform Identifier

Field: platform_id Operators: eq (equals), neq (not equals), in (list), nin (not in list) Values: String (platform name)

Examples:

platform_id eq "chatgpt"
platform_id neq "claude"
platform_id in ["chatgpt", "gemini"]
platform_id nin ["deepseek", "grok"]

Supported platforms: chatgpt, claude, gemini, deepseek, perplexity, mistral, copilot, poe, huggingchat, grok, mammouth, typingmind, openrouter, windsurf, cursor

Risk Score

Field: risk_score Operators: gt (>), gte (≥), lt (<), lte (≤), eq (=) Values: Float (0-1)

Interpretation:

• 0.0 = No PII detected
• 0.1-0.3 = Low risk
• 0.3-0.7 = Medium risk
• 0.7-0.9 = High risk
• 0.9-1.0 = Critical risk

Examples:

risk_score gte 0.8          # Block high-risk only
risk_score gt 0.5           # Block medium+ risk
risk_score eq 0             # Block only if no PII (inverse logic)
risk_score lt 0.2           # Block only if low risk (unusual)

Direction

Field: direction Operators: eq Values: "outbound" (user sending to AI) or "inbound" (AI response)

Examples:

direction eq "outbound"     # Monitor user inputs
direction eq "inbound"      # Monitor AI responses (rare use)

Note: Currently, only outbound (prompts) are monitored. Inbound support coming in v0.2.

Interaction Type

Field: interaction_type Operators: eq Values: "prompt", "completion", "tool_call", "embedding"

Examples:

interaction_type eq "prompt"      # Block prompts only
interaction_type eq "tool_call"   # Block function calls only

User ID / Email

Field: user_id or user_email Operators: eq, neq, contains Values: UUID, email address, or wildcard pattern

Examples:

user_email eq "alice@acme.fr"
user_email contains "@finance.acme.fr"
user_id eq "uuid-123-456"

Department / Group

Field: department (requires SSO) Operators: eq, neq, in, nin Values: String (from Entra ID, LDAP, SAML)

Examples:

department eq "Finance"
department in ["Finance", "Legal", "HR"]
department neq "Engineering"

Requires: SSO enabled (Entra ID, LDAP, SAML, OIDC)

Classification Count

Field: classification_count Operators: gte (≥), gt (>), lt (<), lte (≤), eq Values: Integer (0+)

Examples:

classification_count gte 1      # Any PII detected
classification_count gte 2      # Multiple PII types
classification_count gt 3       # More than 3 PII matches

Classification Types

Field: classification_types Operators: contains, not_contains, intersects, not_intersects Values: String (PII type name) or list

Examples:

classification_types contains "EMAIL"                    # Contains email
classification_types contains "CREDIT_CARD"             # Contains credit card
classification_types intersects ["EMAIL", "PHONE"]      # Contains any of these
classification_types not_contains "FR_NIR"             # Excludes social security

Available types: EMAIL, PHONE, CREDIT_CARD, IBAN, FR_NIR, FR_SIRET, FR_SIREN, MEDICAL_TERM, LEGAL_REFERENCE, API_KEY, IP_ADDRESS

Source

Field: source Operators: eq, neq, in Values: "browser_extension", "proxy", "endpoint_agent", "api"

Examples:

source eq "browser_extension"
source in ["browser_extension", "api"]

Data Region

Field: data_region (requires service mapping) Operators: eq, neq, in Values: "EU", "US", "APAC", "UNKNOWN"

Examples:

data_region neq "EU"        # Non-EU services
data_region eq "US"         # US-based services only

Example Policies

1. Block All DeepSeek Usage

Use case: Organization policy prohibits Chinese AI services.

Policy Name: Block DeepSeek
Description: Organizational compliance - prohibited vendor
Enabled: Yes
Priority: 10
Action: Block

Conditions:
  - platform_id eq "deepseek"

Effect: Any attempt to use DeepSeek is blocked. User sees red banner.

---

2. Coach Users on PII (Non-Blocking)

Use case: Educate users about data sharing without blocking work.

Policy Name: Coach on Sensitive Data
Description: Nudge users to review PII before sending
Enabled: Yes
Priority: 20
Action: Coach

Conditions:
  - classification_count gte 1
  - risk_score gte 0.5

Effect: Any message with PII gets a yellow warning. User can still send.

---

3. Block PII on US-Based Services

Use case: Comply with EU data sovereignty (no US cloud).

Policy Name: Block PII on US Services
Description: GDPR compliance - prevent US exposure
Enabled: Yes
Priority: 15
Action: Block

Conditions:
  - data_region eq "US"
  - classification_types contains "EMAIL"
  OR
  - data_region eq "US"
  - classification_types contains "PHONE"
  OR
  - data_region eq "US"
  - classification_types contains "CREDIT_CARD"

Effect: Emails, phone numbers, and credit cards are blocked on ChatGPT, Gemini, etc.

---

4. Block Finance Team from Non-EU Services

Use case: Department-specific policy (requires SSO).

Policy Name: Finance - EU Services Only
Description: Finance dept restricted to EU cloud providers
Enabled: Yes
Priority: 5
Action: Block

Conditions:
  - department eq "Finance"
  - data_region neq "EU"

Effect: Finance team members cannot use non-EU AI services.

---

5. Log All API Key Usage

Use case: Detect potential credential leaks.

Policy Name: Log API Keys
Description: Monitor API key leakage attempts
Enabled: Yes
Priority: 30
Action: Log

Conditions:
  - classification_types contains "API_KEY"

Effect: Silent logging. Admins can review in Interactions later.

---

6. Block High-Risk Medical Data (Healthcare)

Use case: HIPAA compliance.

Policy Name: Block Medical Data on Unsecured Services
Description: Protect patient PII per HIPAA
Enabled: Yes
Priority: 5
Action: Block

Conditions:
  - classification_types contains "MEDICAL_TERM"
  - source eq "browser_extension"

Effect: Patient names, diagnoses, etc., are blocked from public AI services.

---

7. Restrict Specific Users to Approved Services

Use case: Contractor or partner access control.

Policy Name: Contractor - Claude Only
Description: External partner limited to Claude
Enabled: Yes
Priority: 10
Action: Block

Conditions:
  - user_email contains "@partner-corp.com"
  - platform_id neq "claude"

Effect: Partner users can only access Claude. All other services blocked.

---

8. French Social Security Numbers - Strict Block

Use case: French GDPR compliance (FR_NIR is sensitive).

Policy Name: Block FR Social Security (NIR)
Description: FR_NIR never allowed per CNIL guidance
Enabled: Yes
Priority: 1
Action: Block

Conditions:
  - classification_types contains "FR_NIR"

Effect: Any mention of French social security number blocks the interaction.

Policy Evaluation Order

When an AIInteraction arrives at the backend:

1. Load all ENABLED policies
2. Sort by PRIORITY (ascending: 0, 5, 10, 15, ...)
3. For each policy:
   a. Evaluate all conditions with AND logic
   b. If all conditions match:
      - Apply action (Block/Coach/Log)
      - Stop evaluation (don't check remaining policies)
      - Create audit record
   c. If any condition fails:
      - Move to next policy
4. If no policies matched:
   - Log with action = "Allowed"

Example Walkthrough

Scenario: User alice@acme.fr sends a message with an email address to ChatGPT.

Interaction Data:

platform_id: "chatgpt"
user_email: "alice@acme.fr"
department: "Finance"
risk_score: 0.25
classification_types: ["EMAIL"]
classification_count: 1
data_region: "US"

Policies (enabled, by priority):

1. Priority 5: "Finance - EU Services Only" (Block if Finance + non-EU)
2. Priority 10: "Block PII on US Services" (Block if US + EMAIL/PHONE)
3. Priority 20: "Coach on Sensitive Data" (Coach if PII + risk > 0.5)

Evaluation:

Step	Policy	Condition	Result	Action
1	Finance - EU	department eq "Finance" ✓ AND data_region neq "EU" ✓	MATCH	Block
—	—	(Stop here, don't check Policy 2 or 3)	—	—

Result: Message is Blocked by "Finance - EU Services Only".

Admin sees: Policy violation, policy ID, timestamp.

---

Editing Policies

Modify a Policy

1. Go to Policies
2. Click the policy name
3. Click Edit
4. Change any field:
   • Name, description
   • Add/remove conditions
   • Change action
   • Adjust priority
5. Click Save

Effect: Updated policy takes effect immediately for all future interactions.

Historical interactions are unchanged (their decision record is immutable).

Enable/Disable Without Editing

1. Go to Policies
2. Find the policy in the list
3. Click the Enabled toggle

Off = policy not evaluated. On = policy evaluated.

Useful for:

• Testing new policies
• Temporarily pausing a rule during investigation
• A/B testing effectiveness

Duplicate a Policy

1. Click a policy
2. Click ⋮ More → Duplicate
3. Edit the copy (it's disabled by default)
4. Click Save

Useful for creating similar policies with slight variations.

Deleting Policies

1. Click the policy
2. Click Delete
3. Confirm: "Are you sure? This action is permanent."

Important: Deleting a policy does NOT delete historical records. All past interactions remain in the audit log forever.

After deletion: New interactions skip the deleted policy during evaluation.

Policy Best Practices

1. Start Restrictive, Relax Over Time

Bad: Create vague policies that block half your usage.

Good: Start with Log-only policies to understand usage patterns. Graduate to Coach. Finally, Block only clear violations.

Week 1: Log all DeepSeek usage
       → Understand how much is used
Week 2: Coach on PII (non-blocking)
       → Train users
Week 3: Block PII on ChatGPT
       → Enforce compliance

2. Use Descriptive Names

Bad: "Policy 1", "Rule A"

Good: "Block PII on ChatGPT", "Coach Finance on US Services"

Names should tell you the intent without reading conditions.

3. Document Context in Description

Name: Block DeepSeek
Description: Organizational decision per security review 2026-03-15.
Complies with EU AI Act Article 4 (prohibited practices).
Approved by: Security Committee (Chair: Jane Doe)

4. Manage Priority Carefully

Lower-priority (lower number) policies should be most important:

Priority 1:  Block FR_NIR (GDPR critical)
Priority 5:  Block PII on US (data sovereignty)
Priority 10: Block DeepSeek (organizational policy)
Priority 20: Coach on High Risk (educational)
Priority 100: Log all (default)

5. Test with Log-Only First

Never immediately Block. Always test:

1. Create policy with Action = Log
2. Run for 1-2 days
3. Check Interactions to see what would be blocked
4. If acceptable, change Action to Block
5. Enable

6. Avoid Overly Complex Conditions

Bad: 8 conditions, hard to understand logic

Good: 2-3 clear conditions, one policy per intent

If you need complex logic, split into multiple policies with different priorities.

7. Use Negation Carefully

Confusing:

NOT platform_id = "claude"

Clear:

platform_id in ["chatgpt", "gemini"]

Positive conditions are easier to understand.

Common Policy Patterns

Pattern 1: Restrict by Vendor

Block specific vendors (e.g., Chinese, Russian):
  platform_id in ["deepseek", "grok"]
  Action: Block

Pattern 2: Protect Sensitive Departments

Block non-EU services for Finance/Legal:
  department in ["Finance", "Legal"]
  data_region neq "EU"
  Action: Block

Pattern 3: Education Over Enforcement

Coach on any PII:
  classification_count gte 1
  Action: Coach

Pattern 4: Compliance-Driven

Block specific PII types:
  classification_types contains "FR_NIR"
  Action: Block

Pattern 5: High-Risk Only

Block only high-risk interactions:
  risk_score gte 0.8
  Action: Block

Monitoring Policy Effectiveness

Check Trigger Count

In the Policies list, see "Triggered" column (last 7 days):

• 0 triggers = Policy never matched (too strict, or rare scenario)
• 1-10 triggers = Healthy enforcement
• 100+ triggers = May need adjustment (too broad?)

Review False Positives

If users complain policies are too strict:

1. Go to Interactions
2. Filter by policy decision: "Blocked"
3. Review a sample
4. Identify patterns (e.g., "always blocks on certain keyword")
5. Adjust condition (e.g., increase risk_score threshold)

A/B Test Policies

1. Create new policy with Coach (instead of Block)
2. Run for 1 week
3. Compare behavior change
4. Decide to upgrade to Block or revert

Next Steps

• PII Detection Types — Understand classification types
• Admin Console Guide — Manage policies in the UI
• Architecture Overview — How policies are evaluated

---

Need help?

• Email: support@noxys.eu
• Template policies: Available in console under Policy Templates
• Audit trail: All policy changes logged in Audit Log