In late April 2026, CISA co-authored joint guidance with Australia’s ASD, the NSA, and the UK’s NCSC recommending “careful adoption” of agentic AI systems. The same week, the Pentagon had already deployed over 103,000 AI agents built through vibe coding on its GenAI.mil platform.
That gap between the guidance and the reality is not a Pentagon problem. It’s the situation in most engineering teams right now.
Vibe coding tools — Lovable, Cursor, Bolt.new, GitHub Copilot — speed up development while leaving accountability exactly where it always was. Someone owns every line of code that ships, regardless of who or what wrote it. The question is whether you have a framework that makes ownership traceable and risk auditable before an incident forces the question.
This article gives you that framework: a concrete 30/60/90-day governance programme you can take to your board to show you have a handle on AI risk — without a dedicated security team. For the full evidence base this governance framework responds to, the research, the incidents, and the scale of the problem are all documented there.
Who owns the code when the AI writes it?
The developer who clicks “accept” owns the code. That is the legal and professional default — established in the AI tool vendors’ own terms of service.
GitHub Copilot’s IP indemnity covers intellectual property infringement claims where generated code duplicates third-party copyrighted content. It does not cover security vulnerabilities, functional defects, or regulatory compliance failures. No AI vendor has taken accountability for what their tools produce. They have all been explicit about this.
Accepting AI-generated code is legally and professionally the same as writing it. The developer’s signature is on the commit. The model’s is not.
The accountability chain runs upward from there. The developer accepted the code. The CTO permitted the tool and set — or failed to set — the review standards. The board carries the ultimate risk exposure: regulatory liability and reputational consequences if AI-generated code is the vector for a breach.
IP ownership is worth flagging for FinTech and HealthTech teams near fundraising or acquisition. The US Copyright Office has stated that AI-generated work without human authorship is not eligible for copyright protection. Acquirers are asking: can you demonstrate clear ownership of your codebase? An AI work product assignment clause in developer contracts and an automated licence scan gate in CI/CD are the minimum contractual artefacts.
The foundational governance artefact is the ownership chain record: which developer accepted which AI-generated code, when, and under what review conditions.
For the research that quantifies the risk this governance addresses — the vulnerability rates, the hallucination frequencies, the production scan data — that evidence base makes the ownership question concrete rather than theoretical.
What governance frameworks are actually worth building on?
Three frameworks give you credible external anchors to cite when presenting governance rationale to a board.
CISA Careful Adoption Guidance was co-authored with Australia’s ASD, the NSA, Canada’s Cyber Centre, and the UK’s NCSC. It recommends deploying incrementally, limiting initial use to low-risk tasks, and enforcing strict privilege controls. For what institutional-scale vibe coding governance failure looks like — what happened when even the Pentagon skipped the careful part — that article has the evidence.
Five Eyes Joint Guidance elevates AI governance to a national security concern, stating that “until security practices, evaluation methods and standards mature, organisations should assume that agentic AI systems may behave unexpectedly.” Australia’s ASD membership makes this directly applicable to Australian engineering teams.
CIS Controls v8.1 AI Companion is the most operationally specific of the three. The companion MCP Guide applies CIS Controls to Model Context Protocol integrations — a coverage gap in most other frameworks — and maps controls to concrete actions rather than principles.
💡 Model Context Protocol (MCP) is a standard that lets AI coding assistants connect to external tools and data sources — file systems, databases, APIs. It expands capability and expands attack surface simultaneously.
OWASP Agentic Top 10 is not a governance framework but the required vocabulary for writing one. It classifies vulnerability categories specific to agentic applications — agent goal hijack, prompt injection, memory poisoning — that the traditional OWASP Top 10 does not capture.
Our recommendation for teams without a dedicated security function: lead with CIS Controls v8.1 AI Companion for daily implementation, use CISA and Five Eyes as board-level legitimacy anchors, and use OWASP Agentic Top 10 as your security coverage checklist.
What does a 30/60/90-day governance programme look like without a dedicated security team?
The sequencing is what matters. A governance programme that tries to implement everything simultaneously will implement nothing.
Days 1–30: Inventory and Accountability
Before writing any policy, know what you are governing. The shadow AI inventory comes first because a policy written without knowledge of what your team is actually using will be worked around, not followed.
Deliverables by day 30:
- Shadow AI inventory complete. Survey the team anonymously — anonymity surfaces honest answers. Audit browser extensions and IDE plugins. Audit MCP server connections and their permission scopes. Review network logs for traffic to known AI platform domains. Document findings before writing policy: the inventory is an input to the permitted-tools list, not the output of an enforcement action.
- Ownership chain documentation established. For AI-generated code already in production, establish the record retroactively: which developer committed it, when, and under what review conditions.
- AI code governance policy written and communicated. Four elements: a permitted-tools list grounded in inventory findings; review requirements by risk tier; an enforcement mechanism; and a stated accountability principle that developers have acknowledged.
Days 31–60: Pipeline and Controls
Deliverables by day 60:
- SAST gates integrated into CI/CD for all AI-generated code. Static analysis runs automatically on every commit. AI models reproduce insecure code patterns from training data, so automated scanning is the minimum baseline.
- Risk-tiered review process live. Authentication handlers, data handling code, infrastructure configuration, and payment processing are high-risk and require senior engineer review plus a security tool pass before merge. UI components and test scaffolding are lower risk. Allocate review effort proportionally.
- Security review pipeline documented. What checks each risk tier must pass, who can approve high-risk merges, and the escalation path when SAST returns a critical finding.
How the 2.74x multiplier sizes the security review workload: AI code introduces cross-site scripting vulnerabilities at 2.74 times the rate of human-written code. If your team has tripled its code output through AI tools, senior review bandwidth must be planned to match — or the review pipeline gets bypassed.
Days 61–90: Hardening and Measurement
Deliverables by day 90:
- DAST added to the pipeline for production-facing components. Dynamic application security testing identifies vulnerabilities that do not appear in static analysis.
- Manual penetration test on highest-risk AI-generated components. Components that handle authentication, data access, or payment processing need a manual pentest by day 90 — this is what gives your board a security outcome, not only a process.
- Measurement framework established. Three metrics: percentage of AI-generated code passing SAST without modification; time-to-review by risk tier; shadow AI incidents surfaced per period.
- Board briefing prepared. A one-page evidence summary: permitted-tools list, ownership chain documentation rate, SAST pass rate, and outstanding high-risk components awaiting manual penetration testing with scheduled completion dates.
How do you evaluate a vibe coding platform before your team uses it?
Platform vendor security posture varies dramatically. Lovable is the evidence. What happened when platform vendor security obligations failed — a 76-day BOLA exposure where any free account could read another user’s source code, database credentials, and AI chat history — is the cautionary benchmark.
These questions apply to platforms your team is considering, and retrospectively to tools already in use.
Sandbox isolation. Does the platform execute generated code in an isolated environment? Good answer: full sandbox isolation with explicit permission grants required to connect to any external system.
Row-level security (RLS) defaults. Are RLS policies enabled by default? A May 2025 study found approximately 70% of Lovable-built applications had RLS disabled entirely. Good answer: RLS on by default; insecure configurations require an explicit override.
💡 Row-level security (RLS) is a database feature that restricts which rows a user can see or modify based on their identity — the control that prevents one user from reading another user’s data in a multi-tenant application.
Bug bounty programme. Does the vendor operate a public programme with disclosed scope? No bug bounty programme is a red flag.
Breach response history. Good answer: transparent disclosure within 72 hours and a published post-incident review. Delayed or absent disclosure should disqualify a platform from enterprise use.
IP and data handling. Does the vendor train models on user-submitted code? Good answer: opt-out available and data deletion on request confirmed in writing.
How do you govern what your team is already using?
Shadow AI is the realistic starting state. More than 80% of Fortune 500 companies use active AI agents built with low-code and no-code tools. Only 10% have a clear strategy to manage them. Companies are averaging 223 shadow AI incidents per month — a figure that has doubled year-over-year.
💡 Shadow AI refers to the use of AI tools within an organisation without official approval or governance oversight — the engineering equivalent of shadow IT, where developers adopt Lovable, Cursor, or other platforms outside any sanctioned procurement or security review process.
The shadow AI inventory is the governance response. Four methods:
- Anonymous team survey. Ask what AI tools developers use for coding, code review, and scaffolding. Anonymity surfaces honest answers. The goal is an accurate picture, not an enforcement action.
- Browser extension and IDE plugin audit. Cursor, Copilot, Tabnine, and similar tools leave installation traces. Audit across team machines.
- MCP server and permission audit. List which MCP servers are connected to which tools, with what permission scopes, and which team members authorised them. This is the step most organisations skip — and the one that surfaces the highest-risk integrations.
- Network log review. Review logs for traffic to known AI platform domains: Lovable, Bolt.new, v0.dev, Claude.ai, Cursor’s telemetry endpoints.
Write the policy after the inventory, not before it. A policy written without the inventory describes what leadership wishes was happening, not what governance can actually enforce.
The arms-race framing that makes governance urgent — attackers using the same vibe coding tools as your developers — makes the shadow AI inventory a continuous process, not a one-time audit.
Why does traditional IAM fail for AI agents, and what replaces it?
Traditional identity and access management was designed for human users: a person authenticates, is granted a role, and acts within its boundaries. AI agents break this model in three ways.
Credential inheritance. AI agents inherit the credentials of the developer who configured them. If the developer has production system access, so does the agent.
Autonomous cross-system operation. An agent can read from one system, write to another, and call external APIs within a single session — without the human checkpoints that constrain this in practice.
Prompt injection susceptibility. If a valid agent presents a valid token to perform a malicious action — because external content manipulated it — Zero Trust authorises the action. The identity is verified. The malicious instruction is not. Google documented a 32% relative increase in malicious prompt injection activity between November 2025 and February 2026.
The governance response is agentic permission scoping: minimum permissions, granted just-in-time and revoked upon task completion. Four steps:
- Inventory all AI agent tool access scopes and MCP permissions as part of the day 1–30 shadow AI audit.
- Require explicit approval for any agent permission that grants write access to production systems, external APIs, or sensitive data stores.
- Establish an agent identity registry. Each agent integration documented: permitted scope, developer accountable, last review date.
- Treat MCP integrations as supply chain risk. Supply chain security as a governance requirement covers how attackers are targeting the AI coding toolchain itself.
What does governance look like when it works?
Governed AI engineering means AI tools operating within a traceable accountability framework — development velocity maintained, ownership unambiguous, risk auditable.
The signal that governance is working is that you can answer four questions at any point:
- Which AI tools are in use, and by which developers?
- Who is accountable for each piece of AI-generated code currently in production?
- What security checks did that code pass before deployment?
- If an AI-generated component were the vector for a breach in the next 24 hours, who would own the response?
If any of those questions produces uncertainty, the governance programme has a gap. The 30/60/90 framework closes those gaps systematically — and it gives you something to put in front of a board before they ask.
The governance gap is not a knowledge gap. The frameworks are available. The remaining variable is whether you act before or after an incident forces the question. For the full scope of the vibe coding security landscape that makes governance urgent — from the Pentagon’s 100,000-agent deployment to the statistical evidence base — that context is documented in our comprehensive overview.
SoftwareSeni works with engineering teams to implement governed AI development practices — from shadow AI inventory through security review pipeline design to board-level reporting. Teams that want implementation support rather than a framework to self-execute can enquire directly.
Frequently Asked Questions
Who is legally responsible if AI-generated code causes a security breach?
The developer who accepted and committed the code bears primary professional accountability. The organisation carries regulatory and liability exposure. AI tool vendors disclaim liability for functional and security defects in their terms of service. Governance documentation — ownership chain records, review logs — is the primary evidence in any post-incident investigation.
What is the difference between vibe coding and governed AI engineering?
Vibe coding generates functional code with minimal human review, prioritising speed over verification. Governed AI engineering applies defined controls — ownership assignment, security review gates, permission scoping — so output is traceable and auditable. The difference is not the tools used but whether accountability and review are built into the workflow.
What is shadow AI and why is it a governance problem?
Shadow AI is the use of unsanctioned AI tools — developers adopting Lovable, Cursor, Bolt.new, or other platforms without official approval or governance oversight. Policies written without knowledge of actual tool use will be worked around rather than followed. The shadow AI inventory is the prerequisite for any enforceable governance policy.
Does GitHub Copilot’s IP indemnity protect my company if AI-generated code contains a security vulnerability?
No. GitHub Copilot’s IP indemnity covers intellectual property infringement claims under specific conditions. It does not cover security vulnerabilities, functional defects, or regulatory compliance failures. The developer who accepted the code remains accountable for its security posture.
What security tests should AI-generated code pass before going to production?
At minimum: SAST as a CI/CD gate for all AI-generated code; DAST for production-facing components; manual penetration testing for high-risk components handling authentication, data access, and payment processing. Risk-tiered review allocates senior engineer effort by component risk level. The 2.74x multiplier provides the quantitative basis for sizing review capacity.
What is prompt injection and why does OWASP treat it as the primary agent risk?
Prompt injection occurs when malicious instructions embedded in external content hijack an AI agent’s behaviour. It is the primary agent risk because agents will act on instructions from any source they can read. Google documented a 32% relative increase in malicious prompt injection activity between November 2025 and February 2026.
How do I find out which AI tools my developers are already using without formal approval?
Four methods: anonymous team survey; audit of browser extensions and IDE plugins across team machines; audit of MCP server connections and their permission scopes; review of network logs for traffic to known AI platform domains. Document findings before writing any policy.
What questions should I ask a vibe coding platform vendor before allowing team-wide adoption?
Five areas: sandbox isolation; RLS defaults; bug bounty programme; breach response history; IP and data handling — does the vendor train on user-submitted code, and is opt-out available?
Why doesn’t traditional IAM handle AI agent permissions?
Traditional IAM is designed for human users acting within a defined role. AI agents inherit the credentials of whoever configured them, operate autonomously across multiple systems, and can be manipulated through prompt injection. Agentic permission scoping — least-privilege tool access, just-in-time grants, and an agent identity registry — is the governance response.
What is the CIS Controls v8.1 AI Companion and why does it matter for vibe coding governance?
CIS Controls v8.1 AI Companion extends the Center for Internet Security’s control framework to AI-assisted development. It covers MCP integrations explicitly — a gap in most governance frameworks — and maps controls to concrete actions. For teams without a dedicated security function, it is the most immediately actionable control set available.
What should a board-level AI governance briefing include?
Four elements: permitted-tools list; ownership chain documentation rate; SAST pass rate for AI-generated code; outstanding high-risk components awaiting manual penetration testing with scheduled completion dates.
Is it safe to let developers use AI coding tools for HealthTech or FinTech applications?
Yes, under governed conditions. HIPAA, PCI DSS, and SOC 2 do not prohibit AI-assisted development but require auditability, access controls, and demonstrable security review. Governance requirements for regulated verticals: ownership chain documentation for audit evidence, SAST/DAST gates before any data-handling component ships, and agentic permission scoping for any agent that touches regulated data.
