Skip to main content

Enabling Capture (Creating a Guard)

By default the agent observes metadata only — capture is off everywhere. This page shows how to deliberately turn capture on for a specific AI host by adding a layer to the Guard cascade, and how to verify it before you rely on it.

This is the one switch that terminates TLS

Enabling capture means the agent will terminate TLS for the host(s) you list, read the request/response, redact secrets/PII on the device, and upload the redacted result. It applies only to catalog AI hosts — never banking, health, or mail. Make sure you understand Privacy & DLP before turning it on for a fleet.

Decide the scope first​

Because the cascade resolves Global → App type → User group → Device → Agent group → Agent, where you add the layer decides who it affects:

You want to…Add the layer at…
Pilot capture on one machineDevice
Capture a class of app everywhere (e.g. all CLI coding agents)App type
Capture for one teamUser group
Capture for one governed agentAgent
Set the org-wide baselineGlobal

Start narrow (a single Device) for a pilot, confirm it behaves, then widen.

Step 1 — Open the Guard tab​

Go to Governance → Connect → AI Endpoints → Guard. You'll see the cascade strip (with a count of overrides per layer), the Resolve a context simulator, the App-type guards grid, and the All overrides list.

Step 2 — Add the layer​

  • To scope by app type: in App-type guards, find the app type and click add override (or edit if one exists).
  • To scope by global / device / user group / agent: use edit global in the All overrides panel, or edit an existing layer of that scope.

You'll get a small partial-config JSON editor. Set only the fields you need — everything else inherits from the layer above. To turn capture on for specific hosts, set the capture flag and the host list, for example:

{
  "capture_enabled": true,
  "intercept_hosts": ["api.openai.com", "api.anthropic.com"]
}
Only set what you mean to change

A layer is a partial override. The two lines above flip capture on for those two hosts at this scope and leave every other field inheriting from the cascade. You don't restate the whole policy.

Click Save. The new layer appears in All overrides tagged with its scope and field count.

Step 3 — Verify with Resolve​

Don't assume — resolve it. In Resolve a context, pick the app type / user group / device / agent you care about and click Resolve. The effective config appears with a colored badge on each field showing which layer it came from.

Confirm:

  • capture_enabled is true (and the badge points at the layer you just added).
  • intercept_hosts lists exactly the hosts you intended.
  • Nothing unexpected is being set by a layer you forgot about.

Step 4 — Confirm on the device & in Captures​

  1. Wait a few minutes — the on-device policy daemon long-polls and applies the new policy.
  2. Use the targeted AI app/host on that device.
  3. Open the Captures tab. The redacted, attributed requests for the enabled host appear. Click a row to see the redacted payload.

Blocking instead of capturing​

Capture is for seeing traffic; blocking is for stopping it. The same layer mechanism drives process/app blocking (a preventive posture) via the network monitor — set the relevant block fields on a layer at the scope you want. On Windows this is enforced through WFP; note that blocking there is currently process-scoped (see Key concepts for detective vs. preventive).

Turning capture back off​

Edit the same layer and set capture_enabled to false, or delete the layer entirely (the trash icon in All overrides) to fall back to the layer above — ultimately to the capture-off default. Resolve again to confirm the change took.

Next​