Span Agent Trace Analytics: Security Overview (auspex)

Span Agent Trace Analytics shows engineering leaders how their teams use AI coding tools. This page explains what the Span agent, auspex, captures on developer machines, how Span protects that data, and who can see it.

Why it matters

Agent traces contain prompts, code, and tool output. Before you deploy, your security team needs clear answers: what gets installed, what leaves each machine, where it is stored, who can read it, and how long Span keeps it.

• For security reviewers: every control, network host, data store, and model provider in one place.

• For IT admins: what to deploy, which hosts to allow, and which macOS profiles keep engineers from seeing prompts.

• For engineers: what is captured, what is redacted before it leaves your machine, and how to stop capture with privacy mode.

How it works

At a glance

The data path

The platform has four parts: the auspex agent on developer machines, a telemetry ingestion endpoint, an AI analysis pipeline, and the Span app.

1. Capture. auspex adds hook entries to each supported AI tool's own configuration. When the tool fires a hook (a prompt is submitted, a tool call starts or finishes, a file is edited, a session ends), auspex writes the event to a local folder and exits. The hook never waits on the network.

2. Redact on the device. A per-user background process reads each event, redacts secrets and personal data in memory, stores the result locally, and uploads it over HTTPS. If the machine is offline, events wait on disk and upload when it reconnects.

3. Scan again at ingestion. Span's ingestion endpoint checks your organization's token and queues events for processing. Every event is scanned by TruffleHog and a self-hosted PII model before it is written to Amazon S3 in the US.

4. Analyze. Span's pipeline rebuilds each session, links it to a person by work email, generates a title and summary, classifies the task, screens it for sensitive topics, scores it, and matches the agent's edits to the lines in each pull request.

5. Control access. In the Span app, only the engineer who ran a session can read its prompts and transcript by default. People with permission see facts about the session, such as cost, model, linked PRs, and evaluation scores.

The Span backend also pushes your organization's policy to each agent periodically, so local policy stays in sync.

What auspex captures

What auspex does not capture: keystrokes, browser activity, terminal use outside an agent session, files the agent never touched (unless Snapshotting is on), or anything outside the supported AI tools. For edits outside a git repository, auspex records the path only. A tool's own output can still include what the agent read, such as the result of a shell command.

Raw trace events expire under your organization's retention policy (see Data retention and deletion). Derived summaries, labels, and scores are stored in Span's analytics database and retained per Span's MSA.

Secret redaction

Span redacts secrets at two independent layers:

• On the device, before upload: every event is scanned in memory before it reaches the local buffer. The defaults cover API keys and access tokens for several hundred common services and credential formats, private key blocks, database connection strings and passwords, and high-entropy strings that look like secrets but don't match a known format.

• On Span's servers, before storage: every event is scanned with TruffleHog, a secret scanner, before it enters the analysis pipeline. This second pass catches credentials that escaped redaction on the device before they are written to Span's trace storage or processed.

PII redaction

Span detects and redacts personally identifiable information (PII) in agent traces. Each detected value is replaced in place with a marker such as ‹REDACTED:email:1› that names the kind of value removed. Values auspex removes on the device never leave it. Values the server-side pass removes reach only Span's own infrastructure, no third party, and are never written to Span's trace storage, but the uploaded event that held them stays in Span's internal ingestion queue for about 7 days. Within a single event, repeated copies of the same value share a marker number; markers aren't linked across events. In a trace in Span, hover over a redacted value to see its type and whether it was redacted on the device or on Span's servers.

1. On the device. Deterministic patterns and checksum validators run inside auspex, in memory, before an event is written to the local buffer. No model and no network call are involved. They cover contact and network details, financial numbers, and national IDs for the US and 11 other countries. Passport numbers, driver's license numbers, bank account numbers, ITINs, and UK postcodes are redacted only when a related word appears nearby. auspex errs toward redacting too much, and URLs aren't redacted. These defaults always run: your organization can add to them but can't remove or turn off any of them.

