# Security model

> What aisync protects, and what it doesn't.

## What it protects

| Situation | Outcome |
|---|---|
| Your GitHub repo leaks | Tokens are ciphertext only and can't be opened without the passphrase |
| A config file (`.claude.json`) is backed up or shared | It holds references, so no token goes with it |
| Another website targets the admin UI | 127.0.0.1 only, a fresh token per run, Host and Origin checks |
| You paste a token into a file by mistake | The upload stops at the check |

## What it doesn't

- **An attacker who already controls this machine.** The decryption key is in the keychain (a file on Linux), and while an MCP server runs its token is in that process's memory.
- **A short passphrase.** Someone with your repo can try passphrases offline. 600,000 PBKDF2 rounds slow this down; they don't stop it.
- **Environment from `aisync run`.** A profile's `env` goes into the whole Claude process, so every command Claude runs can read it. MCP server tokens are different: they reach only that server.
- **Tokens the check misses.** Token detection is rule-based and can miss formats it hasn't seen.
- **Copies made before aisync.** Old plain text in Claude Code's own backups (`~/.claude/backups/`) is not removed by aisync.

## GitHub access

aisync gets a token from `gh auth token` each time and never stores it. gh tokens usually reach all your repos, so keep your gh login safe.

## Unattended machines

If macOS shows a keychain permission dialog, aisync waits up to 20 seconds, then stops and says why. On a machine nobody sits at, run `aisync keystore file` to keep keys in a file. Any program running as your user can read that file and it ends up in backups, so it is one step weaker than the keychain.