AppSec and AI-Generated Code: Executive Briefing

AI coding assistants and agents are now writing a large share of the software organisations ship, and most boards have no view of how much, how it is checked or who is accountable when it goes wrong. This briefing is for board members, chief executives, chief technology and finance officers and audit and risk committees who are asked to approve AI coding tools, fund application security, or explain software risk to regulators and customers. It sets out what changes when code is generated rather than typed, which evidence matters, the questions directors should put to management, where to invest first and a 90-day plan. It stays at board level and is vendor neutral. The practitioner method for reviewing generated code is in the AI-Generated Code Review Guide, and the research figures are collected in AI Generated Code Security Statistics.

The risk in one paragraph

AI tools let developers, and increasingly non-developers, produce working software far faster than before, and the business case is real. The security problem is that speed and volume rise while the controls that catch flaws (design review, code review, testing, dependency checks) stay sized for human output. Independent testing shows that generated code often carries well-known flaws, that models sometimes recommend software packages that do not exist, and that AI-assisted commits leak credentials more often than ordinary ones. Coding agents add a second risk: they act with real access to source code, build pipelines and sometimes production, so a misread instruction or a poisoned file can do damage directly. None of this argues for banning the tools. It argues for treating AI-generated code as untrusted input until it has passed the same, or stronger, checks as any other code, for limiting what coding agents can reach, and for one accountable owner who can show the board the evidence.

Why this is a board-level issue now

Adoption is near universal: Google's 2025 DORA report, based on nearly 5,000 technology professionals, found 90% use AI at work and more than 80% believe it has raised their productivity, while 30% report little or no trust in AI-generated code. Its central finding is that AI amplifies what is already there: strong engineering teams improve, struggling ones see their problems grow.
New supply chain exposure: a USENIX Security 2025 study of 576,000 generated code samples from 16 models found commercial models suggested non-existent packages in at least 5.2% of cases on average and open-source models in 21.7%, with 205,474 unique invented names. Attackers can register those names. OWASP lists unsafe code generation, including invented libraries, under LLM09:2025 Misinformation.
Credentials in code: GitGuardian's State of Secrets Sprawl 2026 counted 28,649,024 new secrets in public GitHub commits in 2025, reported that commits co-authored by one AI coding tool leaked secrets at about twice the baseline rate, and found 24,008 unique secrets in MCP configuration files used to connect AI tools to systems.
Regulators and governments are setting expectations: the UK Software Security Code of Practice (voluntary, first published 7 May 2025) asks software vendors to appoint a Senior Responsible Owner at top-tier leadership level who is accountable for its 14 provisions. The NCSC chief executive used his March 2026 RSAC keynote to say AI coding tools must not introduce or propagate vulnerabilities, and the NCSC published its "vibe coding spectrum" guidance in June 2026. In the EU, the Cyber Resilience Act places security obligations on manufacturers of products with digital elements whoever wrote the code; see the EU Cyber Resilience Act Executive Briefing.

What actually changes when code is generated

Directors do not need the technical detail, but they need to know which assumptions no longer hold. The table compares the familiar software risk picture with the AI-assisted one.

Area	Traditional development	AI-assisted development	Board implication
Volume of change	Limited by developer time	Much higher output per person, larger pull requests	Review and testing capacity must scale with output, or checks are skipped quietly
Who writes code	Trained developers	Developers, analysts and business users building their own tools	Software is being produced outside the governed development process
Authorship and accountability	The committer wrote it	The committer may not fully understand it	Policy must keep the human who merges code accountable for it
Dependencies	Chosen by developers, often from known lists	Suggested by the model, sometimes invented	Dependency allow lists and registry controls become essential
Secrets	Leaks through human error	Leaks through generated configuration, agent tool files and pasted context	Secret scanning and short-lived credentials move up the priority list
Actors with access	People and build systems	Coding agents that run commands, open pull requests and call tools	Agents are non-human identities and need scoped, owned, logged access
Data flow	Code stays in company systems	Code and context may go to external model providers	Contract terms on retention, training and location become part of the decision

Matching oversight to risk: the vibe coding spectrum

The NCSC's June 2026 guidance describes a spectrum from manual coding with AI autocomplete, through a wide middle where people design and review while AI writes functions, to full "vibe coding", where a high-level prompt lets the AI choose the architecture, code and tests and the person judges the result rather than reading the code. Its advice is to place each piece of work on the spectrum by risk. Prototypes, demos and limited internal tools with no sensitive data can tolerate light supervision. Anything handling authentication or authorisation, sensitive personal data, secrets, safety-critical functions or where a flaw would have significant consequences should move towards the manual end, with review of what the AI produces, understanding of the code, vulnerability checks, verification that it does what is expected, and system design that limits the impact of any exploitation. The NCSC also says to calibrate to what tools can do today, not what they might do later.

