Security and data handling

Extentos collects aggregate metadata about how developers use the platform — which capabilities are popular, which vendors get adopted, how flows perform, where errors surface. This data powers three things: the developer-facing analytics dashboard (coming soon — you'll see your own app's usage in one view), the Extentos team's product roadmap (which vendors to add next, which capabilities to harden), and the ecosystem insights Extentos shares with glasses vendors as aggregate market data (10+ account minimum). What Extentos never collects as telemetry is end-user content (speech transcripts, photo or video bytes, audio samples, AI prompts and responses), end-user PII (names, emails, phone numbers), toggle values, or stack traces.

Captured media runs locally. Photos, video, and sensor frames flow from the glasses to your app on the user's phone and never touch an Extentos server — the production transport is Bluetooth, and we are not in the path.

There is exactly one exception, and it is not telemetry: rendering a captured photo or clip on a Ray-Ban Display. The glasses can only load media from an http(s) URL they fetch themselves, so rather than make every developer stand up storage, we host a copy for you. It's a convenience you can decline — host the media yourself and pass a URL, and nothing is uploaded. If you do use it, read Hosted display media; it changes what your own privacy policy has to say.

This page is the honest, complete picture of what crosses the network from your install and your shipped apps to Extentos's backend.

TL;DR

Why we collect telemetry — the honest answer

Extentos's business model includes monetizing aggregate ecosystem insights, and we're upfront about it.

Three concrete uses:

1. Your own analytics dashboard. When the developer dashboard ships, you'll see your app's usage at extentos.com/apps/<your-app> — which voice triggers your users fire, which AI calls are slowest, which device models your users have, error rates, session lengths, weekly active users. Same data Extentos collects centrally, scoped to your accountId. This is genuinely valuable to developers and is why the underlying collection is broad rather than narrow.
2. Extentos's product roadmap. Aggregate signal across all developers tells us which vendors to add next (if 30% of new MCP installs ask about a vendor we don't support, we prioritize that transport), which capabilities are over-used relative to expectations, where the SDK has rough edges. Without this, every roadmap call is a guess.
3. Cross-vendor ecosystem signals to glasses vendors (planned, multi-vendor only). Once Extentos supports ≥2 vendors with material installed bases, aggregate comparative market data — capability mix across the ecosystem, vendor market share, session-hour totals across vendors — becomes uniquely valuable to glasses vendors who only see their own SDK telemetry. We plan to sell this as market research, only as aggregates over at least 10 distinct accounts, never as individual-developer or individual-end-user data. This is a planned future revenue line that activates at multi-vendor scale; a single-vendor version isn't a meaningful product because each vendor already collects their own platform's usage data.

We chose a transparent collect-and-aggregate model rather than a "we collect nothing" claim that vendors quietly walk back. The discipline is in the firm content/PII boundary, not in collecting less data overall.

What we collect

All telemetry events conform to a single envelope:

{
  "eventId": "tev_a1b2c3d4",
  "timestamp": "2026-04-18T14:22:10.432Z",
  "category": "runtime",
  "name": "connection.opened",
  "accountId": "acct_xyz",
  "installId": "inst_abc123",
  "appId": "com.example.app",
  "anonymousDeviceId": "dev_789",
  "libVersion": "2.8.0",
  "mcpVersion": null,
  "vendor": "meta_rayban",
  "platform": "android",
  "osVersion": "14",
  "deviceModel": "pixel_8",
  "country": "US",
  "userSegment": null,
  "properties": { "transportType": "RealMeta", "timeToConnectMs": 1820 }
}

The events split into two categories:

Dev-time events (MCP server, category: "mcp")

Emitted from your machine while your AI agent operates Extentos — so they're tagged with your installId (anonymous) and, after linking, your accountId.

Runtime events (your shipped app, category: "runtime")

Emitted by the Extentos library if the developer enables runtime telemetry (ExtentosConfig.telemetryConsent = true, default). Tagged with appId and anonymousDeviceId — never with end-user identity.

Notice the bold disclaimers — every event explicitly carries metadata only, never content.

Retired (deprecated) runtime events: pre-pivot the library also emitted trigger.fired, flow.completed, block.executed, callback.invoked, and spec.loaded to describe spec-DSL execution. Those events were retired with the pure-SDK pivot — the library no longer interprets a spec, so the events that described its execution no longer fire. Their schemas remain in the event registry marked deprecated: true for historical event-log validation; no new code emits them.

What we never collect

Verbatim list from the canonical telemetry doc (this list is published in the privacy policy). It describes the telemetry pipeline — the events your shipped app uploads to api.extentos.com/api/telemetry/events. Two features sit outside the telemetry pipeline and have their own data stories: the managed AI gateway (relays, never stores) and hosted display media (stores, until you release it).

