To explain AI coding agent risk to leadership, name five plain risks, show the control for each, state what decision you need, and promise a simple progress report. Skip jargon and model internals. Executives need to know what could go wrong, how likely you think it is, and what it costs to reduce.
Start with the decision
Open with the ask. For example: approve a pilot of one coding agent for eight developers, with defined controls, for a fixed period, with a go or no go review at the end. A decision framed this way is easier to say yes to than a general briefing on AI risk.
Five risks in plain words
1. The agent leaks something it should not. Credentials, customer data, or proprietary code enter the tool. OWASP lists credentials and source code among the sensitive data types at risk of disclosure.
2. The agent does more than we meant. OWASP calls this excessive agency and traces it to too many functions, too many permissions, and too much autonomy.
3. Someone steers the agent. Text in an issue, a web page, or a dependency can carry instructions. OWASP names this indirect prompt injection.
4. Bad code is merged. The agent writes plausible code with flaws or invents a dependency. Research on package hallucination across 16 code generating models found hallucinated package rates averaging at least 5.2 percent for commercial models and 21.7 percent for open source models, in the setup the authors tested. Treat that as a reason to check dependencies, not as a forecast for your tool.
5. We cannot show what happened. Without logs and labels, an incident or an audit question becomes guesswork.
The control for each
| Risk | Main control | Evidence you can show |
|---|---|---|
| Leakage | Secrets kept out of reach, clear data rules | Rotation records, policy page |
| Overreach | Least privilege, human approval | Permission settings, approval logs |
| Steering | Limit actions after reading untrusted input | Test results from guardrail probes |
| Bad code | Required review, dependency checks | Branch protection settings, pull request gates |
| No trail | Action records, commit labels | Log lookup test |
What to ask leadership for
- A named executive owner for the risk.
- Time from two or three developers and one reviewer for the pilot.
- Agreement on the go or no go criteria before the start.
- A clear message to the wider team that unapproved tools are not the route.
How to report
Send a short note every two weeks: controls in place, incidents and near misses, one number on developer use, and the next decision. Keep it to ten lines. Link out to detail for those who want it.
Be honest about uncertainty
Say what you do not know yet. Leaders trust a team that names its open questions and has a date to answer them. The NIST AI Risk Management Framework is voluntary and built around governing, mapping, measuring, and managing risk. You can use that vocabulary if your leadership already does, and plan the next rings in rollout rings with gates.
Safeguard offers compliance and evidence automation and policies that help you produce the evidence column of the table.
Quick check
Should I quote statistics to leadership?
Only ones you can source, with the conditions attached. One cited number beats five loose ones.
Do I need to explain how models work?
No. Explain what the agent can touch and what stops it.
Sources
- OWASP LLM01 Prompt Injection
- OWASP LLM02 Sensitive Information Disclosure
- OWASP LLM06 Excessive Agency
- We Have a Package for You (arXiv 2406.10279)
- NIST AI Risk Management Framework
Last reviewed: 19 October 2026.