For a board, this gives a simple policy shape: a short list of application tiers, each with a permitted way of working and required checks. The tiering below is our recommendation, built on the NCSC spectrum.

Tier (NHI Mgmt Group recommendation)	Examples	Permitted AI use	Minimum checks before release
Tier 1: critical	Payments, authentication, customer data stores, safety or regulated systems	AI assistance with full human design and line-by-line review	Two reviewers, automated security testing, dependency and secret scanning, threat model updated
Tier 2: business	Customer-facing apps, internal systems with personal data	AI-written functions within human-designed architecture	One qualified reviewer, automated testing and scanning as merge gates
Tier 3: low impact	Internal tools with no sensitive data, reporting scripts	Agent-led development allowed in approved tools	Automated scanning; registered owner; no production credentials
Tier 4: prototype	Demos, experiments	Full vibe coding in a sandbox	No real data, no live credentials, cannot be promoted without re-tiering

Where identity fits

Coding agents are a new class of non-human identity. They hold tokens for source repositories, package registries, cloud accounts and sometimes databases, and they act on instructions that can be manipulated by content they read. The commonest serious incidents in this area are not exotic model failures: they are agents or AI tools using credentials that were broader, longer-lived or closer to production than the task needed. Management should be able to show that every agent and AI tool has its own identity, an accountable owner, least-privilege scopes, no standing write access to production, and logs that a person can review. See the AI Coding Agents Security Guide and the Secrets Management Guide.

Where it sits in the frameworks

Framework	Reference	What the board should expect
NIST CSF 2.0	GV.RR-01	Leadership is accountable for cyber risk, including the risk of AI-written software
NIST CSF 2.0	PR.PS-06	Secure development practices are integrated and their performance monitored across the lifecycle, whoever or whatever writes the code
NIST CSF 2.0	GV.SC-01	Supply chain risk programme covers AI model providers, coding tools and the packages they suggest
NIST SP 800-53 Rev 5	SA-11, SA-15	Developer testing and defined development tools and standards apply to AI tools too
NIST SP 800-218 and 800-218A	SSDF and its generative AI community profile (final, 26 July 2024)	Secure development practices, with AI-specific additions for teams that build or use models
UK Software Security Code of Practice	Principles 1 to 4, Senior Responsible Owner	Named senior owner with assurance on secure design, build environment, deployment and customer communication
OWASP Top 10 for LLM Applications 2025	LLM09 Misinformation, LLM06 Excessive Agency	Invented packages and over-privileged agents treated as named risks

For a whole-programme view, see the NIST SP 800-218A SSDF Community Profile for Generative AI Guide and the AppSec Maturity Model.

Five questions for the board to ask

How much of our code is AI-generated, and where? Management should know which tools are approved, which teams use them, and roughly what share of merged changes they produce, including software built by business users outside engineering.
Do our checks scale with the extra output? Ask whether review, security testing and dependency checks are automatic merge gates, and whether review backlogs or skipped checks have grown since adoption.
Which applications must never be vibe coded? There should be a written tiering of systems, with stricter rules for authentication, payments, personal data and safety-related code.
What can our coding agents touch? Ask for the list of agents and AI tools with access to repositories, pipelines, cloud and production, who owns each one, and how destructive actions are approved.
What happens to our code and data in the tools? Ask what the contracts say about retention, model training on our code, data location and indemnity, and who signed them off.

Red flags in management answers

"Developers review everything", with no data on review time, size of changes or checks that block a merge.
AI usage figures from licence counts only, with no view of personal accounts or tools used by non-developers.
Agents running under a developer's own credentials or a shared service account.
No inventory of MCP servers or tool connections used by AI assistants.
Security testing that reports findings but never blocks a release.

What good looks like

Policy: an approved tools list, application tiers with permitted AI use, and a rule that the person who merges code is accountable for it, whatever wrote it.
Automated gates: static analysis, software composition analysis, secret scanning and tests run on every change and block high-severity findings; packages come from an approved registry or proxy, so invented names fail. See the Slopsquatting and Package Hallucination Guide.
Human review where it counts: review effort concentrated on Tier 1 and Tier 2 code, with smaller changes and trained reviewers. See the Secure Code Review Guide.
Governed agents: each coding agent has its own short-lived, scoped credentials, runs in a sandbox, and needs human approval for destructive or production actions.
Provenance: the organisation can tell which changes were AI-assisted, so it can target review and respond fast if a tool or model is found to produce a flaw pattern.
Skills: developers trained to review generated code, and security champions in each team. See the Developer Security Training Programme Guide.

Where to invest first

