Azure DevOps analytics without a PAT, and without your work items leaving your tenant

How the extension authenticates without a personal access token

Agile Analytics is a Visual Studio Marketplace extension that loads inside dev.azure.com, in an iframe, using the Microsoft-provided VSS SDK. The signed-in Azure DevOps user’s session authorizes every request the extension makes against your tenant; the extension does not store or transmit Azure DevOps user credentials. That has two consequences worth spelling out to a reviewer. First, there is no standing credential anywhere: nothing to create, hand over, rotate, or revoke, because access ends when the user’s session ends. Second, because every request is made as the signed-in user, Azure DevOps applies that user’s own permissions. A project someone cannot open in Boards is a project the extension cannot read on their behalf. Microsoft is already retiring the broadest form of the alternative: from 1 December 2026, personal access tokens scoped to all accessible organizations are no longer supported. The extension has never depended on any PAT, so that change does not touch it.

Four read-only scopes, listed before you install

The extension declares exactly four Azure DevOps scopes, and all four are read scopes: vso.project for project, team, sprint, and iteration metadata; vso.work for work item fields and the revision history the analytics need; vso.graph for the group and membership information used by Access Control; and vso.build for build and pipeline metadata whenever a DORA view, widget, or Configuration → DORA is opened. It does not request vso.code, so it never reads repository content, and it requests no write or administrative scope, so it cannot modify work items, repositories, pipelines, or permissions. The scope list is shown on the Marketplace listing before install and on the Security page, and any change to it would require a new version to be reviewed and installed.

Where the data goes: three paths, only one of which crosses the publisher

The reporting path is the one that matters for your backlog, and it runs between the browser and the Azure DevOps REST API. Work item content and the metrics computed from it are rendered client-side and never traverse Baytek’s backend. The licensing path is the second: the extension talks to a single backend at ado-analytics.baytekdev.com for checkout, license issuance, activation, validation, revocation, seat enforcement, and a minimal install heartbeat. Each licensing request carries an HMAC-signed application token issued by the Marketplace for the publisher’s extension, and the backend verifies the signature and issuer before doing any work. The third path is optional integrations: GitHub Copilot Metrics and Teams or Slack webhooks are off by default, and when you enable them the request goes from the browser directly to api.github.com or to your webhook URL, with the iframe’s Content-Security-Policy restricting outbound connections to those known endpoints. Your configuration and per-user preferences are stored in Microsoft’s Azure DevOps Extension Data Service, hosted by Microsoft and scoped to your organization; Baytek does not host it and cannot read it.

Exactly what does reach the publisher, and the switch that turns most of it off

A design that keeps work items in your tenant still needs to know that an organization is licensed. Here is the complete list of what reaches Baytek, with the control you have over each item. It mirrors section 3 of the Privacy Policy, which is the single source of truth.

• License records (required): Azure DevOps organization name and ID, plan, expiry, status, and the activation tokens Baytek issues, which rotate on each successful re-validation, about every 12 hours of active use.
• Install and heartbeat events (required): organization name and ID, extension version, event type, and timestamps, used to count active installs and spot an organization whose extension has stopped loading. Licensing depends on the heartbeat, so it stays on.
• Usage and error telemetry (opt-out): an allow-list of event names such as which view was opened or which feature was used, a graded error category and never the error text, extension version, organization ID, and a pseudonymous Azure DevOps user GUID. Never a name, an email address, or work item content. Any licensed user can turn it off for the whole organization at Configuration → Privacy.
• Seat roster (required, assigned-seat organizations only): opaque Azure DevOps identity descriptors of the users holding a seat. No names and no email addresses; the descriptor format the backend accepts cannot decode to one.
• Trial-contact email (opt-in): an admin address submitted through the in-extension reminder prompt, used only for the day-23 and day-28 trial-end reminders.
• Anonymized peer benchmarks (opt-in, off by default): a rounded aggregate of cycle time, throughput, and sprint completion with a coarse team-size bucket. Never work item titles, IDs, or descriptions, and never project, team, or people names. A peer group is shown only once at least five organizations contribute, and turning Benchmarks off deletes your snapshot.
• Scheduled report digest (opt-in, off by default): a small aggregate computed by a pipeline in your own Azure DevOps, described in the next section. Report content is never stored; only delivery counters are kept.

Scheduled reports and alerts run in your tenant, not ours

Because there is no publisher-hosted service reading your work items on a schedule, anything that has to run when nobody has the extension open runs as an Azure Pipeline that you add to your own project. The extension generates the YAML; you review it and commit it. Those pipelines authenticate with the pipeline’s own System.AccessToken, the build service identity your organization already governs, so once again no personal access token is involved. The Delivery Digest and sprint transition alerts post straight from your pipeline to your own Microsoft Teams or Slack webhook, with Baytek nowhere in the path. The one exception, and it is opt-in and off by default, is the scheduled executive report digest: your pipeline computes a small aggregate (items delivered, WIP count, bugs opened and closed, average cycle time, plus the sprint name and reporting period) and hands it to Baytek’s delivery service, which renders it into an email, sends it, and discards the content. Recipients confirm by email before anything is delivered, and every email carries a one-click unsubscribe link. That is the only work-item-derived data that ever passes through Baytek, it is aggregate rather than item-level, and it is never stored.

What this design costs, said plainly

Keeping analytics in the browser is a trade-off, and a reviewer should see the other side of it. License enforcement runs client-side: the backend validates a license and answers yes or no, but there is no server-side chokepoint enforcing per-feature entitlement, because building one would mean proxying your data through the publisher, which is the opposite of the point. Baytek accepts that a determined engineer could tamper with the iframe to keep using the product past a trial, and deliberately fails open rather than risk a backend outage locking out a customer who has paid. The optional GitHub Copilot Metrics integration is the one place a personal access token appears at all, and it is a GitHub token, not an Azure DevOps one: it is stored in your organization’s Extension Data Service as a password-type field, read by your browser, and sent only to api.github.com. Because that storage is organization-scoped, any member who can open the extension could in principle read it, so use a minimum-scope, fine-grained token. Finally, the extension targets Azure DevOps Services; it is not available for Azure DevOps Server on-premises.