What is VibeSecOps?

AI-assisted development constrained by explicit, written-down, machine-enforceable security rules — the method Foxx Cyber uses to build every product, with a human who verifies and owns every change.

VibeSecOps is how every Foxx Cyber product is actually built: with an AI coding assistant doing the drafting and execution, a founder setting direction and verifying every change, and a layer of machine-enforced rules that catch the AI's mistakes before they ship.

The name is deliberate. "Vibe coding" — asking an AI for code and pasting what comes out without understanding or verifying it — is indefensible for anything that touches user data. "Never use AI" throws away a genuinely useful tool. VibeSecOps is the synthesis: the "vibe" is the speed and conversational fluency; the "SecOps" is the non-negotiable discipline that makes the speed safe.

Why write this down

I'm Jeremiah Price, founder of Foxx Cyber. My background is DoD cybersecurity — Risk Management Framework and GRC work, CISSP, CISM. My professional obligation is to reason about threat models, security controls, and evidence. I don't treat AI-assisted development as a way to skip the hard parts of building software. I treat it as a way to move faster at the parts I already know how to do right, with guardrails that make it obvious when the AI gets one of them wrong.

This page exists because prospective customers, partners, and the broader developer community reasonably ask: if AI wrote a lot of this, why should I trust it? The honest answer isn't "trust me." It's "here is the method, here are the rules the AI must follow, here are the machine checks that fail the build when it doesn't, and here is a worked example you can inspect."

The three things that make it work

VibeSecOps is not one trick. It's three parts, and if any one is missing it degrades back into vibe coding with extra steps.

1. A rulebook the AI must read before touching code. Every repository carries a CLAUDE.md with non-negotiable invariants — tenant scoping, auth-gate-first, parameterized SQL only, validation at every trust boundary. See The Rulebook.
2. Guardrails that fire on every change. Lint, type-check, tests, container and dependency scanning, and an SBOM — all wired into CI so a rule violation fails the pipeline, not a code review that might get skipped. See CI Guardrails.
3. A human who verifies, pushes back, and owns the outcome. The AI drafts and proposes; I read, correct, and authorize everything that lands. I never delegate the strategic decisions — architecture, threat model, which trust boundary to introduce.

How the collaboration actually works

I set direction. The AI executes.

I decide what to build and what the constraints are. The assistant proposes a plan, I review it, it executes. When I say "build me a financial advisor feature," I don't mean "decide whether we should build it" — I mean "I've decided; show me the implementation plan and ask questions if it's unclear."

The AI drafts. I verify.

Every non-trivial change, I read. I check that it matches what I asked for, follows the rulebook, and that the commit message is honest about what changed. AI assistants sometimes state things as fact that are close but wrong — "the test suite uses Jest" when it's Vitest, "the .env was committed" when it was only on disk. Catching those is the job, not an interruption to it.

I push back when I disagree — and the pushback becomes a rule.

Early in one project's hardening pass, the assistant started silencing lint errors with inline eslint-disable comments. I stopped it: lint exists for a reason; the fix is to correct the underlying code, not to mute the tool. We removed the suppressions, added a rule to CLAUDE.md banning them outright, and then added a CI check that greps every change for eslint-disable, @ts-ignore, @ts-expect-error, raw SQL string-building, and dangerouslySetInnerHTML. Any match fails the build.

That exchange is VibeSecOps in miniature: the AI suggested a shortcut, the human rejected it, and the rejection became a durable, machine-enforced rule that the next session can't backslide past.

When the AI doesn't know, it says so.

The useful failure mode is an assistant that admits the edge of what it knows — "I think this is an upstream issue, here's what I'd need to verify it" — rather than manufacturing confidence. That honesty is what makes the verification step tractable.

What VibeSecOps is not

• Asking an AI to build features without supervision.
• Accepting AI output without reading it.
• Merging code that passes the type-checker but hasn't been thought through.
• Claiming "the AI built it." The AI drafted; I directed, verified, corrected, and authorized.

It is also not free. It requires a rulebook you'll enforce without exceptions, a CI pipeline that catches the mistakes the rules target, documentation that reflects reality rather than aspiration, and a human who treats verification as part of the job.

The method is public

Everything on these pages is written up as a repository you can copy: gitlab.com/foxxcyber-oss/vibe-sec-ops — the rulebook template, the reference pipelines, the GitLab CI/CD components we include in every product, the triage / accepted-risk / POA&M formats, and the incident log that produced each rule. Apache-2.0.

Applied across the company

VibeSecOps has been the constant across every Foxx Cyber product since Bedrock CMMC v1 in late 2025, whether it's the CUI-handling Bedrock platform or a Railway-hosted commercial app. The hosting model changes; the way the code is written, reviewed, and gated does not.