ADR-0006-security-and-integrity.md

# ADR-0006: Security and integrity

Date: 2026-05-04  
Status: Accepted

## Context

Kompis-managed projects must protect secrets, data, access boundaries, and the integrity of code, deployments, and backups.

Security is not just about preventing unauthorized access; it is also about preserving trust in what is running, what is stored, and what was changed.

## Decision

### 1. Secrets must stay out of GitHub

Credentials, tokens, private keys, and similar secrets must not be committed to GitHub or stored in public docs/chat.

Secrets belong in approved secret stores, environment variables, or local root-only files as appropriate.

### 2. Least privilege by default

Access should be limited to what is needed.

- only necessary users get access
- only necessary permissions are granted
- production access is stricter than sandbox/test access
- temporary access should be temporary

### 3. Data separation must be preserved

Projects must keep sandbox/test and production separated for:

- secrets
- OAuth clients
- redirect URIs
- token stores
- databases
- third-party company accounts

### 4. Input and output must be handled carefully

Applications should validate inputs and escape or encode outputs where relevant.

Assume data may be malformed, adversarial, or incomplete.

### 5. Supply-chain integrity matters

Dependencies and build inputs should be treated as part of the trust boundary.

Use practices such as:

- lockfiles / pinned versions where appropriate
- reviewed dependency updates
- minimal dependencies
- clear provenance for important tooling

### 6. Logging must support audits without leaking secrets

Logs should help diagnose and audit behavior, but must not expose secrets, raw tokens, or unnecessary personal data.

### 7. Backups and restore paths must be trustworthy

Backups should be recoverable, and restore paths should preserve the intended data and file boundaries.

### 8. High-risk changes require explicit review

Changes affecting auth, secrets, access control, data boundaries, or deployment trust should receive explicit review and approval.

## Consequences

### Positive

- Better protection of credentials and data
- Stronger trust in deployments and backups
- Lower risk of accidental leakage or drift
- Clearer review expectations for sensitive changes

### Tradeoffs

- More caution around sensitive changes
- Slightly more operational discipline needed

## Notes

See also:

- `docs/ADR-0002-app-projects-environments-and-repos.md`
- `docs/ADR-0003-agent-user-and-memory-governance.md`
- `docs/ADR-0004-app-solution-documentation-and-acceptance.md`
- `docs/APP-DEVELOPMENT-POLICY.md`
- `docs/PROJECT-POLICY.md`