Security posture
PathWise is built so a weak or manipulated model can produce a wrong answer, never a wrong action. Credentials, host access, and probe reach are each locked down on their own terms.
The core guarantee: diagnose, never remediate
PathWise gathers evidence and writes up a fix. It never applies one, on any system, even if you ask it to. That boundary is enforced in the engine, not left to the model's judgment. A weak or hijacked model can still produce a worse diagnosis. It cannot produce an action, because no tool exists for it to call. See Diagnose, never remediate for how the boundary is enforced.
How credentials are stored
Your model provider keys, and any vendor credential a module uses, are encrypted at rest on the machine PathWise runs on. Nothing sensitive is written in plaintext. Every key is masked anywhere PathWise displays it back to you. Each provider you connect keeps its own stored key, so holding keys for more than one provider and switching between them never means re-entering credentials. See Data, egress, and privacy for what those keys are used for.
Under the hood technical detail
Sensitive values are stored as AES-256-GCM encrypted rows in a local SQLite database, using only the Node crypto library and no extra dependency. The 32-byte encryption key lives in a separate file, mode 0600, beside the data directory and never inside the database, so a database backup taken without the key file leaks no credential. A container deployment can supply the key through the PATHWISE_SECRET_KEY environment variable instead. The store fails closed: if ciphertext exists but the key is missing, it refuses every operation rather than regenerate the key and silently orphan the data. Any code path that surfaces a key back to a user masks it before display.
How the host is hardened
PathWise runs in a container with nearly every Linux capability dropped. The one exception is NET_RAW, which the ping and traceroute probes need to open raw sockets. That capability grants no filesystem access, no process control, and no privilege escalation. The container also runs as a non-root user, with a read-only root filesystem and no path to gain new privileges.
The primary deployment uses host networking, so probes see your real network the way a tool running directly on the host would. That is what lets probes like ping, dig, and traceroute return real answers about your LAN. It also means the hardening claim above is about capabilities and the read-only filesystem, not about network isolation. PathWise shares your host's network position by design, because that is the vantage point the probes need.
Under the hood technical detail
NET_RAW alone does not make ping work inside a hardened, non-root container. The host also needs net.ipv4.ping_group_range set for the container's group, because a non-root process with no-new-privileges cannot fall back on ping's file-capability path. In host-networking mode this is a host-level sysctl, since the host network namespace cannot be configured per container. A bridged deployment sets the equivalent value per container instead.
Reach is open by default, and yours to fence
Out of the box, PathWise does not fence off which hosts or ports it can probe. It can look at any host, on any port, on your LAN, your WAN, or a SaaS endpoint, because that is what diagnosing an arbitrary ticket takes. The guardrail is on what kind of operation it can run there: gather evidence, never change anything.
If you want a fence anyway, set the target allowlist in Settings, under Environment. With an allowlist set, every probe target must match it before the probe runs, so PathWise can only look where you told it to. Leave it blank and reach stays open. Either way, a probe is only ever a read, never a remediation.
Under the hood technical detail
A probe like a DNS lookup can carry information outward in the query itself, not only in the response that comes back. Validating that a target has the right shape is not the same as validating that it belongs to the investigation at hand. Every target is checked for valid shape before anything executes, and the optional allowlist adds the belongs-here check on top: each probe target is matched against the operator-provided list before the probe runs.
What modules can reach
PathWise is extended by modules that add new data sources. A module's interface has exactly one method, a read. There is no write, execute, or mutate method for a module to implement, so a module cannot add a remediation capability regardless of what it declares about itself.
The manifest has no general field that lists every system a module contacts. It has two related declarations. Optional permissions entries come from a closed set, and an entry the engine does not recognize fails the whole load. Optional external_consent: true withholds that module's tools until the user gives per-investigation consent at intake. Where evidence comes from belongs in connection.yml, and the engine wires three source types there: a file drop, a vendor API, and an MCP server. An api source names the base URL and the name of a credential, so the module folder never holds a secret and the engine reveals the stored value only at the moment of the outbound call. An mcp source must list the exact read tools it uses, and a module that omits that list fails to load rather than exposing the vendor server's whole surface to the model.
The audit log
PathWise keeps a local, persistent record of every operation it runs during an investigation, including anything that was denied. It stays on your machine. See the audit log for what it records and how to read it.
See also
- Data, egress, and privacy, for what leaves your box and what does not.
- Diagnose, never remediate, for the boundary enforced at the tool-call level.
- Run it locally with Ollama, for the fully local reasoning path.