Vibecoding security PoCs: from idea to testable control in an afternoon

Lately I have been using AI-agentic workflows the same way I would use a lab bench — not as a replacement for judgment, but as a way to clear the bench, mount the experiment, and see whether a control actually holds before anyone argues about a six-week project plan.

AI coding security research keeps reminding us why that human gate matters. Pearce and colleagues found roughly 40% of GitHub Copilot suggestions vulnerable in the scenarios they studied. A later SecurityEval-based evaluation reported more than 75% vulnerable outputs across tested models, with weak self-detection and better results only when repair was paired with tooling. So when I talk about a security PoC built with an LLM in an afternoon, I mean a testable draft — not production code you ship because it compiled.

I call it vibecoding: Cursor (or a similar agent) plus a shell plus a tight brief → a working proof of concept in hours, not weeks. The point is to shrink the distance from idea to testable control, then put human review and infrastructure-as-code around what survived. I do this from Victoria and remote engagements. If you can describe the check clearly, you can usually stand up something you can poke the same day.

What vibecoding is (and what it is not)

Vibecoding, here, is intentional prototyping with an agent in the loop. You write a short brief: goals, constraints, non-goals, and how you will know it worked. The agent scaffolds the repo, wires the CLI, iterates on failures, and leaves you with something you can run, break, and explain.

It is a lab bench. You still own the experiment design. You still decide what “pass” means. You still refuse to promote anything that cannot survive review.

What it is not:

• Not “the model is the architect.” You are.
• Not a path to unreviewed production changes.
• Not an excuse to skip threat modeling, least privilege, or change control.
• Not magic — vague briefs produce vague PoCs. Tight briefs produce useful ones.

If you would not trust a junior engineer to merge without review, do not trust an agent either. Treat the output as draft evidence for a design conversation — especially knowing how often LLM insecure code shows up in controlled evaluations.

What the research says about LLM insecure code

Pearce et al. (“Asleep at the Keyboard?”) generated 1,689 programs across 89 scenarios and found approximately 40% vulnerable — a result that has been widely cited in IEEE S&P and later in CACM. Siddiq and Santos’s SecurityEval dataset (MSR4P&S’22) was built specifically to evaluate ML code generation against CWE-mapped tasks; follow-on work uses it as a stress test for whether models produce secure code end to end.

On that benchmark, the arXiv 2408.10495 study found the tested models generated over 75% vulnerable code, struggled to identify vulnerabilities in their own output, and improved repair success mainly when iterative repair was assisted by semantic analysis tooling. That is the practical takeaway for practitioners: the model can draft fast; detection and repair need humans and tools, not confidence from the chat window.

OWASP’s Top 10 for LLM Applications 2025 still leads with LLM01 Prompt Injection. Their Prompt Injection Prevention Cheat Sheet emphasises human-in-the-loop review and least-privilege tools — the same gate I put between an afternoon PoC and anything that touches a real tenant.

Three places a security PoC pays off quickly

1. Cloudflare Access / Gateway policy experiments

Zero Trust policy is easier to feel than to debate. Spin up a disposable Access application, a couple of service tokens, and Gateway rules that encode “only this identity, from this posture, to this origin.” Hit it with curl. Watch the logs. Break the happy path on purpose.

In an afternoon you can learn whether your intended policy language matches reality — device posture checks, email-domain allow lists, path-based rules, or block-by-default for admin panels. The PoC does not need to be your production tenant. It needs to be close enough that the lesson transfers. I use agentic workflows to scaffold Terraform or API calls, generate test matrices, and document what each rule was meant to prove. A human decides what graduates into the real account.

2. Terraform sketches that bake in secure-by-default defaults

Greenfield modules are a gift: you can encode secure defaults before habit and “just make it work” erode them. Vibecoding helps sketch modules that refuse public buckets by default, require encryption, force private endpoints, or demand explicit break-glass tags.

The PoC is not “apply to prod.” It is a small stack in a sandbox account: plan, apply, try to misconfigure it, confirm the guardrails catch you. Agent-assisted iteration is fast at provider wiring, variable validation, and example terraform plan outputs — so you spend human time on the threat model and the defaults that matter. What survives gets cleaned up, reviewed, and promoted into your real module registry with tests and owners.

3. Guardrail demos before anything hits production

Prompt injection and data-leakage checks are easier to argue about after you have a failing test. Build a tiny harness: a sample agent or RAG path, a handful of adversarial prompts, and assertions that secrets, PII, or tool calls outside policy do not leave the box.

That demo is a conversation piece with product and engineering. “Here is what happens when we do not constrain tools” beats a slide deck. An afternoon PoC will not cover every red-team case. It will show whether your intended guardrails are even wired — rate limits, allow-listed tools, output filters, logging of tool invocations. Lab bench first. Production gate later.

The real trick: human review and an IaC gate

Shrinking idea → testable control only helps if something hard sits between the PoC and production. My working loop:

1. Brief — one page: problem, success criteria, out of scope, data you must not touch.
2. Vibecode the PoC — agent + shell, iterate until the demo is boringly repeatable.
3. Human review — threat model, least privilege, secrets handling, failure modes. Kill anything cute but unsafe. Assume LLM insecure code until proven otherwise.
4. IaC and policy — rewrite the survivor as Terraform / declarative config / CI checks with owners and tests.
5. Promote deliberately — change window, observability, rollback. No “it worked in the agent chat.”

The agent accelerates steps 1–2. Steps 3–5 are where architecture earns its keep. If you skip them, vibecoding becomes a faster way to accumulate fragile snowflakes — and the SecurityEval-style results suggest you will accumulate vulnerabilities along with them.

FAQ: AI coding security and PoCs

Is vibecoding safe for production security controls?

Not by itself. Use it to stand up a security PoC you can break and measure. Promote only after human review and an IaC/policy gate — the same discipline OWASP recommends for LLM tool use.

Why bother if models produce so much insecure code?

Because speed on the lab bench is still valuable when the output is treated as a draft. The research shows the risk of trusting suggestions; it does not say prototyping with an agent is useless. It says review and tooling are non-negotiable.

What should I prototype first?

Pick a check you can falsify the same day: a Gateway deny for admin paths, a Terraform module that refuses open security groups, or a prompt-injection harness around an internal chatbot.

From afternoon PoC to something that holds

If a security check only took an afternoon, what would you stand up this week? I am always looking for better lab-bench exercises.

If you want a second opinion on a scoped PoC — Zero Trust access patterns, secure-by-default IaC, or AI guardrails with a human gate — that is the kind of work I take on.

Services ·
Request a service ·
zameni.us

Expanded from a LinkedIn note (September 2026).

References

• Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., & Karri, R. Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. https://doi.org/10.1145/3610721
• How Well Do Large Language Models Serve as End-to-End Secure Code Producers? arXiv:2408.10495. https://arxiv.org/abs/2408.10495
• Siddiq, M. L., & Santos, J. C. S. (2022). SecurityEval Dataset: Mining Vulnerability Examples to Evaluate Machine Learning-Based Code Generation Techniques. MSR4P&S ’22. https://doi.org/10.1145/3549035.3561184 · dataset
• OWASP Top 10 for Large Language Model Applications 2025 — LLM01 Prompt Injection. https://owasp.org/www-project-top-10-for-large-language-model-applications/ · also genai.owasp.org/llm-top-10
• OWASP LLM Prompt Injection Prevention Cheat Sheet (human-in-the-loop, least privilege tools). OWASP Cheat Sheet Series