Explain AI coding risk as three simple questions: Is the code correct and safe? What information leaves the company? What can the tool touch or change? Then show what you already do about each one and ask for two or three clear decisions. Skip the jargon, and bring one real example.
TL;DR: Managers do not need to know how the AI works. They need to know what could go wrong, how likely it is, who owns the fix, and what you need from them. Use three risks, one table and a short list of decisions. Keep the whole talk under five minutes.
Definition: AI coding assistant. An AI coding assistant is a tool that suggests or writes software code from a plain-language request. Some only suggest text. Others, called coding agents, can also edit files and run commands.
Why does a boss need to hear about this at all?
Because your team is probably already using AI tools to write code, whether or not anyone announced it. The tools are popular, easy to install and often free to try.
A manager owns the outcomes: customer trust, deals that depend on security answers, and the cost of a bad day. They also own the decision of who may use what. They cannot make good choices if all they hear is "it is complicated."
So the aim of your talk is not to teach AI. It is to make three or four decisions easy.
If your boss has seen a software report before, our post on how to explain an SCA report to executives uses the same approach for dependency risk.
What are the three risks, in plain words?
Risk 1: the code may be wrong or unsafe. AI tools write code that looks confident. It can still contain mistakes, such as a missing check on user input, or a library that is out of date. Think of a very fast new hire who works without much supervision. Quick, helpful, and in need of a second pair of eyes.
Risk 2: information may leave the company. When someone pastes code, customer data or passwords into an AI tool, that information goes to an outside service. Whether that is acceptable depends on the tool, the plan and your company rules.
Risk 3: the tool may be allowed to do too much. Some AI tools can now edit files and run commands on a laptop. Anthropic's documentation says its coding tool has permission modes. In its Manual mode, it stops and asks before most actions that edit files, run shell commands or reach the network. OpenAI's documentation says its Codex tools, when run from a terminal or editor, default to no network access and limit writing to the active workspace. In both cases, the settings can be changed, so someone should decide on purpose.
How do you show this on one page?
A table works well because a manager can read it in thirty seconds.
| Risk | What it means | Example question to ask | What we do about it |
|---|---|---|---|
| Wrong or unsafe code | Mistakes in what the tool writes | Who reviews AI-written changes? | Every change gets a human review and an automatic security scan |
| Information leaving | Data sent to an outside AI service | Which tools may staff use, and for what? | A short approved tool list and a rule on what must never be pasted |
| Too much access | The tool can change or run things | What may it touch without asking? | Start with ask-first settings and review them quarterly |
Fill the last column with what is true today. If the honest answer is "nothing yet," write that, and make it the first decision you ask for.
What does a worked example look like?
All numbers below are invented to show the shape of the story.
Imagine a team of 15 developers. In a quick survey, 11 say they use an AI coding tool at least weekly. Only 3 of those 11 use a tool the company has approved.
You explain it to your boss like this:
- The situation. "Most of the team already uses AI tools. About a quarter use ones we approved."
- The risk. "Code and sometimes customer test data may be going to services we have not reviewed. And nothing guarantees AI-written code gets a security scan before release."
- What we do today. "We review every change in pull requests. We do not yet scan for known library flaws on each one."
- What I need. "Approve a short list of tools, approve a rule on what must not be pasted, and approve adding an automatic scan to every pull request."
A pull request is a proposed code change that others can read before it is accepted. That one sentence is enough for a manager who has never seen one.
Notice what is missing: model names, benchmark scores, technical acronyms. They add nothing to the decision.
What decisions should you ask for?
Ask for specific, small decisions. Vague requests like "support for AI security" get a vague answer. Try these:
- An approved tool list. Which AI tools are allowed, on which plans, for which kinds of work.
- A "never paste" rule. For example: no passwords, no customer records, no private keys. Our post on whether it is safe to paste code or secrets into an LLM chat can help you word it.
- A review rule. Every AI-written change is read by a person before it ships.
- An automatic check. A scan on each pull request, with a gate (a rule that blocks the merge) for serious findings.
- An owner. One named person who keeps the list and the settings current.
Each of these is cheap compared with explaining a leak or a bad release afterward.
What questions will your boss probably ask?
Be ready for these four.
- "Should we ban it?" A ban often pushes use out of sight. Many teams do better with approved tools and clear rules. Your answer may differ, and that is a business call.
- "Is it safe?" Say that it can be used safely with rules, reviews and checks, and that no tool makes risk disappear.
- "What does our customer ask?" Buyers increasingly ask how AI-written code is reviewed. Having a short, true answer helps in security reviews.
- "What will it cost?" Give a rough effort in people-days, not a price tag, and offer to bring a firmer estimate.
Our AI coding assistant security FAQ has fuller answers you can adapt.
Where does Safeguard fit in?
Safeguard covers the "automatic check" decision. It builds a software bill of materials (a list of every component in an application), scans dependencies for known flaws, and uses reachability analysis to show which flaws your code can actually trigger, so the report your boss sees is shorter and clearer. Policies and gates can block a pull request that breaks your rules.
Safeguard can also open fix pull requests. That is off by default, with every category set to Manual, so a person decides when and whether to enable it. For the access question, Safeguard offers an MCP Guardrail for controlling what connected AI tools may do, and agent identity for tracking which agent did what.
The Safeguard command line tool runs on your own machine, sends only scan results (not source code) to the platform, and can also write code. It installs with the curl or PowerShell installers listed on the download page. For a first look, try the free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo and watch how a pull request gate works. Look at what makes a change pass or fail. This is the kind of rule you are asking your boss to approve.
Click through it at your own pace, or open it full screen.
Quick check
How long should the talk be?
Five minutes is enough. Use three risks, one table and a short list of decisions. Leave deeper detail for questions.
Do I need to name specific AI products?
Name the ones your team actually uses, because that makes the risk real. Avoid comparing products. The decision is about rules, not brands.
What if we have no controls yet?
Say so plainly and make the first decision a small one, such as an approved tool list and a rule on what must never be pasted. Starting small beats waiting for a perfect plan.
Is the risk mostly about the AI or about our own process?
Mostly about process. The tool is one new source of code. The questions are the old ones: who reviews it, what does it touch, and what gets checked before release.
Sources
- Claude Code permission modes, Anthropic documentation
- Codex agent approvals and security, OpenAI developer documentation
- Safeguard downloads
- Safeguard CLI
Last reviewed: 19 October 2026.
