To threat model an AI coding agent in one hour, list what it can reach, what it reads, who can influence its input, and what damage a wrong action would cause. Then rank the abuse cases and attach one control to each. The goal is a one page worksheet, not a diagram.
Definitions first
A coding agent is a tool that reads your code, runs commands, and edits files with some autonomy. A threat model is a short written answer to four questions: what are we protecting, who or what can attack it, how, and what do we do about it.
OWASP describes the core risk as excessive agency: damaging actions taken in response to unexpected, ambiguous, or manipulated model output. Its three root causes are excessive functionality, excessive permissions, and excessive autonomy. Those three give you a ready frame for the hour.
The one hour plan
Minutes 0 to 10: assets. Write down what the agent can touch. Source code, environment files, cloud credentials on the laptop, the package manager, the git remote, CI secrets if it runs in a pipeline. Mark each item as read, write, or execute access.
Minutes 10 to 25: inputs. List everything the agent reads that a person outside your team could have written. Issue text, pull request descriptions, README files in third party packages, web pages it fetches, tool server responses. OWASP defines indirect prompt injection as instructions arriving through external sources such as websites or files, and notes that injected content does not have to be visible to humans.
Minutes 25 to 40: abuse cases. For each input, ask what a hostile instruction could make the agent do with the assets from step one. Typical cases: read an env file and send it out, add a dependency, edit a workflow file, push to a protected branch.
Minutes 40 to 55: controls. Match one control per abuse case. Use the table below as a starting set.
| Abuse case | First control |
|---|---|
| Secret read and sent out | Keep secrets out of the project tree, restrict network access |
| Unwanted dependency added | Dependency review on every pull request |
| Workflow file edited | Owner review required on those paths |
| Destructive shell command | Approval required for commands outside an allow list |
| Push to main | Branch protection, no direct push by the agent |
Minutes 55 to 60: owners and dates. Every control gets a name and a date. A threat model without owners is a document.
What to leave out
Do not try to model the vendor's cloud. Ask the vendor for their data handling answers in writing and move on. Do not model model weights or training either. Your hour is better spent on the parts you control: permissions, inputs, and review.
Keep it alive
Re-run the worksheet when the agent gains a new tool, a new repository scope, or a new network path. OWASP also advises treating the model as an untrusted user in testing, so add a short adversarial test to each review. For a test plan, see how to test coding agent guardrails before rollout.
Safeguard offers an MCP Guardrail, pull request gates, and SBOM and dependency scanning that map onto several rows above, and you can run the free scan on a repository to see your dependency picture first.
Quick check
Do I need a diagram?
No. A table of assets, inputs, abuse cases, and controls is enough for a first pass. Add a diagram later if the agent touches many systems.
Who should be in the room?
One security engineer, one developer who uses the agent daily, and whoever owns CI. Three people is enough.
How often should we repeat it?
When scope changes: a new tool, a new repository, a new network path, or a new autonomy setting.
Sources
Last reviewed: 19 October 2026.
