Span Agent Trace Analytics: Security Overview (auspex)

Updated: 8/21/2026

Platform Overview

Span Agent Trace Analytics gives engineering leaders visibility into how their teams use AI coding tools. It captures developer–AI interaction events from developer machines, reconstructs agent traces (conversation threads, tool call sequences, code edits), and surfaces insights in the Span analytics dashboard.

The platform has four components: a lightweight client agent on developer machines, a telemetry ingestion endpoint, an AI analysis pipeline, and the Span analytics application.

System Architecture

Secret redaction is applied at two points: on the developer's machine before any data leaves the device, and again at the ingestion layer using TruffleHog before events reach S3. Events are buffered locally on the developer machine and forwarded when connectivity is available. Within the ingestion pipeline, Kafka decouples receipt from inspection, it absorbs peak traffic without back pressure, ensuring every event is fully scanned by TruffleHog before being written to storage, with no data loss. The Span backend can also push org policy updates to the client agent periodically, keeping local policy in sync.

Data Collection

auspex is the client agent component of Span Agent Trace Analytics. It monitors AI coding IDE activity and captures interaction events. Currently supported on macOS, with Linux available in beta (self-install, containers); Windows is coming soon.

Events are captured across the following categories:

What is NOT collected: file contents outside AI-driven edit events, terminal output, browser activity, keystrokes, or anything outside the IDE.

All data is processed in the AI analysis pipeline and not retained in the analytics database.

Secret Redaction

Span applies secret redaction at two independent layers:

On-device (before transmission): Every event is scanned in memory before reaching the local event buffer. Redacted patterns include API keys, authentication tokens, private key blocks, database connection strings, environment variable files, and common credential formats.

At ingestion (server-side): All events received by the Span backend are scanned using TruffleHog before entering the analysis pipeline. This provides a second, independent pass against a comprehensive set of credential patterns, ensuring that any data that escaped client-side redaction is caught before it is stored or processed.

PII Redaction

Span detects and redacts personally identifiable information (PII) from agent traces. Detected values are replaced in place with a stable marker, so identical values correlate across events of the same trace without the original ever being stored. Each marker also indicates the detected entity type and where the redaction happened — on-device or in Span's pipeline.

Where redaction happens

1. On-device. Pattern-based, deterministic redaction runs inside auspex on the developer's machine, before any data leaves it. No model and no network call are involved.

2. In Span's data pipeline. A second pass on Span's ingestion pipeline that redacts raw data before it is stored, adding semantic detection (e.g. names, addresses) that patterns alone can't catch. This stage runs entirely within Span's infrastructure — it never makes external calls, so your data is never sent to any third party.

Custom organization patterns

Organizations can define their own named redaction patterns (regexes) in Span. These sync to the agent and are compiled and applied on-device, alongside the built-in secret and PII detectors, before any data leaves the machine. They are additive: an organization can add detectors to tighten redaction, but cannot disable the built-in PII detector set. Patterns are safety-screened on the device (bounded complexity, RE2-only) and fail safe — a malformed pattern is skipped rather than breaking capture.

Installation

macOS

The client agent is deployed as a signed macOS package (.pkg) via MDM. On a managed fleet no user interaction is required: the package installs elevated, provisions each engineer's identity, and starts the per-user agent at login. No kernel extensions or system extensions are required.

File-access permission (macOS TCC / Full Disk Access)

Unlike a passive hook, auspex captures the before/after of an AI-driven edit by reading the edited file straight out of the project's git working tree at the moment the edit fires. When a developer keeps their repositories under a macOS TCC-protected folder — Documents, Desktop, or Downloads — that read is subject to macOS Transparency, Consent & Control (TCC), which would otherwise prompt the user to approve access.