2. On Span's servers. Before trace content goes into long-term storage, a named-entity recognition model that Span hosts inside its own infrastructure finds people's names, postal addresses, phone numbers, and account numbers from context. The secret scanner runs in the same pass. Because this pass runs after upload, these values do leave the developer's machine, but they reach only Span's own infrastructure and no third-party service. If some content must never leave the machine, use privacy mode.

See auspex: Default redaction, custom patterns, and privacy mode for the full lists of what is redacted, how markers work, and a worked example.

Custom redaction patterns

Span can add your organization's own named redaction patterns, such as internal customer IDs or project code names. Send your Span representative a name (uppercase letters, digits, and underscores), a regular expression, and a few example values. Each pattern must use RE2 syntax, stay at 512 characters or fewer, avoid nested unbounded quantifiers, and be unable to match an empty string. Patterns sync to every device and run on the device alongside the defaults, before any data leaves the machine. They only add: they can't turn off or narrow any default. If a device receives a pattern it can't compile, it skips that pattern and keeps capturing with everything else in place.

Org policy controls

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

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

• Central policy from Span: the agent periodically syncs your org policy from Span and applies it without a restart. Org policy can only tighten the on-device baseline, never weaken it. A newly installed agent holds uploads until its first policy sync.

Privacy mode (developer-controlled)

Every developer can turn on privacy mode on their own machine at any time. Privacy mode doesn't redact more: it discards everything. While it is on, auspex captures, stores, and sends nothing from AI coding sessions on that machine. The setting takes effect immediately, persists across restarts, and works even when the background process isn't running. A heartbeat keeps reporting the device 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 only works in one direction. Your organization can never turn a developer's privacy mode off. It can force privacy mode on for every device: contact your Span representative, and the setting reaches each device on its next policy sync. While it is active, developers can't turn privacy mode off, and auspex privacy reports:

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

When your organization releases this setting, each device returns to its developer's own choice: a developer who never turned on privacy mode resumes capture, and one who did stays private.

Privacy controls and how they combine

The controls apply in sequence. Privacy mode, whether a developer or your organization turns it on, stops data at the source. Redaction cleans what is captured before it is stored. Screening and permissions decide who can read what Span stores. Retention decides how long raw events stay.

Access control

Access in the Span app follows the same permission groups as the rest of Span. By default, prompts and full trace contents are visible only to the trace's author. People granted Agent Trace Data see facts about a trace, such as cost, model, linked PRs, and evaluation scores, but not its contents, title, or the reasoning behind its scores. If your organization wants named people to read trace contents, Span can switch your organization to permission-based trace contents on request. See Agent Trace permissions.

On the developer machine, auspex runs as a per-user agent, never as a single root daemon. Your MDM delivers the organization's telemetry token as a root-owned managed file, and auspex copies it into each user's own private (0600) identity file, readable only by that user. No shared, world-readable credential sits on disk. You can rotate the org token across the fleet without restarting devices; the agent reloads its identity.

Infrastructure and hosting

Span's backend is hosted on Amazon Web Services (AWS) in the United States only. This includes the ingestion layer, the AI analysis pipeline, and the analytics database. The model providers that process trace content are listed under How Span uses LLMs.

Data segregation

Span isolates tenants with a separate logical data partition (Postgres schema) for each customer organization, reinforced by application-level access controls that scope every query by organization ID. Regular penetration testing and code reviews target cross-tenant vulnerabilities.

Data retention and deletion

Redacted trace events are retained under your organization's retention policy, which Span sets with you during onboarding to between 30 and 90 days. We recommend 90 days for more complete analysis and attribution. Once a trace passes your retention window, its prompts and transcript are no longer available in Span. Processed insights and summaries are retained under the same terms as Span's MSA.

People with the Manage Traces permission can delete traces in Span. On termination or expiration, data is deleted from production systems within 30 days and permanently removed from S3. Span responds to data deletion requests within two business days.

Encryption

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

How Span uses LLMs

Span's analysis pipeline uses large language models to title, summarize, classify, screen, and evaluate agent traces, and to link related sessions. Harness health and coaching reports use an AI agent that reads session content. Processed outputs are stored in the analytics database. All data processed by LLMs is subject to the same handling and retention commitments described on this page.

