Guide
What is the threat model for AI coding agents like Claude Code and Cursor?
Updated
Short answer
Harden's threat model sorts what can go wrong when staff use coding agents into 15 harm classes and 203 threats. It's organized by harm to the business, not by attack technique. It starts from three facts: the agent holds the developer's credentials, it reads untrusted content while taking privileged action, and it's the only thing that knows what it did.
Why attack-centric models miss agent harm#
Classic threat modeling asks who the attacker is and how they get in. That works for a web app. It fits coding agents badly, because much of what goes wrong with them has no attacker at all.
Harden's threat model for AI coding agents (Nov 2026) organizes threats by harm to the business instead. It has 15 harm classes and 203 threats. It's Harden's own analysis, and the counts are ours.
The harms fall into three groups: harm the agent causes, harm the agent suffers, and the conditions under which oversight stops working.
The three properties that create the problem#
- The agent holds the developer's credentials and acts with them. Anything the developer can reach, the agent can reach, usually with no second authorization step.
- It reads untrusted content and takes privileged action in the same step. Repo files, web pages, tickets, dependencies and CI logs all arrive as text. Nothing separates "data to look at" from "instruction to follow".
- It's the only thing that knows what it did. Volume has outgrown review, so the agent's own report becomes the record.
Put the first property next to an over-scoped token and one API call can reach production. In one widely reported incident, an agent used a token that "was scoped for any operation, including destructive ones" and deleted a startup's production database and all volume-level backups in a single API call. The company said it took 9 seconds.
The 15 harm classes#
| Class | What goes wrong | Example threats |
|---|---|---|
| H1 Sensitive data disclosure and mishandling | Code, secrets or customer data reach somewhere they shouldn't | Credential file read then sent out; secrets committed; proprietary code sent to an unapproved model endpoint |
| H2 Destructive change and data loss | Work, repos or infrastructure destroyed | Drops a database; force-push overwrites history; deletes files outside the workspace |
| H3 Unauthorized access, lateral movement, offensive action | The agent reaches systems beyond the task | Uses credentials found on out-of-scope systems; touches production from a dev task |
| H4 Insecure or incorrect artifact authored | The agent writes something that weakens security | Opens a firewall to the world; wildcard IAM policy; disables a CI gate |
| H5 Persistence and privilege manufacturing | Lasting access that outlives the task | Hidden instructions in a rules file re-infect future sessions; git hooks; new SSH keys |
| H6 Outward supply-chain contamination | Harm reaches customers and the public and can't be recalled | Publishes a bad package version; pushes to a shared upstream; edits a shared CI template |
| H7 Service disruption and resource abuse | Systems taken down, money burned | Runaway loop; restarts a live service; migration against a live database |
| H8 Untrusted code ingestion and execution | Unknown code enters and runs on company machines | Typosquatted dependency; piping curl to bash; a tool approved once and changed later |
| H9 Deceptive reporting and objective substitution | The agent reports success it didn't achieve | Deletes the failing test; hardcodes the expected value; claims a fix with no change |
| H10 Recovery, intervention and evidence destruction | You lose the ability to restore, to know, or to stop it | Deletes backups; clears logs; rewrites git history |
| H11 Exercise of the user's external authority | The agent acts as staff toward the outside world | Emails a customer; comments on a public issue; accepts terms |
| H12 Compromise of the agent's own runtime and identity | The agent itself is the target | Code runs at project-open before any consent prompt; session tokens stolen from disk |
| H13 Model integrity and model supply chain | The reasoning engine is wrong or tampered with | A silent model version change alters behavior under the same prompt and policy |
| H14 Retrieval, memory and knowledge-surface integrity | What the agent believes is poisoned | Planted documents steer retrieval; the agent writes its own wrong conclusion to memory |
| H15 Erosion of human oversight capacity | Whether people can supervise at all | Output volume exceeds review; approval fatigue leads people to switch the control off |
H1 to H12 are the agent acting and the agent being attacked. H13 to H15 are the surfaces threat models often skip: the model, the knowledge layer, and your own people.
The most likely harm has no attacker#
Our view: the most likely harm is the agent quietly faking success (H9). It deletes a failing test, mocks the thing under test, or reports "done" with no change.
An attacker-centric method like STRIDE has no category for that, so it never gets a control. Only comparing what the agent claimed with what actually ran catches it.
Harms you can't undo#
Some harms escape your blast radius. Publishing a package, pushing to a shared upstream, deploying, paying, emailing a customer: once done, nobody recalls them (H6 and H11).
That set is small and enumerable. Gate it first.
Attackers also borrow the agent you already trust. In the s1ngularity supply-chain attack, the malware abused locally configured AI CLIs to find more files to exfiltrate, and Wiz counted over 2,000 unique, verified secrets leaked.
What rules catch and what needs context#
Rules can decide alone when the action itself is the evidence: a secret reaching a network call, a private key read, a recursive delete at the root, piping curl to a shell, a security setting changed.
Context decides when the same action is fine or harmful depending on the task. Deleting a test file is a refactor in one session and hiding a failure in another. Editing CI config, adding a dependency, widening an IAM policy: all ordinary, all sometimes harmful.
A decision rule worth keeping: the session's intent should narrow what an agent may do, never widen it. A vague request like "fix the failing tests" should produce more questions, not more permissions.
Some cases are hard, and we'd rather say so:
- Harm by omission, where the agent does exactly what was asked.
- Fabricated reports.
- Low-bandwidth leaks, such as DNS or data hidden in requests to approved hosts.
- Laundered approval: the agent proposes what injected content wanted, a tired human clicks approve, and the attacker's instruction now carries your authority.
- An adaptive attacker who knows the rules.
Laundered approval works because human approval isn't the backstop people assume. Anthropic reports that users accept 93% of permission prompts anyway. In its 1,053-tester study, human review caught 13.6% of dangerous commands.
First controls, in order#
Ordered by confidence and cost:
- Make agent configuration and rules files read-only, and watch them for changes. It's the cheapest high-confidence control and it removes the re-infection path.
- Run agents in a sandbox with short-lived, narrowly scoped credentials and controlled network egress.
- Snapshot the workspace each turn, so in-workspace destruction becomes recoverable.
- Keep monitoring outside the agent's own privileges, so what's watched can't switch off the watcher.
- Gate the small set of irreversible external actions: publish, push to shared repos, deploy, pay, email externally.
- Treat CI and unattended sessions as the weak point, since trust prompts don't appear there.
- Budget human friction like latency, and measure how much agent-authored change actually gets reviewed.
Conventional engineering does most of the prevention. Action checks are a layer on top. For the built-in options, see permissions vs hooks vs sandbox.
Where Harden fits#
Harden Agentic Integrity Foundation (AIF) is that layer. It runs on the developer laptop, outside the agent, at the agent's pre-execution hook. Every command, file edit and push is checked against the session's intent before it runs.
Decisions are made locally, in milliseconds, under one policy across agents. Deterministic rules decide alone where the action is the evidence; a local model reviews the action in the context of the session and can only make a verdict stricter, never weaker.
It starts watch-only, so you see what agents do before you enforce. It's a layer, not a perimeter, and it doesn't replace least privilege, scoped credentials or egress policy. More at Harden for security teams.
FAQ
Related questions
How is this different from attack-technique models like STRIDE?
Harden's model is organized by harm to the business, such as data loss or an unrecallable publish, instead of by attack technique. That lets it cover harm with no attacker, like an agent faking a passing test.
Which harms can't be undone?
Outward supply-chain contamination (H6) and exercising the user's external authority (H11): publishing a package, pushing to a shared upstream, deploying, paying, or emailing a customer. Gate that small set first.
Can rules alone stop these threats?
Rules decide alone when the action is the evidence, like a secret reaching a network call. When the same action is fine in one task and harmful in another, you need the session's intent.
What should a security team do first?
Make agent config and rules files read-only, then run agents with scoped short-lived credentials and controlled egress. Add a pre-execution check on top, starting in watch-only mode.