Keep DOCX editing inside a governed workflow
safe-docx runs locally and never sends your .docx files to UseJunior. Your AI client may still
send text extracted from the document to its own model provider — so here is the full data flow, the
deployment options, and exactly what your security and procurement teams should review.
Three deployment models
safe-docx is local-by-default. These are the patterns teams use, and what leaves the machine in each.
Local-by-default
A stdio MCP server your AI client launches with npx. Reads and writes .docx on your filesystem.
- Where it runs
- Your machine
- What leaves it
- No document content (only the AI client's own model traffic)
- Governs model data
- Your AI client's terms
Remote MCP
Run the MCP server on infrastructure you control and connect agents to it over your network.
- Where it runs
- A host you operate
- What leaves it
- Documents move to your chosen host, not to UseJunior
- Governs model data
- Your infra + AI client terms
Governed remote
The remote pattern placed behind your tool-management, logging, and access controls for fleet use.
- Where it runs
- Your managed environment
- What leaves it
- Only what your policy allows
- Governs model data
- Your governance layer
The actual data flow
Be precise with your reviewers: document bytes stay local; text extracted from the document may travel through your AI client to its model provider. safe-docx is not in that second path.
1 · Local disk
Your .docx file
Stays on your filesystem the whole time.
2 · safe-docx
Local MCP process
Reads, edits, and writes the file locally. Sends no document content to UseJunior.
3 · Local disk
Edited .docx saved
Output written back to your machine.
Separate path: your AI client → its model provider
The agent that calls safe-docx (Claude Code, Gemini CLI, etc.) may upload prompt content — including text extracted from the document — to its own model provider. That flow is governed by your AI client's terms, not by safe-docx. For a fully air-gapped pipeline, pair safe-docx with a locally hosted model.
What safe-docx does not send
safe-docx does not transmit your document content to any UseJunior server, third-party server, or
cloud service. Network access is needed only for the initial npm install and updates.
Because nothing is transmitted, there is no safe-docx server retaining your documents or training on them.
Governing against Shadow MCP
Treat safe-docx like any controlled dependency: pin the published npm version, review the MIT source, and enumerate its capabilities — a fixed set of 24 typed tools, not open-ended code execution. Roll it out through your approved tool-management path rather than ad-hoc local installs.
Forward this to procurement
Everything a reviewer needs to assess local agentic DOCX editing, in one place.
- Source on GitHub (MIT) — audit the code →
- npm package — pin a version →
- The 24 typed tools it exposes →
- Request a security packet →
Evaluating the hosted UseJunior (Junior) document-review service instead? That is a separate product with its own SOC 2 Type II / ISO 27001:2022 trust surface — see the UseJunior security page.
Security & deployment FAQ
Where does safe-docx run, and what leaves my machine?
safe-docx runs entirely on your local machine as an MCP server process started by your AI client (Claude Code, Gemini CLI, Cursor, etc.). It reads and writes .docx files on your local filesystem and does not send document content to any UseJunior server, third-party server, or cloud service. Network access is needed only for the initial npm install and for updates.
Important nuance for review: safe-docx itself is local-only, but the AI client calling it may upload prompt content — including text extracted from your document — to its own model provider (Anthropic, Google, etc.). That data flow is governed by your AI client's terms, not by safe-docx. For a fully air-gapped workflow, pair safe-docx with a local model.
Is safe-docx a SaaS vendor we need to run a full security review on?
safe-docx is not a hosted service — it is an MIT-licensed, open-source package that runs as a local process. There is no safe-docx tenant, login, or backend to assess for the DOCX editing itself. The data-flow surface your review should focus on is your AI client and its model provider, which is where extracted document text actually travels.
Do you train on or retain our documents?
Because safe-docx never transmits your document content off your machine, there is no safe-docx server that retains your documents or uses them to train models. Any retention or training consideration applies to your AI client's model provider, under that provider's terms — review those alongside safe-docx.
How do we govern this against Shadow MCP risk?
Treat safe-docx like any other dependency you want under control: pin the published npm version (@usejunior/safe-docx), review the MIT source on GitHub, and enumerate exactly what it can do — the surface is a fixed set of 24 typed tools, not open-ended code execution. Roll it out through your approved tool-management path rather than ad-hoc local installs.
Can safe-docx run fully air-gapped?
Yes for the editing layer: once installed, safe-docx reads and writes local .docx files without network access. To make the entire pipeline offline, pair it with a locally hosted model so no extracted text leaves the machine via the AI client either.
How does this relate to UseJunior's SOC 2 / ISO 27001 certifications?
Those certifications cover the hosted UseJunior (Junior) document-review service — a separate product. safe-docx is a local open-source tool and is not the same trust surface. If you are evaluating the hosted service, see the UseJunior security page; if you are evaluating local agentic DOCX editing, this page is the relevant one.
What is the license, and can we audit the code?
MIT. The full source is public at github.com/UseJunior/safe-docx and published as @usejunior/safe-docx on npm, so your team can read, fork, pin, and vendor it as your policy requires.
Bring it to your security team with the facts in hand
Local-by-default, MIT-licensed, and auditable. Request a packet or read the source.