TSE-Assistant

Security & Data Handling

Last updated: 1 October 2026

TSE-Assistant reaches your data in three different ways, and each handles it differently:

• The developer tools in your IDE run on your developer's machine.
• The installed Sofia app runs on the consultant's or super-user's machine, and sends each question to the AI model that seat uses.
• Sofia in the company dashboard, in Microsoft Teams and in Slack is a service we host, which your admin switches on. It keeps your conversations so you can come back to them.

The sections below say, for each one, what stays with you, what reaches an AI model, and what we keep.

1. Developer tools in your IDE — on your developer's machine

For the person who approves software on developer machines or administers your GitHub organisation's Copilot policies: For IT administrators is the one-page version — what is installed, what leaves the machine, how to verify the installer, and the registry entry a GitHub Copilot Business or Enterprise organisation may need.

What happens on the machine. Setup builds the metadata index from your PackagesLocalDirectory on the developer's machine. The tools search, read and change your X++ on that machine, and builds, best-practice checks and tests run there too. Before any change, the agent keeps a backup of the file on that machine, encrypted on company seats.

What reaches an AI model. Whatever the tools return, X++ source included, goes to the AI model your IDE uses: GitHub Copilot in Visual Studio, VS Code or the Copilot CLI, Cursor, Claude Code or Claude Desktop. That happens under your agreement with that provider. We don't choose the model, and that traffic doesn't pass through us.

What we receive and keep.

• Your account and licence.
• For company plans, one audit record per tool call: which tool, which seat, when, a SHA-256 fingerprint of the arguments and the size of the response. For tools that change something, the record also carries the names of the objects and models changed. It never holds the arguments, code, field values or record keys. An automated test fails our build if source text ever appears in an emitted record.
• The machine's check-in: host name, Windows user name, machine id, agent version, and the index build and its status.

2. The published index — company plans, for consultant and super-user seats

Consultant and super-user seats answer from a copy of the environment's index that a developer machine (the environment's producer) publishes. It is published only when the environment is set to "Publish index" on the dashboard; a new environment does not publish until an admin says so.

What it holds: the metadata of your custom models — objects and their structure, such as tables, fields, relations and methods — and the environment's label texts. That includes the text of Microsoft's standard labels, generated on your own machine from your licensed environment.

What it never holds: source code, code snippets, comments, usage examples or descriptions. The publish step refuses to upload an index that carries any of them.

Where it is kept: in your account's private storage area on our Azure storage in UK South. Only your account's seats can download it, and Sofia in the dashboard, Teams and Slack reads it on your behalf. The Microsoft standard half comes from a shared prebuilt we publish for every customer; it carries no source and no label text.

3. The installed Sofia app — on the consultant's or super-user's machine

What happens on the machine. Sofia runs on the machine and reads the downloaded published index. With live data connected, she also reads your environment through the person's own Microsoft sign-in, so your Dynamics 365 security applies to what she can see. On a consultant seat she can propose record changes and business operations, and nothing changes until the person confirms. A super-user seat never changes anything. Conversations and memories are kept on that machine.

What reaches an AI model. Each question goes to the model the seat uses, together with what the tools found, which can include record values from live data. The seat uses one of two routes:

• Your own API key — the provider you chose, under your agreement with it. You paste the key into the app, which keeps it encrypted on that machine.
• TSE's LLM (company seats, off until your admin switches it on) — the question passes through our service to Azure OpenAI in UK South (gpt-4.1-mini) or, if your admin allows it, OpenAI's API in the United States (gpt-5.6-terra). Our service records the seat, the model, the tokens and the cost of each call. It does not keep the question or the answer.

4. Sofia in the dashboard, in Microsoft Teams and in Slack — hosted by us, when your admin switches it on

