Security Cards Reduce Insecure AI Code

Security Cards is an open-source Reware Labs project that gives AI coding agents short, targeted security guidance for popular software libraries. It deals with a very ordinary problem: agentic coding can produce code that works, passes tests, and still mishandles auth, parsing, secrets, uploads, SQL, or TLS. The useful takeaway is simple: put security guidance next to the library call, then make the generated diff prove it followed the boundary.

Security Cards is a library-specific security prompt set for 80+ widely used libraries across 13 programming languages. Reware Labs says its evaluation reduced insecure code generation by up to 72.3% in Claude Code, Anthropic’s coding agent, with Opus 4.7. That number is interesting, but the shape of the fix is more interesting for Cursor users: small, local rules beat one giant “write secure code” instruction. Gemini Workshop is part of Harness Institute.

Read the card before the import

Security Cards aims at the moment where an agent chooses an API and fills in the defaults. That is where a lot of unsafe code starts.

A human might know that a file upload route needs content-type checks, size limits, path normalization, and safe storage. A coding agent might see “add avatar upload” and produce a working route with multer, express-fileupload, or a similar library, then stop at “the file reaches disk.” Functionally correct. Not yet safe.

The Reware Labs idea is to give the model a compact card about the specific library before it writes the code. Not a security textbook. Not a compliance policy. A sharp nudge: here are the risky defaults, here are the common insecure patterns, and here is what safe usage usually looks like.

The trap is believing the model failed because it lacked general security taste. Often it lacked the one library-specific warning that a senior reviewer would have said out loud in ten seconds.

Notice where the exposure happens

The exposure usually happens in boring code, not cinematic exploit code.

Picture a session in Cursor, Anysphere’s AI code editor, on a small TypeScript service. You ask Cursor Agent to add a webhook endpoint. The diff compiles. The local request works. The route handler is tidy. But the generated code accepts unsigned payloads, logs raw request bodies, or parses JSON before verifying the provider signature.

That is the boundary Security Cards points at. The unsafe part is not “AI wrote code.” The unsafe part is “an agent wrote against a library without carrying the library’s security constraints into the edit.”

One Hacker News reader asked the obvious question: whether the project only covers libraries, and whether it also handles general secure coding best practices. That question is fair. Library cards help at the API boundary. They do not replace threat modeling, review, tests, dependency scanning, or a boring human asking, “what can an attacker control here?”

This lines up with a broader pattern in AI coding: small syntax and context mistakes can bend model behavior more than we expect. We covered a related version of that problem in Why Human Syntax Breaks LLMs. Security Cards is one concrete answer: make the fragile part smaller.

Keep the boundary small in Cursor

The practical move is not to paste the whole Security Cards repository into every prompt. Keep the boundary small.

In Cursor, use the card when the agent touches a risky library or a risky surface: auth, uploads, crypto, database queries, template rendering, shell commands, deserialization, HTTP clients, webhooks, and secrets. Then ask for a diff that names the security-relevant choices it made.

A simple workflow looks like this:

1. Ask Cursor Agent to identify the libraries in the change.
2. Pull the relevant Security Card for the library, if one exists. The project ships as an agent skill, installed with npx skills add Reware-Labs/securitycards --skill securitycards -g, so the agent can fetch cards itself once you tell it to use the Security Cards skill.
3. Add a narrow Cursor rule or prompt note for this edit.
4. Generate the code.
5. Review the diff against the card, not just the task request.

The trap is turning the card into background noise. If every agent session starts with a thousand lines of generic security advice, the important part becomes just another paragraph. Better to attach the smallest relevant rule at the point of use.

If you are keeping a shared set of code review guardrails, this sits naturally under the related training topic, but the day-to-day habit is much smaller: one risky import, one card, one review pass.

Use a reviewable rule, not a vibe

Cursor rules are a good place to make this concrete because they are close to the repo and visible during review. You can keep a narrow .mdc file for security-sensitive library work, then point the agent at the relevant card when needed.

Here is a small rule stub you can copy and adapt:

---
description: Security checks for AI-generated library usage
alwaysApply: false
---

When editing code that uses security-sensitive libraries, do this before writing the final diff:

- Name each library whose defaults affect security.
- Check whether a Security Card exists for that library.
- Apply the card's library-specific warnings to the generated code.
- Prefer explicit safe configuration over implicit defaults.
- Add or update tests for attacker-controlled input where practical.
- In the final response, list the security choices made and any card guidance not applicable.

Do not claim the code is secure. Say what was checked.

This is intentionally plain. It does not say “never make mistakes.” It asks the agent to surface the exact review handles a human needs.

The trap is making the rule too broad. “Write secure code” is not reviewable. “For this upload handler, enforce file size, MIME validation, extension allowlist, randomized storage name, and no user-controlled path joins” is reviewable.

Copyable artifact: risks before you copy this

Use this table before accepting an AI-generated diff that adds or changes a library call. It is small enough to run inside an IDE review, which is the point.

The last row matters. Security Cards currently covers many libraries, not all software behavior. A missing card should make the review more careful, not more confident.

Common questions

Do Security Cards only cover libraries?

Yes, the project is centered on library-specific guidance. Reware Labs describes coverage for 80+ widely used libraries across 13 programming languages, which means the strongest fit is a concrete API boundary. General secure coding still needs separate review, tests, and project rules.

Does the 72.3% result mean AI-generated code is safe?

No, it means Reware Labs measured a reduction in insecure generation under its evaluation setup. The headline number is “up to 72.3%” in Claude Code with Opus 4.7, so treat it as a promising eval result, not a blanket guarantee for your repo.

How would I use Security Cards in Cursor?

Use a card when Cursor Agent touches a risky library, then review the generated diff against that card. The lightweight pattern is: identify the import, load the relevant card, add a narrow .mdc rule or prompt note, generate the edit, and ask the agent to list the security choices it made.

What if there is no card for the library I use?

Fall back to a small risk checklist and make the absence explicit in review. Ask the agent to identify attacker-controlled input, unsafe defaults, secret handling, and missing negative tests; do not let it imply that library-specific guidance was applied when no card exists.

Where does MCP fit into this?

MCP can help agents fetch external context, but it does not remove the need for a boundary. If an MCP server gives access to documentation, tickets, or internal security notes, keep permissions narrow and make the agent cite the specific guidance it used in the diff summary.

Best ways to use this research

• Best for: evaluating AI-generated code at library boundaries, especially auth, uploads, parsing, database access, webhooks, HTTP clients, and secrets.
• Best first artifact: a narrow Cursor rule that tells the agent to find the relevant Security Card, apply it, and report the security choices made in the final diff.
• Best comparison angle: compare generic secure-coding prompts against library-specific cards on the same task, then count insecure patterns in the generated code.
• Best review habit: ask for one negative test around attacker-controlled input before accepting a generated change.
• Best limitation to remember: Security Cards can reduce a class of insecure outputs, but they do not replace code review, threat modeling, dependency maintenance, or runtime controls.

Further reading

• Security Cards — source
• Security Cards — GitHub repository
• Model Context Protocol — specification
• Cursor — Agent

Try one risky import today

Pick one generated diff that uses a security-sensitive library, then review it with the relevant Security Card beside the code. If the agent cannot name the boundary it protected, do not merge on vibes.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.