Threat model for agent workflows

Before you can protect against risks, you need to know what they are. This section maps out the five main threat categories in agent-assisted development. None of these threats are hypothetical — they emerge from the same capabilities that make agents useful: reading files, running commands, modifying code, and interacting with external services.

Understanding the threat model is not about scaring yourself out of using agents. It is about identifying which risks apply to your workflow so you can apply targeted mitigations covered in the rest of this module.

flowchart TB
    A[Agent Capabilities]:::primary --> B[Read files\nRun commands]:::neutral
    A --> C[Modify code\nAccess network]:::neutral
    B --> D[Unintended\nmodifications]:::warning
    B --> E[Credential\nexposure]:::warning
    C --> F[Destructive\noperations]:::danger
    C --> G[Prompt\ninjection]:::danger
    A --> H[Install packages\nAdd dependencies]:::neutral
    H --> I[Supply chain\nrisks]:::warning

    classDef primary fill:#dbeafe,stroke:#2563eb,color:#000
    classDef warning fill:#fef3c7,stroke:#d97706,color:#000
    classDef danger fill:#fee2e2,stroke:#dc2626,color:#000
    classDef neutral fill:#f3f4f6,stroke:#6b7280,color:#000

Diagram showing the five threat categories in agent-assisted development: the agent’s core capabilities (reading files, running commands, modifying code, accessing the network, and installing packages) give rise to five categories of risk — unintended modifications, credential exposure, destructive operations, prompt injection, and supply chain risks.

Unintended modifications

The most common risk is also the most mundane: the agent modifies code in ways you did not intend. Unlike a human developer who can recognize when a change has gone off track, an agent executes instructions literally and keeps going.

How it happens

Scope creep in modifications. You ask the agent to fix a bug in one function, and it refactors three other files “while it was at it.” The refactoring introduces subtle behavioral changes that your tests do not catch.
Misinterpreted instructions. You ask the agent to “clean up the user model” and it deletes fields it considers unused — including one that an external service depends on.
Pattern propagation. The agent copies an incorrect pattern from one part of the codebase to another. If you have a bug in a utility function, the agent may replicate that bug when creating similar utilities.
Conflicting context. Two context files give contradictory instructions (one says “use camelCase,” another says “use snake_case”), and the agent picks one without warning you.

Impact

Unintended modifications range from minor annoyances (extra whitespace changes mixed into a feature branch) to serious issues (data model changes that break production). The risk increases with the scope of the task you delegate.

Mitigation at a glance

Keep delegated tasks small and well-scoped
Always review diffs before committing (see code review practices)
Use git branches so changes are isolated and reversible
Set clear boundaries in your prompts: “Only modify src/auth/login.ts. Do not change any other files.”

Credential exposure

AI coding agents operate within your development environment, which means they can access the same secrets you can: API keys, database passwords, authentication tokens, and private keys. The risk is not that the agent deliberately steals your credentials — it is that the agent inadvertently includes them in output that ends up somewhere it should not.

How it happens

Hard-coded secrets. The agent reads a .env file to understand your configuration and then hard-codes a secret value into a source file or context file instead of referencing the environment variable.
Secrets in context files. You copy a configuration example with real credentials into your CLAUDE.md or AGENTS.md, and the agent reads and references those credentials in subsequent output.
Secrets in output. The agent generates configuration snippets, docker-compose files, or CI/CD pipelines that include placeholder values filled in with real secrets from your environment.
Secrets in prompts. You paste an error message that contains a connection string with embedded credentials, and the agent processes and repeats it.
Commit leakage. The agent commits code containing a secret to version control. Even if you remove it in a subsequent commit, the secret remains in git history.

Impact

Credential exposure can lead to unauthorized access to your systems, data breaches, and significant remediation effort (rotating keys, auditing access logs, checking for unauthorized use). The impact scales with the privilege level of the exposed credential.

Mitigation at a glance

Never put real secrets in context files or prompts
Use .gitignore to exclude files that contain secrets (.env, credentials.json)
Audit agent output for accidental secret inclusion before committing
Use secret managers instead of environment variables for sensitive credentials
Rotate any credential that may have been exposed, even if you are not sure

See credential management for detailed practices.

Destructive operations

Agents can run shell commands, and some commands are irreversible. A rm -rf on the wrong directory, a DROP TABLE on a production database, or a git push --force to main can cause damage that is expensive or impossible to recover from.

How it happens

Overly broad commands. The agent runs rm -rf ./build to clean a build directory, but the working directory is not what it expected, and the command removes something else entirely.
Missing safeguards. The agent generates a database migration that drops a column. In development, this is fine. In production, it deletes data permanently.
Cascading failures. The agent encounters an error and tries to fix it by running increasingly aggressive commands — resetting git state, reinstalling packages, deleting caches — each of which can cause its own problems.
Misunderstood environment. The agent does not distinguish between development and production environments. A command that is safe locally (docker-compose down -v) might be catastrophic if run against the wrong target.

