Skip to main content

Security

SkillFlaw is an application platform that can run user-authored flows, call external services, handle files, and in some cases execute custom code paths.

That makes security a deployment responsibility, not just a feature checklist.

SkillFlaw includes authentication, authorization, visibility, and management boundaries, but you should not treat a shared SkillFlaw runtime as a sandbox for untrusted code or hostile tenants.

warning

You are responsible for the security posture of the environment where SkillFlaw runs, including:

  • infrastructure isolation
  • network exposure
  • secret management
  • transport security
  • safe handling of custom code, imported resources, and user-supplied inputs

Security model in practical terms​

For current SkillFlaw releases, assume all of the following are true:

  • flows can trigger outbound network access depending on the components you enable
  • custom code and code-adjacent workflows deserve the same caution as application code
  • public API, webhook, and MCP endpoints must be protected like any other internet-facing service
  • deployment topology matters: backend-only, full web, and docs exposure all create different attack surfaces

If you are exposing SkillFlaw to the internet, keep the public surface as small as possible.

Secure local development​

For local development and debugging:

  • run only flows and components you trust
  • avoid reusing production secrets in local environments
  • keep SKILLFLAW_SECRET_KEY_FILE outside the repository
  • use isolated or disposable environments when testing untrusted custom code or imported resources

If you are experimenting with third-party code, containerized or otherwise isolated execution is the safer path.

Secure internet-facing deployments​

For any real public deployment:

  • terminate TLS at a controlled edge such as Nginx or Kubernetes ingress
  • keep backend routing explicit for /health, /api/*, and /api/v1/mcp/streamable
  • expose the frontend only when you actually need the browser UI
  • expose docs only when you actually need public documentation
  • store credentials and API secrets outside images
  • mount SKILLFLAW_SECRET_KEY_FILE as a real secret-backed file
  • keep SKILLFLAW_CONFIG_DIR on writable persistent storage

For reverse-proxy guidance, see Deploy SkillFlaw behind Nginx and HTTPS.

Secure hosted or multi-tenant offerings​

If you operate SkillFlaw for multiple customers, teams, or otherwise untrusted workloads, do not rely on a single shared runtime as your only protection boundary.

At minimum, plan for infrastructure isolation such as:

  • separate processes or workloads for mutually untrusted tenants
  • isolated writable storage
  • restricted network reachability to private services
  • controlled database credentials and scope
  • per-environment secret boundaries

Application-level permissions are important, but they are not a substitute for infrastructure isolation when custom code, file handling, or outbound integrations are in play.

Authentication and API exposure​

SkillFlaw API and MCP endpoints should follow the same authentication expectations as the rest of your service.

In practice:

  • keep API authentication enabled in public environments
  • protect MCP clients that use /api/v1/mcp/streamable
  • treat webhook and run endpoints as production API surfaces
  • review generated or copied client snippets before sharing them publicly

For MCP-specific guidance, see Use SkillFlaw as an MCP server.

Operational hardening checklist​

Before calling a deployment “production-ready”, confirm the following:

  • current supported release in use
  • TLS enforced for real user traffic
  • PostgreSQL and Redis are not broadly exposed
  • SKILLFLAW_ENABLE_SUPERUSER_CLI=false unless you explicitly need that capability in a controlled environment
  • backups and rollback procedures exist
  • logs and health checks are monitored continuously

Security advisories and vulnerability reporting​

The source of truth for reported vulnerabilities, fixed versions, and disclosure workflow is the repository security policy:

If you discover a vulnerability, report it privately through the repository's GitHub Security tab instead of disclosing it publicly first.

See also​