On a managed fleet, this is pre-authorized centrally so that no user is ever prompted: the deploying MDM pushes a Privacy Preferences Policy Control (PPPC) configuration profile granting auspex file access, keyed to the binary's path and code-signing requirement. The grant appears in System Settings → Privacy & Security → Full Disk Access as "managed by your organization" and cannot be revoked by the end user, and the profile's code requirement re-validates auspex's signature on every access, so a tampered or re-signed binary is refused.

Important for administrators: deploy the file-access profile (and the background-items profile below) before the package installs. Doing so guarantees engineers never see a "'auspex' would like to access files in your Documents folder" prompt. Every MDM guide includes this profile and the correct ordering. See Suppressing macOS prompts below.

A least-privilege alternative is available for organizations whose policy forbids Full Disk Access: the same profile can grant only the three protected folders (Documents, Desktop, Downloads) instead of full-disk scope.

Suppressing macOS prompts

On macOS 13 (Ventura) and later, macOS notifies the user the first time it sees a new background service ("auspex can run in the background"). On a managed fleet there is no reason to prompt end users. The same configuration profile bundle that grants file access also:

• Pre-approves auspex's background items (com.apple.servicemanagement), so they are shown as "managed by your organization" and cannot be disabled by standard users.

• Silences the Background Task Management notification (com.apple.notificationsettings).

A ready-to-deploy combined profile (file access + background items + notification suppression) is provided with each MDM guide and hosted at https://auspex.span.app/config/darwin/auspex-background-items.mobileconfig. It is keyed to auspex's Developer ID signing identity, so it applies unchanged across every customer org.

Removal: on a managed device, removal is performed via MDM (remove the package and the managed configuration). For an individual/self-installed device, auspex uninstall removes the agent and its hooks; user-defined hooks in Cursor and Claude Code are preserved.

Network Access

All connections are outbound over HTTPS on port 443. Every host auspex may contact is listed once in the table below; each install method needs only the subset noted in its section.

Every install needs the three Span hosts (agent-traces.span.app, api.span.app, auspex.span.app); the agent makes no other outbound connections — no auto-update, no third-party services — beyond the per-method extras below.

auspex devcontainer feature

auspex installed as a native devcontainer feature publicly available on GitHub. Currently in alpha for Ona devcontainers.

Hosts: the three Span hosts + ghcr.io / pkg-containers.githubusercontent.com (feature image at build time) + github.com / objects.githubusercontent.com (the pinned cosign / jq CLIs under verify: cosign, the default, when not already on the image).

With verify: cosign (the default), the Feature resolves the release's cosign-signed version→digest manifest for the requested tag and os/arch, then installs the artifact by its SHA-256 from the content-addressed store (https://auspex.span.app/blobs/sha256/<digest>) and self-verifies the bytes — proving authenticity and closing version-substitution. The verification step itself makes no Sigstore (Fulcio / Rekor / TUF) calls (the trust root is pinned/embedded). The only egress it adds is a one-time download of the pinned cosign and jq CLIs from GitHub (used to fetch cosign and parse the signed manifest), unless they are already present on the image. Setting digest on the Feature pins the exact bytes directly — a version-free install straight from the content-addressed store that needs no manifest, cosign, or jq (the digest is the trust anchor; the CDN is the only host touched).

Some options exist to reduce the required allowlist surface:

1. auspex artifacts download - vendor the auspex binary into the base devcontainers image and set binaryUri to an in-container path

2. cosign verification - relax requirement to verify: checksum, or pin digest (installs by content straight from the CDN — no cosign/jq download)

3. feature installation - mirror the feature into your own GitHub registry or vendor ./src/span-auspex in-tree

4. cosign / jq CLI download - pre-provision cosign and jq on the image, or set AUSPEX_COSIGN_BASE_URL / AUSPEX_JQ_BASE_URL to an internal mirror, so the pinned binaries are not fetched from github.com

auspex bootstrap installer (curl | sh / PowerShell)

For laptops, CI, or any non-devcontainer host, auspex can be installed with a piped script served from the auspex-distribution repo's GitHub Releases. This is a deliberate two-origin design.

