This policy describes the personal data processed by [TO COMPLETE — registered name, legal form, company number] (“Asteria”, “we”) in connection with the Asteria Cloud service, the purposes of that processing, its legal bases, how long data is kept, and who it is disclosed to.
Data controller: [TO COMPLETE — registered name, registered address]
Contact: [TO COMPLETE — privacy contact e-mail address]
1. Controller or processor, depending on the data
Asteria Cloud is sold to organisations. That distinction determines who you should address a request to.
- For the content you submit — conversations, documents, collections, workspaces — we act as a processor under Article 28 GDPR, on behalf of the organisation that gave you access. That organisation is the controller: it decides the purposes, and it is where you direct a rights request first.
- For account data and security logs we keep on our own account — authentication, incident detection, evidence of diligence, billing — we act as a controller.
If you are unsure which applies, write to us and we will point you to the right organisation.
2. Data we process
Account data. E-mail address, first and last name, password (never stored in the clear — only a bcrypt hash is kept), a profile picture if you upload one, and, if you sign in with single sign-on, the identifier and verified address supplied by Google or Microsoft.
Preferences. Language, occupation, nickname, interests and response-tone settings, where you fill them in to personalise responses. These fields are optional and can be cleared at any time.
Content. The text of your conversations, files you upload (PDFs, spreadsheets, images), document collections, workspaces, the agents and skills you create, and the derived representations the service needs (text extracts, index vectors, summaries, entity graphs).
Technical and security data. IP address, timestamps, event type, sanitised metadata, SHA-256 content fingerprints (not the content itself), and response volume. For a narrow subset of higher-risk operations — outbound tool calls, code execution, requests matching an injection signature — a plaintext excerpt is retained for 7 days solely for incident analysis.
Connector data. If you connect a third-party service (see §4), the corresponding OAuth tokens, encrypted at rest, and the data that service returns at your request.
Application diagnostics. When an error occurs, a technical report is sent to our monitoring tool (see §6). That report may include a session replay: a reconstruction of your interaction with the interface. Replays are sampled, and always captured when an error occurs.
3. Language models: three distinct configurations
This is the part of this policy a generic template does not cover, and the part that determines where your content goes.
The service sends the content needed to answer your request to a language model. Which provider receives it depends on the configuration your organisation has chosen, and the three cases are not legally equivalent:
- Asteria credits. We supply model access. The provider is then our sub-processor; it is listed in §6, and any change is notified to your organisation under Article 28(2) GDPR.
- Customer keys (BYOK). Your organisation registers its own credentials with a provider of its choosing. We transmit content to the provider it has designated, on its instruction. That provider is a processor of the customer, not ours: the contract, the safeguards and the processing locations are governed by the agreement between your organisation and that provider.
- Customer-supplied model (BYOModel). Your organisation runs its own model, typically inside its own infrastructure. Content does not leave the perimeter it controls, and we receive no data on this basis.
In all three cases the content transmitted is limited to what the current conversational turn requires: your message, the relevant context, and the document excerpts retrieval has selected.
Your organisation can tell you which configuration applies; the administration interface also shows it.
4. Data from Google services
When you connect a Google account, we ask for your explicit consent, through Google’s own consent screen, for the following permissions — and no others:
| Permission requested | What it allows | Why we request it |
|---|---|---|
openid, email |
Identify the connected account | Attach the authorisation to the right account and display it in your connections |
https://www.googleapis.com/auth/drive.readonly |
Read files in your Drive | Let you submit a document from your Drive for analysis, at your request |
https://www.googleapis.com/auth/bigquery.readonly |
Read BigQuery data and metadata | Let you inspect projects, datasets, tables and run read-only SQL queries at your request |
https://www.googleapis.com/auth/drive |
Read and write files in your Drive, and their comments | Let you create and edit Google Docs and reply to their comments, at your request. Google offers no narrower permission for document comments. |
https://www.googleapis.com/auth/calendar.events |
Read and write events in your calendars | Let you consult your schedule and create, update or cancel events, at your request |
https://www.googleapis.com/auth/calendar.calendarlist.readonly |
List the calendars you have access to | Know which calendar an event belongs to, without reading any other calendar data |
https://www.googleapis.com/auth/gmail.modify |
Read, search, draft, send and file messages in your mailbox | Answer questions about your mail and compose replies — sending and filing ask for your confirmation first; permanent deletion is not requested |
https://www.googleapis.com/auth/chat.users.readstate.readonly |
View when you last read Google Chat conversations | Distinguish messages you have already seen from newer activity, at your request |
https://www.googleapis.com/auth/chat.memberships.readonly |
View members of Google Chat conversations | Identify who participates in a space or conversation, at your request |
https://www.googleapis.com/auth/chat.messages.readonly |
View Google Chat messages and reactions | Answer questions about conversation content, at your request |
https://www.googleapis.com/auth/chat.messages.create |
Send messages in Google Chat | Post a message or threaded reply only after your confirmation |
https://www.googleapis.com/auth/chat.spaces.create |
Create Google Chat conversations and spaces | Start a direct message, group conversation or named space only after your confirmation |
https://www.googleapis.com/auth/chat.spaces.readonly |
View Google Chat conversations and spaces | List the destinations available to your account, at your request |
https://www.googleapis.com/auth/admin.directory.group.readonly |
Read the Google Workspace groups an administrator designates for collection access checks | Keep access to mirrored documents aligned with their source group membership |
https://www.googleapis.com/auth/cloud-identity.groups.readonly |
Read transitive Google Workspace group membership | Keep nested group access to mirrored documents aligned with the source |
Permissions are requested per service: you are asked only for the ones the connection you are setting up needs — connecting Drive alone never asks for calendar access. The table above lists everything that can be requested.
Use. This data is read at the moment you make a request that needs it, and used to answer that request. If you configure a workflow trigger, we also check the selected service in the background so the workflow can detect the event you chose; we do not crawl other Google services or resources for that trigger.
Retention. We do not build a persistent copy of your Google data. Authorisation tokens are kept, encrypted, until you revoke access. Calendar created and updated workflow triggers retain only opaque event identity fingerprints while the trigger exists. Calendar attendee-response triggers retain only those event fingerprints, event-scoped keyed attendee fingerprints and the last observed response value for the same lifetime, so later changes can be classified without storing names or addresses. Deleting the trigger deletes this state. Retrieved content is retained in two cases only. If you explicitly ask for it to be added to a collection, §7 applies. If you build a workflow that uses this data, each run records what started it and what its steps produced, so the workflow can act on it and so you can see what it acted on; both are deleted automatically 28 days after the run, and the run’s own history is kept without them. An audit log records the access (what, when, at whose request) without the content.
Drive trigger classifier state. Drive trash and removal triggers retain only trigger-scoped keyed file fingerprints and the last observed trash state, without file identifiers, names, paths, owners or content. Deleting the trigger deletes this state.
Selected Google Workspace file changes. A selected Docs, Sheets or Slides change trigger uses a Drive notification and reads only the selected file’s current metadata. It does not read document, cell or slide content. While the trigger exists, we retain its configured file reference, Drive notification channel and last observed file version. A change run records the file’s minimal current metadata under the 28-day workflow retention above. Deletion, trashing and loss of access do not create a run.
Google Docs trigger classifier state. A text-appearance trigger reads only the selected Google Doc in the background and retains only whether its configured literal was present and a private sequence number, without document content, excerpts or content fingerprints. A run created when the text appears records the selected document id, title and link, the configured literal and the presence transition under the 28-day workflow retention above. Deleting the trigger deletes its classifier state.
Sharing. Google data you give us access to may be transmitted to the applicable model provider under §3 where answering your request requires it, and to no other third party. It is never sold, never used for advertising, and never used to train models.
Limited Use commitment. Asteria’s use of information received from Google APIs, and any transfer of that information to other applications, adheres to the Google API Services User Data Policy, including the Limited Use requirements.
Revocation. You can withdraw this access at any time from the service’s Connections page, or from your Google account security settings. Revocation immediately invalidates the tokens we hold.
The same rules apply to Microsoft connectors, for which we request openid, email, profile, Files.Read.All, Mail.Read, Mail.ReadWrite, Mail.Send, Calendars.ReadWrite, Files.ReadWrite.All, Sites.Read.All, User.Read.All, GroupMember.Read.All, Chat.Read, Team.ReadBasic.All, Channel.ReadBasic.All, ChannelMessage.Read.All, ChatMessage.Send and ChannelMessage.Send. The directory permissions support profiles, photos, the connected account’s manager and group membership; the directory and Teams channel-read permissions require tenant administrator consent in Entra ID. Sites.Read.All is requested only when you choose to browse SharePoint while setting up a synced collection: it lists the sites you follow and the document libraries in them so you can pick a folder, and it is not used to read site contents on its own. Teams reads are limited to selected chats, joined teams, channels and bounded message metadata. Microsoft returns the complete message object because these Teams endpoints do not support field selection; unless a tool or workflow explicitly requests message text, Asteria Cloud drops the body before it reaches the model or workflow input. Hosted-content bytes are not fetched. If a Teams trigger, or an Outlook mail trigger, includes message text, the workflow input and output follow the 28-day retention described above. Outlook mail, Outlook calendar and OneDrive workflow triggers use the read permissions listed above and request none of their own; a mail trigger fetches message text only when you turn it on for that trigger. Interactive Teams sends are plain text and require confirmation; an unattended workflow send runs only under the authored workflow policy, with a separate approval step when a second human decision is required. Stable destination ids are always used, and provider labels are untrusted display data.
Profile photos. When you request a Microsoft 365 profile photo, Asteria Cloud stores it as a file. In the app, it is deleted with the conversation. A file produced through the API belongs to the organisation and remains until the organisation deletes it or storage-quota rules remove it.
5. Legal bases
| Processing | Legal basis |
|---|---|
| Providing the service, managing the account | Performance of a contract (Art. 6(1)(b)) — or of the contract entered into by your organisation |
| Processing submitted content | Instructions of the controller, under the processing agreement (Art. 28) |
| Security logging, incident detection, evidence | Legitimate interest (Art. 6(1)(f)): systems security, fraud prevention, defence of legal claims; where applicable, legal obligation (Art. 6(1)(c)) |
| Access to connected third-party services | Consent (Art. 6(1)(a)), collected by the provider at authorisation time |
| Optional response personalisation | Consent, withdrawable by clearing the fields |
| Transactional e-mail (password reset, invitation) | Performance of a contract |
6. Recipients and sub-processors
| Recipient | Role | Location |
|---|---|---|
| Scaleway SAS | Hosting, object storage, database, key management, transactional e-mail delivery | France (fr-par) |
| Sentry | Error monitoring and session replay | European Union |
| Applicable model provider | Response generation, under §3 | Depends on the configuration — see §3 |
We do not sell personal data and disclose none to any third party for advertising. Your content is not used to train models, by us or — in the configurations we control — by our sub-processors.
Transfers outside the European Union. Hosting, storage and monitoring take place within the European Union. A transfer outside the EU can only result from the model-provider choice described in §3; where that choice is ours (the “credits” configuration), the transfer is governed by the European Commission’s standard contractual clauses.
7. Retention periods
| Data | Period |
|---|---|
| Account and preferences | Until the account is deleted, then 30 days of residual backup |
| Conversations, documents, collections | Until deleted by you or your organisation |
| Connector tokens | Until revoked |
| Security event log | 400 days in the queryable store |
| Evidential archive of the same events | 5 years, in immutable storage |
| Plaintext excerpts of higher-risk operations | 7 days |
| Error reports and session replays | 90 days |
| Transactional e-mail (delivery metadata) | 12 months |
Deleting an account deletes the content belonging to it. Content contributed to a space shared by your organisation belongs to that organisation and may be retained after you leave, under its own policy.
8. Security
Encryption in transit (TLS) and at rest; passwords hashed with bcrypt; connector secrets encrypted in the database; per-user and per-organisation isolation, enforced and verified by dedicated automated tests; an append-only event log sealed daily with a cryptographic digest; restricted and audited administrative access.
No measure makes a system impregnable. In the event of a breach likely to result in a high risk to your rights, we inform the organisation concerned and, where the law requires it, the CNIL and the individuals affected.
9. Cookies
The service sets one session cookie that is strictly necessary for authentication. It is HttpOnly and Secure, and cannot be read by code running in the page. Display preferences (theme, language) are stored locally in your browser.
We use no advertising cookies and no third-party analytics trackers. No cookie consent is therefore required under Article 82 of the French Data Protection Act.
10. Your rights
You have the rights of access, rectification, erasure, restriction, objection and portability set out in Articles 15 to 22 GDPR, together with the right to give directions on what becomes of your data after your death.
Where to exercise them. For content and your account, contact the organisation that gave you access first: it is the controller and has the necessary tools. For data we control (§1), write to [TO COMPLETE — privacy contact e-mail address]. We respond within one month.
Complaints. You may lodge a complaint with the Commission nationale de l’informatique et des libertés (CNIL), 3 place de Fontenoy, 75007 Paris, France — cnil.fr.
11. Minors
The service is intended for professional use. It is not directed at people under 16, and we do not knowingly collect their data.
12. Changes
Any material change is signalled by updating the effective date at the top of this document and, where the change affects your rights, by a notice in the service. Previous versions are retained and can be provided on request.