None of these providers logs, stores, or trains on your prompts and completions. Specific models change as providers update their offerings; any change keeps the same data handling and retention commitments.

Setup

1. Have your security team review this page.

2. Get your organization's traces token from Settings → Traces in Span (the Trace collection card, View token). Span admins and people whose permission group can manage integrations can open this page.

3. Deploy auspex with the guide for your device management tool, linked from Understanding Agent Traces in Span (auspex). Deploy the macOS file-access and background-items profile before the package.

4. Ask your Span account team to turn on trace processing for your organization.

Install options

• macOS (MDM): a signed and notarized .pkg for supervised devices on macOS 13 or later. It installs without user interaction, provisions each engineer's identity, and starts the per-user agent at login. No kernel or system extensions are required.

• Windows (MDM): a signed .msi for Windows 10 build 1809 or later and Windows 11, with guides for Intune, Rippling, and Hexnode.

• Self-install (macOS, Windows): installs into the engineer's home folder with no admin rights. See Self-Install auspex on macOS and Self-Install auspex on Windows.

• Linux and containers (beta): see Self-Install auspex on Linux and Install auspex in a Container (Docker) on Linux.

• Cursor and Claude Code cloud agents (beta): a setup script fetches and verifies the signed binary when the agent's VM starts.

• Dev Container Feature (alpha): available for Ona dev containers on GitHub.

auspex has no auto-update. To upgrade, IT pushes the new package through MDM, and self-installers rerun the install.

macOS file access (TCC and Full Disk Access)

auspex captures the before and after of an AI-driven edit by reading the edited file from the project's git working tree when the edit fires. When repositories live in a TCC-protected folder (Documents, Desktop, or Downloads), macOS Transparency, Consent, and Control (TCC) would otherwise ask the user to approve that read.

On a managed fleet, your MDM pre-authorizes this centrally, so no user is prompted. It pushes a Privacy Preferences Policy Control (PPPC) configuration profile that grants 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 the end user can't revoke it. The profile re-validates auspex's signature on every access, so a tampered or re-signed binary is refused.

Important for admins: deploy the file-access profile and the background-items profile before the package installs. Engineers then never see an "'auspex' would like to access files in your Documents folder" prompt. Every MDM guide includes the profile and the correct order.

If your policy forbids Full Disk Access, the same profile can instead grant only the three protected folders (Documents, Desktop, Downloads).

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"). The same profile bundle that grants file access also:

• Pre-approves auspex's background items (com.apple.servicemanagement), so they show as "managed by your organization" and standard users can't disable them.

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

The combined profile (file access, background items, and notification suppression) comes with each MDM guide and is hosted at https://auspex.span.app/config/darwin/auspex-background-items.mobileconfig. It is keyed to auspex's Developer ID signing identity, so it works unchanged for every organization.

Removal

On a managed device, remove the package and the managed configuration through your MDM. On a self-installed device, auspex uninstall removes the agent and its hooks. auspex removes only its own entries from each tool's config, so your own hooks in Cursor and Claude Code are preserved.

Network access

All connections are outbound over HTTPS on port 443. auspex opens no inbound ports. The table lists every host auspex may contact; each install method needs only the subset noted below.

Every install needs the three Span hosts. The agent makes no other outbound connections (no auto-update, no third-party services) beyond the per-method extras below.

