Data handling

Who receives data

Amy runs in the browser inside Azure DevOps. AI features send content only to the backend your organization administrator configured. That backend is operated by your organization or a provider it selected, and it forwards content to the AI provider it is configured with.

The Marketplace publisher operates no backend, no AI subscription and no data store for Amy, and receives no Wiki, work-item, pull-request or usage data. The extension does not include a shared or default remote backend.

What is sent, and when

Content is sent only when a user triggers the corresponding action:

Action	Content sent to the configured backend
Create Work Items from a Wiki page / regenerate item	Markdown of the selected Wiki page and, when the user includes them, of its subpages that fit in the request (read with the user's permissions, each with its title and path), the instruction, page title and path, process work-item types, area and iteration path names
Test Cases	Story title, description, acceptance criteria
Documentation assistant	Markdown of the loaded Wiki page and the command or instruction
Ask the Wiki	The question and the most relevant passages (page title, path, section, text) from the chosen scope. In scopes over 40 pages, the question (with the earlier turns, if session memory is on) first goes to the backend once more for search terms, and those terms and the question's keywords go to Azure DevOps Wiki Search, inside your organization and with the user's own permissions, to choose the pages. With Session memory on (1.1, default), also the chat's last six earlier questions and answers (answers shortened); they are kept in the browser only until the user leaves the chat. With Web search on (1.1), the backend masks the question's personal data, asks the AI model for up to three public search terms from it, and sends only those terms (backend 0.15.2; before, the question as typed) to the web search service your organization configured
Amy on work items (more actions)	Title, description, acceptance criteria, repro steps and comments of the selected work items
Release documentation	ID, type, title, state, description excerpt and link of the selected work items; the sprint goal and notes the user entered
Sprint documentation at the end of a sprint (1.1, `sprint-docs-automation`)	ID, type, title, state, description excerpt and link of the completed work items of the sprint, read with the backend's own Azure DevOps access for the teams an administrator chose. The documents are stored as proposals, visible to everyone in the organization who uses Amy
Pull-request docs (1.0 backends)	PR title, description, branch names, changed file paths, commit messages (no code diff) and relevant Wiki passages
Create a Wiki Page	The prompt, the chosen template's section names, and optionally the selected page's Markdown and the selected work items' text
Summarize Wiki Content	Passages of the pages in the chosen scope (page title, path, section, text) and the optional focus
Create Work Items from a prompt	The title and short description you typed
Create Work Items with web search (1.1, on by default where the backend has web search)	Nothing more from the browser. The backend asks the AI model whether public facts would help, from the title, the instruction and the beginning of the page or description, and sends up to three search terms the model writes (public names only) to the search service; never the page or description, and never a term that looks like it contains a secret. The results' titles, addresses and snippets go to the AI model with the request; the pages the work items rely on are linked in the review, in the created items' descriptions and in the backlog summary page
Ask about Work Items (1.1)	The question and the user's local date; then, for up to 300 work items the user can read that match the filter: ID, type, title, state, dates, area and iteration path, tags, parent title, and the description and acceptance criteria shortened to 600 characters each. With Both, also Wiki passages as for Ask the Wiki
Generate Project Documentation (architecture) (1.1, off unless the backend enables it)	Source code: the selected files of the chosen repositories, a share of each service's most informative files or all of them where the user chose so (at most the backend's upload budget, 25 million characters by default), with values that look like keys, passwords or connection strings masked; secrets files are never read. Also facts found by patterns in all other code and configuration files of the documented services (endpoint paths, trigger, queue, topic and schedule names, outgoing addresses, connection string names, setting and environment variable names, ports and base images, each with its file and line; masked like uploads, without the files' content), runtime data the user adds (caller and target names, dependency types and call counts exported from Application Insights; names and types of deployed apps exported from Azure Resource Graph), the paths of the other files, classic pipeline definitions (masked), and the pages of the chosen Wikis (this project's Wiki and, if the user chooses them, Wikis of other projects the user can read; all their pages or the pages the user picks) except the documentation trees. The Wiki pages the documentation cites are copied into it, in this project's Wiki, once the user approves the pages; copies of other projects' pages can then be read by everyone who can read this project's Wiki. Accepted for Amy on 2026-10-15; each organization decides by enabling the backend setting
Generate Project Documentation (project management) (1.1, off unless the backend enables it)	The pages (path, title, Markdown) of the chosen Wikis: this project's Wiki and, if the user chooses them, Wikis of other projects the user can read (their pages under `/<project>/<wiki>`, their Wiki links as plain text), except the architecture documentation, the management documentation and old `/Amy` persona pages; no source code. The new tree is saved only in this project's Wiki
Revise with Amy (both kinds of documentation)	The owner's instruction and the pages they name as right (pages of the result, or Wiki pages the browser reads with their permissions). The backend sends the AI model the instruction, an outline and related passages of the stored result, those pages, and the pages it rewrites; the instruction is kept in the job's history and the previous result for one undo, both deleted with the job
Debate Architecture (1.1)	The question, the conversation's earlier turns (shortened), passages of the documentation tree, and files the model asked for (masked), read with the user's permissions. With Web search on (backend 0.15.1), the backend asks the AI model whether public facts would help, from the question and earlier turns, and sends up to three search terms it writes (public names only, never one that looks like a secret) to the search service, once per question; the results' titles, addresses and snippets go to the AI model, and the answer links the pages it relies on
Review a Pull Request (1.1)	Source code: both versions of each changed file of the chosen pull request (within a size budget), with values that look like keys, passwords or connection strings masked; lock files, secrets files, binaries and generated files are never read. Also the pull request's title, description, branches and commit messages, the paths of skipped files, the review focus and instruction, the linked work items (title, description, acceptance criteria), and passages of the documentation tree and of the repository's decision records and API reference in its documentation folder. Read with the user's permissions; nothing is posted to the pull request. With Web search on (backend 0.15.1), the backend asks the AI model whether public facts would help (a library version, a known vulnerability, a standard), from the title, description, instruction, changed paths and the changed lines of dependency manifests, and sends up to three search terms it writes (public names only; never code, and never a term that looks like a secret) to the search service; the results' titles, addresses and snippets go to the AI model, and the review links the pages it relies on
Repository Documentation: Check (1.1, with architecture documentation)	Source code: of the chosen services, their documents (READMEs, docs, OpenAPI and Swagger definitions), configuration, manifests and container files, and as much of their other code as the backend's upload budget allows, with values that look like keys, passwords or connection strings masked; secrets files are never read. Also the facts found by patterns in all their code, as for the architecture documentation. The backend keeps the files until the check ends; per service it keeps the last result (to reuse it while nothing changed) and the checked documents' paths and contradicted statements (for the architecture documentation). The report is saved in this project's Wiki only after the user's review; dismissals are kept as project data
Code with Amy (1.1, `code-agent`, off unless the backend enables it, and only for organization administrators and the teams they allow)	From the browser: the task, the work item's title, description and acceptance criteria (read with the person's permissions), the chosen repositories and the AI settings; later answers, changes to the plan and instructions. The backend reads the chosen repositories itself, with its own Azure DevOps identity, and sends to the AI model what the run reads: the repository's file names, instruction files and README, source code of the files it opens and the lines its searches find, with values that look like keys, passwords or connection strings masked (secrets files are never read), and commit messages of files it looks into. After the plan is approved, also the changes so far, the pull requests' open review comments when asked, and the failed tasks' errors and log ends from the pipelines that validate its pull requests (masked). What it writes is pushed to a branch of the same repository and shown in a pull request: everyone who can read the repository can read it, and the code runs in your pipelines before anyone has reviewed it
Repository Documentation: Generate (1.1, `repository-docs`, off unless the backend enables it)	Nothing from the browser except the chosen repositories (ID, name, project) and the AI settings. The backend reads the default branch of each administrator-enabled repository itself, with its own Azure DevOps identity: source code within `REPO_DOCS_MAX_CHARS`, with values that look like keys, passwords or connection strings masked (secrets files, dependencies, build output, binaries and lock files are never read), README files, CLAUDE.md and the documentation folder, and sends them to the AI model in parts. To check findings against the connected services it also reads files of other enabled repositories that the person who started the run may read, masked the same way, and sends what the check asks for to the AI model; lines quoted as evidence appear in the documentation of the repository being documented. The documentation it writes, with code quotes and the assessments' findings (security findings with their evidence unless administrators chose Summary only or Left out), is pushed to a branch of the same repository and shown in a pull request: everyone who can read the repository can read it. Dev documents, when administrators turn them on: the lines that differ between the default branch and the dev branch, masked and with the lines around them, go to the AI model, except tests and changes of whitespace alone; commit messages, pull-request numbers and titles, authors and linked work-item numbers are written into the repository without AI
Update the Wiki (1.1)	The instruction, and the pages of the active Wiki in the chosen scope (all pages or the chosen ones, except `/Amy`), read with the user's permissions. The backend keeps the pages until the edits are proposed, and the result until the user saves or discards it; the AI receives the passages that match the change (or every page, if the user chooses so), the affected pages' mentions, the user's answers, and each chosen page in full for its edits. The extension saves the approved edits with the user's permissions
Personas (1.1)	Nothing from the browser with AI requests: the backend applies the organization's personas itself. Administrators send the persona texts and defaults when they save them. The one-time import reads the project's earlier `/Amy` Wiki pages with the administrator's permissions
Field controls on work items	The field's current text (Improve only; never for Regenerate), the title and the other supported text fields, the template outline
Pull-request documentation checks	Nothing from the browser except the time frame and scope of on-demand reviews. The backend reads PR metadata (no code diff) and the configured Wiki pages itself
MCP (AI clients)	The tool arguments the AI client sends; the backend reads the named Wiki pages and work items with the user's own permissions
Access by tab (1.1, `access-control`)	Nothing from the browser except the rules administrators save (teams and groups by name and identity descriptor), kept in the backend's state store. The backend reads each user's group memberships from Azure DevOps with its own identity and keeps them in memory for 5 minutes
Search index (1.1, `knowledge-search`, off unless the backend enables it)	Nothing from the browser except the settings administrators save. The backend reads the chosen projects' Wikis, source code (default branches; no build output, dependencies, lock files, media or files over 300 KB) and work items (fields and the newest 20 comments) with its own Azure DevOps identity, and sends passages of them to the embedding model and to Azure AI Search. Secrets files (`.env`, keys and certificates, secrets configs, `.npmrc`, infrastructure state and variables…) are never indexed, and values that look like keys, passwords or connection strings are masked in every passage (backend 0.34.0; an index built before reads every source again once and drops what it held of secrets files). Everyone who uses Amy can find what is indexed
Ask with search (1.1)	The question and, with session memory, the chat's earlier turns (all of them, up to 200,000 characters; answers shortened), with personal data masked. They are kept in the browser until the user selects New question or leaves the chat. The backend sends the model the passages it finds and the files, pages and work items it reads, only from the projects and repositories the administrators chose and never secrets files, with values that look like keys or passwords masked but personal data as it is; with web search on (the user's setting since backend 0.15.1; before, whenever the backend had web search), the model's search queries (never one that looks like it contains a secret). Attached files (`attachments`): text files masked like the question; screenshots are sent to the AI model unmasked, once, to be written down as text. Files are kept in the browser with the chat, not in the backend
Diagnose a Ticket (1.1)	The ticket text and replies the agent pastes, with personal data masked before anything goes to the AI model; the backend then reads code, Wikis, work items and, when connected, log lines and traces from Grafana (read-only, at most 7 days per query, masked). Attached files (`attachments`): text files masked; screenshots are sent to the AI model unmasked, once per screenshot. Sessions, including the end user's details and the attached files as they were attached, are kept in the backend's state store until an administrator deletes them, and are visible to everyone who uses Amy. Bugs are created by the agent with their own permissions. With Web search on (the user's setting since backend 0.15.1; before, whenever the backend had web search), the model may send search queries for public facts (never one that looks like a secret)
Design Requirements (1.1)	The messages and attached files of a design (research notes, transcripts, screenshots), and the requirements kept for it. Personal data is masked before anything goes to the AI model; screenshots are sent to the AI model unmasked, once per screenshot. Designs, their turns, their requirements and files are kept in the backend's state store per project until their creator or an administrator deletes them, and are visible to everyone in the project who has the Requirements tab. The Wiki pages are created and updated by the user with their own permissions. With Web search on (backend 0.15.1), the backend asks the AI model each turn whether public facts would help (a regulation, a standard, a public product), from the masked message and the product, and sends up to three search terms it writes (public names only, never one that looks like a secret) to the search service; the reply links the pages it relies on
Delight Check (1.1, off unless enabled)	Source code: each chosen UI page's file and the files it imports (two levels, at most 40,000 characters per page), read with the user's permissions, with values that look like keys, passwords or connection strings masked; optionally the motivators of a Design Requirements design. The backend keeps each page's assessment (not its code) per project for the next check; the uploaded files and the result are deleted when the user saves or discards the report
How It Works Today (1.1, `how-it-works`, off unless the backend enables it since backend 0.34.0)	Source code: the chosen apps' screen files and up to 300 backend files (endpoints, schedules, events), read with the user's permissions, with values that look like keys, passwords or connection strings masked; secrets files are never read. The backend keeps the files and the steps' results until the run ends, and each project's last map until it is replaced; the Wiki pages are written by the user with their own permissions
Mockup Designer (1.1, `mockup-designer`, off unless the backend enables it)	The messages, the screenshots (sent to the AI model unmasked) and links of each message, and with a new mockup's first message the Wiki passages it may concern (read with the user's permissions). The backend reads the chosen apps' code, styles, fonts and images itself, with its own Azure DevOps identity (secrets files are never read; values that look like keys or passwords are masked) and from the storage containers administrators name, and sends what the designer asks for to the AI model. With Amy's browser (`mockup-browser`, off unless the backend enables it), the backend opens the test environment address administrators give an app, signed in when the backend has a signed-in state for it, and sends the pages' screenshots and accessibility outlines to the AI model; a page it copies becomes the mockup's file, its pictures and fonts kept with the mockup. While Amy's designer works, the page runs in hidden frames in the user's browser, with no network. The mockups, their versions and screenshots are kept in Blob storage until the mockup is deleted; the designer's working file of a message (the conversation, pictures included) is deleted when the message's run ends, or an hour after a run that didn't finish, when the next one starts (backend 0.36.0). A version opened from a share link (`/m/<token>/…`) is readable without sign-in by anyone who has the link, until sharing is turned off or the link expires

