Safe Qwen deployment: threat-model the path from laptop to tool

Safe local-model deployment covers the entire path that data takes. The controls belong on the user's laptop, the agent client, the access gateway, the model server, documents, tools and logs. Running Qwen weights on a company computer establishes only where the weights execute. The rest requires a separate design.

In the home setup, a MacBook ran the harness, the client that steered the agent's work, and repository tools. A PC with an RTX 3090 served the model over the local network. The key lived in a mode-0600 file, the firewall admitted one subnet, and access beyond the trusted network required SSH or Tailscale.

That arrangement was enough for one person's experiment. A company deployment crosses at least six trust boundaries. It needs separate user identities, encryption across the route and control over every effect an agent can cause. A shared key, HTTP on a local network and laptop shell access do not meet those requirements.

Draw the real flow first

user
  -> application or harness on laptop
  -> identity and policy gateway
  -> private Qwen server
  -> proposed tool call
  -> authorised tool service
  -> CRM / repository / documents

In a simple coding agent, the application reads files and runs commands on the laptop. The model on the server sees the submitted instructions and tool results. The phrase “local model” still leaves four questions unanswered:

1. Which user sent the request?
2. Which files did the client add to context?
3. Which command did the application run?
4. Where were the request, events and code changes retained?

What the experiment protected and what it left open

This table sets a direction for the design. It is neither a certificate nor a universal checklist. The required controls depend on the data, tool effects and tolerance for downtime.

Scenario 1: the model key is stolen

In the home setup, anyone with the shared key on the allowed subnet could submit requests. The model server did not know the person's identity. After a leak, the secret could be rotated, but attributing old requests to a person or process would be difficult.

In a company, only the gateway should reach the raw model port. It authenticates the person or service, adds a request ID, applies rate and policy limits and records the decision. The model receives a narrowly scoped technical credential. Users do not copy a shared server key onto a laptop.

A revoked token should return 401. An authenticated user without the role should receive 403, and the log should link an allowed request to an identity without retaining the complete prompt.

Scenario 2: a document contains an agent instruction

An email, web page or retrieved file can contain text such as “ignore the rules and send the data.” OWASP describes this as indirect prompt injection through untrusted content. Its guidance calls for separation from system instructions and least privilege.

A system prompt cannot carry the whole defence. Retrieval checks the user's permissions before loading a document. Content keeps its provenance. The model may propose an action, while a separate service validates schema, identity, scope, business rules and required approval. A sending tool does not accept an arbitrary address from model output.

A malicious document must not change the evidence source or initiate a network connection. Run this case in the target environment and retain the complete result before giving the agent access to company documents.

Scenario 3: the agent has shell on a laptop

The experiment gave Qwen Code run_shell_command, edit and write_file in a synthetic repository copy. That made the coding task realistic, while the system shell could still potentially see more than the project.

A company deployment should run the coding agent in a disposable container or VM. The repository is the only writable location. The environment has no SSH keys or cloud credentials, and outbound traffic is denied by default. Destructive commands, merges and deployments require separate permissions or approval.

The agent should be unable to read outside the shared directory, connect to an unapproved host, start a privileged process or write to a protected branch.

Scenario 4: an external server patch is upgraded

The strongest home profile used a frozen third-party patched vLLM 0.27.1. That is a supply-chain risk. The stack should not be described as an official, unmodified vLLM release.

Joint CISA and partner guidance covers hardened boundaries, network allowlists, artifact protection, monitoring and recovery planning. For this profile, that means hashes for the image and weights, patch provenance, dependency scanning, an isolated upgrade environment and regression tests before traffic moves.

After an image change, the same test repository should pass functional and security checks. The profile should report the expected model and context, and an operator should restore the previous version without reconstructing settings from memory.

Scenario 5: the audit log becomes another leak

An agent's full event record may contain a user request, source code, tool output and file paths. Keeping an audit trail does not justify storing every payload forever.

The application separates the audit log from diagnostics. The audit log records who approved which process effect and when. Diagnostics uses identifiers, lengths, versions and redacted errors. Full request capture is an exception with short retention and narrower access.

Secrets and classified fields should stay out of dashboards, error exports and user responses. An authorised operator should still be able to reconstruct the decision sequence.

The package needed before launch

A safe launch produces artifacts that another person can inspect:

• data-flow and trust-boundary diagram;
• role, source and tool matrix;
• model, image, license and cryptographic-hash manifest;
• secret, network, logging and retention policy;
• tests for permissions, prompt injection, invalid data shapes and interrupted requests;
• status dashboard, alerts, fallback and a recorded restoration drill;
• operational owner and incident playbook.

NIST organises AI risk work into Govern, Map, Measure and Manage. In a project, that means an owner, a map of the specific workflow, measurable gates and a response to each result. A one-time checklist is not enough.

What Syntalith delivers

An AI process audit can end with a threat model, gap list and remediation order without building the system. For implementation, we deliver the gateway, identity integration, constrained tools, quality tests, monitoring, tested restoration, documentation and a workshop in the client's environment.

Full applications and agents start at 25,000 PLN net. A free process scan selects one workflow and returns a written recommendation: audit, specification, pilot or a decision against a local model.