Private Agent Telemetry with Differential Privacy

Observability is non-negotiable for production AI agents. You need to know when a tool call is failing, which workflows are slow, and whether your error rates are creeping up. But every telemetry event you emit carries a cost: somewhere in your logs is a trail of exactly what each user did, when they did it, and how your agent responded.

Differential privacy gives you a way out of that tradeoff. Instead of choosing between useful telemetry and user privacy, you can have both — provided you apply the math correctly.

The Problem With Naive Agent Logging

Most teams start with the simplest approach: log everything, aggregate later. A structured log line looks innocent enough:

{
  "user_id": "u_abc123",
  "agent_id": "research-agent-v2",
  "tool_called": "web_search",
  "query": "quarterly earnings report Acme Corp",
  "latency_ms": 312,
  "timestamp": "2026-10-15T14:23:01Z"
}

The problem is in the combination. A user searching for a specific company's earnings at a specific time is identifiable even without a name attached. Aggregate enough events and you can reconstruct sensitive workflows: which documents a user accesses, what questions they ask repeatedly, how their behavior shifts after a given event.

When a breach happens — and breaches happen — your telemetry pipeline becomes an attacker's goldmine.

What Differential Privacy Actually Guarantees

Differential privacy (DP) is a mathematical framework with a precise guarantee: an algorithm is ε-differentially private if the presence or absence of any single individual's data changes the output by at most a factor of e^ε.

In plain terms: any report or aggregate you publish can't be used to reliably determine whether a specific user's data was included. The smaller ε is, the stronger the privacy guarantee — but also the more noise you need to add.

For agent telemetry, the key insight is that you don't need exact counts to make good engineering decisions. You need direction and magnitude. Did error rates go up? Are latencies trending worse? Is tool X being called far more than expected? Differential privacy can answer all of these while making individual user events meaningless to an attacker.

Practical Techniques for Agent Telemetry

1. Local Differential Privacy for Event Collection

The strongest form of DP applies noise at the source — before data ever leaves the user's session. Each agent client randomizes its own telemetry before emitting it.

The classic mechanism for binary attributes (did the agent call tool X?) is randomized response:

import random

def randomized_response(true_value: bool, epsilon: float) -> bool:
    """
    Flip the true value with probability 1/(1 + e^epsilon).
    With epsilon=1.0, probability of flipping is ~0.27.
    """
    p_flip = 1.0 / (1.0 + (2.718281828 ** epsilon))
    if random.random() < p_flip:
        return not true_value
    return true_value

def emit_tool_usage(tool_name: str, was_called: bool, epsilon: float = 1.0):
    noisy_value = randomized_response(was_called, epsilon)
    # Emit noisy_value instead of the true value
    telemetry_client.emit({
        "tool": tool_name,
        "called": noisy_value,
        # NO user_id, NO timestamp with second precision
    })

When you aggregate thousands of these responses, the true rate emerges from the noise — but no single event reveals truth.

2. The Laplace Mechanism for Continuous Metrics

For numeric measurements like latency, token counts, or cost per request, you add calibrated Laplace noise:

import numpy as np

def privatize_latency(true_latency_ms: float, epsilon: float, sensitivity: float = 5000.0) -> float:
    """
    sensitivity: max possible change from one user's data.
    For latency capped at 5000ms, sensitivity is 5000.
    """
    noise_scale = sensitivity / epsilon
    noise = np.random.laplace(0, noise_scale)
    return max(0.0, true_latency_ms + noise)

def emit_latency_event(latency_ms: float):
    private_latency = privatize_latency(latency_ms, epsilon=2.0)
    telemetry_client.emit({
        "metric": "tool_latency_ms",
        "value": private_latency
    })

With ε=2.0 and a 5000ms sensitivity cap, individual measurements are meaningless. But averaged over thousands of calls, your p50/p95 estimates will be accurate to within a few percent.

3. Aggregation-First Architectures

An alternative to local DP is keeping raw events only on the user's device or in an isolated secure enclave, and releasing only aggregates to your central observability stack.

The architecture looks like this:

1. Agent session runs locally or in a per-tenant enclave
2. At session end, compute local aggregates: tool call counts, total latency, error flags
3. Apply Laplace noise to each aggregate (with ε budget split across metrics)
4. Emit the noisy aggregates — never the raw events

