Security by architecture, not policy.

The trust boundary

Prosponsive is structured as a layered model using containers for runtime isolation and separate storage for access separation. Each tier communicates only with the tier directly adjacent to it. Credentials never cross a tier boundary.

The diagram below shows all components running on localhost only. The Electron app (UI and main process API) communicates with the n8n tool runtime and PostgreSQL over TLS. n8n and PostgreSQL run in an isolated private container network — not reachable from the host network or LAN. Each database is accessible only by its own dedicated user; no cross-database access is permitted.

LLM inference (not shown): The main process makes outbound inference calls to either Ollama running locally on the machine, or to an external LLM provider (Anthropic, OpenAI, etc.) over HTTPS. Only the prompt and context are sent — credentials and data never leave the machine as part of inference calls.

n8n tool calls (not shown): Tools you build in n8n can make any outbound call their workflow is configured to make — reading from or writing to Salesforce, querying a database, calling a REST API, sending a webhook. You design the tool; you decide what it touches. Prosponsive does not restrict or inspect what your tools call, and never initiates any external call on its own.

Security principles

Properties enforced by the architecture, not by configuration or policy.

• Local-first execution

  Agent runtime, tool execution, and storage all run on the user's machine. Nothing routes through Prosponsive servers. There is no cloud routing layer for your content.

• Least-privilege access

  Every resource Prosponsive touches — credentials, database connections, files — is granted the minimum access required. Credentials are accessible only to the tool execution runtime. Database users can only access their own database. Files are created with 0600/0700 permissions. The agent runtime and LLM cannot access the credential store under any code path.

• Tool runtime isolation

  Tools run in n8n as an isolated container with its own storage. The agent sends a request and receives only the result. Credentials and internal container state are never exposed to the agent runtime. Because tools execute inside a container, they have no access to the host OS filesystem or host processes — the container boundary prevents any tool from reading arbitrary files or interacting with the host system directly. Tools can make outbound network calls to external systems and communicate back to the Prosponsive API via defined channels, but nothing beyond those explicitly permitted paths.

• No server-side data storage

  Conversation history, documents, and workflow state are never sent to or stored by Prosponsive. Your data exists only on your machine. This is enforced by the architecture, not a setting.

• FIPS encryption in transit and at rest

  All local data is encrypted at rest using AES-256-GCM. All communication between components — including localhost-only traffic — is SSL-enforced. Even though all traffic stays on the machine, TLS is required on every connection: the renderer to n8n, the main process to PostgreSQL, and the n8n container back to the host API.

• Data retention — built-in, not bolted on

  Prosponsive enforces data retention by design. Soft delete marks data as deleted and excludes it from all views immediately. Hard delete permanently and irreversibly purges your local data — there is no server-side copy to recover from, so a hard delete is truly final. Inactive conversations are automatically archived after a configurable period (default: 60 days) and enter the same hard-delete lifecycle.

• Provider-agnostic design

  No vendor lock-in on the security model. Swap AI providers without re-architecting. Automatic failover between providers does not change the isolation model or credential boundaries.

• Supply chain security

  Security is enforced at two layers. Every pull request runs dependency vulnerability scanning, static analysis (SAST), and secret scanning before code can merge. In parallel, the repository is continuously and proactively scanned — newly disclosed vulnerabilities in dependencies, container images, and the runtime stack trigger P1 priorities and often automated remediation processes that close them within the same release cycle, independent of any scheduled update window. Dependencies are locked with cryptographic integrity hashes. Container images are pinned by SHA-256 manifest digest.

What leaves your machine

The short answer: very little, and never anything sensitive.

The tool runtime is a black box to the agent runtime — it receives requests and returns results. Credentials never leave the container.

Implementation details

For security engineers doing technical due diligence.