Off until your admin switches it on (Configuration → Sofia → "Enable Sofia in Teams, Slack and the Company dashboard"). Switched off, she answers every message in Teams, in Slack and on the dashboard with a sentence saying so; she stores nothing and nothing is charged. Switching it off later stops her at once, and what is already stored stays under the retention schedule (section 6). Your account owner can also delete all of your company's Sofia data at once, from the same place.

What she does. Sofia answers from the environment's published index — metadata, security objects and label texts. She doesn't read source code here. Without live data she changes nothing; with it (below) a consultant seat can have her propose a change, which happens only on that person's confirmation. A person must have a seat, and must have signed in to the dashboard once, before Sofia answers them in Teams; in Slack, the person signs in with their Microsoft work account once from the chat, which links their Slack user to their seat.

Live data in Teams, in Slack and on the Chat tab — off until your admin switches it on (Configuration → Sofia → "Live data in Teams, Slack and the Chat tab"). Switched on, Sofia also reads records from your environment, under each person's own D365 permissions: Teams signs the person in silently, the Chat tab and Slack ask once for a Microsoft sign-in, all against the TSE-Assistant Live Data app your organisation approved. The token Microsoft issues for that person is held in the Sofia service's memory, never written to disk, and the records Sofia reads go to the AI model and to the person, and nowhere else; every such answer says "read N rows from <entity> under your permissions — not stored". A consultant seat can also ask Sofia to propose a record change (create, update, delete) or an operation (an OData action, such as posting a journal). The proposal is shown with the records it touches, and nothing is written or run until that person clicks Apply — a delete or an operation also needs the word "confirm" typed; it then runs under the person's own D365 permissions, and our audit keeps a value-free record of it (the entity or action, the outcome — no record values). Super-user seats stay read-only. With this switch on, conversations in Teams, in Slack and on the Chat tab are no longer stored: they are held in the service's memory for the conversation only — the last 20 turns, gone after 30 minutes of quiet or an update of the service — and never reach our database or a backup (Teams and Slack keep their own copy of the chat in your organisation and your workspace). Your company's stored conversations, and the feedback records that quote an answer, are deleted the moment the switch goes on. Documents and memories are kept as before. Switching it off stores conversations again from the next message; what was held in memory is not written.

Where the model runs. Always on TSE's LLM: gpt-4.1-mini on our Azure OpenAI resource in UK South, or gpt-5.6-terra on OpenAI's API in the United States under OpenAI's API data terms. A new account's seats use gpt-4.1-mini until your admin allows the US model; your admin chooses which models seats may use, and the default.

What we keep, for your account and each person.

• Conversations: your messages, including the text of any requirement file you attach, and Sofia's answers.
• The memories Sofia saves when you ask her to.
• The documents she writes, such as functional design documents.
• Each person's model choice.
• The link between a Teams chat, or a Slack thread, and its conversation.
• For Slack: your workspace's id and the bot token your admin granted (encrypted at rest), and the link between each person's Slack user id and their seat.
• Your 👍 or 👎 on an answer, with a copy of that question and answer (not while live data is on).
• The tokens and cost of every model call.
• An audit record per tool call, as in section 1: value-free.

Storage. Sofia's data counts against your account's storage allowance, together with the published indexes (1 GB included; more in +2 GB packs), and your admins see how much each person's conversations, memories and documents take on the Storage tab. Above the allowance Sofia keeps answering, and only saving a new document waits until storage is added or data deleted.

Microsoft Teams. Messages reach Sofia through Microsoft's Bot Framework. A file you attach in Teams is downloaded by Sofia from Teams' own link, and only a text file's contents are kept, as part of your message. The chat itself also stays in Microsoft Teams, under your organisation's Teams settings: when a conversation is deleted on our side, our copy goes, not the chat in Teams.

Slack. Messages reach Sofia through Slack's Events API, each one signed by Slack and checked by us. Sofia answers in the thread of your message, and a file you attach in Slack is downloaded by Sofia from Slack's own link under the bot token your admin granted; only a text file's contents are kept, as part of your message. The chat itself stays in Slack, under your workspace's retention settings. Your admin's Disconnect revokes the token and forgets every person's link.