Hosts: the three Span hosts + github.com / objects.githubusercontent.com (installer script + trust anchor, and the pinned cosign / jq under --verify cosign, the default, when not already on the host).

Like the Feature, the bootstrap installer with --verify cosign resolves the signed version→digest manifest and installs the artifact by its SHA-256 from the content-addressed store, self-verifying the bytes. The verification step is fully offline — the Sigstore trust root is pinned/embedded, so there are no Fulcio / Rekor / TUF calls; the only added egress is the one-time pinned cosign + jq CLI download (the bash installer fetches jq to parse the manifest; the PowerShell installer uses native JSON and needs none). --verify checksum drops the CLI downloads, --digest <sha256> pins the exact bytes straight from the CDN (no manifest/cosign/jq — the CDN is the only host touched), and AUSPEX_COSIGN_BASE_URL / AUSPEX_JQ_BASE_URL point the pinned CLIs at an internal mirror for air-gapped fleets.

auspex in Cursor cloud agents

auspex runs inside Cursor cloud agents (Cursor-managed Linux VMs) via a small setup that fetches the recipe and the signed binary at agent startup, then captures like any other host.

Hosts: the three Span hosts + github.com / objects.githubusercontent.com (recipe Release assets, the installer, and the pinned cosign / jq under AUSPEX_VERIFY=cosign, the default).

The dispatching engineer's identity (work email) is read from Cursor's local agent metadata socket — no external egress. The team-level recipe now fetches its scripts from signed GitHub Release assets (github.com / objects.githubusercontent.com) rather than raw source — the same hosts the installer already uses, so no extra hostname is needed. To shrink the allowlist further: set AUSPEX_VERIFY=checksum to drop the cosign/jq download, and commit the recipe per-repository to skip the run-time script fetch entirely.

auspex in Claude Code cloud agents

auspex runs inside Claude Code cloud agents (Anthropic-hosted Linux VMs behind Claude Code on the web / claude --cloud / the Claude tag / routines) via an environment setup script that fetches the recipe and the signed binary before the session starts, then captures like any other host.

Hosts: the three Span hosts + github.com / objects.githubusercontent.com (recipe Release assets, the installer, and the pinned cosign / jq under AUSPEX_VERIFY=cosign, the default).

Claude cloud's default Trusted network level does not include the Span ingest host, so the environment must use Full or Custom network access with the base auspex endpoints (agent-traces.span.app, api.span.app, auspex.span.app) plus the GitHub hosts above allowlisted. The dispatching engineer's identity (work email) is resolved in-session from Claude's CLAUDE_CODE_USER_EMAIL (then the repo's git identity) — no external egress. To shrink the allowlist further, set AUSPEX_VERIFY=checksum to drop the cosign/jq download.

Managed installs (MDM verify-before-install gate)

On a managed fleet, an optional pre-install gate verifies the signed .pkg / .msi against auspex's pinned cosign release identity before installing — adding build provenance on top of the OS-native Gatekeeper / Authenticode gate. With a pinned cosign pre-provisioned on the runner, the gate adds zero external egress at verify time: it uses only the CDN (auspex.span.app) to fetch the installer and its cosign bundle, with no Fulcio / Rekor / TUF / GitHub calls.

Hosts: auspex.span.app only at verify time (installer + cosign bundle) — with a pre-provisioned cosign, no other egress; add github.com / objects.githubusercontent.com only if cosign isn't baked into the runner image.

Org Policy Controls

auspex applies organization policy from two sources, which can be used together:

• MDM-managed configuration — a root-owned managed config placed on the device by your MDM. An admin sets fleet policy there and can mark individual keys as locked so they take precedence over a developer's local settings.

• Central policy from Span — the agent periodically syncs org policy from Span and hot-applies it without a restart. By design, org policy can only ever tighten the on-device baseline, never weaken it. This includes the org privacy kill switch (see below), a fleet-wide discard mandate.

Privacy Mode (developer-controlled)

