The Cybersecurity Playbook for AI-Assisted Development (Vibe coding)

AI-assisted development has fundamentally changed how software is built. Features that once took days can now be implemented in minutes. Boilerplate disappears. Refactoring accelerates. Documentation becomes easier to generate. For experienced developers, the productivity gains are undeniable.

But as a cybersecurity researcher, penetration tester, and software developer, I do not look at AI coding tools only as productivity tools. I look at them as systems that introduce risk.

That does not mean I am against using them. Quite the opposite. I use them because they are powerful. But powerful systems require controls. Every AI coding agent, whether Claude Code, Cursor, GitHub Copilot, OpenAI Codex, or another platform, creates a new layer in the software development lifecycle. That layer can produce excellent code, but it can also introduce vulnerabilities, architectural drift, hidden technical debt, unnecessary dependencies, and insecure assumptions at a speed that is difficult for a human reviewer to keep up with.

This is where a cybersecurity mindset becomes useful.

The same principles we apply to security programs apply directly to AI-assisted development: trust but verify, least privilege, defense in depth, independent validation, and continuous monitoring. These are not abstract slogans. They are practical engineering controls. They help ensure that speed does not come at the expense of correctness, maintainability, or security.

The following guardrails are the practices I use when developing with AI.

1. Never Allow Unrestricted Writes

The fastest way to lose control of a codebase is to allow an AI agent to modify files without review.

Many AI coding platforms offer modes that automatically edit files, execute commands, generate migrations, install dependencies, and restructure projects with minimal interaction from the developer. The convenience is obvious. The risk is that you remove one of the most important controls in software development: human validation before change.

Every proposed modification should be reviewed before it lands in the codebase. That means reading the diff, understanding which files changed, and validating why the change was made. It also means checking whether the implementation still aligns with the architecture of the application.

Security issues rarely announce themselves clearly. They often appear as subtle implementation details hidden inside otherwise legitimate-looking changes. A permission check removed in the wrong place, a relaxed validation rule, a new dependency pulled in without justification, or a migration that changes data assumptions can all look harmless in isolation.

The goal is not to slow development down for the sake of process. The goal is to ensure that every change remains intentional.

2. Avoid Unsupervised Agent Loops

One of the most dangerous trends in AI-assisted development is the idea that an agent should continue working indefinitely until a task is complete. On the surface, this sounds attractive. Give the agent a goal, let it run, and come back to completed work.

In practice, this is where many problems begin.

Unsupervised loops can produce technical debt, architectural inconsistency, scope creep, hidden regressions, and excessive code generation. The model may keep producing output long after it has moved away from the original intent of the task. It may solve the problem as it understood it, but that is not always the same as solving the problem you actually had.

This distinction matters.

AI agents do not have real situational awareness of your business context, your threat model, your users, your production constraints, or your long-term architecture. They operate within the context provided to them, and that context is always incomplete.

The safer approach is to break work into small, verifiable tasks. Give the agent a narrow objective, review the result, approve or reject the change, and then proceed to the next step. This creates checkpoints. It also forces you to maintain ownership of the codebase instead of delegating judgment to a system that cannot truly be accountable for the result.

Security professionals already understand this principle. Large unreviewed changes create risk. AI-generated changes are no different.

3. Treat Rule Files as Security Policies

Most AI coding environments provide a way to guide agent behavior. Claude Code uses CLAUDE.md. Other tools may use AGENTS.md, .cursorrules, workspace instructions, or project-level prompts.

These files should not be treated as convenience notes. They should be treated as policy.

A good rule file should document coding standards, security expectations, architectural decisions, dependency rules, testing requirements, and lessons learned from previous mistakes. If the agent repeatedly makes the same mistake, the correction should be added to the file. If CI catches a recurring issue, the requirement should be documented. If a security review identifies a weakness, the guardrail should be written down.

This turns the rule file into institutional memory.