Every request also carries a correlation ID, the Azure DevOps organization name and, as a label, the current project name. Without a separate sign-in (AUTH_MODE=azure-devops), when a session starts the extension sends the user's Azure DevOps access token once: the backend asks Azure DevOps who the user is in the organization (connectionData), issues its own session and discards the token; it is neither stored nor logged. The token carries the extension's permissions (see PERMISSIONS.md) and expires on its own. Backends offering ai-settings also receive the user's AI settings (model, thinking, response length, web search); the extension keeps them in memory for the conversation only.

What the extension stores

Organization configuration: backend URL, display name, flags, API version, trusted hostnames and change history, in Azure DevOps extension data.
Per user: whether the user has confirmed a backend hostname, in Azure DevOps extension data.
Backend session token: in the browser tab's sessionStorage until it expires, so Amy's pages in the same tab share one sign-in; removed when the tab closes or the backend rejects it.
Project templates: template names and section names per project, in Azure DevOps extension data.
Architecture documentation choices: per project, the team's changes to the Services table (names, kinds, merges, what to read) and the Code-vs-Wiki differences dismissed (the difference's kind, Wiki page and quote or page and code file, the reason, who dismissed it and when), in Azure DevOps extension data, readable by everyone who uses Amy in the organization. Generate Project Documentation also sends the team's Architecture Facts page, the dismissed differences and the names and last activity dates of repositories left out as possibly retired to the backend with the job.

