Manage Guardrails

Use this guide when you need to create, review, publish, or maintain reusable guardrail policies for Pharaoh sessions and self-healing context.

Before You Start

You need an organization admin role.
You should know whether you are creating a brand-new policy, editing an existing baseline, or cloning a policy for a related workflow.
If another workflow depends on the policy, decide whether the change should affect future use of that same policy or whether you should clone first.

Before editing, identify the operational job the policy protects: diagnostic investigation, routine remediation, emergency recovery, or self-healing review. That decision should drive how permissive the rules and defaults are.

Step 1: Open The Guardrails Inventory

Open Guardrails from the Security navigation group.

The main page is the policy inventory. What you should expect:

a Search templates field
a Refresh action
a New template action
a template table when policies already exist
row navigation into the policy builder
clone and delete actions for existing templates

If no templates exist yet, Pharaoh shows Create your first guardrail template instead of an empty table.

Start here even when you already know which policy you need. The inventory tells you whether the right record already exists, whether another admin recently changed it, and which maintenance actions are available.

Step 2: Decide Create, Edit, Clone, Or Delete

Use this decision point before opening the policy builder:

Create a new template when the workflow needs a clean policy baseline.
Edit an existing template when the same workflow should use updated behavior in future sessions after the next publish.
Clone a template when you need a close variant but the original must remain available.
Delete only when operators should no longer be able to choose the template.

If you are unsure, open the template and review its description, matrix, and history before changing it. A short review prevents one broad policy from absorbing unrelated endpoint jobs.

Step 3: Create A New Policy

If you are starting from scratch:

Select New template.
Review the policy builder overview.
Enter a clear Template title.
Add a description that names the workflow, team, or endpoint class the policy protects.
Configure the platform and rule-family pages that matter for the workflow.
Enter a Change summary.
Select Publish v1 when the builder shows Ready to publish.

New policies use the v2 policy builder. The builder opens with Windows selected, but the overview matrix shows Windows, macOS, and Linux so you can see where a rule family is enforced, limited, evaluated, not enforced, or unavailable.

Create a separate template when a workflow needs a different risk posture, audit audience, or approval expectation. Do not overload one broad template for unrelated endpoint jobs.

Step 4: Use The Overview Matrix

The Overview page is the best place to check whether the policy matches endpoint runtime reality before you edit individual rules.

Use it to review:

Template title and Description
command, application, file, network, and AI behavior rows
Windows, macOS, and Linux columns
capability status for each platform and rule family
the default decision for each supported non-AI rule family

Treat unavailable or limited cells as important operator information, not just UI decoration. For example, Windows can support the current command/application host-execution profile, but Windows file and network policy pages are unavailable until the endpoint runtime can enforce those restrictions. macOS and Linux file rules can express stronger file access behavior, while network destination enforcement remains limited where Pharaoh cannot prove the destination strongly enough.

The matrix is also a draft review surface. A policy with no named rules may still have meaningful defaults, and the matrix helps you catch accidental broad allow, block, or audit-only behavior before publishing.

Step 5: Configure Rule Families

Use the left rail to move between Commands, Apps, Files, Network, and AI policy.

On each rule-family page:

Select Windows, macOS, or Linux in the platform switcher.
Read any unavailable-platform message before adding rules.
Use the table to review named rules from top to bottom.
Open an existing rule row to edit it, or use Add rule to create a new one.
Review the default row before leaving the page.

Named rules are evaluated top to bottom in the order shown. The table does not use a separate priority number, so keep the most specific rule above broader wildcard rules.

Command, application, file, and network rules use exact values or basic * wildcards. Do not enter comma lists or regular expressions. AI behavior rules use a natural-language policy field instead of a pattern.

Step 6: Set Defaults Deliberately

Command, application, file, and network pages include a Default row. This row applies when no named rule matches.

Review the default row for each supported platform before publishing:

Commands, applications, and network use actions such as Allow, Block, Require approval, and Log only.
Files use access modes such as Full access, Read-only, Read requires approval, Write requires approval, and Block.
Network also has an Unverifiable destinations row for destinations Pharaoh cannot resolve or prove strongly enough.
AI policy does not have a default row; unmatched AI requests continue through the normal non-guardrail flow.

Defaults are first-class policy decisions. A policy with only broad defaults can still allow, block, log, or require approval for a large amount of endpoint activity.

Step 7: Test A Rule Before Publishing

Rule editing opens a two-pane dialog.

Use the left pane to edit the rule or default decision. Use the right pane to run a live candidate test against the unsaved draft. The result card shows whether the candidate matched the current rule, fell through to the default, had no match, or was evaluated by the backend preview path.

Use live tests for representative examples before publishing:

a command the policy should block or approve
an application name or path that should match a rule
a file path that should become read-only or blocked
a network domain, IP, or CIDR that should match the intended rule
an AI request that should trigger the natural-language policy

A passing candidate test is a local rule check, not proof that every endpoint platform can enforce the policy. Always pair the test with the overview matrix and the platform switcher.

Step 8: Publish, Revert, Or Restore

The policy builder autosaves draft edits. Autosave does not make the draft active for future sessions.

Use the publish area in the header:

Unpublished draft, Autosaving, or Autosaved tells you the current draft state.
Ready to publish means the builder has no blocking validation errors.
Change summary records why the next version is being published.
Publish v<N> creates the next immutable published version.
Revert draft returns the draft to the latest published version.
Back to templates returns to the inventory.

Use History when you need to inspect or restore published versions. Restore as draft copies an older v2 version into the current draft after confirmation. It does not rewrite old history and it does not publish immediately. Review the restored draft, then publish it as the next version only if it is still the right policy.

Step 9: Understand Runtime And Evidence Impact

Published guardrail versions are what future sessions and self-healing workflows use. Existing sessions keep the guardrail snapshot that was selected when that work ran, so a later publish does not rewrite historical evidence.

At runtime, Pharaoh combines the published policy with endpoint capability data. Supported restrictions can be enforced by the endpoint runtime, limited restrictions may be evaluated or partially enforced depending on platform capability, and unavailable platform/domain combinations stay non-editable in the builder.

Evidence and audit views use the versioned guardrail snapshot plus endpoint-reported decisions and runtime violations. When you investigate a decision later, compare the session’s recorded guardrail version with the current policy. A newer policy may exist even though the historical session correctly used an older version.

Step 10: Clone Or Delete Safely

Use Clone when you want a distinct starting point for a new workflow.

Return to the inventory.
Select Clone on the source template row.
In Clone guardrail template, enter a New template name.
Save the clone.
Open the cloned record and adjust the description, matrix, defaults, and rules for the new workflow.

Prefer Clone over direct edits when active runbooks, support teams, or self-healing policies still depend on the current template behavior.

Use Delete only when you are certain the template should be removed.

Confirm operators no longer need to start sessions with that template.
Select Delete on the template row.
In Delete guardrail template, type the exact template name in Confirmation.
Complete the delete action only after the destructive action becomes enabled.

If you cannot confidently type the exact template name, stop and re-check the inventory. Deleting the wrong reusable template can remove a known-safe starting point for future sessions.

What Success Looks Like

You are done when all of the following are true:

the correct template appears in the inventory
opening the template row shows the expected draft in the policy builder
the overview matrix reflects the intended platform behavior
each supported rule family has the expected named rules and defaults
live tests cover the most important examples
History shows the published version you intended to create
any restored version was reviewed and published as a new version only when appropriate
any clone has a distinct name and separate record
any intended delete is confirmed and removed from the inventory