Mission: Crafting Access Policies – Cipherscale Support Center

Abstract

An access policy is the core enforcement mechanism in Cipherscale. It defines who can access what, under which conditions, and with what action (Allow or Deny).

Overview

An access policy is the core enforcement mechanism in Cipherscale. It defines who can access what, under which conditions, and with what action (Allow or Deny). Every access request is evaluated against the list of active policies before traffic is permitted or blocked.

Instead of navigating a complex matrix of firewall rules, you use the Intent Bar to state who gets access to what. The AI handles the heavy lifting of mapping these identities to the correct resources and configuring the Access Policies. Access Policies become more effective when they are linked to Admission Rules, which evaluate the context in which access is requested. Refer to Mission: Context-Aware Security and [Reference] Relationship between Access Policies and Admission Rules

The Two Actions

Allow grants access to a resource when all policy conditions are met. It supports custom admission rules, meaning you can attach conditions such as location, time, or device posture to refine when the Allow applies.

Deny blocks access unconditionally. It can only use the default "Admission without Restrictions" rule — no custom conditions can be attached. It is used to explicitly block specific users, groups, or devices regardless of other policies.

Priority and Policy Matching

Policies are evaluated in priority order, according to the priority number assigned to the policy starting from 1 (highest or topmost). When an access request comes in, Cipherscale walks down the policy list "Top-Down" hierarchy and stops at the first policy that matches the request. Match is based on the source and destination. This is known as first-match enforcement.

This makes policy ordering critical. A few key principles to keep in mind:

Deny policies should generally be placed above Allow policies when you want to explicitly block specific users or devices that would otherwise be caught by a broader Allow policy below
More specific policies should sit above broader ones — for example, a policy targeting a specific user should be ranked higher than one targeting all groups
A policy that is never reached has no effect — if a broader Allow policy sits above a more specific Deny, the Deny will never be evaluated for users that match the Allow first

The Default Behavior

If no policy matches an access request, access is denied by default. Cipherscale operates on a zero-trust principle — nothing is permitted unless explicitly allowed by a matching policy.

Admission Rule Interaction

An admission rule does not grant or deny access on its own. It acts as a gate on an Allow policy — if the admission rule condition is not met, the Allow policy is skipped entirely and evaluation continues to the next policy in the list. This means a user may fall through to a lower-priority policy if their device or location doesn't satisfy the admission rule of a higher-priority Allow policy.

Key Things to Remember

Deny policies are unconditional — they always block regardless of device or location
Allow policies with admission rules are conditional — they only apply when the rule's conditions are satisfied
Policy order determines outcome — always review priority when troubleshooting unexpected access behavior
The default is always deny — if no policy matches, access is blocked

1. Creating a New Access Policy

Interaction Flow

Creating an Access Policy

Maximize your efficiency by navigating to SaaS Access / Private Access / Internet Access and choose Access Policy from Details Ribbon before entering prompts. You’ll gain instant visibility into the Detail Panes to verify Copilot’s actions and receive tailored Prompt Catalysts to help guide your next steps.

Different information is needed for the AI intent based on the type of access the policy applies to.

The Intent: What the AI Needs for Creating Access Policies for Private Access

Action (Required) — Allow or Deny
Source (Required) — at least one of: all users, all groups, all devices, specific users, specific groups (by name), or specific devices (by name)
Destination (Required) — at least one specific private resource, or "all private resources"
Admission rule (Optional) — which condition set to apply; defaults to "Admission without Restrictions" if omitted; Deny policies can only use the default rule
Policy name (Optional) — if not provided, one will be generated based on the destination
Description (Optional) — a short summary of the policy's purpose

The Intent: What the AI Needs for Creating Access Policies for SaaS Access

Action (Required) — Allow or Deny
Source (Required) — at least one of: all users, all groups, all devices, specific users, specific groups, or specific devices
Destination (Required) — at least one specific SaaS resource, or "all SaaS resources"
Admission rule (Optional) — which condition set to apply; defaults to "Admission without Restrictions" if omitted; Deny policies can only use the default rule
Policy name (Optional) — if not provided, one will be generated based on the destination
Description (Optional) — a short summary of the policy's purpose

The Intent: What the AI Needs for Creating Access Policies for Internet Access

Source (Required) — at least one of: all users, all groups, all devices, specific users (by email), specific groups (by name), or specific devices (by name)
Mode (Required) — one of: LOCAL (direct internet access from the device), RESTRICTED (block all internet access), or INTERNET_ACCESS_POINT (route internet traffic through a gateway)
Destination resource (Optional) — the internet access point resource to route traffic through; only applicable when mode is INTERNET_ACCESS_POINT
Admission rule (Optional) — which condition set to apply; defaults to "Admission without Restrictions" if omitted
Policy name (Optional) — if not provided, one will be generated based on the destination
Description (Optional) — a short summary of the policy's purpose