Impact

Destructive operations can cause data loss, service outages, corrupted repositories, or irreversible state changes. The impact depends on what environment the agent has access to and whether backups exist.

Mitigation at a glance

Never give agents direct access to production environments
Use sandboxed execution environments (see permissions and sandboxing)
Require confirmation for destructive commands when your tool supports it
Work on branches, not directly on main
Maintain regular backups of critical data and repositories

Prompt injection

Prompt injection occurs when untrusted input manipulates the agent’s behavior. If the agent reads content that contains hidden instructions — from a file, a web page, a pull request description, or an MCP server response — those instructions can override your intent.

How it happens

Malicious content in code. A file the agent reads contains a comment like . Depending on the agent’s instruction hierarchy, this could influence its behavior.
Untrusted PR descriptions. The agent reviews a pull request whose description includes injected instructions designed to make the agent approve the PR or introduce additional changes.
Compromised MCP server responses. An MCP server returns data that includes prompt injection payloads, attempting to redirect the agent’s actions.
Web content. If the agent has web browsing capabilities, a page it visits could contain hidden instructions targeting AI agents.

flowchart LR
    A[Untrusted input]:::danger --> B[Agent context]:::neutral
    C[Your instructions]:::primary --> B
    B --> D{Agent decides}:::secondary
    D --> E[Intended action]:::success
    D --> F[Manipulated action]:::danger

    classDef primary fill:#dbeafe,stroke:#2563eb,color:#000
    classDef secondary fill:#f3e8ff,stroke:#7c3aed,color:#000
    classDef success fill:#dcfce7,stroke:#16a34a,color:#000
    classDef danger fill:#fee2e2,stroke:#dc2626,color:#000
    classDef neutral fill:#f3f4f6,stroke:#6b7280,color:#000

Diagram showing how untrusted input can enter the agent’s context alongside your instructions, potentially influencing the agent’s actions.

Impact

Prompt injection can cause the agent to execute unintended actions with your permissions: modifying files, running commands, exfiltrating data, or approving malicious changes. The severity depends on what the agent has access to and what the injected instructions attempt.

Mitigation at a glance

Treat all external input as untrusted — files from unknown sources, web content, PR descriptions from external contributors
Use permission models that limit what the agent can do regardless of what it is told to do (see permissions and sandboxing)
Review agent actions on untrusted content more carefully than usual
Prefer agents that implement instruction hierarchy (system prompts override user prompts, which override content in files)

Supply chain risks

When agents generate code, they may introduce dependencies, reference packages, or suggest tools that you have not vetted. This creates supply chain risk similar to what you face when a human developer adds a new dependency — but faster, because the agent does not pause to evaluate the trustworthiness of a package before recommending it.

How it happens

Hallucinated packages. The agent suggests installing a package that does not exist. If an attacker has published a package with that exact name (a technique called typosquatting or package confusion), you could install malicious code.
Outdated or vulnerable dependencies. The agent recommends a package version it learned about during training, which may have known vulnerabilities in the current version.
Unnecessary dependencies. The agent adds a dependency for functionality that already exists in your project or the standard library, expanding your attack surface unnecessarily.
Unvetted tools. The agent suggests installing a CLI tool or MCP server that you have not evaluated for security, and you install it because the agent recommended it.

Impact

Supply chain attacks can introduce backdoors, data exfiltration, or cryptominers into your project. The impact ranges from minor (an unnecessary but benign dependency) to critical (a compromised package that steals credentials).

Mitigation at a glance

Verify that every package the agent suggests actually exists and is maintained before installing it
Check package names carefully for typosquatting (e.g., lod-ash instead of lodash)
Use lockfiles (package-lock.json, uv.lock) to pin dependency versions
Run security audits on dependencies (npm audit, pip-audit)
Question whether a new dependency is actually necessary — the agent defaults to adding packages rather than using what is already available

Threat severity summary

Not all threats carry equal weight. Here is how they compare in a typical development workflow:

Threat	Likelihood	Typical impact	Your priority
Unintended modifications	High	Low to medium	Mitigate first — happens on almost every task
Credential exposure	Medium	High	Prevent proactively — hard to undo once exposed
Destructive operations	Low	Very high	Guard against — rare but catastrophic
Prompt injection	Low	Medium to high	Be aware — threat is real but evolving defenses exist
Supply chain risks	Medium	Medium to high	Verify always — same diligence as any dependency decision

The rest of this module covers the specific practices and tools that address each of these threats.