Separately from any org policy, every developer can turn on privacy mode on their own machine at any time. While privacy mode is on, auspex discards all capture — nothing is spooled, stored, or transmitted (it is dropped at the capture hook, again at ingest, and again at egress). The setting persists across restarts, takes effect immediately, and is enforceable even when the background agent is not running. A lightweight liveness heartbeat keeps beating so the device still reports as healthy, but it carries no captured content.

auspex privacy on      # discard all capture
auspex privacy off     # resume capture
auspex privacy         # show the current state

Privacy mode is one-directional between developer and organization. A developer's toggle is always their own: an organization can never turn a developer's privacy mode off — it can never re-enable capture on someone's machine. An organization can, however, force privacy on across its fleet with the org privacy kill switch (see Org Policy Controls above) — a tighten-only discard mandate.

While an org kill switch is active, capture stays off even if the developer runs auspex privacy off, and the CLI says so rather than reporting a misleading "off":

privacy mode: on (enforced by your organization — you cannot turn this off)

Either source engaging privacy — the developer's own toggle or the org kill switch — discards all capture the same way. Releasing the org kill switch returns control to the developer's own setting: a developer who never engaged privacy resumes capture, while one who did stays private.

Infrastructure & Hosting

Span's backend is hosted on Amazon Web Services (AWS) exclusively in the United States. No data leaves the US by default. This includes the telemetry ingestion layer, AI analysis pipeline, and analytics database.

Data Segregation

Span enforces strict tenant isolation through separate logical data partitions (Postgres schemas) for each customer org, reinforced by application-level access controls that scope all queries by org ID. Regular penetration testing and code reviews explicitly target cross-tenant vulnerabilities.

Access Control

Access control in the Span app follows the same RBAC model as the main Span platform. Admins have full org-level access; manager and developer access is scoped by role, with org admins controlling visibility of aggregated values.

Prompts and full trace details are accessible only for the authors of a given trace. If you would like to change this policy and be able to modify the permissions control for trace and prompt details, please reach out to your Span representative.

On the developer machine, auspex runs as a per-user agent (never a single root daemon). The organization's telemetry token is delivered by MDM as a root-owned managed file and provisioned into each user's own private (0600) identity file, readable only by that user. There is no shared, world-readable credential on disk, and the org token can be rotated fleet-wide without a device restart — the agent hot-reloads its identity.

Data Retention

Post-redacted agent trace events are retained per the customer org's configured retention policy which defaults to 90 days, but can be configured to as low as 30 days. The advantage with the default retention policy is to provide increased analysis and attribution completeness. Processed insights and summaries are retained per the same terms as Span's MSA. Upon termination or expiration, data is deleted from production systems within 30 days and permanently removed from S3 buckets. Span responds to data deletion requests within two business days.

Encryption

Data at rest is encrypted using AES-256. Data in transit is protected by TLS 1.2 or higher. Cryptographic keys are generated via FIPS 140-2 certified hardware security modules (HSMs) or validated cryptographic libraries, with master keys rotated at least annually.

How Span Uses LLMs

Span's analysis pipeline uses large language models to reconstruct agent traces and generate insights such as session summaries and work classification. Processed outputs are stored in the analytics database. All data processed by LLMs is subject to the same data handling and retention commitments described in this document.

Both providers offer Zero Data Retention (ZDR) commitments: prompts and completions are not logged, stored, or used for model training by the provider.

Specific models may evolve over time as providers update their offerings; any such changes will continue to adhere to the same data handling and retention commitments outlined here.

Planned Improvements

Span is actively working to address the following ahead of general availability:

Hybrid Deployment

For customers with strict data residency requirements, Span aims to support a customer-hosted data option on AWS. We plan on adding support for a customer-managed AWS S3 bucket for storage of Agent Trace events, ensuring that raw telemetry events never cross into Span's infrastructure. Customers interested in this option should contact Span to discuss requirements and availability.

Summary