3 minute read

Summary

Threat modeling an AI coding agent is not only about hallucinated code. The attack surface includes repository input, external content, tool authority, secrets, sandboxing, approvals, traces, and deployment boundaries.

Document Information

  • Written date: 2026-04-29
  • Verification date: 2026-04-29
  • Document type: analysis tutorial
  • Test environment: No live execution. This post is based on OpenAI Codex/Agents SDK documentation and OWASP LLM risk categories.
  • Test version: Related official documentation checked on 2026-04-29. No specific agent runtime version is fixed.
  • Evidence level: official documentation, security project documentation, NIST documentation

Problem Statement

A coding agent can read code, create patches, run tests, execute shell commands, interact with issues and pull requests, call MCP connectors, and prepare deployments. A web-application style threat model that only lists network endpoints is not enough. You need to model the boundary between data the agent reads and tools it can execute.

Verified Facts

Reproduction Steps

Start by listing assets and boundaries.

Area Question Example risk
Input Can the agent trust what it reads? prompt injection, poisoned issue, malicious README
Authority Which tools and credentials are available? excessive agency, secret access, destructive command
Execution Where do commands and tests run? sandbox escape, persistence, network egress
Changes Which files and branches can be modified? unauthorized patch, workflow tampering
External connections Does it reach GitHub, cloud, MCP, or package registries? data exfiltration, connector side effect
Records What is stored in traces and logs? missing audit trail, sensitive trace storage

An initial threat modeling pass can follow this order.

  1. Split task types: Q&A, code review, code edit, test execution, deployment preparation, incident response.
  2. Classify input origins: user request, repository files, issue/PR comments, web results, MCP resources, memory.
  3. Limit tool authority per task: read, write, shell, network, secret, and deploy are separate permissions.
  4. Put high-risk actions behind approval: writes outside the workspace, external sends, deploys, secret access, IAM changes.
  5. Set sandbox and network defaults: deny by default, approve when needed, allowlist where possible.
  6. Define trace fields: input source, tool call, approval, guardrail, verification, failure.
  7. Test abuse cases: malicious README, PR title injection, compromised dependency, secret exfiltration, test command manipulation.

Observations

  • Coding agent security depends more on operational boundaries than on model quality alone.
  • The same prompt injection has different impact on a read-only agent and an agent with deployment authority.
  • Threat models become actionable when they describe what this task may do, not what the agent can do in theory.

Interpretation

In my view, the main threat appears when natural-language input can drive execution authority. Prompt, tool, sandbox, approval, and trace should be designed as one harness boundary.

Opinion: the first threat model does not need a perfect diagram. Five concrete abuse cases mapped to current controls are more useful.

Limitations

  • Agent products differ in sandbox, approval, network, and MCP behavior.
  • This is an introductory threat model and does not measure exploitability of specific vulnerabilities.
  • Organization-specific legal, privacy, and security requirements must be added separately.

References

Change Log

  • 2026-04-29: Initial draft.
  • 2026-04-29: Added AI coding agent assets, trust boundaries, abuse cases, and official evidence.

댓글남기기

You may also enjoy