A Threat Model for Cloud Coding Agents

A cloud coding agent threat model should cover untrusted instructions, excessive permissions, secret exposure, supply-chain manipulation, unsafe code changes, and weak review:not only model behavior.

This guide focuses on the engineering decision behind cloud coding agent security: what to standardize, what to constrain, and what evidence a reviewer should expect before accepting the result.

The core decision

Map assets first: source code, credentials, customer data, build infrastructure, package trust, and deployment authority. Then trace inputs from issues, repository files, websites, dependencies, and tool responses. Any of those inputs can be wrong or intentionally hostile.

A workflow that holds up in review

Define boundaries around the sandbox, repository token, network proxy, tool APIs, artifact store, and merge pipeline. For each boundary, record prevention, detection, and recovery controls. Test abuse cases with canary secrets and deliberately malicious repository text in a safe environment.

The failure mode to design around

Security reviews often focus on whether the model follows instructions. The more durable question is what damage a compromised or confused agent could cause. Design the system so the answer is small, visible, and reversible.

Implementation checklist

Inventory assets and untrusted inputs.
Map every granted capability.
Test prompt injection and exfiltration paths.
Plan detection, revocation, and rollback.

Turn the checklist into operating controls

Inventory assets and untrusted inputs: name the owner, the evidence that proves it happened, and the condition that should stop the run.
Map every granted capability: name the owner, the evidence that proves it happened, and the condition that should stop the run.
Test prompt injection and exfiltration paths: name the owner, the evidence that proves it happened, and the condition that should stop the run.
Plan detection, revocation, and rollback: name the owner, the evidence that proves it happened, and the condition that should stop the run.

The list becomes useful when every item produces visible evidence. Store that evidence with the task or pull request rather than in a private chat. A future reviewer should be able to tell which repository revision was used, which permission profile applied, what stopped or failed, and who accepted the remaining risk. For cloud coding agent security, a short, complete record is more valuable than a long narrative that cannot be reproduced.

Move from one run to a repeatable practice

Test the control with a safe adversarial exercise before relying on it. Attempt an out-of-scope file edit, a denied network request, a fake instruction in repository content, and access to a canary credential. Confirm that prevention or detection produces an actionable event with a named owner. Retest after adding tools, integrations, or repositories because effective authority changes when capabilities are combined. Record accepted residual risk and its review date.

Before expanding the workflow, ask three review questions:

What evidence shows that inventory assets and untrusted inputs was satisfied, and would that evidence survive a rerun from the recorded commit?
What evidence shows that map every granted capability was satisfied, and would that evidence survive a rerun from the recorded commit?
What evidence shows that test prompt injection and exfiltration paths was satisfied, and would that evidence survive a rerun from the recorded commit?

Write the answers in the same place as the code review. That creates a compact decision record and lets the team compare later runs without relying on memory.

A practical acceptance test

Run the workflow from a clean checkout at a recorded commit. Give the agent only the documented task packet and the intended permission profile. Then ask a reviewer who did not launch the run to reproduce the important checks, explain the changed behavior, and identify the rollback path. The task passes only when the artifact, evidence, and repository state agree. Keep the failed examples as regression cases; they are more useful than a polished demo because they reveal where instructions, environment, permissions, or tests need improvement.

Primary references

Vendor features, limits, preview labels, and pricing can change. Recheck the linked first-party documentation for the current state before making a purchase or rollout decision.