5. Microsoft standard code

Microsoft licenses the standard D365 F&O source to your environment. We never store it. What TSE-Assistant does with it:

• Sofia in the dashboard, Teams and Slack never reads source code, standard or custom. She gives the location of a standard method.
• The published index carries no source. It does carry your environment's label texts, including Microsoft's standard labels, generated on your machine from your licensed environment and kept only in your account's private storage.
• Standard-code review (Configuration → "Standard-code review", off until your admin turns it on): when Sofia needs a standard method's implementation, she asks your dev box to explain it. A review runs there on the box's own Microsoft channel (GitHub Copilot with an Azure-hosted model, or Azure OpenAI in your tenant), and only the explanation comes back. Without a dev box online, or with the switch off, Sofia tells you where the method is.
• The capability relay (behind the same switch) passes only your own custom-model code, from your dev box to your consultant's app, in memory for one request. Microsoft standard code is refused on the dev box before anything leaves it.
• In your IDE, and in the installed Sofia app on your own AI key on a machine that holds PackagesLocalDirectory, the tools return source — standard code included — to the AI model that client uses. Choose a channel whose terms allow processing Microsoft's code: we recommend GitHub Copilot Business or Enterprise, or Azure OpenAI in your own tenant. The choice, and the account tier, are yours (Terms, section 5).
• One case to know about, until agent release 1.2.28: the installed Sofia app on TSE's LLM, on a machine whose profile holds PackagesLocalDirectory, can send standard source through our service to the model, which does not store it. Company consultant installs register without that folder, so this is not the default. From 1.2.28 the app routes such questions to the review above instead.

6. What we keep, and for how long

A daily sweep deletes each record when its period ends. "While the account exists" means until the account's data is deleted, 90 days after it closes.

Record	What it contains	Kept
Account and seats	names, e-mail addresses, Microsoft or GitHub account ids, roles, tiers, seat environments	while the account exists; deleted 90 days after the account closes, or earlier on request
Billing	plan, seats, trial and renewal dates, Paddle customer and subscription ids (card details stay with Paddle)	while the account exists, then as accounting law requires
Registration tokens	a hash of the token, with the seat, tier and environments it registers	expire after 15 minutes; removed by the daily clean-up
Activation codes (individual plans)	the code, the account and the plan chosen	until redeemed; unredeemed codes expire after 24 hours and go at the daily clean-up
Machines (company plans)	host name, Windows user name, machine id, agent version, index status, check-in times	until an admin revokes the machine (uninstalling does not), then 14 days; a developer install that never checks in, 48 hours
Individual licences	the licence, the plan and a one-way hash of the machine it is bound to	while the account exists
Trial checks (individual plans)	a one-way hash of a machine's identifiers and the account that used a trial on it	24 months after the trial
Licence revocations	a refunded or charged-back licence's identity, so it cannot start a new trial	24 months
Admin actions	privileged dashboard actions, such as an ownership change: who, what, when	6 years, including after the account is deleted
Audit records (company plans)	tool, seat, time, argument fingerprint, response size; change events add object and model names	reads 90 days, changes 180 days
Published index	custom-model metadata without source; the environment's label texts	while the environment publishes; when it stops, the published copy is retired and deleted 7 days later (restorable until then), together with the copy Sofia composes from it; the account's standard label-text pack once no environment publishes; all of it within 90 days of the account closing
Team instructions and configuration	what your admins write for your team	while the account exists
Sofia conversations	your messages (with attached file text) and Sofia's answers	while live data in Teams, Slack and the Chat tab is off: 12 months after the last message, or when you delete them — each conversation has a delete button
Sofia conversations (live data on)	your messages and Sofia's answers in Teams, in Slack and on the Chat tab, which can quote records read under your own permissions	never stored — held in memory for the conversation (the last 20 turns, gone after 30 minutes of quiet or an update of the service); the company's stored conversations and feedback records are deleted when the switch goes on
Answer feedback	your 👍 or 👎 on one of Sofia's answers, with the question, the answer, the tools and the model it names, so we can improve her	12 months after the verdict, or when you delete the conversation or take the verdict back; none is recorded while live data in Teams, Slack and the Chat tab is on
Live-data sign-in token	the token Microsoft issues for you to the TSE-Assistant Live Data app, and the ones exchanged from it for your environments	never stored — held in the Sofia service's memory, dropped after 12 hours without a read, or when you disconnect
Sofia memories	what you asked Sofia to remember	until you forget them (at most 200; past that the oldest drop out)
Sofia documents	the documents Sofia wrote	until their author or your account owner deletes them
Model choice	the model each person picked	while the account exists
Teams chat link	Teams' reference to the chat and to you, and the chosen environment	deleted with its conversation
Slack workspace and person links	the workspace's id and name, the bot token your admin granted (encrypted), who connected it and when; each linked person's Slack user id against their seat	until your admin disconnects the workspace, or the person sends /sofia unlink; the thread's reference is deleted with its conversation
Model usage	per call: seat, model, tokens, cost — never the prompt	12 months
Sofia credit purchases	the Paddle transaction reference and the amount	as the billing records
Security events	refused requests and tamper signals (for example a modified bundle or a changed producer): time, kind, account, machine, IP address	12 months
Mail we send	recipients, subject, delivery status	90 days
Payment notifications	Paddle's event ids, types, dates and outcomes — no payment details	12 months; the latest one per subscription while the account exists
Data protection requests	the reference, when it arrived, how it was answered (our log, outside the Service)	2 years after it is closed; a complaint's, 6 years
Relay snippet	your own custom-model code passed from your dev box to your consultant's app for one request (off until your admin switches it on)	never stored — held in memory for that request

