Security & Privacy

Anyy is local-first, but local does not mean consequence-free. The assistant can use files, terminal commands, messaging Channels, schedules, and external providers. Treat each enabled capability as authority you have granted.

Start with the Safe Defaults

1. Keep the default approval execution mode.
2. Connect only the model providers and Channels you need.
3. Enable one toolset, Skill, or MCP server at a time.
4. Review the proposed ChangePlan before authorizing a state-changing action.
5. Keep a recent Profile backup before broad configuration changes.

Workspace is not a security boundary

Workspace selects context and artifact locations. It does not turn an otherwise authorized tool into a sandbox. Review file paths, commands, and enabled toolsets on their own merits.

Approvals and YOLO Mode

In approval mode, sensitive file or terminal mutations can produce a ChangePlan instead of running immediately. The plan describes the intended commands or changes, expected impact, validation, and rollback information.

YOLO mode permits supported work to continue without interactive approval. Use it only for a narrowly scoped session or scheduled job whose prompt, toolsets, working directory, and delivery route you have reviewed.

YOLO is not a blanket safety guarantee

Anyy keeps hard interlocks for catastrophic operations, but unattended execution can still modify files, start processes, call external tools, and send messages within its configured authority.

See Approvals & ChangePlans for the complete review flow.

Protect Credentials

Prefer Dashboard or an interactive setup flow for API keys and channel secrets. For non-interactive Channel setup, pass secrets through file descriptors:

anyy setup channel CHANNEL \
  --set FIELD=VALUE \
  --sensitive-fd SECRET_FIELD=FD

Do not place secrets in prompts, shell history, screenshots, Skill files, or durable memory. Anyy redacts recognized secret material from protected persistence and delivery paths, but redaction is a last line of defense—not a reason to expose a credential.

When a secret may have leaked, rotate it at the provider first, update Anyy, reload the affected integration, and inspect its health.

Control Messaging Access

Each Channel profile exposes only the access policies it supports. Depending on the platform, direct messages can be pairing, open, allowlist, or disabled; group messages can be mention, open, allowlist, or disabled.

Review pending requests before granting access:

anyy channel pairing list
anyy channel pairing approve --request REQUEST_ID

Revoke an unwanted grant immediately:

anyy channel pairing revoke --grant GRANT_ID --reason "access removed"

Pairing is an authorization decision. Verify the platform identity and account before approving it.

Keep External Integrations Narrow

• For MCP, enable a server only after probe or test, then include only the tools you intend to expose.
• For Skills, inspect SKILL.md and linked files before installation or use.
• For scheduled automation, prefer approval mode and explicit toolsets.
• For public webhooks, use HTTPS and keep verification/signature secrets private.
• For Dashboard, keep access limited to trusted users and networks.

Backups and Audit History

Backups include Profile data needed for recovery. Credentials are excluded unless you explicitly include them. Treat any credential-bearing archive as sensitive material.

Anyy records audited operations and authorization outcomes. Use Dashboard health pages plus anyy status, anyy doctor, and integration-specific doctor/status commands when investigating unexpected behavior.

If Something Looks Wrong

1. Stop or disable the affected schedule or integration.
2. Revoke Channel pairing grants that should not exist.
3. Rotate exposed provider, Channel, or MCP credentials.
4. Run the relevant doctor/status command.
5. Restore from a known-good backup only after preserving evidence you still need.