Project CodeGuard: security rules that ride along with your AI coding agent

The gap Project CodeGuard is aimed at

An AI coding agent writes the code it was trained to write. Nothing in that process knows your threat model. The failure modes the README lists are the ordinary ones: skipped input validation, hardcoded secrets, weak cryptographic algorithms, unsafe functions, missing authorization checks. Each is a pattern the model reproduces because it appears constantly in public code.

The people this is built for are not security engineers. They are developers who already have an agent in their editor and want the generated output to stop at the obvious mistakes. The framework is model-agnostic, so the same ruleset can be pointed at different assistants. CoSAI, the Coalition for Secure AI, publishes it as an OASIS Open Project, which is the governance context behind the file layout rather than a product claim.

Markdown rules, translators, and a release ZIP

The mechanism is deliberately boring. Rules and skills are authored once in unified markdown under the sources/ directory. Conversion tools then translate that single source into the formats different coding agents expect, and release automation packages the result into downloadable ZIP files. The repository layout reflects those three stages: sources/ holds the canonical text, skills/ holds the packaged skills, and src/ holds the tooling, including the MCP server.

That single-source design is the interesting part. Agent rule formats change, and a ruleset written directly for one editor ages badly. Here the markdown is the artifact that gets reviewed, and the per-agent output is generated. The README describes the flow in five steps, ending with the claim that secure code is produced automatically without developer intervention. Treat that last clause as intent, not a measurement. A ruleset influences what a model generates; it does not verify the result.

Coverage spans cryptography (including post-quantum algorithms and certificate validation), input validation, authentication, authorization, supply chain, cloud and container security, platform and API security, and data protection. The breadth is a real constraint as much as a feature: a ruleset this wide is long, and long context competes with the rest of your agent's instructions.

Installing CodeGuard rules into a project

There is no package to install for the rules themselves. The README's quick start is three steps: download the skills and rules from the releases page, copy the agent and IDE specific files into your repository, and start coding. The Python project in pyproject.toml exists to build and serve the ruleset, not to be imported by your application.

If you want to work from the repository, clone it and sync the environment with uv. The project requires Python 3.11 or newer.

git clone https://github.com/cosai-oasis/project-codeguard
cd project-codeguard
uv sync

The dependency set is small: pyyaml, mkdocs and mkdocs-material. Two details in pyproject.toml are worth reading before you vendor anything. The first is a set of CVE floors for transitive dependencies, pinned so that a resolver cannot pick an older vulnerable version.

[tool.uv]
constraint-dependencies = [
    "urllib3>=2.7.0",
    "requests>=2.33.0",
    "pygments>=2.20.0",
    "idna>=3.15",
    "pymdown-extensions>=10.21.3",
]
exclude-newer = "7 days"

The second is exclude-newer = "7 days", a supply-chain cooldown that refuses package versions published in the last week. That is a deliberate trade: you get protection from a freshly compromised release, and you accept being up to a week behind on every dependency. For a documentation-and-rules repository this is cheap. For a library you import at runtime it would be a different conversation.

For a first real use, take the packaged skills from the releases page and place the directory matching your agent at the root of your own repository. The README names Cursor, GitHub Copilot, Codex, Windsurf and Claude Code as the agents that can consume the rules for review. The repository also carries .claude-plugin/ and .codex-plugin/ directories at the top level, which is where the agent-specific packaging lives. After copying, ask your agent to review an existing file and check whether it cites the CodeGuard rules by name. If it does not, the rules are not in context and the copy step is the thing to fix.

The MCP server and what central deployment assumes

The repository includes an MCP server that exposes all CodeGuard rules as tools over streamable HTTP. The intended shape is organizational: deploy one instance, point every developer's assistant at it, and update the rules in one place instead of asking each repository to re-copy files. The README points to src/codeguard-mcp/README.md for setup.

That model has an obvious cost. A central HTTP service becomes a dependency of the editing loop, and the README does not describe what an agent sees when the server is unreachable. It also does not discuss authentication for the endpoint or how rule updates are versioned across teams. The setup instructions live in a separate README, so read that file before promising anyone a managed rollout. For a single developer, copying files is simpler and has no runtime dependency at all.

Where a ruleset stops being the right tool

Project CodeGuard shapes generation. It does not inspect a diff, fail a CI job, or prove that a rule was followed. The README's own framing puts the rules in the planning phase, during generation, and in review, all of which are model-driven moments. If your requirement is a hard gate that blocks a merge on a detected SQL injection, this is the wrong layer. A static analyzer or a dependency scanner answers that question; CodeGuard tries to prevent the pattern from being written.

The second limitation is context budget. Rules covering cryptography, input validation, authentication, authorization, supply chain, cloud, platform and data protection are a lot of text to keep in front of a model that is also holding your codebase. Teams that load the full set into every request may find the agent less responsive to the actual task. The repository's structure suggests the intended answer is per-agent packaging rather than one giant prompt, but the README does not document a recommended subset.

The third is verification. The release history shows rules releases at v1.3.0, v1.3.1 and v1.4.0 between January and June 2026, and the last push to the repository was on 2026-09-15. That cadence is visible, but the README does not publish efficacy measurements, so you cannot tell from the repository alone how much of a difference the rules make on your code. The evaluations/ directory exists at the top level, which is where I would look before trusting any claim about impact.

How this differs from a Semgrep-style scanner

Semgrep is the natural comparison point, and the difference is where each one sits in time. Semgrep matches patterns in code that already exists and reports findings you triage. Project CodeGuard supplies instructions to a model before and while the code is written, so the output is influenced rather than inspected.

The two are complements, not substitutes. A scanner has deterministic rules, an exit code and a report; CodeGuard has markdown guidance and whatever your agent does with it. A scanner also cannot stop a model from choosing a weak hash in the first place, which is precisely the moment CodeGuard targets. If you already run a scanner in CI, adding CodeGuard changes what arrives at that scanner rather than replacing it.

Maintenance, licence and what to check before adopting

The ruleset is versioned separately from the tooling, which is the right call for something agents consume: you can pin a rules release and upgrade on your own schedule. The last push to the repository was on 2026-09-15, two days before this writing, so the project is being worked on. The Python side is small and the dependency list is short, which keeps upgrade cost low for anyone who only consumes the packaged rules.

Licensing needs a closer look than the README provides. The README carries a CC BY 4.0 badge, while the repository's licence field is reported as NOASSERTION and there is a LICENSE.md at the top level. Those two signals do not agree, and the difference matters: CC BY 4.0 permits commercial use with attribution but is not a software licence, so the terms for the Python tooling under src/ may differ from the terms for the markdown rules. Read LICENSE.md and CONTRIBUTING.md directly. This is not legal advice, and for a redistribution scenario you should get an actual answer from whoever owns licensing at your organization.

Editorial conclusion

Adopt Project CodeGuard if your team already runs Cursor, Copilot, Codex, Windsurf or Claude Code and wants security guidance applied during generation rather than after a merge request. Skip it if you need a scanner that blocks a build on its own; this project shapes what the model writes, it does not gate a pipeline by itself. Verify first that your agent's format appears under skills/ and src/, then check LICENSE.md, because the repository is marked NOASSERTION while the README badge points at CC BY 4.0, and that difference matters if you plan to modify and redistribute the rules internally.

Frequently asked questions

Official sources

1. cosai-oasis/project-codeguard on GitHub
2. Issues
3. Project website
4. README
5. Releases