Security and Governance

This page does not try to replace the full security whitepaper. It focuses on the boundaries most easily missed during deployment and use: which ports should not be directly exposed, which data should not be sent directly to public models, and how to report product issues.

Public Exposure Notes

Flocks runs locally by default, which is itself a security boundary. External hosts can access the service only when you explicitly change the bind address to 0.0.0.0.

Recommended Exposure Strategy

If remote access is required, prefer the following approach:

• Expose only the unified service port used by the WebUI and API.
• Route browser API requests through the /api endpoint on the same host and port.
• Use security groups, firewalls, TLS, or reverse proxies for access control.
• Require API Token for programmatic clients.

Do not continue the old pattern of exposing both 5173 and 8000. The current standard deployment only needs the unified service port, which defaults to 5173.

Why the Unified Entry Point Should Not Be Exposed to the Public Internet Without Restriction

The unified service entry point hosts both WebUI and API. Once it is directly exposed to the public Internet, the concern is not only page access. You also face:

• A larger attack surface
• Risk of unauthorized access
• Risk of direct API probing and invocation

Therefore, even if account authentication is enabled on the unified entry point, unrestricted direct public exposure is not recommended. Further narrow the exposure with a reverse proxy, TLS, trusted network segments, or firewall rules.

Minimum Pre-deployment Checks

Confirm at least:

1. Whether Internet access is truly required
2. Whether only required ports are open
3. Whether firewall allowlists or trusted network segment restrictions are in place
4. Whether exposure is narrowed through a reverse proxy or unified entry point

Data and Desensitization

For "what desensitization is performed before data is sent to models", current public materials are better suited to stating principles than promising a universal, automatic, exception-free desensitization process. In production, focus on the data boundary itself instead of assuming the system has already handled all sensitive information for you.

Recommended Principles

• Prefer internal-network or private models for highly sensitive data.
• For public model services, review your organization's data egress policy first.
• For highly sensitive inputs such as raw logs, original alert text, or sample content, decide whether preprocessing is required before use.

Content That Requires Special Care

Content that usually needs careful assessment includes:

• Configurations containing accounts, tokens, passwords, or keys
• Raw attack samples or malicious payloads
• Raw alerts containing large amounts of internal asset information
• Business data subject to compliance constraints

If you are unsure how to handle it, the most conservative approach is:

• First reduce outbound transmission of raw sensitive data.
• Then evaluate whether a public model is necessary.
• Finally decide whether to add desensitization or trimming steps in the transit flow.

Understanding Governance Boundaries

Flocks is better understood as an analysis and orchestration platform, not as a black-box system that automatically takes on all data governance responsibilities for your organization. Real security implementation still needs to be designed together with your model deployment location, network boundaries, logging standards, and compliance requirements.

Feedback Channels

For ordinary feature issues, documentation issues, or usage questions, use public feedback channels first. For suspected vulnerabilities, security configuration risks, or issues affecting historical versions, use a clearer security feedback path.

General Feedback

Suitable for:

• Missing documentation
• User experience issues
• General feature defects

These issues can usually be reported through:

• Official repository Issues
• Public community or product team communication channels

Security-related Feedback

Suitable for:

• Suspected product vulnerabilities
• Unauthorized access risks
• Security risks in historical versions
• Issues involving sensitive data processing boundaries

For these issues, contact the official security feedback channel, product team, or designated contact directly instead of leaving only a brief public discussion comment.

A Practical Recommendation

If you suspect your deployment is affected by a historical-version issue after upgrade or deployment, do three things first:

1. Check the official announcement for the affected version range.
2. Check your own deployment time and running version.
3. Then decide whether to upgrade, roll back, or add protective measures.

This is more controlled than immediately reinstalling the system or changing configuration broadly.