Understand security boundaries

This checkout is a local learning implementation. It should not be presented as a hardened multi-user service.

Implemented controls

The API uses one shared bearer key, Pydantic request validation, a CORS allowlist, and in-memory limits on query and ingest. /health and generated API documentation are public. There is no implemented JWT login, role-based authorization, mTLS layer, or encrypted model-storage system in the reviewed backend.

Known limitations

• Conversation ownership is not enforced and semantic retrieval crosses threads.
• Omitting user_id can store/log the API credential as a user identifier.
• Authentication logs include credential prefixes; other logs can include input text.
• The repository tracks a private-key file and environment-specific configuration files. Do not assume ignore rules remove tracked material.
• Model routing and prompt approval labels do not enforce tool permissions.
• The current pipeline does not implement all security scans described in historical documentation.

Use the lab responsibly

Bind the manual backend to localhost and use non-sensitive examples. Restrict access to stores and backups. Keep credentials outside version control and out of hosted-assistant context. Review generated commands before execution.

For existing deployments, inspect actual network exposure and service permissions. The setup script adds firewall rules; it does not prove access is restricted to authorized hosts. External sharing requires a separately reviewed security design.

Secrets and rotation

Use a unique lab key. Coordinate rotation with the service and clients, and account for copies in logs/backups. A tracked private key requires assessment and potential revocation by its owner; removing the visible file alone does not remove historical exposure. This documentation change does not rotate or delete credentials.

Next: Configuration reference and conversation limitations.