Before staff install a free AI tool, check its access

If your staff use free AI tools on work computers, this is for you.

Free tools change fast. In all three examples below, the maintainers fixed or changed the behavior after concerns were raised. That is useful progress. It also means the answer IT gave last month may not match the version installed today.

Before you say yes to an installation, ask whoever runs IT what the tool can reach and what limits that access. Keep the answer with the tool's name and version. Ask IT to review the access behind a useful demonstration.

We checked these examples against primary project sources on October 18, 2026. The fixes matter, and so do their limits.

A browser connection can use an existing account

Agent-Reach documents OpenCLI as a desktop route for Reddit and a fallback for Twitter. OpenCLI's extension policy describes Chrome DevTools Protocol, Chrome's browser-control feature. It also describes reading cookies, small pieces of login information, for the requested site where the user is already signed in. It describes separate automation windows within that browser setup.

The tool runs a background service on the computer, on port 19825. Its service code accepts connections through the computer's own local address. That is a local service, not evidence that the port is exposed to the internet.

Separately, Agent-Reach issue 446 reported that login import collected more platforms and credentials than intended. It closed on August 6 after the maintainer described narrower collection and made older Twitter copies optional. That report concerned the importer, not a finding that the browser tool collected every site's login details.

Use a dedicated test account. Ask IT which browser profile the tool uses. A separate window does not establish that it uses a separate account.

Ask IT: "Which signed-in accounts can this tool use, and how do you restrict it to the account we approved?"

An animation feature can run supplied code

OpenMontage issue 219 reported that its math animation tool saved supplied Python, a programming language, to a file. It then ran that file through Manim, an animation program, without a sandbox. A sandbox restricts what running code can access. The report concerned running supplied code, rather than a particular Python command named eval.

The issue closed, and pull request 252 merged on July 5. It added a code scan, clearer disclosure that code runs on the computer and an option to bypass the scan. The current code keeps that scan and warns that it does not contain the running code.

Before business files are involved, ask IT for a demonstration with test material. If you approve a tool to make an animation, ask what else that process can read or change. Checking code for blocked patterns does not prove that its access is restricted. Credit the fix, then ask IT to show the limits that remain.

Ask IT: "If this tool runs generated code, what prevents that code from reaching files and network connections outside the approved task?"

An update answer can change with the version

An earlier codebase-memory-mcp security policy described a background request to GitHub for release information after startup. It said that request sent no project data.

The project's July 29 change removed that automatic update check. Its current README says it makes no network request on its own. Yet the security document at the inspected version still describes the older check. That leaves conflicting documents, not proof that today's software still makes that request.

Ask IT which release it plans to install and what evidence supports the answer. For a tool described as local, separate everyday use from installation and updates someone chooses to run. Ask where any automatic request goes and why. If it is optional, ask how to turn it off. We have not confirmed a setting to disable the historical check in this example.

Ask IT: "What leaves this computer during normal use, and can optional outbound requests be disabled in the version we will install?"

Hand this checklist to whoever runs IT

Before you say yes, ask for answers to these:

• Access: Which files, folders and business accounts does it need? How is access limited to those?
• Local server: Does it start a background service on the computer? Record the port, who can connect and how to stop it.
• Browser: Which browser profile and signed-in account does it use? Explain any access to login information or copies it keeps.
• Network: Where does it send automatic requests, and why? Can optional requests be turned off? List updates someone starts separately.
• Maintenance: Record the project, download source and installed version. Assign someone to check fixes and approve later updates.
• Running code: Does it run supplied code? Show what restricts file and network access, and identify any setting that bypasses those limits.

Assign someone to resolve each missing answer before approval. Keep the written reply and review it again when access changes.

All three projects addressed the reported concerns. Free tools change fast, so keep IT's answer tied to the version you approve. Last month's answer is a starting point for today's check.

For help planning an independent review, contact us with your tool list and the decision you need to make. We agree on a consulting scope and provide a written review. How an engagement runs explains the process.