> ## Documentation Index
> Fetch the complete documentation index at: https://docs.guardway.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Policy
> The Policy hub — Endpoint Policy, AI Control (Org Level) and Access Profile — and what every setting in an Endpoint AI Policy does on your developers' machines.
**Policy** is one page with three tabs, under **Endpoint AI Risk › Policy**:
| Tab | What it holds |
| - | - |
| **Endpoint Policy** | The Endpoint AI Policies: one per group of machines, each with posture, detections, telemetry, AI Control switches and agent updates. The rest of this page. |
| **AI Control (Org Level)** | The organization-wide baseline every policy raises from: the **Controls**, the **Catalogs** of sanctioned skills, MCP servers and models, the **Org login gate**, **Route through Guardway**, and the **Rollout** state. Every pull of this document is signed with your organization's key, and agents verify it against their pinned public key. |
| **Access Profile** | The named limits (models, rate, budget, lifetime) a policy applies to each machine's gateway key. See [Access Profiles](/platform/configuration/access-profiles). |
An **Endpoint AI Policy** tells the Guardway agent on a group of machines how to govern the AI
tools running there: whether model traffic goes through your gateway, which detections run and
whether risky actions are blocked, what usage is reported, which AI tool restrictions apply, and
how the agent updates itself.
## How policies work
**You never run anything on the machines.** Saving a policy is all it takes. Each machine picks up
the change on its next check-in, applies it, and reports back what it runs. There is no separate
draft or publish step: turn a policy off with its **Enabled** switch to keep it inert.
**Which policy a machine gets.** A policy applies to the machines in its scope: every machine in
its groups, plus any machines pinned to it by name (pins only add). When several enabled policies
contain a machine, the one with the lowest **Precedence** number wins; a blank precedence sorts
last. A machine no policy contains gets the policy bound to the **All endpoints** group. If
nothing applies, the machine keeps the last policy it received.
**A machine you name belongs to one policy.** Pinning a machine, or listing it in a hand-picked
group, names it explicitly, and only one policy can do that. When you pin a machine in the
**Endpoint scope** picker, each machine shows the policy it is already in. Picking one that another
policy pins asks you to move it: saving moves it to this policy and removes it from the other. A
machine in another policy's hand-picked group can't be pinned until you remove it from that group.
Rule-based groups such as **All endpoints** or an operating-system group are different: they
overlap by design, and Precedence decides between them.
**Find a machine's policy.** Type a hostname or user in the **Search** box on the Policies tab.
Each matching machine shows the one policy that governs it, how it got there (pinned or through
which group), and any policies it also matched but that were outranked. To see the machines behind
a policy, click its endpoint count: a side panel lists them with the policy version each one runs,
and **Export CSV** downloads the list. Click "taken by a higher policy" to see which policy took
each machine.
Groups synced from a directory (Microsoft Entra, Okta, Active Directory) do not match any machine
yet. Use the built-in groups or pin machines by name.
**Policies only raise.** A policy can make a machine stricter than its local setup, never more
permissive. A machine an operator set to Enforce locally stays on Enforce even under an Observe
policy, and AI Control switches raise your organization's baseline without ever lowering it.
**Per-policy and org-wide settings.** Most settings apply only to the machines a policy covers.
Two live in one shared document every enrolled machine fetches, so editing them in any policy
changes them for the whole organization: the **indicator lists** under Detections and **Endpoint
routing**. The editor marks both as shared.
**Unset means default.** A section you leave unset follows the fleet baseline or the agent's
defaults.
**Rollout status.** The footer shows how many machines run the latest policy version, out of every
enrolled machine (not only this policy's scope). Saving any policy starts a new version, so
machines read as behind until their next check-in. A machine that never reported which policy it
runs is shown as unknown, not as clean.
Saving a policy needs the **Owner** or **Admin** role.
## General
| Setting | What it does | Default |
| - | - | - |
| **Name**, **Description** | How the policy appears in the list. | Name required |
| **Group scope** | The groups whose machines get this policy. A policy bound to no group applies only to pinned machines. | Your choice |
| **Endpoint scope** | Individual machines added on top of the groups. A machine can be pinned to one policy only; pinning one held elsewhere moves it here. | None |
| **Precedence** | Lower wins when several policies contain a machine. Blank sorts last. | Blank |
| **Impact tier** | How much a finding on these machines weighs in risk scores: Contractor 0.4, Engineer 0.6, Production access 0.8, Executive or admin 1.0, or a custom value. A tier set on a machine itself still wins. Used for scoring only; nothing on the machine changes. | No policy tier |
## Posture
How strictly model traffic from AI tools is governed by your gateway.
| Level | Where traffic goes | If the gateway cannot serve a request |
| - | - | - |
| **Observe** | Straight to the AI vendor on the developer's own key. Captured and reported, not governed. | No effect |
| **Enforce, fail open** | Through your gateway: governed, logged and priced. | It goes to the vendor on the developer's key and is reported as ungoverned. A deliberate denial by the gateway still stands. |
| **Enforce, fail closed** | Through your gateway. | The request is blocked. |
* Choosing Enforce without choosing a fallback means **fail closed**.
* Under Observe, machines are still given their gateway address and key ahead of time, so moving
to Enforce takes effect on their next check-in.
* **Windows:** only **Enforce, fail closed** applies. The agent points Claude Code and Codex
straight at your gateway, and each machine reports when a setting cannot apply there. Under
Observe or fail open, Windows machines are reported, not governed.
**Enforce single tools** (shown under Observe) sends one tool's traffic, Claude Code or Codex,
through the gateway while everything else stays observed. These always fail open. Not available on
Windows.
**Gateway setup** chooses where machines relay to:
* **Platform gateway:** pick one of your registered gateways. Each machine gets its own key on its
next check-in, so one machine's key can be revoked on its own.
* **Other gateway:** a URL and one shared key for every machine. Revoking that key revokes the
whole fleet.
Changing the gateway re-keys every machine in scope automatically; only owners and admins can
change it. The gateway address must use `https` and a public address: a machine refuses a private
IP address or an internal name (ending in `.local`, `.internal` or `.lan`) and keeps observing. A
gateway an operator configured on the machine itself always wins.
**Access profile** limits what each machine's gateway key may do: models, rate limit, budget and
key lifetime. **Unrestricted** is the default. Editing a profile updates every key already issued
from it within one gateway poll.
## Detections
One table of every rule the agent runs, in four layers. Each rule can be turned off; a rule that
is off never runs on these machines, so there is no finding and no evidence for it. New rules from
agent updates are on by default. Rules marked **May be noisy** are pattern-based leads to review.
Only Live guard can block anything. Every other rule records a finding.
### Live guard
Checks each action an AI tool is about to take, such as a shell command, a file edit or a web
fetch, before it runs. It works in Claude Code, Codex, Cursor, Antigravity, Junie, Grok Build,
Devin and GitHub Copilot: the agent adds its check to each tool installed on the machine, and
removes it when you switch Live guard off. Nothing needs to be installed or run on the machines.
* **Record** (default): matches are recorded as "would block"; nothing is stopped.
* **Block:** four rules stop the action: credential exfiltration (`GUARD-CRED-EXFIL`), download
and execute (`GUARD-FETCH-EXEC`), destructive commands (`GUARD-DESTRUCTIVE`) and writing secrets
to files (`GUARD-SECRET-WRITE`). The other Live guard rules always record only. Blocking applies
on machines with the managed (MDM) install; a per-user install records only.
Run in Record for about a week and review the would-block findings before switching to Block.
Live guard never stops work because of Guardway itself: if the agent is stopped or does not
answer within a few seconds, the action goes ahead. Changes apply within seconds of a machine
receiving the policy, and before any policy has arrived nothing is installed.
A few limits of the tools themselves: GitHub Copilot does not check searches, file globs or
sub-agent tasks; Junie's hooks do not run inside the JetBrains IDE plugin; and on a per-user
install Codex asks the developer to trust the check once. When Skills is set to **Claude Code** or
**Every AI tool**, Claude Code keeps its check even with Live guard off, so blocked skills stay
refused there.
### Behavior
Rules over each AI tool's sessions. They record findings and never block. Claude Code's come from
its telemetry (see [Telemetry](#telemetry)); the other tools' from the session files they already
write, read without changing anything in the tool.
| Rule | Fires when | Setting | Default |
| - | - | - | - |
| **Session ran unattended** (`BEHAV-AUTONOMY`) | An agent made many tool calls per human prompt, a sign that something other than the developer was steering (prompt injection or unattended automation). Checked once a session has 10 or more tool calls. | Tool calls per prompt, 5 to 60 | 15 |
| **Operator rejected most agent actions** (`BEHAV-REJECT-SPIKE`) | The developer rejected most of what the agent proposed. A cautious developer can trigger it, so treat it as a lead, strongest alongside other findings in the same session. Checked once there are 5 or more decisions. | Rejection rate, 10% to 90% | 34% |
Which tools are covered, and what counts as the developer's rejection:
| Tool | A rejection is | Rate counted against |
| - | - | - |
| **Claude Code** | The developer declining a permission prompt | The prompts the developer answered |
| **GitHub Copilot** (VS Code and CLI) | A prompt answered "no" by the developer; Copilot's own approvals (assisted mode, rules) are not decisions | The prompts the developer answered |
| **Codex** | A call Codex records as "rejected by user", or an interrupted turn with a call waiting | Every action the agent proposed |
| **Kiro** | Kiro's "The user rejected this tool call." | Every action the agent proposed |
| **Grok Build** | A turn the developer ended by rejecting or cancelling a permission prompt | Every action the agent proposed |
| **Devin** | "User rejected this tool call" on a call that failed | Every action the agent proposed |
| **Junie** (CLI) | A step Junie marks rejected (only the developer's answer to its prompt sets it) | Every action the agent proposed |
| **OpenCode** and **Kilo Code** | The tool's "rejected permission" error, after the prompt waited at least a second (`opencode run` rejects by itself, within milliseconds) | Every action the agent proposed |
Most tools record only the rejection, not which actions asked for approval, so their rate is over
every proposed action. That can only miss a spike, never raise a false one. A session with prompts
switched off (Grok's always-approve, Copilot's allow-all) is marked as having no human in the
loop. A rule that blocks a call (Guardway's Live guard included) never counts as the developer's
rejection.
### Governance
* **Artifact not in the approved baseline** (`GOV-UNAPPROVED`): when on, each machine records what
is installed now (skills, MCP servers, hooks and other agent extensions) as approved, and flags
anything new or changed after that. What is already installed raises no finding. Turning it off
stops the findings; turning it back on reuses the original snapshot.
* **Blocked skill present** (`GOV-SKILL-BLOCKED`): a skill your organization marked Blocked in the
skill catalog is installed.
This rule also controls blocking. Turning it off stops blocked skills from being refused in
Claude Code or moved aside in other AI tools, whatever the Skills setting under AI Control says.
* **Unsanctioned skill** (`GOV-SKILL-UNSANCTIONED`): a skill not on your sanctioned list, or a
modified copy of one.
* **Blocked skill reinstalled** (`GOV-SKILL-TAMPER`): a skill that was moved aside came back 3 or
more times in a day.
### Installed content
Rules that score the skills, MCP servers, hooks and other agent extensions installed on the
machine (see [Inventory & Risk Scoring](/endpoint-ai-risk/agent/inventory)). They raise an
artifact's risk score; nothing is blocked or moved.
Four of them use **indicator lists** you can extend: known malicious indicators (`IOC-KNOWN`,
Critical), paste and file-drop hosts (`EXT-PASTE`), protected brand domains (`EXT-LOOKALIKE`,
names one character away from yours) and popular packages (`EXT-TYPOSQUAT`, package names one
character away from popular ones). The built-in entries cannot be removed; your entries add to
them. These lists are **shared by every policy** in your organization.
## Endpoint routing
Where model traffic is allowed to go. **Shared by every policy** in your organization.
* **Require Guardway gateway** (default): any model endpoint not reached through one of your
platform gateways is reported non-compliant, even an approved vendor called directly.
* **Allow sanctioned vendors:** direct calls to the hosts you list are compliant; anything else is
reported non-compliant.
Your platform gateways are always sanctioned. Routing reports compliance in the fleet view; it
does not block requests. What actually routes traffic is [Posture](#posture).
## Telemetry
**Send Claude Code and Cursor usage to Guardway**
* **On:** each machine's agent sets up Claude Code and Cursor's usage hooks to send their usage to
the agent, starting with the next session. If the machine already sends Claude Code telemetry
to another collector, that setup is left alone and the machine reports it.
* **Off:** usage stays on the machine. Those machines show as unknown in the console, and the
Behavior rules cannot fire for them.
* **Not set** (default): each machine keeps whatever its install set up.
What is sent is metadata only: cost and tokens (including personal Pro and Max subscriptions),
sessions, active time, prompts sent, tool calls by tool name, lines added and removed, commits and
pull requests, accepted and rejected agent actions, models used, Cursor sessions, prompts sent and
shell and MCP calls, and the account's email domain (never the address) and whether it is personal
or corporate.
**Never sent:** responses, tool inputs or outputs, and file contents. Prompts are not sent either,
unless **Keep Cursor prompt previews** is on. The agent never turns on Claude Code's content
logging.
**Keep Cursor prompt previews** (off by default, needs the usage switch above): keeps the first
240 bytes of each prompt typed in Cursor, redacted on the machine. Claude Code prompts are never
sent. See [Cursor](/endpoint-ai-risk/agent/cursor).
## AI Control
Switches that raise your organization's AI tool restrictions for the machines this policy covers.
They never lower your baseline, and your catalogs and login settings stay organization-wide.
| Switch | What it does | Applied in |
| - | - | - |
| **Deny YOLO mode** | Stops AI tools from running actions without asking. Claude Code: blocks Bypass permissions and Auto mode, and restores the block if it is removed (Accept edits stays allowed). GitHub Copilot: blocks bypass mode, and in VS Code turns off auto-approve for tools. Codex: allows only its read-only and workspace-write sandboxes, and pauses a developer's full-access setting until the policy allows it again. Grok Build: disables bypass mode. Cursor: switches "Run everything" back to "Ask" (best effort, not undone when switched off). | Claude Code, Copilot, Codex, Grok Build, Cursor |
| **Managed permission rules only** | Only your organization's permission rules apply; a developer's own allow rules are ignored. | Claude Code |
| **Managed MCP servers only** | Only MCP servers approved in your catalog can run. | Claude Code, Copilot, Codex, Grok Build |
| **Sandbox required** | AI tools must run commands in their sandbox. | Claude Code, Copilot, Codex, Grok Build, Cursor |
| **Hook lockdown** | Only hooks your organization manages can run. | Claude Code, Codex, Grok Build |
| **Deny-command pack** | Blocks force-pushes, recursive deletes, `sudo` and piping downloads into a shell. Codex covers all but the last, which Live guard handles. | Claude Code, Copilot, Codex, Grok Build |
| **Model allowlist** | Only the models in your catalog can be used. | Claude Code, Grok Build |
| **Network allowlist** | Limits Claude Code's sandboxed network access to your approved MCP proxy hosts. | Claude Code |
| **Disable background agents** | Turns off background and remote agent runs. | Claude Code, Cursor (best effort) |
| **Approved harnesses only** | Reports AI coding tools on the machine that are not on your approved list. Nothing is blocked yet (marked Pending). | Reported only |
AI Control applies on machines with the managed (MDM) install. The agent re-checks every few
minutes and puts back anything a developer changed. Antigravity, Junie, Gemini CLI and Devin have
no settings for these controls; Live guard covers them.
Each machine reports, per tool, which controls it could apply and which that tool has no setting
for.
### Skills
**Blocked skills: where should they be stopped?** Skills your organization marked Blocked in the
skill catalog are always reported. This setting decides where they are also stopped:
| Level | Effect |
| - | - |
| **Report only** | Flagged in the console. Every AI tool can still load them. |
| **Claude Code** | Claude Code refuses blocked skills, and any skill not on your sanctioned list. Other AI tools can still load them. |
| **Every AI tool** | Also moves a blocked skill's folder aside in every AI tool on the machine and leaves a short note in its place. Nothing is deleted, and the skill returns when you lower the setting. Skills inside a git repository are reported, never moved. Managed installs only. See [Skill Custody](/endpoint-ai-risk/agent/skill-custody). |
**Claude Code** and **Every AI tool** need at least one sanctioned skill in the catalog. On a
managed install, either of them also switches Live guard to **Block** on those machines.
**Quarantine unsanctioned skills** is delivered but not yet enforced.
## Agent updates
How the Guardway agent on these machines updates itself. The agent only installs releases from
Guardway's signed release index and never downgrades itself.
| Setting | Options | Default |
| - | - | - |
| **Update mode** | **Off**, **Notify** (report available updates, install nothing), **Auto-install** (install eligible updates with no one present) | Notify |
| **Version strategy** | **Always latest**, **Stay N releases behind** (1 to 10; withdrawn releases are skipped), **Pin to a version** (machines already newer are not downgraded), **Stable channel**, **Agent default** | Two releases behind |
| **Minimum version** | Machines below it must update, ignoring soak, ring and the maintenance window. | None |
| **Soak before adopting** | A release younger than this is not adopted, leaving time for a bad build to be withdrawn first. | 72 hours |
| **Rollout ring** | The share of machines eligible, chosen by a stable per-machine bucket. | 100% |
| **Maintenance window** | Days and a local start and end time on each machine. An end earlier than the start wraps past midnight. Empty means any time. | Any time |
Windows machines installed from an MSI older than 0.2.148 cannot install updates by themselves.
Install 0.2.148 or later over them once.
On Linux machines installed from the `.deb` or `.rpm` package, the agent updates through the
package manager, so `dpkg` and `rpm` always know which version is installed. With **Auto-install**,
the agent downloads the package for the selected release, checks it against Guardway's signed
release index, and installs it with `dpkg -i` or `rpm -U`. If `apt` or `dnf` is busy at that moment,
it tries again 15 minutes later. A package update is not rolled back automatically: if the new
version does not start, the machine is reported as needing attention.
Linux machines installed from a `.deb` or `.rpm` package older than 0.2.160 cannot install updates
by themselves. Install the 0.2.160 or later package over them once, for example
`sudo apt install ./guardway-agent_0.2.160-1_amd64.deb`.
## Related
What the agent finds and how each artifact is scored.
Stopping a blocked skill in every AI tool.
How each AI tool's usage and cost are measured.
How Guardway governs Cursor on the device.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.