david.delagneau
1ad707373a
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
64 lines
2.0 KiB
Markdown
64 lines
2.0 KiB
Markdown
# 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/
|
|
workspaces/*/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.
|