Security

Design

• The application process owns engine processes and listens on the loopback interface, not the network.
• The interface receives whether a credential is configured, not the credential itself.
• Each provider credential is passed only to the process that needs it, so unrelated engine processes do not inherit it.
• Risky actions appear as approval cards in the conversation instead of being allowed implicitly.
• Control of your own computer is a separate opt-in, chosen per folk.
• Cloud and server backends are validated before they are reused.

Approvals

When an engine reports a permission request, OpenFolks shows it in the thread with its scope. Cancelling a turn closes outstanding requests so a stale approval cannot be answered later. “Always allow” is tied to a specific request and does not grant general execution.

Secrets

• Packaged builds use write-only settings and operating-system-backed encryption where it is available.
• Secret values are removed from configuration responses.
• OAuth tokens for connected apps are held by the connection provider, not stored in folk instructions.
• Do not paste API keys into a conversation. Anything in a conversation can be sent to a model provider.

Webhooks and remote access

The webhook receiver is a separate listener that exposes a health route and secret hook routes only. It does not expose the rest of the application. If you make it reachable from the internet, put a narrow relay in front of it and use bearer authentication. Do not expose the main application port.

Your part

• Read approvals, especially shell commands, file writes and actions in connected services.
• Use a dedicated environment, such as a Local VM, for untrusted or destructive work.
• Connect accounts with only the access a folk needs.
• Keep OpenFolks and your engine tools up to date.
• On a shared computer, assume other administrators can read application data. Use a separate operating system account if you need stronger separation.

Installers

The installers are not signed with an Apple or Microsoft certificate. Each release publishes a SHA256SUMS.txt file. Compare your download with it before you run it. The download page shows how.

Reporting a vulnerability

Please report security issues privately so a fix can be released before details are public. Use GitHub private vulnerability reporting for this repository. Include the version, the steps to reproduce, and the impact you expect. Do not open a public issue with exploit details.

If private reporting is not available to you, open a public issue that asks for a private contact and contains no technical detail. A machine-readable contact is published at /.well-known/security.txt.

Supported versions

Security fixes are made in the latest release. Update to the newest version before reporting.

More detail

• Security model
• Permissions and secrets
• Privacy