Without it, every session starts closer to zero. With it, the agent has a better chance of respecting the patterns and constraints that matter to your project. It will still make mistakes, but you are giving it a controlled operating environment rather than asking it to infer everything from scattered examples.

In security terms, the rule file becomes part of your control framework.

4. Build Reusable Operating Procedures

Experienced security teams rely on standard operating procedures because repeatable processes reduce mistakes. AI-assisted development should work the same way.

If you have a validated pattern for database migrations, API endpoints, authentication changes, infrastructure modifications, documentation generation, or security reviews, convert that pattern into a reusable instruction set. The less the model has to improvise, the more predictable its output becomes.

Predictability matters because AI agents are very good at generating plausible solutions. The problem is that plausible is not the same as correct. A solution can look clean, pass a quick review, and still violate project conventions or introduce future maintenance problems.

Reusable procedures reduce that risk. They tell the agent how work should be done in your environment. Over time, these procedures become similar to internal engineering standards. They are not just prompts; they are operational controls.

Predictability is a security feature.

5. Documentation Is a Security Control

Documentation is often treated as a maintenance activity, something to clean up after the “real work” is done. In AI-assisted development, documentation becomes much more important because it provides context to both human reviewers and AI reviewers.

Every meaningful change should be accompanied by clear commit messages, descriptive branch names, updated changelog entries, accurate docstrings where appropriate, architectural notes when required, and comprehensive pull request descriptions.

This matters because AI reviewers cannot infer context that was never written down. If the pull request only contains a bare diff, the reviewer sees code but not intent. If the pull request explains what changed, why it changed, what assumptions were made, and how the change was tested, the quality of the review improves significantly.

The same applies to human reviewers. Good documentation makes review easier, faster, and more accurate. Poor documentation forces reviewers to guess, and guessing is not a security control.

When AI is involved, context is everything. Documentation is how you preserve that context.

6. Every New Dependency Requires Justification

AI agents frequently solve problems by adding packages. Sometimes this is the right decision. Often, it is simply the easiest path for the model.

Every new dependency should be treated as a security and maintenance decision. Before approving it, ask whether the package is truly necessary, whether the same result can be achieved with existing project dependencies, whether the package is actively maintained, whether the license is acceptable, and whether the transitive dependency chain introduces additional risk.

This is not paranoia. It is basic supply chain security.

Every package added to a project becomes part of the attack surface. It may introduce vulnerabilities, licensing concerns, build issues, abandoned code, or long-term maintenance obligations. AI agents do not reliably weigh those trade-offs unless you force them to.

The easiest dependency to secure is the one that was never added.

7. Never Provide Secrets or Production Data

AI coding agents should never receive production database dumps, API keys, access tokens, private keys, customer records, sensitive log files, authentication credentials, or confidential client data.

Use sanitized examples whenever possible. Create sample payloads. Redact tokens. Replace real customer data with synthetic data. Strip logs before pasting them into prompts.

Organizations spend significant effort protecting sensitive data through access controls, logging, encryption, retention policies, and contractual obligations. Accidentally exposing that data through an AI-assisted workflow bypasses many of those controls.

Treat AI conversations as development environments, not secure vaults.

This is especially important for cybersecurity professionals because our logs and artifacts often contain exactly the kind of material that should not leave a controlled environment: tokens, headers, session identifiers, internal hostnames, customer details, exploit traces, and sensitive infrastructure information.

8. Use Independent AI Reviewers

One AI system generating code should not be the only AI system reviewing it.

Automated code review tools can provide a useful second opinion by identifying logic errors, edge cases, security concerns, maintainability issues, and architectural inconsistencies. They are not perfect, and they will produce false positives, but that does not make them useless.

The point is independent validation.

In cybersecurity, we rarely rely on a single control. We layer controls because each one catches a different class of failure. The same principle applies here. The coding agent may miss something because it is focused on completing the task. A separate reviewer may catch it because it is evaluating the diff from a different perspective.

Treat AI reviewer findings as a checklist, not a verdict. Read the finding, understand it, and decide whether it is valid. If it is valid, fix it. If it is not valid, document why.

