Security practices

Beflux develops and operates several products with a small team of people and AI agents. Rather than depending on individual care, we build our systems so that unsafe states cannot be created in the first place. This page describes the practices currently in operation.

For the information we handle, see Security.

Use of AI

Selection of services

Before adopting an AI service, we check the provider's terms for the conditions under which inputs are used for model training. Where this depends on a user setting, the service is used with training turned off.

Processing of external text

When AI reads text written outside the company, such as articles or reviews, three controls apply:

1. Permissions are restricted by the runtime. The process runs in an environment where the action is not possible, rather than relying on an instruction not to perform it
2. Data and instructions are separated. Text to be read is passed within explicit boundaries, and instructions written inside it are not treated as instructions
3. Output is verified mechanically. Format, vocabulary, and link destinations are checked before anything is published or stored

Permissions for automation

• Automation (CI) is read-only by default, and write access is granted individually, only to the jobs that need it
• Credentials given to automation are either read-only or scoped to a specific target
• Operations that cannot be scoped are not automated; a team member runs them when needed
• Third-party automation components are pinned to a version whose contents can be identified

Release of changes

• Changes to product code are released only after passing automated checks. These cover leaked secrets, permission settings for automation, and how dependencies are introduced. A change that fails a check cannot be released
• In addition to the automated checks, changes are reviewed by AI, and a person decides whether to release them. The one exception is minor dependency updates, which are released automatically once the checks pass

Dependencies

• Versions are pinned, and a new release is adopted only after a waiting period, so that a compromised release is not taken up immediately after publication
• Known vulnerabilities are detected automatically, and updates are applied as fixes become available

Databases

Services with a database are configured to grant no permissions beyond those required, and automated daily checks confirm that the configuration has not drifted from its intended state.

Periodic review

• For the repositories in scope — including the one for this site — possible attack paths are reviewed mechanically on a regular schedule. The review covers authentication, exposure of sensitive data, dependencies, client-side deliverables, input validation, database permissions, CI/CD, hosting, and matters specific to mobile apps
• What is learned in one repository applies to every repository in scope from the next review onward
• Findings are mapped to the ten categories of the OWASP Top 10 (2021), a widely used reference for web application security. This is a self-assessment based on the OWASP Top 10, not a third-party certification, and we do not describe it as compliance
• Areas that were not examined, such as anything outside the repository, are recorded as well. Without that distinction, a result of "no issues found" cannot be relied on
• When an issue is found, the response covers both the fix and a way to detect the same kind of issue automatically from then on

Scope of this page

This page describes practices that Beflux operates on its own. We do not hold third-party certifications such as ISO/IEC 27001.

Details of our architecture and access paths are omitted, because they could assist an attacker. If you need to confirm something specific, please contact us.