Investment	Why first	Rough effort	Typical owner
Inventory of AI coding tools, agents and their access	Nothing else can be governed without it; often reveals unapproved tools and over-privileged tokens	Weeks	CISO with engineering leads
Secret scanning and pre-commit blocking across all repositories	Cheap, fast, and addresses the most measurable AI-related leak	Weeks	Platform engineering
Approved package registry or proxy	Stops invented or malicious package names reaching builds	One to three months	Platform engineering
Security testing as merge gates for Tier 1 and 2	Makes checks scale with volume instead of relying on reviewer stamina	One to three months	AppSec
Scoped, short-lived identities for coding agents	Limits the damage of agent mistakes and prompt injection	One to three months	IAM with platform engineering
Reviewer training and application tiering	Puts human attention where the impact is highest	Ongoing	Engineering leadership

Tools that use AI to review code can help with volume, but they do not remove the need for accountable human review on critical systems. See the AI-Assisted Code Review and AI SAST Guide and, for procurement, the AI Code Security and Agentic Coding Security Buyer's Guide.

Metrics to track

Ask for a short quarterly pack. The aim is trend, not a single number. Programme-level metrics are covered in the AppSec Programme Metrics Guide.

Metric	What it tells the board	Healthy direction
Share of merged changes that are AI-assisted, by application tier	Where generated code is concentrated	Known and stable in Tier 1
High-severity findings per 1,000 changes, AI-assisted versus other	Whether generated code is raising flaw rates	Falling, gap closing
Releases blocked by security gates, and time to fix	Whether gates are real and teams can respond	Gates firing, fix time falling
Secrets detected in commits per month, and median time to revoke	Credential hygiene in AI-assisted work	Fewer reaching the main branch, faster revocation
Coding agents with owner, scoped credentials and no standing production access	Agent governance coverage	Towards 100%
Packages blocked at the registry for being unknown or unapproved	Supply chain gate working	Visible, with exceptions reviewed

A 90-day plan

Days 1 to 30: appoint one senior accountable owner (the UK Code's Senior Responsible Owner model works well); publish an interim approved tools list; inventory AI coding tools, agents, MCP connections and the credentials they hold; switch on secret scanning with push protection across all repositories.
Days 31 to 60: agree application tiers and permitted AI use for each; make static analysis, dependency and secret checks merge gates on Tier 1 and 2 systems, starting in report-only mode for two weeks to measure noise before blocking; move package installs to an approved registry or proxy; remove standing production access from agents.
Days 61 to 90: issue scoped, short-lived identities to every coding agent and require human approval for destructive actions; start tagging AI-assisted changes; train reviewers; deliver the first metrics pack to the board with targets for the next two quarters. If a gate blocks critical delivery, use a time-limited, logged exception rather than switching the gate off.

Common failure patterns

Productivity first, controls later: tools rolled out to everyone with security added after incidents, by which time habits and unreviewed code are entrenched.
Review theatre: large AI-generated pull requests approved in minutes because the reviewer cannot realistically read them; the metric looks fine and the control has gone.
Agents borrowing human credentials: coding agents run with a developer's own tokens, so nothing separates what the person did from what the agent did, and the agent holds everything the person holds.
Instructions instead of permissions: "do not touch production" written in a prompt or chat rather than enforced by access controls.
Shadow builders: business teams vibe coding internal apps with real customer data, outside the development process and with no owner.
Contract blind spots: code and context sent to external models under consumer terms, with no agreement on retention or training.

Lessons from incidents

In the Replit AI Agent Database Deletion 2025, a coding agent deleted a live production database during a declared code freeze. The freeze existed only as an instruction in the chat; the agent had standing write access to production. The lesson for boards is that agent controls must be enforced through permissions, separate development and production credentials and human approval for destructive actions, not through instructions. In the Moltbook Database Exposure 2026, a fast-built application exposed its production database because a public key was shipped in the site's JavaScript and row-level authorisation was not configured, revealing 1.5 million agent API tokens. Whatever tool wrote the code, the missing control was a basic one that automated testing of what a public key can reach would have caught before launch.

Practitioner checklist

Name one senior owner accountable for software security, including AI-generated code.
Publish an approved AI coding tools list and block or monitor unapproved ones.
Inventory every coding agent, AI tool, MCP connection and the credentials each holds.
Define application tiers and the permitted AI use and checks for each.
Make static analysis, dependency and secret scanning blocking gates for Tier 1 and 2 systems.
Route all package installs through an approved registry or proxy.
Give each coding agent its own scoped, short-lived credentials and no standing production access.
Require human approval for destructive or production-affecting agent actions.
Review contracts with AI tool providers for retention, training use and data location.
Report the metrics pack to the board quarterly with targets.

Standards and references

How NHI Mgmt Group can help

We provide independent board briefings and assessments of the non-human identities behind AI-assisted development: coding agents, the tokens they hold, MCP connections and pipeline credentials. Our NHI Foundation Level Training Course, which includes an agentic AI section, helps engineering, security and IAM teams govern those identities. Contact us to arrange a briefing.

Application Security and AI-Generated Code Executive Briefing