Nothing else is stored in browser storage.

User confirmation

Users confirm the backend before first use and after every change.
Wiki and work-item changes require explicit confirmation: a creation summary, per-change review and an extra confirmation above 10 items.

Reference backend behaviour

The reference backend (backend/):

Content: does not store request content. Logs contain metadata only: correlation ID, operation, organization, pseudonymous user reference, latency, outcome, token counts.
Credentials: redacts credentials.
Per-organization records: keeps usage counters and audit records per organization, in memory.
Usage counts (when offered): how many times each quick action ran per day, per organization, under orgs/<organization>/usage/<month>. Counts only: no content, no user names or references. Shown to administrators under Organization settings > Amy AI > Monitoring.
Personas (when offered): the editor's display name with each entry's last change, plus the organization's identity and per-quick-action personas (text, default model, effort, lock), the last editor and a history of the last 20 changes (time, editor name, changed personas), in the state store under orgs/<organization>/personas. Only administrators can read or change them: Project Collection Administrators (the backend looks up the signed-in user's Azure DevOps groups with its own access and keeps the answer in memory for 5 minutes) or people with the backend's admin role. With STATE_STORE=memory they are lost on restart.
Architecture documentation jobs (only when enabled): in the organization's own storage account. Everyone with the tab sees that a job exists: who started it, when, its project, repositories, step and counts. Its result is open only to who started it and administrators. The uploaded code and intermediate results are kept until the job succeeds (for retries), then deleted; the result is deleted when the user creates the pages or discards it. One result per user and project: a new run replaces their unused one, never a colleague's. No time limit applies. Update the Wiki jobs work the same way, under orgs/<organization>/wiki-update/; everyone with the tab also sees their instruction, and what the job found and proposes is open only to who started it and administrators.
Design Requirements (when offered): in the state store under orgs/<organization>/requirements/<project>/: each design (title, creator's name and pseudonymous reference, every turn, the requirements, a summary of older turns for the AI model, the masking map, and the Wiki pages created from it as Amy wrote them) and the project's list of designs; files under orgs/<organization>/requirements-attachments/. Kept until the design is deleted.
Code with Amy (only when enabled): in the state store, under orgs/<organization>/code-agent/: the settings administrators save; the runs (who started them, the task, the work item's text, the plan, questions and answers, steps, what their AI requests used, pull-request links), and while a run works its conversations with the AI model, with the code it read as the model saw it (masked), and the full text of the files it changed (unmasked: lines it didn't change keep what they hold) until they are pushed. Conversations go when the run reaches its reviewers, or with a later follow-up; the rest stays until the run is discarded. Runs waiting for checks are also kept under code-agent-checks/<organization>/, by ID. Colleagues who have the feature see that a run exists, who started it, its status and pull requests, and nothing it read.
Repository Documentation (only when enabled): in the state store, under orgs/<organization>/repo-docs/: the settings administrators save (projects, excluded repositories, reviewer teams and groups by name and descriptor, folder, options); the runs, visible to everyone with the Code tab (who started them, repositories, status, counts, what their AI requests used, pull-request links), with intermediate results until the job ends (those of a repository to retry until it runs again) and the files written for each repository, downloadable only by who started the run and administrators, until the run is discarded or the newest 20 finished runs of the project push it out; per repository the AI's notes on each part of the code (summaries, endpoints, types and findings with short code quotes), reused while the part's files are unchanged and deleted when they change; and per repository its connections, found by patterns in the code (addresses, client names, topics, each with its file and line), and the commit a review reached when the documents needed no change. Merges waiting for an update are kept under repo-docs-automation/<organization>/ as pull-request numbers until the update starts, and when dev documents are next due under repo-docs-dev-schedule/. The code itself is not stored. One running job per project and repository. An update after a merge sends the changed lines of the changed files to the AI model, with the lines around them, and the sections of the documents that mention them.
Stored proposals (only when pull-request checks or MCP are enabled): in the organization's own storage account, keyed by organization. It keeps:
- pending and decided Wiki proposals (page path, proposed changes or new page content, reasons, source pull requests);
- backlog proposals from AI clients;
- pull-request review records (status, impact summary);
- service-hook delivery IDs;
- the check settings.
Proposals from AI clients are visible to their requester only. Pull-request proposals are visible to the organization's Amy users. Blob versioning and a 14-day soft delete apply; delete blobs under orgs/<organization>/ to remove an organization's data.