The Swif ADR Sensor Policy helps organizations observe how supported AI coding agents are used on managed macOS, Windows, and Linux devices. It uses the open-source Uber Agentic Detection and Response (ADR) Sensor to read supported local agent logs, normalize the activity into a common format, and optionally upload the resulting ADR artifacts to Swif.

ADR stands for Agentic Detection and Response. Its Sensor component is designed to provide security observability for AI agents by recording their intent, conversations, tool use, and execution traces in a consistent schema.

Use this policy to:

Privacy notice: ADR telemetry can contain conversation content, project paths, tool arguments, tool results, usernames, hostnames, and other sensitive data. Review the Data Collected by ADR Sensor and Privacy and Security Considerations sections before enabling this policy.

Source availability varies by operating system. Claude Desktop and Warp are supported by ADR Sensor on macOS and Windows, but not Linux. Sources that are unavailable on the current operating system are skipped.

When the policy is enabled, the Swif agent runs ADR Sensor at the configured interval. ADR Sensor reads the local records created by the selected AI agents and converts them into normalized session artifacts.

The workflow is:

The policy is an observability control. It does not itself prevent an AI agent from running a command, accessing a file, or using a tool. Use it with appropriate application controls, AI-agent runtime policies, endpoint protections, and access restrictions.

Because Enabled defaults to disabled, the policy does not collect telemetry until an administrator turns it on.

Important: If you enable the sensor without changing the other defaults, it scans all supported sources available to this Swif policy, includes up to 14 days of session history, runs every 60 minutes, and uploads the generated artifacts to Swif.

The Sources field accepts the following values:

Leave Sources empty to collect from every source recognized by this Swif policy that is available on the device's operating system. To reduce collection scope, enter only the source values your organization has approved.

Source names must match the values in the table exactly. For example:

The upstream ADR project may add or support other parsers. A source is not available through this policy unless it appears in the Swif policy's supported values. For example, current upstream ADR documentation lists opencode, but the current Swif ADR Sensor Policy does not expose opencode as an allowed source.

For the current upstream list and storage formats, see the ADR Sensor documentation.

The exact fields depend on the AI agent, its version, the available local logs, and the source parser. ADR's normalized event schema can include:

Some sources expose more information than others. If a source application does not record a field, ADR Sensor cannot collect it.

ADR Sensor reads existing local agent records and normalizes them. It does not reconstruct activity that the source application never logged.

Controls whether ADR Sensor collection runs on the device.

Default:

Disabling the policy stops future scheduled collection. It does not necessarily delete artifacts that were previously generated locally or uploaded to Swif.

Limits collection to specific supported AI agents.

An empty list means all sources supported by the Swif policy. This is broad collection, not a setting that disables source collection.

For least-privilege deployment, explicitly select only the AI agents approved for the targeted users. This also reduces processing time and avoids collecting unrelated AI sessions.

Supported values:

Controls how much recent session history is included in generated and uploaded ADR artifacts.

A shorter history window reduces the amount of historical conversation and tool activity processed during each collection. A longer window provides more investigative context but increases data volume and privacy exposure.

This setting controls the session-history window included by the sensor. Do not assume it automatically deletes previously uploaded artifacts after the same number of days. Apply your organization's retention requirements separately to data already stored in Swif or another connected system.

Controls how often the Swif agent runs ADR Sensor.

Examples:

A shorter interval provides faster visibility but increases local processing, artifact generation, network use, and upload frequency. Start with 60 minutes unless your monitoring requirements justify more frequent collection.

Controls whether generated ADR artifacts are uploaded to Swif.

Default:

Disable upload during a local validation phase if your organization must first review the content and sensitivity of generated artifacts. When upload is disabled, centralized Swif visibility will not receive those artifacts through this policy.

An offline device cannot upload artifacts until connectivity is available and the Swif agent retries or performs a later collection. The exact handling of locally generated artifacts during offline periods can depend on the installed Swif agent version.

For an initial company-owned device pilot:

Using an explicit source list and a seven-day window reduces collection scope while providing enough recent activity for validation and investigations.

For BYOD devices, do not automatically reuse the company-owned configuration. Determine whether collecting personal account conversations, personal project paths, or other non-work activity is technically avoidable and legally permitted.

Consider leaving the policy unassigned to BYOD devices unless there is a clearly defined business scope, employee notice, and approved data-handling process.

Use this configuration when the organization permits Claude Code, Codex CLI, and Cursor:

The sensor ignores the other source adapters exposed by this policy.

Use this configuration during a privacy or technical evaluation:

This configuration limits the scan to recent Codex activity and prevents this policy from uploading the generated artifacts. Centralized telemetry will not be available in Swif until upload is enabled.

Use a 15-minute interval only when faster telemetry is necessary. Return to a longer interval after the investigation to reduce endpoint and network activity.

Leaving Sources empty instructs the policy to use all six source adapters it currently exposes. Review this scope carefully before deployment.

After assigning the policy:

Use a controlled test session that contains no credentials, customer data, or proprietary source code. A successful pilot should prove collection behavior without intentionally exposing sensitive information.

ADR telemetry can support investigations into:

Detection quality depends on the source application's local records, the configured history window, collection timing, and the analysis applied to the resulting artifacts. The sensor does not guarantee that every action is logged or that every harmful event is detected.

Uber describes ADR as combining discovery, observability, benchmarking, detection, and prevention capabilities. The Swif policy described here specifically configures ADR Sensor observability on macOS, Windows, and Linux. It should not be represented as enabling every component of the broader ADR project.

Before deployment:

ADR Sensor reads data already stored by supported applications. The policy does not change the privacy or logging settings of those source applications. Review each application's own data storage, cloud processing, and retention behavior separately.

The upstream ADR Sensor project is open source under the Apache License 2.0. Review the source code and release history as part of your software supply-chain process before production use.

Check the following:

Review the policy execution report for source-specific parser errors.

Confirm that the missing agent is included in Sources, or that Sources is empty. Then confirm that the source application has produced local records in a format supported by the installed ADR Sensor version.

Supported upstream platforms do not automatically mean that every source is enabled in the Swif policy. Use only the six source values documented in this article.

Increase History Window Days if the session is older than the configured window. The maximum supported value is 30 days.

Also confirm that the source application still retains its local session data. ADR Sensor cannot ingest a session after its original records have been deleted by the application or user.

Confirm that:

If the device was offline, allow it to reconnect and complete another collection cycle.

Do not set the collection interval below the supported minimum of 15 minutes.

The Swif policy validates source names. Current accepted values are:

An upstream ADR parser is not automatically available through Swif. Contact Swif Support if your organization needs another source added.

Disabling Enabled stops future scheduled sensor collection. It does not necessarily delete:

Use the applicable retention and deletion procedures for each storage location.

To change collection behavior:

To stop future ADR Sensor collection:

Removing the policy does not delete the original session data stored by Claude, Codex, Cursor, or another source application.

The Swif ADR Sensor Policy provides centralized configuration for collecting AI-agent telemetry from supported applications on managed macOS, Windows, and Linux devices.

For a responsible deployment: