Privacy and Data Retention

Roster stores only the data it needs to authenticate users, model routing responsibilities, resolve workflow questions, and maintain an audit trail. Administrators can tune PII controls from platform settings.

Data Minimization Defaults

Roster prefers write-time minimization. When a PII option is disabled, new records should avoid storing that field rather than storing it and hiding it later. Read-time filtering is still used for existing history so older data does not bypass the current policy.

Roster does not run an automatic backward data migration for historical PII. Existing deployments that already stored data outside the current policy should use an explicit cleanup, redaction, or erasure process.

Raw provider directory payloads are not stored. Directory sync keeps canonical fields such as display name, primary email, description, source external ID, and explicit allowlisted metadata.

Resolve Result Fields

Resolve requests can include personal data in the natural-language query, actor details, result users, selected participants, memberships, metadata, and delegation details.

Use the resolve PII settings to control:

• whether query text is retained
• whether actor name, actor email, and actor credential details are retained
• which result fields are returned and persisted: user ID, display name, email, title, labels, metadata, memberships, delegation details, participant names, and project IDs

The same field policy applies to REST responses, MCP responses, stored response JSON, selected participants, and resolved users.

Directory Sync Data

Directory records represent provider users, groups, organization units, roles, and external emails. Roster does not edit upstream provider accounts.

When upstream records disappear or a privacy policy requires removal, directory PII should be permanently removed, expired, or anonymized. Audit history should keep durable IDs and safe metadata rather than personal directory data.

Audit History

Audit events are durable security and product history. They store stable actor, resource, owner, effective-principal, and credential IDs. Optional IP address, user agent, and personal-looking metadata fields can be minimized with PII settings.

The Settings screen can set audit-event retention days. Leave the value empty for no configured retention limit, or enter a positive integer number of days.

Audit history is not a source of live account state. Removing or anonymizing a user should not require deleting audit rows that are needed for security and compliance, but personal metadata inside audit rows should be redacted when an erasure policy requires it.

Model Diagnostics

Model run diagnostics can contain model input, output, tool payloads, actor display details, request IDs, traces, token usage, costs, latency, and errors. Treat model input/output and tool payloads as high-risk because they may include directory records, participants, labels, metadata, and free-form user text.

The Settings screen can set model-run retention days and choose whether to retain actor name, actor email, input/output, tool payloads, and error details.

Logs And Journals

Operational logs and worker journals can include connector IDs, job IDs, counts, duration, sanitized errors, and model planning notes. Use retention limits for worker journals and avoid sending personal values to logs when a stable ID or count is sufficient.

Worker journal retention is configured in Settings under Worker journals.

Resolve Request Retention

Resolve request history can include the original query, actor details, credential details, project details, selected participants, resolved users, response JSON, provider/model metadata, and error text.

The Settings screen can set resolve-request retention days and choose whether to retain query text, actor details, actor credential details, and each result field. Those same field choices affect platform history screens, REST history responses, MCP history responses, and stored response JSON.

Identity Deletion

Identity deletion is a lifecycle mechanism for access revocation, recovery, and preserving historical references. A deleted identity must not authenticate, act through API credentials, or receive new workflow responsibility.

Deleting an identity is not PII erasure. Erasure requires redaction, anonymization, or permanent removal of personal fields and derived copies.

PII Erasure

A complete erasure workflow must cover source records and copied data:

• identity profile fields and session data
• directory records, sources, metadata, and memberships
• resolve request queries, response JSON, participants, and resolved users
• audit metadata personal fields
• model diagnostics and tool payloads
• worker journals and operational logs within the configured retention window
• search indexes and other copied stores that duplicate source values