Note

The Default Internet Access Policy is a system-managed policy that guarantees all users, groups, and devices have constant access to the local internet. It holds a reserved, special-purpose priority level, exclusively for this default policy, which is always treated as the last (bottom) access policy. All your created policies automatically receive a higher priority. Consequently, the default policy is positioned below all custom policies in the evaluation order, serving as a foundational fallback that remains active regardless of other policies. It’s important to note that this policy cannot be modified or deleted, as its primary purpose is to prevent accidental disruptions to internet access for all users.

Interaction Flow

Step

Participant

Action/Content

1. The Prompt

Admin

"Allow all 'Admins' access to 'Complex SaaS' and apply the 'Windows USA Mon to Fri 8AM to 7PM EST' condition"

2. The Draft

AI Copilot

"Let me check the current policy configuration first!

Now let me check the existing resources and the Admins group!

Here's my planning summary:

Planning Summary

What I found:

✅ Admission rule: "Windows USA Mon to Fri 8AM to 7PM EST" exists — will reuse
✅ Resource: "Complex SaaS" exists with gateway "SmallGatewayQA" already assigned — will reuse
✅ Group: "Admins" exists
ℹ️ An existing policy "Allow access to Complex SaaS" already covers All Groups (which includes Admins) but uses "Admission without Restrictions". Your new policy will be a separate, more specific policy for Admins with the custom condition applied.

What I'll do:

Create 1 SaaS policy for the Admins group to access Complex SaaS with the "Windows USA Mon to Fri 8AM to 7PM EST" admission rule

Now creating the policy!

Create policy "Access to Complex SaaS"

This policy grants the Admins group access to the Complex SaaS resource during business hours on weekdays, with device posture and location restrictions enforced by the admission rule.

{
Policy Name:"Access to Complex SaaS",
Type:"SAAS",
Action:"Allow",
Source Group:"Admins",
Destination Resource:"Complex SaaS",
Admission Rule:"Windows USA Mon to Fri 8AM to 7PM EST"
}

Confirm or Cancel?

3. Validation

Admin

"Confirm."

4. Finalization

AI Copilot

"✅ Action confirmed, proceeding with execution of operation

The policy has been created successfully! Here's a summary:

✅ New Policy Created: "Access to Complex SaaS"

Field	Value
Type	SAAS
Action	Allow
Priority	3
Source	Admins group
Destination	Complex SaaS resource
Admission Rule	Windows USA Mon to Fri 8AM to 7PM EST

What this means for Admins:

✅ Must be on aWindowsdevice
✅ Must be located inUSA or Canada
✅ Must connectMonday–Friday, 8AM–7PM EST
❌ Access is denied outside these conditions"

5. Follow Up

AI Copilot

“Would you like to make any further changes?”

6. Prompt

Admin

“Assign the access policy for 'Complex SaaS' that has source as 'All Groups' a priority lower than the policy that was just created.”

7. Draft

AI Copilot

"Let me check the current SAAS policies and their priorities first!

I have all the information needed. Currently:

Order 1→ "Allow access to Complex SaaS" (All Groups) — needs to move to order4
Order 2→ "Allow Stas to access his SaaS" — stays at order2
Order 3→ "Access to Complex SaaS" (Admins) — stays at order3

I'll reorder now so the "All Groups" policy gets a lower priority (higher order number) than the newly created Admins policy.

Reorder 3 SAAS policies

Reorder SAAS policies to establish correct priority: the All Groups policy moves to lower priority (order 3), the Admins policy moves up (order 2), and Stas's policy remains at highest priority (order 1)."

{
Policy 1:"Allow Stas to access his SaaS",
Order:{
original:1,
delta:3
},
Policy 2:"Access to Complex SaaS (Admins)",
Policy 3:"Allow access to Complex SaaS (All Groups)"
}

Confirm or Cancel?

8. Validation

Admin

"Confirm."

9. Finalization

AI Copilot

"✅ Action confirmed, proceeding with execution of operation

Done! Here's the updated SAAS policy priority order:

Priority	Name	Source	Admission Rule
1	Allow Stas to access his SaaS	User:stas@example.com	Admission without Restrictions
2	Access to Complex SaaS	Group: Admins	Windows USA Mon to Fri 8AM to 7PM EST
3	Allow access to Complex SaaS	All Groups	Admission without Restrictions

