Security practices

Beflux runs several products with a small team of people and AI agents. Rather than relying on everyone being careful, we try to make the dangerous state unreachable in the first place. Here is what is actually in place.

For what we receive and what we don't, see Security.

How we use AI

Whenever a process has AI read text written by someone outside the company — an article, a review — three rules hold:

1. Take the power away at the runtime level. We don't ask the model to refrain from something; we run it where it cannot
2. Keep data and instructions apart. Text to be read is fenced off, and instructions written inside it are not treated as instructions
3. Verify on the machine side before anything ships. Format, vocabulary, and link destinations are checked before publishing or storing

Secrets never sit in plain text

• Tokens, API keys, and private keys never exist as plaintext values. Config files hold a reference, and the value is pulled from the vault at the moment it is needed

Automation gets the least power we can give it

• What our CI receives is read-only, or a credential scoped to a single target
• Anything that cannot be scoped down is not automated — we run it by hand when it is needed
• Cloud connections use no key files, only short-lived credentials issued for a narrow scope
• Automation defaults to read-only permissions, and write access is added one at a time, only where it is needed

Dangerous changes cannot be merged

• Every code change goes through review, and automated checks run before anything ships. A change that should not pass — a secret left in the code or in a log, for instance — is blocked

Dependencies

• Versions are pinned, and a freshly published one waits before we take it, so a compromised release does not go straight into a build
• Known vulnerabilities are detected automatically, and we upgrade as fixes land

Regular inventory

• We walk the attack paths of our repositories on a regular basis — this site's repository included — across 14 angles: authentication, exposed secrets, dependencies, what ships to the browser, input validation, database permissions, CI/CD, hosting, and others
• What we learn in one repository carries over to every repository from the next round on
• Each round also records what it did not cover — anything outside the repository, for instance. Without that, a clean result is not something you can trust
• When something turns up, fixing it is only half the work. Making sure we catch it automatically next time is the other half

What is not on this page

This page is about principles and practices. Specifics of our architecture and access paths are left out, since those are a map for an attacker. If you need to verify something, get in touch.