class PrivateSessionSummary:
    def __init__(self, epsilon_budget: float = 4.0):
        self.raw_events = []
        self.epsilon_budget = epsilon_budget

    def record_event(self, event: dict):
        # Store locally only
        self.raw_events.append(event)

    def emit_summary(self):
        # Compute true aggregates locally
        tool_calls = len([e for e in self.raw_events if e.get("type") == "tool_call"])
        errors = len([e for e in self.raw_events if e.get("error")])
        total_latency = sum(e.get("latency_ms", 0) for e in self.raw_events)

        # Split epsilon budget across 3 metrics
        eps_per_metric = self.epsilon_budget / 3

        # Privatize and emit
        telemetry_client.emit({
            "tool_calls": max(0, round(tool_calls + np.random.laplace(0, 1.0 / eps_per_metric))),
            "errors": max(0, round(errors + np.random.laplace(0, 1.0 / eps_per_metric))),
            "total_latency_ms": max(0, total_latency + np.random.laplace(0, 60000.0 / eps_per_metric))
        })
        # Discard raw events
        self.raw_events = []

Setting Your Privacy Budget

The ε parameter is where most teams make mistakes. There's no universally "correct" value — it depends on your threat model and how many queries you plan to run against the data.

A rough guide:

• ε under 1: Strong privacy, but you need large sample sizes (10k+ events) for reliable aggregates. Good for sensitive health or financial workflows.
• ε 1–3: Practical for most B2B agent platforms. Good balance between noise level and aggregate accuracy.
• ε above 5: Very little noise added; essentially the same as no protection for small user populations.

Remember that every query you run "spends" from your budget. If you run 10 different aggregate queries on the same dataset with ε=1 each, your effective total is closer to ε=10. Use composition theorems (or libraries like Google's dp-accounting) to track your total spend.

What You Can Measure With DP

With differential privacy in place, here's what you can still measure reliably:

• Error rates by agent version — detect regressions after deploys without knowing which users triggered them
• Tool popularity distributions — understand which MCP tools your agents reach for most, without a per-user breakdown
• Latency percentiles — track p50, p95, p99 with noise-smoothed histograms
• Session length distributions — understand how long agent workflows run without reconstructing individual sessions
• Daily active usage counts — accurate to within a few percent with ε=2 and 1000+ sessions per day

What you lose is the ability to debug individual sessions. You won't be able to pull up "what exactly did user X do in session Y." That's the tradeoff — and for most operators, it's the right one.

Choosing a DP Library

Don't implement differential privacy mechanisms from scratch. Subtle errors in noise calibration or sensitivity bounds break the guarantees entirely. Use audited libraries:

• OpenDP (Python/Rust): Developed at Harvard and Microsoft, covers most standard mechanisms
• Google DP library (Java/Go/Python): Battle-tested at Google scale, includes composition accounting
• Apple's swift-homomorphic-encryption: If you're targeting mobile agent clients

For TypeScript/Node.js agents, the OpenDP Python library can be called via subprocess, or you can wrap the Rust bindings via WASM.

Pairing DP With Zero-Knowledge Storage

Differential privacy solves the analytics problem. But your agent may also need to persist state — conversation history, retrieved documents, intermediate reasoning steps.

For that data, the right tool is zero-knowledge encryption: encrypt before it leaves the client, store only ciphertext, and ensure your infrastructure never sees plaintext. BitAtlas is built around exactly this model — your agent's stored state is encrypted end-to-end, and the storage layer never has access to keys.

The combination is powerful: DP for your telemetry pipeline, zero-knowledge encryption for stored state. Neither layer can reconstruct what a specific user did.

Getting Started Today

The minimum viable implementation for most teams:

1. Add a session ID that rotates every session (not tied to user identity)
2. Drop high-cardinality fields from your log schema: raw queries, document contents, exact timestamps
3. Aggregate at the session level before emitting to your observability backend
4. Add Laplace noise to numeric aggregates with a conservative ε=1 to start

You'll still catch 95% of the engineering issues you care about. And you'll do it without building a surveillance record of your users' agent workflows.

Privacy-preserving telemetry isn't a future concern. The EU AI Act's technical documentation requirements, GDPR's data minimisation principle, and enterprise security reviews are asking about this today. Getting the architecture right from the start is far cheaper than retrofitting it after a breach or a regulator's inquiry.