Security and solver licenses for sim-cli

One-sentence answer

sim-cli does not bundle or redistribute commercial solvers or vendor SDKs; users provide their own licensed solver installations, and sim-cli runs entirely local against those installs without phoning home with model files or solver IP.

Solver licenses stay with you

sim-cli does not bundle or redistribute commercial solvers or vendor SDKs. Users must provide their own licensed solver installations. SVD AI Lab is independent and is not affiliated with, endorsed by, or sponsored by solver vendors.

What that means in practice:

You must already have a licensed install of COMSOL, Abaqus, Ansys Workbench, Mechanical, Fluent, MATLAB, or any other commercial solver on the host where you run sim-cli.
All license-server interaction (FlexLM, RLM, vendor cloud licensing) is between your installation and your vendor. sim-cli does not proxy, cache, or relay license traffic.
Compliance with the vendor’s EULA — including which users, hosts, and use cases are licensed — remains entirely your responsibility.

What data sim-cli collects

sim-cli is a local CLI. It runs on your machine and drives solvers that also run on your machine.

Model files, solver scripts, logs, and result artifacts stay on your local disk and in your working directory.
sim-cli does not upload your .mph, .cae, .inp, .wbpj, .mat, .foam, or any other model or result file to any SVD AI Lab service.
Solver console output and logs that sim-cli surfaces back to a coding agent stay inside the agent’s local context — they aren’t forwarded to SVD AI Lab.

If you connect sim-cli through a coding agent (Codex, Claude Code, or similar), that agent’s harness has its own data-handling policy for prompts and tool output; consult your agent vendor’s documentation for what they send back to their model provider.

Where local credentials live

For features that need a token (for example, a future plugin index fetch or signed plugin verification), sim-cli stores secrets in the OS keychain — macOS Keychain, Windows Credential Manager, or libsecret on Linux — using the platform’s standard secret-storage API. Tokens are not written to plaintext config files in your home directory.

If you’ve configured environment variables (such as SIM_ABAQUS_COMMAND or solver-specific install paths), those are read at process start and not persisted by sim-cli itself.

Auditing what sim-cli is doing

Every solver-touching operation goes through the small CLI surface:

check readiness → attach to live session → inspect model state
→ run one bounded CAE step → verify result/state → save checkpoint/artifacts

There is no daemon running in the background. When sim exits, it is gone. Re-running uv run sim check <solver> is a safe, side-effect-free way to confirm the local install is still reachable.

Remote `sim serve` is a privileged endpoint

The above covers the local mode that the how-to pages use. There is also a remote mode: sim serve starts an HTTP runtime that other machines (or an agent on the same machine) can drive over the network.

Treat sim serve as a privileged code-execution service:

A client reaching /connect and /exec against a running sim serve can execute solver-side code under the user account that started it.
The runtime currently has no built-in authentication layer. Anyone who can reach the listening port can drive the solver.
Do not expose sim serve to the public internet. Bind it only to localhost, a trusted VPN, Tailscale, or a protected lab network.
Even on a trusted network, prefer scoping the listener to a specific interface (e.g. the Tailscale interface) rather than 0.0.0.0.
If you need to share solver access with a teammate, layer your own authentication in front of sim serve (reverse proxy with mTLS, SSO, or a similar mechanism) until first-class auth ships.

This warning applies even when the listener is bound to localhost and exposed via SSH port-forwarding — anyone who lands on that machine, with the user’s account, can drive the solver.

Reporting a security issue

Please report security issues at contact@svdailab.com.