AI & AutomationShippedFeatured Project

Remote Workstation Operations Bridge

A secure chat-based bridge that lets an authorized user trigger commands, run reports, and transfer files on a workstation when they are away from it, with a two-layer security model that blocks destructive operations by default and unlocks only with a password and auto-relocks after five minutes

20
rolling chat exchanges in context
40+
destructive keywords blocked
5
minute unlock window with auto-relock

Remote Workstation Operations Bridge

One-Line Summary: A secure chat-based bridge that lets an authorized user trigger commands, generate reports, and transfer files on a workstation when they are away from it. Two-layer security model blocks destructive operations by default and requires an explicit password unlock that auto-relocks after five minutes.

--

Problem Statement

Critical workstation automation (lead pipelines, scheduled reports, file generation) often needs human attention at moments when the human is not physically at the workstation. Commuting, traveling, in a long meeting, off-hours emergencies. The alternatives are awkward: a full VPN-plus-RDP session on a phone, asking a teammate to log in, or simply waiting until the next morning while work stalls.

The team needed an authorized, audited, chat-driven way for one person to safely act on the workstation from anywhere, without exposing a remote shell to the network or leaving the machine in a permanently-unlocked state.

Solution

Built a chat-based command bridge that runs as a long-lived process on the workstation, listens to a messaging channel that only the operator's account can reach, and routes incoming messages through an LLM that can read files, run scripts, and answer questions about the local environment. The architecture is chat-platform-agnostic: the same bridge can run on Slack, Microsoft Teams, or any other messaging API by swapping the wire-protocol adapter. The destructive-operation guardrails, the password-unlock state machine, and the conversation-memory layer are the value, not the channel.

The security model is the headline. By default the bridge runs in a read-only mode that rejects any message containing destructive verbs (delete, drop, install, modify, execute, etc.) before they ever reach the LLM. A separate system prompt enforces the same read-only constraint at the LLM layer as a second line of defense. To act destructively, the operator must explicitly /unlock with a password stored only in the local environment. The unlock grants a five-minute window, then auto-relocks.

Tech Stack

LayerTechnology
MessagingGeneric chat API (long-poll integration; Slack/Teams compatible architecture)
LLM BackendAuthorized LLM CLI with system-prompt-driven permission modes
AuthOAuth via a personal account; per-user allowlist on the messaging side
LanguagePython 3
PersistenceLocal JSON for rolling conversation history, env-file for secrets
Auto-StartWindows Startup folder wrapper, silent launch on boot

Key Features

  • Chat-to-Workstation Bridge: Messages sent by the authorized operator are piped to a local LLM CLI with full system-prompt context, and responses are chunked back into the chat channel.

  • Rolling Conversation Memory: Maintains the last 20 exchanges in a local history file so multi-turn conversations work across days and across bot restarts.

  • Two-Layer Destructive-Operation Guard:

  • Layer 1 keyword filter: Every incoming message is scanned against 40+ destructive keywords (delete, modify, execute, install, drop table, etc.). While locked, any match is blocked before reaching the LLM.

  • Layer 2 LLM permission mode: Two separate system prompts switch the LLM between strict read-only and full-access. In read-only mode the LLM refuses destructive operations even if Layer 1 missed something.

  • Password Unlock with Auto-Relock:

  • /unlock requires the vault password, stored only in a local env file, never hardcoded or transmitted.

  • Successful unlock grants full access for five minutes (configurable).

  • Auto-relocks on timer expiry. No manual re-lock step required.

  • Bidirectional File Transfer:

  • Inbound: Files sent through the chat channel are downloaded to a local incoming directory and their paths are passed to the LLM for analysis.

  • Outbound: The LLM can return files using a [SEND_FILE:path] tag in its response. Images route as photos, other files as documents.

  • Protected Folder Access Control: A configurable list of protected paths is treated as locked-by-default regardless of message content. Even a benign-looking message that references a protected folder is blocked while locked.

  • Single-Operator Lock: The bridge ignores every message from any account not on the allowlist. No accidental access from a shared workspace.

  • Auto-Start on Boot: A startup wrapper launches the bridge silently on Windows login. No visible console window, no manual step after a reboot.

  • Slash Commands: /clear resets conversation history. /unlock opens the vault. /status reports current lock state and remaining unlock time.

Impact / Metrics

  • Authorized off-site access to the workstation's automation stack without VPN or RDP
  • Zero-touch startup: bridge launches automatically on workstation boot
  • Defense-in-depth security model: a destructive command must clear both a keyword filter and an LLM-side permission check, AND the operator must have manually unlocked the bridge within the last five minutes
  • Used routinely for after-hours file lookups, ad-hoc script runs, and quick status checks when away from the workstation

Status

Production. Running daily on the workstation with auto-start on boot. Stable and in active use. Architecture is portable to Slack or Microsoft Teams by swapping the messaging adapter.

Messaging APIPythonLLMOAuthWindows

More in this category