• Speech transcripts (the words your user said)
• Photo bytes, video frames, audio samples — as telemetry. The display media host is the documented exception; see below.
• Handler-code input/output payloads (the LLM prompts your handler builds, the responses it receives, anything your business logic passes around between SDK calls)
• AI provider responses, prompt text, tool-use traces
• Toggle values, variable values
• End-user PII of any kind (names, emails, phone numbers, account identifiers in your app)
• IP addresses (derived to country at ingest, then dropped — we never store the raw IP)
• Stack traces (may contain arbitrary values; stay local in your on-device event log)
• Anything tied to a specific end-user identity beyond the per-device anonymous anonymousDeviceId

The library architecture enforces this — events are payload-stripped before they enter the upload queue, not in transit. No end-user content can reach the telemetry pipeline even if the network were intercepted, because the content never enters the queue in the first place.

That guarantee is about telemetry. It is not a claim that no end-user content ever reaches Extentos by any route — the gateway and the display media host are two routes that do, both opt-in by the capability you choose to use, both documented below.

Hosted display media — the one content path

If your app renders a captured photo or clip on a Ray-Ban Display, the SDK uploads a copy to Extentos before the glasses can show it. This is the only feature in the SDK that puts end-user media at rest on our infrastructure, and it exists because of a hardware constraint, not a product preference: the display fetches media only from an http(s) URL it can reach over its own Wi-Fi. A data: or file: URL is rejected on hardware, and the phone does not proxy the bytes. So a locally captured asset cannot reach the lens without becoming a fetchable URL first. Rather than make every developer stand up hosting, the SDK does it.

Exactly what happens.

What this means for you as the developer. Two obligations, both small:

1. Wire forgetHosted* into your delete path. If a user deletes a photo in your app and you don't call it, the hosted copy stays. That is the single most likely way this becomes a real privacy problem, and it is entirely in your code.
2. Disclose it in your own privacy policy if you use the display with captured media. Your end user's relationship is with your app, not with us; "media is uploaded to our SDK vendor's host to render on the glasses, and deleted when you delete the item" is the honest line.

How to avoid it entirely. Host the media yourself and pass image(url) / video(url). The SDK uploads nothing on that path. If your app never uses the display, or only renders text and layout nodes, this section doesn't apply to you at all.

A developer-supplied storage option (bring your own bucket) is on the roadmap so this stops being a choice between our host and hand-rolling your own.

End-user privacy — your shipped apps

The clearest line: on real Ray-Ban Meta glasses, the production transport never talks to Extentos.

• RealMetaTransport (the production transport) speaks to Meta DAT and the glasses over Bluetooth. It does not connect to api.extentos.com. End users on real hardware have no network relationship with Extentos at all.
• BrowserSimTransport (the simulator transport) does talk to the Extentos backend over WebSocket — but BrowserSimTransport only runs in config.debug == true builds during development. Shipped release builds resolve to RealMetaTransport when a vendor module claims bonded glasses, otherwise SystemAudioTransport, which doesn't connect.
• LocalSimTransport (in-memory simulation — no DAT SDK) is fully on-device. No network at all.

Runtime library telemetry is on by default (ExtentosConfig.telemetryConsent = true): the library emits the runtime events above to https://api.extentos.com/api/telemetry/events. It carries metadata, never content. The developer can turn it off per-app via telemetryConsent = false.

Telemetry is the only network path that is on by default. Two more open only if you use the capability behind them:

A shipped app that leaves telemetry on, uses the managed assistant, and renders captured media on the display touches all three. An app that does none of those emits nothing to us at runtime.

End users never see Extentos branding, never get prompted by us, never need to consent to anything from us. Their privacy relationship is entirely with the developer's app — Extentos is invisible.

The 5 ID model

Five identifiers, each with a distinct scope. None of them is end-user PII, and Extentos cannot reverse any ID back to a person.

The anonymousDeviceId lets Extentos count distinct devices and sessions without ever learning end-user identity. The userSegment is set by the developer — Extentos never sets or interprets it. It exists so the developer can cut their own dashboard by cohorts they define (beta tiers, geography, app version) without exposing any personal information.

AI calls: the managed gateway, and your own calls

Extentos touches AI two different ways, with two different data stories. The full mechanics are on the managed AI gateway page; here's the privacy-relevant summary.

Managed gateway (the Phase 4 assistant runtime, default). Voice-AI traffic routes through Extentos's gateway on Extentos's provider key. Extentos is in the path — but as a transient relay: audio, transcripts, and model responses are forwarded verbatim and never stored. The only thing recorded is the provider's per-response usage object — token counts (input/output, text/audio, cached) plus the computed cost — tagged with your appId and accountId for per-project metering. No prompt, transcript, photo, or response content is stored. The content boundary in the "what we never collect" list holds for the gateway: relayed, never inspected, never persisted.

Your own AI calls. Your handler calls a non-assistant provider (a vision model on a captured photo, a translation API) directly, with a key you wire into your own code. Extentos has no hook into that path — it never sees the key, the request, or the response. The getCredentialGuide MCP tool generates setup instructions for you to follow with your provider; Extentos never receives the credentials.

So "Extentos never proxies your AI" is true for AI you call yourself from handler code — and that was the only model the earlier docs described. For the managed gateway it isn't: Extentos relays the call, but never stores its content. This page states both honestly.

Three opt-out surfaces

Telemetry is opt-out at three independent levels, each disabling a different layer:

Any combination works. Telemetry never affects functionality — opting out doesn't disable any feature, just stops uploads.

The on-device event log (the 512-entry ring buffer your agent queries via getEventLog) keeps working regardless of telemetry consent — in production that data never crosses the network (in simulator mode it is mirrored to the backend for agent debugging). See event log vs telemetry boundary.

Retention and deletion

Right-to-erasure (GDPR Art. 17 / CCPA right to delete). The indefinite-retention default does not block right-to-erasure. Developers can email support to delete their account's events; Extentos runs DELETE WHERE accountId = ... and acknowledges within 30 days (GDPR-compatible SLA). Note that this covers telemetry events — hosted display media is not reachable by an account-scoped delete, because uploads are not account-attributed. Delete those from your app with forgetHostedImage / forgetHostedVideo; if you need a bulk purge, contact support. This deletes raw events tied to the account; aggregated rollups derived before the deletion request stay (those have no accountId attribution by construction). Anonymous events without an accountId (emitted before account linking and never retroactively re-tagged) cannot be associated to a person and are kept as aggregate-only data.

CCPA "sale" classification. The planned cross-vendor data product qualifies as a "sale" under CCPA when it ships. The developer-level Do-Not-Sell mechanism is ExtentosConfig.dataSharingConsent = false (a shipped SDK field) — disables aggregate inclusion only, while the developer's own analytics dashboard keeps working. The current telemetryConsent = false is all-or-nothing.

Transport and auth security

• TLS everywhere. All Extentos backend connections (api.extentos.com for telemetry and simulator-session WebSockets) use TLS 1.2+. No plaintext channels.
• Auth tokens at file mode 0600. When you link an account, ~/.extentos/auth.json is written with owner read/write only. Other users on the machine can't read your token.
• Identity on telemetry calls. Telemetry uploads carry the installId (MCP-side) or appId + anonymousDeviceId (library-side). When the developer has linked an account, the MCP server also attaches its account bearer so events attribute to the account — no end-user credentials are ever sent.
• Local bridge bound to 127.0.0.1 only. The MCP server's auto-bind listener (port 31337) refuses non-loopback connections. The installId it serves is not a secret — it's the same value sent to api.extentos.com on every tool call — so loopback exposure is intentional.
• Pre-GA hardening note. The current telemetry ingest scheme trusts self-reported IDs (per docs/mcp/TELEMETRY.md). For MVP this is acceptable — spoofed events skew aggregate fleet data, not security-sensitive. Before external GA, this hardens to one of: ingest-signed install tokens, per-request HMAC keyed on a secret baked at library init, or rate-limit-based outlier detection.

How to verify what we collect

You don't have to take this page's word for it — inspect the wire. Proxy your install's and your app's traffic to api.extentos.com and you'll see exactly what's sent: aggregate metadata, never content or PII. The @extentos/mcp-server package is MIT-licensed on npm, so its telemetry pipeline (src/telemetry/) is open to read directly; the native libraries are proprietary, but everything they send crosses that same observable network boundary.

Documentation can drift; the bytes leaving your app can't. Watch the wire and hold us to this page.

Compliance posture

For compliance-sensitive apps today: ship with ExtentosConfig.telemetryConsent = false to disable all library telemetry. Combined with the fact that RealMetaTransport doesn't talk to Extentos's backend, your shipped app emits zero traffic to us at runtime — provided you also skip the two opt-in paths: use your own AI provider from handler code rather than the managed assistant, and pass pre-hosted image(url) / video(url) rather than local captures if you use the display. With those three settings, the privacy boundary is enforced architecturally, not just by policy.

For developers who want telemetry on (for the developer dashboard) but want to opt their app's data out of vendor aggregates: set ExtentosConfig.dataSharingConsent = false. Your own dashboard analytics keep working; your data is excluded from cross-account aggregates we may sell to glasses vendors once the multi-vendor product ships. (The dataSharingConsent field is available in the SDK; the cross-vendor product it would exclude you from is still forthcoming, so today it changes nothing in practice.)

Frequently asked questions

