Vibe Coding and the Next Silent Cyber Risk

he insurability of AI — that is, the insurability of the exposures created by its use — is no longer a speculative question. For casualty insurers, one emerging issue is how to underwrite and cover organizations that use AI-generated code. If that code contributes to a loss, can the insured reconstruct how it entered production and demonstrate what controls were applied. Recent actuarial work, including the CAS AI Primer and the IAA Artificial Intelligence Governance Framework, has placed AI governance, documentation, validation, and auditability on the professional agenda. Cyber risk research has also emphasized shared dependencies and the need to control accumulation across insurance portfolios, as exemplified in CAS work on cyber risk quantification and stress scenarios alongside the Academy Cyber Risk Toolkit. This article examines where these concerns meet: AI-generated software.

One source of this exposure is “vibe coding,” the use of conversational AI systems and agentic coding tools to generate, edit, test, or deploy software. The concern is not simply that AI may introduce bugs. More importantly, AI-assisted development can obscure the chain of provenance. Who specified the function? Who generated the code? Who reviewed the resulting change and any dependencies it introduced? Who approved its deployment? Can the organization reconstruct the sequence after a loss?

In a traditional software development process, responsibility is already distributed across product owners, developers, reviewers, security teams, vendors, and management. Yet the main steps — specification, coding, review, testing, release, and monitoring — are usually documented and distinguishable. Vibe coding can blur these boundaries. A user states an intention, the tool generates code, an agent modifies multiple files, and the same system may generate the tests. Approval may then depend less on understanding how the change was produced than on whether the application appears to work.

For casualty insurers, this loss of visibility turns a software defect into a provenance problem. After a loss, the insured may need to show who requested the change, which model or tool generated it, what modifications and dependencies were introduced, what tests were run, who approved deployment, and what monitoring followed. If that chain cannot be reconstructed, the insurer must assess causation and liability without a reliable evidentiary record.

Consider a simple scenario. A coding assistant modifies an authentication check. The application still runs, the test suite passes, and the pull request is approved. Months later, a customer alleges that the change enabled an unauthorized transaction. The claim investigation will turn not only on whether the final code was defective, but also on how the change entered the code base, which controls applied, whether the reviewer had sufficient information, and whether the organization can reconstruct the path from prompt to production.

Vibe coding should therefore be treated as a software supply chain exposure. The supply chain includes not only vendors, application programming interfaces (APIs), open-source packages, and cloud services, but also prompts, model versions, permissions granted to agents, AI-generated code changes, test results, and review records. A loss may arise from one generated line, but the underwriting issue is the process that allowed that line to enter production.

For underwriting, the relevant question is not whether someone clicked “accept,” but whether that person had the time, competence, authority, and tools to challenge the output. A junior employee may approve generated code without understanding its security implications. A senior engineer may be asked to review too many AI-generated changes too quickly. A business user may deploy a low-code or no-code AI-generated workflow without involving IT or security. In each case, the organization can point to human involvement. The insurer still needs to determine whether that involvement was capable of detecting or preventing the relevant error.

This is a new form of an old accountability problem. Computer scientist and philosopher Helen Nissenbaum described the “many hands” problem in computerized systems decades before generative AI. Vibe coding adds AI models, tools, APIs, generated artifacts, and agent actions to that chain. Accountability does not disappear, but responsibility becomes harder to allocate and the sequence of decisions becomes harder to reconstruct.

• Which AI coding assistants or agentic tools are authorized?
• Can they be used on production code, customer data, authentication, payment flows, pricing systems, or regulated functions?
• Are prompts, model or tool versions, generated diffs, and approvals retained?
• Are inventories of external libraries, software components, and dependencies updated after AI-generated changes?
• Are security scans, unit tests, integration tests, and code reviews mandatory before deployment?
• Can agents execute commands, modify multiple files, call external services, or open pull requests automatically?
• Are high-risk functions reviewed by qualified personnel rather than by the person who prompted the tool?
• Can the insured reconstruct the path from prompt to production after a loss?

These questions are not merely technical. They may affect pricing, limits, exclusions, claims handling, and reinsurance. A cyber or technology errors and omissions (E&O) claim involving AI-generated software will often turn on causation: what changed, when it changed, who authorized it, and which controls were applied. If the insured cannot provide the relevant logs and records, the insurer may be unable to reconstruct the events, assess causation, or defend the claim effectively.

This does not require insurers to read every line of code. A fire insurer does not inspect every wire every day, but it does consider building codes, alarms, maintenance records, and changes in occupancy. Similarly, an insurer covering organizations that use AI-generated software need not understand every generated line, but should assess whether the insured’s controls reduce the likelihood of unsafe code, allow incidents to be reconstructed, and limit correlated losses among organizations using the same tools or vendors.

Machine learning systems already accumulate hidden technical debt through data pipelines, dependencies, monitoring gaps, and organizational processes. Vibe coding can add governance debt: undocumented decisions, unclear responsibilities, and development processes that cannot readily be reconstructed. The issue is not only whether a system works today, but whether the insured can later explain why it failed, what changed, which components were affected, and who was responsible for acting.

Policy wording may therefore need to distinguish ordinary software defects from losses associated with ungoverned AI-assisted development. Relevant considerations include representations concerning authorized AI coding tools, exclusions for unreviewed autonomous deployment, sublimits for shared dependencies capable of producing correlated losses, audit rights, incident-reporting duties, and aggregation clauses addressing failures associated with a common tool, model, or generated coding pattern. Reinsurers will also need to consider whether many insureds rely on the same coding assistant or agent framework because a recurring insecure pattern could produce a portfolio-wide event.

Recent work on agent-generated verified software suggests a constructive approach. In the Axon compiler project, a coding agent generated both code and machine-checked correctness proofs. Trust was placed not in the agent itself, but in the validation structure around it, including tests, certificate checkers, formal proofs, and targeted audits. The lesson for insurers is modest but important: AI-generated code becomes more credible when the development process produces evidence that can be independently checked. Provenance identifies how the code was produced; validation provides evidence that its output can be trusted.

Vibe coding is more readily insurable when the insured can demonstrate a controlled and documented chain of delegation: what was requested, what was generated, what was reviewed, what was tested, what was deployed, and what was monitored. It becomes much harder to underwrite and investigate when that chain cannot be reconstructed. The next silent cyber exposure may not arise from a mysterious autonomous AI. It may arise from ordinary software, written partly by AI, deployed quickly, poorly documented, and difficult to explain after the loss.

For casualty insurers, the key change is therefore evidentiary as well as technical. Vibe coding changes not only how software is produced, but also what an insured must be able to document for the resulting risk to remain understandable and insurable.