Span Agent Trace Analytics: Security Overview (auspex)

Last updated: August 20, 2026

Updated: 8/19/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; Windows and Linux are coming soon.

Events are captured across the following categories:

Category	What is captured
Prompt interactions	User prompt text, model response metadata, model name
Tool calls	Tool name, tool inputs (parameters), and tool outputs (results) — e.g. a file edit's target and diff, a shell command and its output, a web search and its results
File edit events	File path and diff content. When a file edit is detected, auspex performs a bespoke read of the edited file from the project's git working tree to enrich the base hook payload with the file's before/after content (the hook alone does not carry it)
Conversation lifecycle	Session start/end, timestamps, session ID
Git metadata	Branch name, commit author, repo root

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

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.
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

auspex

All connections are outbound via HTTPS on port 443.

Purpose	Needed When	Hostname	IP Addresses
Telemetry export to Span	always	`agent-traces.span.app`	📄 Network Access Requirements
Org policy retrieval from Span	always	`api.span.app`	📄 Network Access Requirements
auspex artifacts download	download is automated	`auspex.span.app`	AWS CloudFront(filter `service: CLOUDFRONT / CLOUDFRONT_GLOBAL`)

No other outbound connections are made. The agent does not auto-update or communicate with third-party services.

auspex devcontainer feature

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

These connections are made on top of those in auspex. All connections are outbound via HTTPS on port 443.

Purpose	Needed When	Hostname	IP Addresses
Feature installation	Installing the feature during build time	`ghcr.io` `pkg-containers.githubusercontent.com`	GitHub
Cosign Verification	Using `verify: cosign` option (default)	`github.com` `objects.githubusercontent.com`	GitHub

Some options exist to reduce the required allowlist surface:

auspex artifacts download - vendor the auspex binary into the base devcontainers image and set binaryUri to an in-container path
cosign verification - relax requirement to verify: checksum
feature installation - mirror the feature into your own GitHub registry or vendor ./src/span-auspex in-tree

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.

Control	Description
Managed configuration	Admins set fleet policy in the root-owned managed config; locked keys override a developer's local config
Custom redaction patterns	Org-defined named regex patterns, synced from Span, are compiled and applied on-device alongside the built-in secret/PII detectors (additive — an org can add detectors, never remove the baseline ones)

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 the developer's own control: an organization can never turn a developer's privacy mode off.

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.

Provider	Models	Data handling
Azure OpenAI	GPT-4o, GPT-4o-mini, o1, o3-mini, GPT-5	Zero Data Retention (ZDR) — Microsoft does not store prompts or completions
AWS Bedrock	Claude (Anthropic) : claude-haiku, claude-sonnet	Zero Data Retention equivalent — Amazon does not store prompts or use them to train foundation models

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:

Area	Current state	Planned
PKG notarization	Apple Notarization	Ongoing
Source code	Private repo — we're happy to share it privately with customers who request it for security review	TBD
MDM guides	Mosyle, Workspace ONE, IRU (Kandji), Jamf Pro, Intune, Rippling	Additional guides available upon request
OS support	macOS (dev containers in early access)	Windows and Linux (coming soon)

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

Property	Detail
Deployment	MDM-managed package (Mosyle, Workspace ONE, IRU/Kandji, Jamf Pro, Intune, Rippling)
Supported platforms	macOS (Windows and Linux coming soon)
Supported IDEs	AI coding IDEs (currently Cursor, Claude Code, Codex)
Data in transit	TLS 1.2+ HTTPS
Data at rest	AES-256, AWS US
Secret redaction	On-device, in memory, before any transmission
Tenant isolation	Separate Postgres schemas + org-scoped queries
Access control	RBAC — consistent with Span platform; per-user (0600) credential on device
Backend AI processing	Azure OpenAI (ZDR) + AWS Bedrock (ZDR); processed outputs only stored
Network egress	Two Span endpoints (telemetry + policy)
Kernel/system extensions	None
macOS file access (TCC/PPPC)	Full Disk Access, pre-granted via an MDM-pushed PPPC profile — no user prompt (least-privilege folder-scoped alternative available)