Data & Privacy
Anyy is local-first: the selected Profile Home is the canonical location for its configuration, memory, sessions, schedules, and operational state. External models, web services, MCP servers, and messaging platforms still receive the data required for the task you ask them to perform.
What stays in a Profile
Run anyy config to see the resolved Home instead of guessing it. Important paths include:
Path under <PROFILE_HOME> | Purpose |
|---|---|
config.yaml | Profile settings and credential references |
secrets/ | Anyy-managed credentials |
state.db | Sessions, messages, notification receipts, Channel accounts/routes, tasks, schedules, and other durable state |
objects/ | Complete content-addressed bodies referenced by durable records, including independent notification bodies |
memory/USER.md | Durable facts and preferences about the user |
memory/MEMORY.md | Durable assistant memory |
SOUL.md, roles/ | Default and named Role identity instructions |
workspace/ | User and assistant working files |
skills/, system/skills/ | Profile-installed and bundled Skills |
channels/, cron/ | Profile directories; current account, route and schedule records are database-owned |
logs/, cache/ | Operational logs and rebuildable/cache data |
Named Profiles live under the configured Profile root and keep their canonical data and credentials separate. Intentionally referenced external directories, readonly Skill roots or service accounts remain managed resources of their own; a reference does not make their source files a disposable Profile copy.
Workspace is a context and artifact location. An authorized file or terminal tool can have broader reach according to its operating-system permissions and runtime environment.
What can leave the host
Data may be sent externally when you use:
- a remote model provider for prompts, selected context, tool results, images, audio, or video;
- web search, public URL fetching, image generation, or speech backends;
- MCP tools connected to another process or service;
- messaging Channels for inbound or outbound messages and attachments; or
- provider OAuth and API-key endpoints.
Only enable destinations you trust for the data involved. Keep secrets and unrelated private files out of prompts, attachments, references, memory, and Skill instructions.
Credentials
Managed credential setup flows store references in configuration and secret material under the Profile's protected secret storage. User-supplied configuration, such as MCP environment variables or headers, can also contain inline credentials. anyy config reports reference health without printing values.
Disconnect or clear credentials from the surface that owns them. If a credential may have leaked, revoke or rotate it at the external provider first, then update Anyy.
Backups
Normal backups include canonical Profile content such as configuration, memory, Workspace, Roles, Skills, schedules, Channels, scripts, and a coherent database snapshot. Temporary runtime files and caches are excluded.
The managed secrets/ directory and supported mcp/oauth/ storage are excluded unless you pass --include-secrets. This does not remove inline credentials from canonical configuration or working files: MCP environment/header values and other sensitive file content may still be archived. A backup is not guaranteed to be fully redacted.
Encrypt it, restrict access, and never upload it to an ordinary issue tracker or public file share.
See Backup & Restore for exact commands and restore guarantees.
Files and artifact delivery
Anyy can create files in the Workspace. To make one downloadable in a user surface, the artifact_export tool exports a Workspace-relative regular file of at most 50 MiB as a generated attachment that expires after 24 hours.
If export fails, the source Workspace file remains unchanged. A generated attachment is a delivery copy, not the authoritative source file.
Reminders and other independent Session notifications retain protected display bodies separately from model conversation messages. Reopening a chat can restore saved notification facts without adding them to Pi message history. A historical receipt without its exact body is not reconstructed from a job summary.
Deletion and retention
Deleting a non-default Profile removes its entire Home after runtime and secret guards pass. Dashboard performs the forced, secret-purging variant; CLI requires explicit flags.
Role deletion archives an unreferenced named Role record so it is unavailable for new sessions. It does not delete the whole Profile.
The Gateway supports Session deletion, but the current public CLI, TUI, and Dashboard do not expose a general session-delete action.
External services keep data according to their own policies. Deleting local Profile data does not recall a message already sent to a provider or messaging platform.
Practical privacy checklist
- Use separate Profiles when people, accounts, or trust domains must not mix.
- Enable only the tool and account access needed for the task.
- Inspect Skills and MCP servers before enabling them.
- Attach or reference only the minimum source material needed.
- Exclude secrets from routine backups and protect any exception.
- Review configured Channels and pairing grants regularly.
- Rotate credentials immediately after suspected exposure.
See Security & Privacy for tool access, Channel access, and incident response.