Security and trust boundaries

Trust boundary with the operator

To establish a connection, credentials must be processed at runtime. This is not a zero-knowledge model. For sensitive systems, always use separate restricted server accounts.

Current evidence status

We clearly separate what is already in place today from what is not externally verified yet.

Available

• HTTPS, session protection, 2FA flow, and encrypted storage of connection data are active.
• There is no public local file route and no public LocalConnector access.

Currently not verified

• There is currently no published external security audit.
• There is currently no certification and no publicly documented penetration test.

How to secure production use in practice

• Use separate least-privilege accounts (no root login).
• Rotate passwords regularly and switch credentials when needed.
• Run your own backups and monitoring as an additional control layer.
• Report security issues at any time through the support contact.

Security transparency sheet

A short and transparent summary of how operations work today:

• Connection data is stored in the database and encrypted at rest.
• Decryption happens only when a connection must be established technically.
• Passwords are not shown in plain text in the admin area.
• Files from connected servers are not exposed as a public local file store.

Threat model in brief

Common risks are actively reduced, but some residual risk still remains with any online tool.

• Session misuse risk: mitigated through session rules, login protection, and 2FA flow.
• Misconfiguration risk: least-privilege accounts and separated credentials are recommended.
• Infrastructure attack risk: plan independent backups and monitoring.

Security reports

You can report security issues or suspicious findings at any time through the support contact. Reports are reviewed with priority and handled transparently.