Endpoint AI Policy

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. You edit policies in the console under Endpoint AI Policy.

​

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. 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

​

Posture

How strictly model traffic from AI tools is governed by your gateway.

• 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.

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 Claude Code’s session telemetry (see Telemetry). They record findings and never block.

​

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). 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.

​

Telemetry

Send Claude Code usage to Guardway

• On: each machine’s agent sets up Claude Code to send its 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, and the account’s email domain (never the address) and whether it is personal or corporate. Never sent: prompts, responses, tool inputs or outputs, and file contents. The agent never turns on Claude Code’s content logging.

​

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. 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: 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.

​

Related