Skip to main content

The Guard Cascade

Guard is the policy that decides what the agent does with a device's AI traffic — observe it, block it, or capture it. You manage it under Governance → Connect → AI Endpoints → Guard.

The key idea: there is one guard config, expressed as a set of layers. Layers are resolved in precedence order, and more-specific layers override less-specific ones field by field. That lets you set a sane org-wide default once, then refine it for a class of app, a team, a device, or a single agent — without restating the whole policy each time.

The cascade​

Global  →  App type  →  User group  →  Device  →  Agent group  →  Agent
(least specific)                                          (most specific)

Resolution runs left to right. For any given field, the value from the right-most layer that sets it wins; unset fields inherit from the layer to the left. So a field can come from Global while the one next to it comes from a single-device override — they compose.

LayerScope it applies to
GlobalThe whole tenant — your baseline posture
App typeA class of AI app (e.g. CLI coding agents, desktop chat)
User groupA group of users
DeviceOne enrolled machine
Agent groupA group of governed agents
AgentA single governed agent
Everything starts at "off"

With no overrides, the cascade falls back to built-in defaults — capture off, observe-only. You build policy up from there by adding layers. Removing all layers returns you to those defaults.

Layers are partial config​

A layer is a partial config — you specify only the fields you want to change at that scope. In the Guard UI each layer is edited as a small JSON object; in the "All overrides" list you'll see each layer tagged with its scope and how many fields it sets. Fields you don't set simply inherit from the layer above. This is why a device override can be two lines and still do exactly what you mean.

Common things a layer controls:

  • whether capture is enabled, and for which hosts
  • which processes/apps to intercept or block
  • the posture (observe vs. block) for an app type

(For the exact steps to turn capture on, see Enabling capture.)

App-type guards & governance level​

The Guard tab shows each discovered app type with its governance level (full, transcript, or muted) and whether it pins TLS. These tell you the ceiling — the most an app type can be governed/captured given how it works. Your layer chooses how much of that ceiling to use. An app that pins TLS, for example, can't be payload-captured even if you ask — the UI makes that ceiling visible so policy and reality don't drift apart.

Resolve a context (the simulator)​

Before you trust a policy, prove it. The Guard tab's Resolve a context panel lets you pick an app type, user group, device, and agent, then shows the effective config and a badge on every field naming the layer it came from (Global, App type, Device, …).

Use it to answer questions like:

  • "If a user in engineering runs Cursor on this laptop, is capture on?"
  • "Which layer is actually setting capture_enabled here — and is that what I intended?"

This removes the guesswork that layered policies usually create: you never have to mentally merge the layers — the resolver does it and shows its work.

How policy reaches the device​

When you save a layer, the change propagates to devices through the on-device policy daemon, which long-polls the control plane and writes the effective policy locally. Devices pick up changes within minutes; the network monitor then acts on the new policy on its next sweep.

Next​