# Security And Privacy

AI Workspace is designed for local-first, auditable context management. Treat it as a companion workspace that may contain sensitive project metadata and communication evidence.

## Rules

- Do not commit secrets, tokens, cookies, API keys, headers, or session IDs.
- Keep connector credentials in ignored `.env` files.
- Keep raw evidence outside canonical project memory until curated.
- Keep MCP read-only unless a write tool has explicit safety rules.
- Treat generated indexes as local artifacts because they may contain snippets from project notes.
- Prefer local services for corporate or confidential projects.

## Ignored Local State

Examples of local-only data:

```text
.aiw/runtime/
.aiw/indexes/
ai/inbox/mattermost-mirror/
scripts/*/.env
```

## Cloud Memory Systems

Tools such as mem9 or managed vector stores can be useful, but they introduce a data boundary.

Before enabling them for a project, decide:

- what data may be stored;
- whether cloud storage is allowed;
- whether self-hosting is required;
- who can inspect/delete memories;
- what happens when cloud memory conflicts with Markdown.

Default recommendation:

```text
Use cloud memory only for non-sensitive preferences unless a project policy approves broader use.
```

## MCP Safety

MCP clients may let models invoke tools automatically. For that reason, workspace MCP tools should stay read-only by default and return bounded, source-attributed context.

If future MCP write tools are added, require:

- explicit user intent;
- narrow target paths;
- clear diffs or summaries;
- no secret exposure;
- easy audit through git.

## Sharing The Repo

Before sharing or open-sourcing a reusable version:

1. Remove or isolate project-specific profile data.
2. Confirm ignored inbox/runtime files are not tracked.
3. Replace real profile examples with sanitized examples.
4. Keep reusable architecture docs in `docs/` and `core/`.
5. Keep confidential project knowledge in private profile/workspace data.