An SOT product
Your work. Your data. Clear boundaries.
How Audoryn handles account, workspace and operational information as the product runs.
This overview describes the Audoryn product. An organization-specific agreement or an applicable legal notice may give further detail, including legal bases and jurisdiction-specific rights.
01Information Audoryn handles
Creating an account provides an email address, an optional display name and a password. If you sign in with GitHub, Audoryn receives the account details GitHub shares for sign-in instead of a password. Within a workspace, Audoryn stores organization membership, worker and job settings, policies, approvals, incidents, conversations, memories, results, artifacts and audit records as those features are used.
- Account and membership details identify the people who can enter a workspace.
- Work content can include instructions, prompts, files, connected tool data and generated output.
- Operational records include action decisions, usage, failures and security events.
02Why it is used
Audoryn uses this information to authenticate users, run and supervise configured work, apply capability and policy checks, request human approvals, show results, enforce plan limits, and investigate reliability or security issues. Workspace content is available according to organization membership and product permissions.
03AI models and connected services
When AI features are used, the relevant task context can be sent to the AI model providers the service is configured to use, such as NVIDIA, Groq, Hugging Face or OpenRouter, for planning, conversation or image analysis. A connected integration can send an authorized action and the payload it needs to the selected provider, such as GitHub, Slack, Gmail, Google Drive or Google Calendar. Those providers process information under their own terms and practices.
- Model requests are limited to the context assembled for the task; they never grant provider authority.
- Provider calls remain subject to Audoryn's capability, policy, risk, approval and incident controls.
04Credentials and browser storage
Account passwords are stored as salted hashes, not readable passwords. Connected service credentials are encrypted in the backend. After sign-in, the web app keeps an access token in browser local storage so it can make authenticated requests. Short-lived values, such as a pending invitation code or a GitHub sign-in step, may be kept in session storage while you finish. Signing out revokes the server session and removes the local token.
05Retention and deletion
Sessions expire or can be revoked. Operational history, audit records, results and artifacts can remain available for governance and investigation. An expiry date on a memory entry limits its use as future AI context; it does not by itself mean the underlying record or file has been deleted. Audoryn does not currently offer a single self-service control for deleting an entire account or workspace and all associated history.
06Access and requests
Workspace administrators can manage membership, workers, jobs and integrations within their permissions. Some records and connections can be removed individually in the product. For broader access, correction or deletion requests, use your organization's existing SOT support or business contact. Requests may need to be handled alongside audit obligations and any applicable agreement.
