Skip to content

Security: rbarok/chat-semantic-task-creation

Security

SECURITY.md

Security

This project follows a human-in-the-loop model: the LLM suggests tasks; only explicit user confirmation writes to Lakebase. See MITRE ATLAS for the threat framework we align with.

Scope: dev environment only unless you add staging/prod with a formal security review.

Reporting issues

If you find a vulnerability or accidentally commit a secret:

  1. Do not open a public issue with credentials or exploit details.
  2. Rotate any exposed tokens immediately.
  3. Contact the repository maintainer privately.

What we protect

Asset Handling
Chat sessions & messages Internal — not passed to LLM beyond task need
Task proposals & tasks Confidential — confirmed writes only
Postgres credentials Runtime injection (OAuth); never in repo or prompts
LLM access Server-side proxy only; no client API keys
Workspace PATs / SP keys Never commit, log, or embed in prompts

Core controls

  • Human-in-the-loop (AML.TA0011): POST /api/tasks requires user_confirmed: true. Unconfirmed proposals never create app.tasks rows.
  • No LLM → database writes (AML.T0053): The model cannot persist tasks. Background jobs use an L2 guard to block autonomous task/chat paths.
  • Prompt injection (AML.T0051): Server-side parsing with schema validation and injection phrase rejection before UI display.
  • Secrets (AML.TA0013): No PATs, connection strings, or .env in git. OAuth tokens are in-memory only and not logged.
  • Exfiltration (AML.TA0010): Leadership APIs return aggregates and truncated previews — not full transcripts, raw UUIDs, or infrastructure identifiers.
  • Least privilege (AML.TA0012): Lakebase app role gets table-scoped DML only; bundle uses valueFrom for endpoints.
  • LLM abuse (AML.T0029 / AML.T0034): Rate limits on inference; eval workers decoupled from the chat hot path.

Human-in-the-loop flow

User chat → LLM response (+ optional proposal) → User Accept/Reject → Backend writes Lakebase

Local development

  • Copy .env.example to .env — never commit .env.
  • Copy config/job_env.example.json to config/job_env.json for local job dry-runs.
  • Prefer databricks auth login over embedding PATs in environment variables.

Known limitations (demo / dev)

This app is not production-hardened:

  • Chat routes accept a client-supplied user_id without end-user authentication.
  • Task confirmation is a boolean flag, not a server-issued confirm token.
  • Leadership dev surfaces (browser, eval trigger, temperature) are gated but enabled in the dev bundle.

Do not expose a dev deployment to untrusted networks without adding proper identity and authorization.

Environment separation

Environment UC catalog Lakebase Bundle target
dev (default) dev_llm_chat llm-chat-dev dev
staging / prod Requires explicit approval + security review

Pre-commit checklist

  • No secrets in the diff (grep for dapi, postgres://, .env)
  • Human-in-the-loop gate intact on task persistence
  • Parameterized SQL only — no string-concat from LLM text
  • Leadership APIs redact IDs and truncate sensitive columns
  • Tests pass: uv run pytest tests/

Further detail

See SECURITY.md for data-handling rules.

There aren't any published security advisories