# Security and Permissions Rules

## Rules
- Do not hardcode secrets.
- Do not log API keys or tokens.
- Do not expose sensitive project or client data.
- Do not fake backend security with frontend-only hiding.
- Do not show admin actions to users who should not see them.
- Always consider the multi-tenant structure.
- Keep client data, project data, user data and agent data separated.
- Sensitive actions need confirmation.
- Dangerous actions need clear labels and safeguards.
- Permission-aware UI is required, but UI hiding alone is not real security.
- If permissions are not implemented yet, structure the code so they can be added cleanly.

## Possible roles
Owner, Admin, Product lead, Developer, Designer, AI agent, Client, Viewer.

## Current model (reference)
- API requests resolve tenant and user identity before operations.
- In production, identity comes from a verified Bearer JWT; demo headers are ignored.
- Service methods call explicit permission checks; tenant scoping is enforced.
- Integration secrets are encrypted and masked in settings responses.
- Destructive or release-affecting actions should be audited.

## Acceptance criteria
- Intended users are clear.
- Sensitive actions are separated.
- Permission assumptions are documented.
- No fake security is presented as real security.
- Future permission enforcement is not made harder by the change.