The value is not blind acceptance. The value is another layer of review.

9. Security Scanning Must Be Automated

Every repository should include automated security validation. At minimum, this should include static application security testing, dependency vulnerability scanning, secret scanning, and license compliance validation.

AI-generated code can introduce vulnerabilities as confidently as it introduces correct implementations. It can produce unsafe query patterns, insecure defaults, weak validation, overly permissive access controls, and hardcoded secrets. These mistakes are not always obvious during manual review, especially when they are buried inside a larger change.

Automated scanning provides a consistent baseline. It will not replace threat modeling, manual security review, or penetration testing, but it catches a class of issues that should not depend entirely on human attention.

Security scanning is not a final approval. It is an early warning system.

10. CI/CD Is Non-Negotiable

Every pull request should prove that the application still builds and the expected checks still pass.

At minimum, the pipeline should include formatting checks, type checking, linting, unit tests, build validation, and container build validation if the application ships in Docker. These checks are not optional when AI-generated code is involved because the agent can produce code that looks correct but fails in the actual runtime environment.

This is especially important with modern JavaScript and TypeScript projects, where a change can pass a narrow local test but fail during the production build. It is also important in Python, Go, Java, .NET, and every other stack where dependency resolution, environment configuration, migrations, or containerization can expose defects that are not obvious in the diff.

The build pipeline should detect these failures before users do.

A local check is useful. A CI check is better. Both are necessary.

11. Test Like a User, Not Just a Developer

This is the guardrail many teams overlook.

Passing CI does not mean the software works. It only means the automated checks passed. That is valuable, but it is not the same as validating the actual workflow.

After every meaningful AI-generated change, run the application and use it. Execute the workflow manually. Test the success path, the failure path, the empty state, the unauthorized state, the validation logic, the responsive layout, the integration behavior, and the database result.

For JavaScript projects, this usually means running the package-manager path first:

pnpm install
pnpm lint
pnpm test
pnpm build
pnpm dev

Then open the application in the browser and test it like a human being.

Click the buttons. Submit the forms. Refresh the page. Log out and log back in. Try a user with lower permissions. Try invalid input. Trigger the error state. Confirm that the data written to the database is actually correct.

This is where many AI-generated defects appear. Not in the diff. Not in the type checker. Not in the linter. They show up when the feature is exercised the way a real user would exercise it.

If you would not ship a human developer’s code without running the application, do not ship AI-generated code without running the application.

12. Address Findings One at a Time

When security scanners, AI reviewers, or CI systems produce findings, resist the urge to paste all of them into a single prompt and ask the agent to fix everything at once.

That approach creates large, difficult-to-review changes. It also increases the chance that the agent will fix one issue while breaking another part of the application.

Evaluate each finding independently. Determine whether it is valid, what caused it, what the correct fix should be, and how the fix will be verified. If the finding is wrong, document why it is being dismissed. If it is valid, make the smallest reasonable change and test it.

This is slower than batch fixing, but it is safer and more controlled.

Reviewers make mistakes. Humans make mistakes. AI systems make mistakes. Validation requires understanding, not blind acceptance.

The Security Mindset

AI-assisted development is not going away. The productivity gains are too significant, and the tools will only improve.

The important question is not whether AI can write code. It can.

The real question is whether we can safely govern the code it writes.

As cybersecurity professionals, we already know the answer. Security is not achieved through trust alone. It is achieved through layered controls, independent validation, continuous verification, least privilege, and disciplined processes.

AI-assisted development is no different.

The speed is extraordinary. The risk is real. The guardrails are what make the speed usable.

Dan Duran, MSc CS, MBA, CISSP, CSSP is a senior cybersecurity researcher, penetration tester, and Chief Technology Officer at Rhyno Cybersecurity. He specializes in offensive security, managed detection and response, software development, and the practical application of AI within secure engineering environments. Dan publishes cybersecurity research, technical analysis, and educational content through GetCyber.