Wait — Extentos collects telemetry from my shipped app?

By default, yes — runtime metadata events (no content, no PII) flow to api.extentos.com/api/telemetry/events from your shipped app if ExtentosConfig.telemetryConsent = true (the default). Set it to false and your app emits zero Extentos network traffic. Many apps will leave it on because the developer dashboard is built on this data — you're trading runtime metadata for an analytics surface for your own app.

Will my users' voice transcripts ever leave their device?

It depends which AI path you use. Transcripts your own handler processes (via glasses.audio.transcriptions()) are never read, logged, or transmitted by Extentos. If you use the managed-gateway assistant, the audio and transcripts are relayed through Extentos's gateway to the AI provider — forwarded verbatim and never stored; only token-usage metadata is recorded. If your handler calls your own provider directly (handler-code BYOK), that's between your app and your provider — Extentos isn't in the path. See the gateway data path.

Can Extentos see what my user captured in a photo?

No — Extentos never inspects photo content. Capture bytes flow from the glasses to your handler and Extentos doesn't read, store, or upload them.

But "can Extentos see it" and "does a copy ever sit on Extentos infrastructure" are different questions, and the honest answer to the second is: once, in one case. If you render a captured photo or clip on a Ray-Ban Display, the SDK uploads a copy to our media host so the glasses can fetch it — it stays until your app calls forgetHostedImage / forgetHostedVideo, and nobody at Extentos looks at it, but it is stored. Full details, including how to avoid it.

Two smaller nuances: if you pass an image to the managed-gateway assistant for vision, it's relayed to the AI provider (never stored by us); and during development, simulator sessions mirror captured frames to the backend debug log, truncated, for 48 hours. Outside those paths, photo bytes only reach an external service if your own handler code sends them.

Will Extentos sell data about my app to my competitors?

When Extentos supports multiple vendors, we plan to sell aggregate cross-vendor ecosystem signals (vendor market share, capability popularity across platforms, session-hour totals across the ecosystem) to glasses vendors as market research, only as aggregates over at least 10 distinct accounts. We additionally suppress vendor-level data when fewer than 25 developers ship to that vendor — small-vendor ecosystems are protected from inadvertent disclosure. Individual-account data, your specific app's usage patterns, and anything that could identify your app or your users is never shared with third parties. These two floors are the structural guarantees against competitive leakage. This product is multi-vendor-dependent — at single-vendor scale today, no such sale takes place because each vendor already has their own platform's data via their SDK.

Developers can also opt their app out of inclusion in future vendor aggregates via ExtentosConfig.dataSharingConsent = false (a shipped SDK field) — separate from disabling telemetry collection. Your own developer-dashboard analytics keep working; your data is excluded from cross-account aggregates.

Can my users opt out of Extentos telemetry?

End users have no direct relationship with Extentos and don't see our branding. Their opt-out is via the developer's app — if you want to give your users a toggle, gate ExtentosConfig.telemetryConsent behind a setting in your app. Or simply ship with telemetry off if your privacy posture requires it.

Is my Extentos auth token shared across machines?

No. ~/.extentos/auth.json is per-machine. To use the same account on another machine, run extentos-mcp login there. The token is stored at file mode 0600 (owner read/write only).

Does Extentos work in air-gapped or no-network environments?

The MCP-driven dev loop (code generation, validation, on-device LocalSimTransport simulation) works fully offline. The browser simulator (BrowserSimTransport) and the simulator-session features need network access to api.extentos.com. Your shipped app on real glasses (RealMetaTransport) doesn't need network access to Extentos — only between the phone and the glasses, plus whatever AI providers your app calls.

When does the developer dashboard ship?

It's on the roadmap; the data pipeline is already collecting events from MVP day-one so the dashboard is purely a backend query layer over data that already exists. Watch the changelog for actual ship dates.

What about developer source code?

Your generated code, your spec, your handler implementations, your test fixtures — none of it ever leaves your machine. The MCP server reads your project to inspect state (inspectIntegration, validateIntegration) and writes generated files, but it does not upload your code, contents, or git history anywhere.

How do I request deletion of my data under GDPR?

Email Extentos support from the email associated with your account. We run DELETE WHERE accountId = ... and acknowledge within 30 days. The indefinite-retention default does not block right-to-erasure — deletion requests are honored independent of retention policy. Aggregated rollups derived before the deletion request stay (those have no accountId attribution by construction); raw events tied to your account are removed. Anonymous events without an accountId (emitted before account linking) cannot be associated to you and are retained as aggregate-only data.

Related

• Pricing — what the free tier covers, the account-required browser simulator
• Auth — anonymous-first identity model, device-code flow, account linking
• Architecture — how telemetry fits into the broader system, what the on-device event log captures
• Changelog — track when the developer dashboard and other features ship