Memories, documents, model choices, the published index and every other row above that says "while the account exists" go when the account's data is deleted, 90 days after it closes — except the billing records and credit purchases, which follow accounting law. Our database backups are kept for 7 days, so a deleted record leaves them within 7 days; our service logs are kept 30 days.

7. Isolation, access and licensing

• Isolation. Every request is scoped to your account on our server.
• Tokens and codes. Registration tokens are single-use and expire after 15 minutes. Activation codes for individual plans expire after 24 hours.
• Licences and seats. Licences are signed, and what each seat can do is decided by its tier on our server, not by files on the machine: a developer seat has no Sofia chat; a super-user can't change anything; a consultant's change through Sofia — on a laptop, in Teams or on the dashboard — happens only on that person's confirmation and under their own D365 permissions.
• Your environment's credentials. Live data uses the person's own Microsoft sign-in, and we store no password or secret for it. On a dev box, the agent keeps the credentials it needs sealed in an encrypted store on that machine.

8. Transport and storage security

• In transit: TLS everywhere.
• Our side: server secrets are held in managed stores, and our database and storage are encrypted at rest by Azure. We host on Microsoft Azure in UK South.
• Backups and logs: our database backups are kept for 7 days, so a deleted record leaves them within 7 days. Index files are not backed up: a deleted index file is gone (a retired environment's index stays restorable for 7 days first — section 6). Our service logs are kept for 30 days and hold identifiers, not your questions, your code, e-mail addresses or file names.
• If something goes wrong: if a personal data breach affects your data, we tell your account owner without undue delay — and in any event within 72 hours of becoming aware of it — and the regulator where the law requires.
• On your machine: the agent seals its credentials, using Windows DPAPI for its registration, and encrypts its pre-change backups on company seats.

9. Responsible disclosure

Found something? Please write to security@tse-assistant.com. We welcome good-faith security research and will work with you on any valid finding. Good faith means: you don't access, change or delete data that isn't yours, you don't disrupt the Service or other customers, and you report promptly and give us reasonable time to fix before you publish.