Dev Container Feature. Hosts: the three Span hosts, plus ghcr.io and pkg-containers.githubusercontent.com for the feature image at build time, plus github.com and objects.githubusercontent.com for the pinned cosign and jq CLIs under verify: cosign (the default) when they aren't already on the image. With verify: cosign, the feature resolves the release's cosign-signed version-to-digest manifest for the requested tag and platform, installs the artifact by its SHA-256 from the content-addressed store (https://auspex.span.app/blobs/sha256/<digest>), and verifies the bytes. Verification makes no Sigstore (Fulcio, Rekor, TUF) calls, because the trust root is pinned. Setting digest pins the exact bytes directly and needs no manifest, cosign, or jq. To shrink the allowlist:

1. Vendor the auspex binary into your base image and set binaryUri to an in-container path.

2. Relax verification to verify: checksum, or pin digest.

3. Mirror the feature into your own registry, or vendor ./src/span-auspex in-tree.

4. Pre-provision cosign and jq on the image, or set AUSPEX_COSIGN_BASE_URL and AUSPEX_JQ_BASE_URL to an internal mirror.

Bootstrap installer (curl | sh or PowerShell). For laptops, CI, or any non-container host, auspex can be installed with a script served from the auspex-distribution repo's GitHub Releases. Hosts: the three Span hosts, plus github.com and objects.githubusercontent.com for the installer script and trust anchor, and for the pinned cosign and jq under --verify cosign (the default) when they aren't already on the host. Verification works the same way as the Dev Container Feature and runs fully offline. The PowerShell installer parses JSON natively and needs no jq. --verify checksum drops the CLI downloads, --digest <sha256> pins the exact bytes from the CDN, and AUSPEX_COSIGN_BASE_URL and AUSPEX_JQ_BASE_URL point the pinned CLIs at an internal mirror for air-gapped fleets.

Cursor cloud agents (beta). A small setup fetches the recipe and the signed binary when the Cursor-managed Linux VM starts. Hosts: the three Span hosts, plus github.com and objects.githubusercontent.com for signed release assets, the installer, and the pinned cosign and jq under AUSPEX_VERIFY=cosign (the default). The dispatching engineer's work email is read from Cursor's local agent metadata socket, with no external call. To shrink the allowlist, set AUSPEX_VERIFY=checksum and commit the recipe per repository to skip the run-time script fetch.

Claude Code cloud agents (beta). An environment setup script fetches the recipe and the signed binary before the session starts on the Anthropic-hosted Linux VM. Hosts: the same as Cursor cloud agents. Claude cloud's default Trusted network level doesn't include the Span ingest host, so the environment must use Full or Custom network access with the three Span hosts and the GitHub hosts allowlisted. The engineer's work email comes from Claude's CLAUDE_CODE_USER_EMAIL, then the repo's git identity, with no external call.

Managed installs with a verify-before-install gate. An optional pre-install gate verifies the signed .pkg or .msi against auspex's pinned cosign release identity before installing, adding build provenance on top of Gatekeeper or Authenticode. With cosign pre-provisioned on the runner, the gate only contacts auspex.span.app to fetch the installer and its cosign bundle. Add github.com and objects.githubusercontent.com only if cosign isn't on the runner image.

Things to know

• Traces need the agent. Span collects agent traces only from machines and cloud agents running auspex. Span's other engineering data needs no laptop install.

• Redaction is a strong filter, not a guarantee. Two layers of secret and PII redaction catch most sensitive values, but no detector catches every one, and sensitive work without a recognizable shape isn't redacted. Use privacy mode for work that should never be captured.

• There are no file or folder exclusions. auspex doesn't skip individual files, folders, or repositories. To keep a piece of work out of Span, turn on privacy mode while you do it.

• Derived data outlives raw retention. For example, with 30-day retention, a session from March 1 can be read in full until about March 31. After that its prompts and transcript are gone, but its title, summary, task labels, and evaluation scores remain under the MSA.

• Screening restricts reading, not counting. Once a trace is screened, its contents are not exposed to anyone or anything but its author, including evaluations, coaching, and Harness health. It still counts in metrics calculated from trace metadata, such as session counts and cost.

• Tool versions matter. Claude Code needs version 2.1.139 or later. If your organization uses Claude Code remote settings, follow the remote-settings guide, or Claude Code capture stops while the device still looks healthy. Copilot CLI needs version 1.0.61 or later.

• Only the five supported tools are captured. Chat in the Claude desktop app, Copilot inline completions, and other AI tools are not captured.

• Source code review. auspex's source is in a private repository. Span shares it privately with customers who request it for a security review.

Related articles

• Understanding Agent Traces in Span (auspex)

• Agent Trace permissions

• auspex: Default redaction, custom patterns, and privacy mode

• Trace Screening: Automatically restrict personal or sensitive traces

• auspex: Claude Code Remote Settings and Managed Hooks (macOS)

Need help?

Contact your Span account team or reach out to support@span.app.