Telemetry Ethics For Open Source Assistants Design Tradeoffs: practical systems guide

Building an AI coding assistant means grappling with a tension most vendors don't discuss: users want helpful tools that learn from their patterns, but they also want zero risk that proprietary code, client secrets, or internal architecture decisions leak outside their perimeter. Telemetry—the events, errors, and usage signals your assistant collects—sits at the heart of this conflict. Design it poorly and you either ship a blind tool that can't improve, or you create a compliance nightmare that enterprise security teams block on sight.

This guide walks through the concrete systems tradeoffs we've navigated at Goatfied, where our agent loop (plan → constrain → edit → validate → retry) generates rich operational signals but runs in environments from air-gapped banks to startups with no data governance policy. You'll see how to structure telemetry pipelines that respect user boundaries while still powering model improvements, debugging, and reliability measurement.

The baseline threat model

Start by defining what "leakage" actually means in your context. For a coding assistant, three categories matter:

1. **Source code and literals**: function bodies, variable names, comments, hardcoded API keys, internal URLs. This is the nuclear material—any transmission is unacceptable without explicit opt-in.

2. **Structural metadata**: file paths, import graphs, language distribution, error types. Lower risk, but can still reveal stack choices or architectural patterns a competitor would value.

3. **Behavioral signals**: which commands users run, how often edits fail validation, retry counts. Generally safe, but aggregate patterns can expose workflow details.

Most teams default to "collect everything and sort it out later." That's backwards. Instead, establish clear consent tiers from day one. Goatfied ships with three modes:

• **None**: Zero outbound telemetry. The assistant runs entirely local or in your VPC. We get nothing.
• **Aggregate**: Anonymized counters and error codes only—no file paths, no snippets. Sufficient for uptime dashboards and model A/B tests.
• **Full**: Structured event logs including sanitized diffs and validation traces, used to improve prompt engineering and catch edge cases.

Users pick at install time. We store the choice in a local config file, cryptographically signed so a compromised plugin can't silently escalate to "Full."

Anonymization is not enough

Simply hashing identifiers or stripping names doesn't prevent re-identification when you're sending graph-structured data. If you log that `file_hash_A` imports `file_hash_B` and `file_hash_C`, and those files are in a public repo, a motivated attacker can brute-force the hashes. We learned this the hard way during early beta when a security researcher reverse-engineered a customer's microservice topology from "anonymized" import telemetry.

Better approach: **differential privacy budgets**. Add calibrated noise to aggregate counts so individual events can't be extracted, and enforce a per-user epsilon bound. For example, when we report "Python edit success rate: 87% over 1,000 attempts," we add Laplace noise scaled to guarantee no single user's data swings the stat by more than 0.5%. This lets us track macro trends without exposing any one team's workflow.

For event-level logs (the "Full" tier), we separate PII stripping from transmission. Each event passes through a local sanitizer that:

• Redacts string literals longer than 3 tokens
• Replaces file paths with language + depth (e.g., `python/3` instead of `src/services/auth/handler.py`)
• Strips comments entirely
• Hashes stable identifiers (user ID, repo ID) with a per-install salt

Only after that pipeline does the event hit the network. Self-hosted Goatfied deployments can run the sanitizer inside their firewall and send only the cleaned payload to our managed analytics backend—or keep everything local and analyze in their own Prometheus/Grafana stack.

The validation telemetry dilemma

Goatfied's agent loop exits every edit through compile/lint/test gates before committing. That validation step is our highest-signal telemetry source: we see exactly which kinds of changes break, which linters fire most often, and where the model's output drifts from the codebase's actual constraints.

The dilemma: **compiler errors often contain snippets of the code that failed**. A Rust borrow-checker error will quote the problematic lines. A TypeScript type mismatch will show the inferred vs. expected types. These are gold for improving the model's understanding of strict languages, but they're also precisely the literals we promised not to transmit.

Our solution is a **structured error taxonomy**. Instead of forwarding raw compiler stderr, we parse it into a schema:

{

  category: "type_mismatch",

  language: "typescript",

  constructs: ["generic", "union"],

  resolved_on_retry: true,

  attempts: 2

}

The agent loop already parses errors to decide how to retry, so extracting this structure adds minimal overhead. We lose the exact line that failed, but we keep enough signal to know "the model struggles with TypeScript generics in union contexts and usually fixes it by the second attempt." That insight directly improves our constrain-phase prompts without touching any proprietary code.

For self-hosted users who want richer debugging, we offer a **local-only error archive** that writes full stack traces to disk, encrypted with their own key. They can spot-check failures without sending anything outbound.

Behavioral signals and the audit trail

Even "safe" behavioral telemetry—command usage, feature engagement, session duration—can create compliance issues if you can't prove when and how you collected it. Financial institutions especially need a full audit log showing that no PII ever left their perimeter.

We address this with a **two-phase commit** pattern:

1. The local agent writes telemetry events to a SQLite ledger with a cryptographic hash chain (each event references the previous hash). This log never leaves the user's machine.

2. If the user has opted into "Aggregate" or "Full" mode, a separate process reads from the ledger, applies sanitization, and transmits. The ledger records which events were sent and when.

3. Users can inspect or export the ledger at any time to see exactly what crossed the boundary.

This makes audits straightforward: point the compliance team at the ledger, show them the hashed chain proves no tampering, and let them diff the "sent" subset against your consent tier. No ambiguity about what went where.

The self-hosted escape hatch

The cleanest way to resolve telemetry ethics is to not transmit at all. Goatfied's self-hosted option runs the full agent loop—planning, constraint checking, validation, retry—in your own infrastructure. You get the same compile-first reliability as the managed service, but all telemetry stays in your Kubernetes cluster or VPC.

This appeals to teams in regulated industries (healthcare, defense, finance) where even anonymized data export triggers a multi-month legal review. The tradeoff is you don't benefit from our continuous model improvements trained on aggregated patterns, but for many users that's a feature, not a bug.

Related reading

• [Goatfied vs Cursor vs GitHub Copilot: a benchmark across 50 real PR tasks](/blog/goatfied-vs-cursor-vs-github-copilot-benchmark-50-pr-tasks)
• [The Goatfied agent loop: how we ship code that actually compiles first try](/blog/goatfied-agent-loop-compiles-first-try)