Telemetry & Data Collection Policy

For: Shielda users, administrators, and compliance officers Last Updated: 2026-04-03 Applies to: Control plane (SaaS) and Go Agent

---

Philosophy What We Collect What We Do NOT Collect Error Tracking (Sentry) Usage Analytics Agent Telemetry Data Retention Opting Out Third-Party Processors Compliance

---

Philosophy

Shielda collects only general usage data necessary to operate the platform, improve reliability, and fix errors. We follow these principles:

Minimal collection — Only data needed for platform operation and reliability No PII in telemetry — Personally identifiable information is scrubbed before transmission No source code exfiltration — We never send user source code to our servers (scans run locally on the agent) Transparent defaults — All collection is documented; nothing hidden User control — Administrators can disable optional telemetry

---

What We Collect

Operational Data (Required)

This data is necessary for the platform to function:

Data Purpose Storage Scan metadata Job ID, status, duration, tool name, finding counts PostgreSQL (tenant-isolated) Finding summaries Severity, status, CWE, tool that found it PostgreSQL (tenant-isolated) Agent heartbeats Agent ID, status (online/offline), last seen timestamp PostgreSQL (tenant-isolated) API request logs Route, HTTP method, status code, response time Server logs (rotated) Authentication events Login success/failure, provider used (not credentials) Audit log (tenant-isolated)

General Usage Metrics (Anonymized)

Metric Purpose Contains PII? Feature usage counters Which dashboard pages are visited, which tools are used No Scan frequency How often scans run per plan tier No Error rates API error counts by route No Performance metrics Page load times, API response times No

---

What We Do NOT Collect

Data Status Details Source code ❌ Never collected Scans run on the agent in your environment. Code never leaves your infrastructure. Scan results content ❌ Not sent to Shielda telemetry Finding details stay in your tenant database; not in telemetry streams IP addresses ❌ Stripped from telemetry Sentry sendDefaultPii: false; IP removed before storage User email addresses ❌ Not in telemetry Auth data is in your tenant DB only, not in error/usage telemetry Secrets or credentials ❌ Never collected Vault data is AES-256-GCM encrypted; never in logs or telemetry Session recordings ❌ Not recorded by default Sentry session replay is 0% in production (10% only on errors, anonymized) Keystrokes or input ❌ Never collected No keyloggers or input capture Browser history ❌ Never collected No tracking of external browsing Device fingerprinting ❌ Not performed No browser fingerprinting

---

Error Tracking (Sentry)

Server-Side Configuration

Client-Side Configuration

What Sentry Receives

Error stack traces — Function names, file paths, line numbers (source maps) Request metadata — URL path (not query params with sensitive data), HTTP method, status code Browser info — Browser name/version, OS name/version (no fingerprinting) Performance spans — Route name, duration, status

What Sentry Does NOT Receive

IP addresses (stripped by sendDefaultPii: false) User email or name Request/response bodies Cookies or session data Source code content Finding details or scan results

---

Usage Analytics

Current Implementation

Shielda uses server-side analytics only — no client-side analytics SDKs (no Google Analytics, no Mixpanel, no Amplitude).

Usage data is derived from: API request logs — Aggregated counts by route and status code Database queries — Feature adoption metrics from application tables Sentry performance traces — Page load and API response times (sampled)

Metrics Collected

Metric Granularity Used For Active organizations Daily count Platform health Active users per org Daily count Plan compliance Scans per org Daily/monthly count Plan metering, PAYG billing Agents per org Current count Plan compliance API calls per route Hourly count Rate limiting, capacity planning Error rate per route Hourly percentage Reliability monitoring Dashboard page views Daily count (anonymous) Feature adoption

---

Agent Telemetry

The Go Agent sends the following data to the control plane:

Sent to Control Plane

Data Frequency Purpose Agent ID + status Every 60s (heartbeat) Monitoring agent health Scan results (findings) After each scan Populating the dashboard Tool versions On startup Compatibility checks Resource usage With heartbeat Capacity monitoring

NOT Sent to Control Plane

Data Details Source code Scans run locally; only findings (file path, line, description) are sent Full file contents Only affected snippets in finding context (configurable, can be disabled) Environment variables Agent does not forward env vars to control plane Network traffic captures DAST tools (ZAP, Nuclei) results are summarized, not raw traffic Container images Only vulnerability lists, not image contents