Security checklist

Deployment boundary

One SoduWork deployment serves one organization. Inside it, a department admin manages their own department and its sub-departments; a super administrator manages everything.

• Department admins can't change sibling departments or create root departments.
• Every admin write endpoint requires a declared permission.
• Successful organization changes are recorded in the audit log with who, what and which target. A rejected change doesn't alter anything.

Before go-live

• SODUWORK_ENV=production, with PostgreSQL, a strong ADMIN_PASS and AUTH_SECRET, explicit CORS_ORIGINS, DEVICE_AUTH_COMPAT=false and HUB_PUBLIC_URL (Deploy for a team).
• HTTPS in front of the Hub, with WebSocket support.
• Secrets in a secret manager or environment, never in a committed file. A dedicated database account with least privilege.
• Database and file storage included in backups, and a restore tested.
• Runners connected only to this Hub, with keys used only on their own machines.
• Plugin and Skill sources reviewed. Plugins and Skills are not a sandbox.
• Admin roles given only the permission keys each person needs (Organizations and permissions).

What SoduWork does with secrets

Secret	Where it lives
Organization model keys	On the Hub. Never returned in plain text
Personal model keys	On the Hub, per account. Never returned in plain text
Plugin secrets	On the runner, mapped through the binding, injected only into the node that uses it
App settings marked secret	Encrypted with the system's secure storage, per account and app
Runner keys	Shown once at enrollment; stored as hashes on the Hub

Secrets never go into plugins, bindings, run evidence, logs or chat history.

Report a vulnerability

Report security issues privately, not in public issues. See Report a security issue.