The "Allow access to Complex SaaS" (All Groups) policy is now at priority 3 — lower than the Admins policy at priority 2. This means:

Admins will be evaluated against the Windows/USA/time-restricted policy first
All other groups will fall through to the unrestrictedpolicy at priority 3

Access Policy Prompt Examples

Access Policy Creation Prompt Examples

Create a private access policy that allows the HR group to access the HR Portal resource during business hours
Create a SaaS access policy that allows all users to access Salesforce with updated OS and disk encryption required
Create a private access policy that denies the Contractors group access to the Finance Database resource
Create an internet access policy that allows all users direct local internet access on weekdays from 9AM to 5PM UTC
Create an internet access policy that allows the Engineering group to route all internet traffic through the gateway
Create a SaaS access policy that allows only Windows devices from the US to access Google Workspace
Create a private access policy that allows userjohn@company.comto access the Dev Server resource
Create a private access policy that denies usercontractor@company.comaccess to all private resources

Access Policy Read Prompt Examples

List all access policies sorted by priority
List all private access policies
List all SaaS access policies
List all internet access policies
Show me the access policy named "Access to HR Portal"
Which policies are assigned the admission rule "Business Hours"?
Which policies apply to the HR group?
Which policies reference the Finance Database resource?
Show me all Deny policies
Show me all Allow policies with custom admission rules

Access Policy Update Prompt Examples

Update the policy "Access to HR Portal" to also include the Finance group as a source
Update the policy "Access to Salesforce" to use the admission rule "Updated OS with Encryption"
Update the policy "Access to Dev Server" to also include the Staging Server resource as a destination
Update the policy "Access to HR Portal" to apply to all groups instead of just the HR group
Update the policy "Access to Google Workspace" to also allow iOS devices
Change the admission rule on policy "Access to Finance App" to "Weekdays 9AM to 5PM UTC"
Remove the Engineering group from the source of policy "Access to Dev Server"

Access Policy Deletion Prompt Examples

Delete the access policy named "Access to HR Portal"
Delete all Deny policies for the Contractors group
Delete the access policy named "Access to Salesforce"

System State & Verification

Navigate to the Access section to which the access policy applies (e.g., SaaS Access) using the Navigation Menu and use the Access Policy tab on the Details Ribbon to verify the Copilot actions or view the current system state.

The Access Policies Data Grid for Internet Access: Click Access Policies on the Details Ribbon to view the data grid listing Access Policies with their Name and Priority, Source, Internet Mode, and Admission Rule. The copy icon appears when hovering over an Access Policy's name, making it easy to copy and paste it into the Intent Bar for use with a prompt. Search allows quick filtering of the rows to show the matching rows.

The Access Policies Data Grid for SaaS and Private Access: Click Access Policies on the Details Ribbon to view the data grid listing Access Policies with their Name and Priority, Source, Action, Destination, and Admission Rule. The copy icon appears when hovering over an Access Policy's name, making it easy to copy and paste it into the Intent Bar for use with a prompt. Search allows quick filtering of the rows to show the matching rows.

A Specific Access Policy's Data Grid: To view details for a specific Access Policy, click that policy's name. You will see details that were displayed earlier . To go back to the SaaS Applications Data Grid, click SaaS Applications from the breadcrumb.

Troubleshooting

Here is a list of troubleshooting tips for resolving access policy issues in Cipherscale:

Check Policy Priority and Order: When multiple access policies apply to a request, Cipherscale enforces the policy that is matched first based on the arranged order. If a user is unexpectedly blocked, check if a "Deny" policy is placed at a higher priority than their "Allow" policy. You may need to edit the order so that the correct policy is matched first.
Verify Linked Admission Rules: Every access policy must have an associated Admission Rule. An access policy is only enforced if the user successfully meets the prerequisite criteria of this linked admission rule, such as having the correct device posture, connecting from an allowed location, or accessing during an approved time window.
Confirm "Source" Assignments: Ensure that the specific User, Group, or Device you are trying to grant or restrict access for is correctly included as a "Source" value within the access policy.
Ensure a Gateway is Attached: Even if an access policy is perfectly configured and active, it will not be enforced if the destination resource (Private, SaaS, or Internet) does not have a Gateway assigned to it. Check that an online gateway is linked to the resource and has reachability.
Leverage AI Root Cause Analysis (RCA): Instead of manually parsing logs, you can use the AI-native conversational interface to instantly diagnose issues. By asking a plain-English question like, "Why can't User A access the Production Database?", the AI will automatically correlate your access policies, admission rules, real-time logs, and gateway reachability to surface the specific failure point.