Skip to content

Security review: messaging-gateway bearer-token capability surface #104

Description

@Pher217

Flagged during the OSS-readiness audit and documented in SECURITY.md + docs/security/threat-model.md as an open item. The messaging-gateway surface is gated by the sidecar's bearer token, not the Telegram allowlist — so its blast radius needs a dedicated map before gateway platforms are recommended for production.

Confirmed so far (preliminary lead read)

  • Gateway endpoints authenticate via a single shared bearer token (apps/gateway/views.py), no per-sender allowlist.
  • Pending approval Prompts are scoped to the gateway's own thread (apps/gateway/service.py::handle_inbound), so a gateway sender canNOT approve a Telegram-requested action — good.
  • resolve() records by=sender but does not validate who answers (apps/prompts/service.py) — within a gateway thread, any token holder can approve.

Load-bearing unknowns to close

  • Does get_or_create_thread_for_chat create a plain LLM-chat thread (free text → model reply, no host execution) or a host-bound driveable thread? This determines whether gateway free-text can reach send_host_command / headless.prompt (i.e. code execution on a host).
  • Are session-control slash handlers (/run, /stop) reachable from the gateway dispatch_text path, and do they receive/enforce an identity (from_user_id)?

Done when

A capability table (LLM chat / list / start / stop / inject / drive headless / approve) × (reachable via gateway? gated by?) with file:line evidence, plus any hardening PRs (e.g. bind gateway threads to a non-driveable runtime, or add a gateway sender allowlist).

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestquestionFurther information is requested

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions