Cloud Coding Agents: Runtime Architecture, Security, and Gates

TL;DR

A cloud coding agent is a remote software-execution system. The model is only one component. A production design must also control:

task -> policy -> per-run identity -> isolated workspace
-> tools and network -> branch-only changes -> acceptance evidence
-> human/policy decision -> teardown and retention

The pull request is a proposal, not proof that the task is correct. A secure system gives every run a bounded identity, treats repository and web content as untrusted, separates setup credentials from agent runtime secrets, restricts egress, defines acceptance gates before execution, and can cancel or recover without duplicating external side effects.

This article replaces product-era predictions and vendor adoption claims with the architecture a team can actually review.

Key Takeaways

• Cloud is a runtime location, not a trust property. Remote execution changes data, identity, network, and retention boundaries.
• The unit of isolation is the run. Each run needs a known base commit, environment image, policy, identity, branch, budget, and teardown state.
• Prompt injection becomes a systems risk. Issues, source files, package docs, test fixtures, tool results, and web pages are untrusted inputs.
• Evidence must be machine-verifiable. Logs and summaries help investigation; exit codes, signed commits, artifact hashes, and final-state checks support acceptance.
• Parallel agents multiply review and blast radius. Concurrency should be limited by merge conflict, budget, environment capacity, and reviewer throughput.

Define the Runtime Boundary First

A cloud agent platform has at least six planes:

A vendor may combine these planes internally, but an enterprise review should assess them separately.

The Run Lifecycle

1. Accept

Normalize the request into a RunSpec:

• repository and base commit;
• task text and trusted instruction sources;
• allowed file scope;
• permitted tools;
• network policy;
• secret classes;
• resource and time budgets;
• required acceptance gates;
• delivery target;
• retention class.

Reject a task before provisioning if its requested privileges exceed policy.

2. Provision

Create a dedicated environment from a pinned image or attested template. Record:

• image digest;
• CPU, memory, disk, and time limits;
• tenant and run ID;
• host isolation type;
• mounted volumes and cache provenance;
• initial policy version.

"Ephemeral VM" does not mean "no retained data." Transcripts, snapshots, build caches, artifacts, and provider logs may outlive the active machine. Review each retention path.

3. Bootstrap

Checkout the exact base commit and install dependencies under a separate setup policy.

Dependency installation executes third-party code. Treat it as part of the threat model:

• require lockfiles;
• pin registries and mirrors;
• verify checksums or signatures where available;
• block unreviewed lockfile changes when the task does not need them;
• do not inject runtime secrets during dependency installation;
• invalidate caches when provenance changes.

4. Execute

Run the agent with:

• bounded filesystem writes;
• command and tool policy;
• explicit network egress;
• per-run budgets;
• structured event capture;
• cancellation propagation.

Repository instructions are useful context, but a malicious source file can contain instructions too. Establish a trust order: platform policy and run spec outrank repository instructions; repository and external content never authorize new capabilities.

5. Verify

Acceptance gates run independently of the agent's own conclusion:

• required tests and linters;
• generated-file and lockfile policy;
• secret and dependency scans;
• changed-file allowlist;
• migration and API compatibility checks;
• deterministic final-state assertions;
• UI or runtime evidence where relevant.

The agent may attempt to fix a failed gate within budget, but it cannot mark the gate passed by explaining why it should pass.

6. Deliver

Push only to the assigned branch and open or update a review artifact. Protect the base branch with normal repository rules. The agent should not bypass:

• required reviewers;
• CI;
• signed-commit policy;
• deployment approvals;
• code-owner rules;
• environment protection.

7. Teardown

Revoke run credentials, stop processes, expire leases, preserve only approved evidence, and schedule workspace and snapshot deletion. Teardown should be observable and retryable.

Identity: One Run, One Bounded Principal

Do not copy a developer's long-lived credentials into the workspace.

Source-Control Identity

Prefer a Git application or broker that:

• can read only the selected repository;
• can push only to the run branch;
• cannot alter branch protection;
• cannot approve or merge its own change;
• attributes and signs agent commits;
• expires credentials with the run.

GitHub documents that its cloud agent works in an ephemeral Actions-powered environment and on one branch for a task. Anthropic documents a related pattern for hosted cloud sessions: short-lived session credentials, Git traffic through a proxy, and pushes restricted to the working branch. These are useful architectural reference points, not substitutes for verifying the exact plan and configuration you deploy.

Cloud and Internal-Service Identity

Use workload federation where possible:

run attestation -> OIDC token -> cloud role exchange
-> short-lived, audience-scoped credential

Bind authorization to:

• organization and repository;
• run ID;
• environment;
• allowed action;
• expiration;
• audience;
• optional resource tags.

A leaked token should be unusable outside that narrow context.

Secrets: Separate Build, Runtime, and Model Visibility

Classify secrets by exposure:

Redaction is defense in depth, not containment. A process can transform or exfiltrate a secret without printing the literal value. Prefer a proxy that performs the authorized operation without placing the raw credential in the VM or model context.

Never place production secrets in:

• prompts;
• repository files;
• generated .env files committed to Git;
• unrestricted shell history;
• demo artifacts;
• agent summaries.

Network Egress Is an Authorization Surface

An internet-connected agent can exfiltrate code through a normal-looking request. An allowlist reduces reach but still grants every allowed destination a data path.

Policy Modes

OpenAI describes managed network policy with allowed, denied, and approval-required destinations. Cursor documents configurable egress controls and explicitly identifies prompt-injection exfiltration as a cloud-agent risk. Anthropic documents cloud sessions with network access limited by default and configurable domain allowlists.

Controls Beyond Domain Names

• resolve through a controlled proxy;
• prevent direct IP and alternative-protocol bypass;
• consider DNS rebinding and redirects;
• separate read-only documentation from write-capable APIs;
• cap request size and rate;
• record destination, decision, tool, and run ID;
• scan or classify outbound payloads where appropriate;
• deny metadata services and internal control planes.

Package registries deserve special treatment because downloaded packages execute code.

Prompt Injection: Treat Context as Data

Potential injection sources include:

• issue and pull-request descriptions;
• repository documentation and comments;
• test fixtures;
• package README and install scripts;
• webpages and search results;
• compiler errors and tool output;
• MCP or plugin responses.

Controls should be structural:

1. capabilities come only from policy, never from content;
2. untrusted text is delimited and labeled;
3. high-risk tools require a separate authorization decision;
4. egress and secret access remain constrained after injection;
5. protected files and branch settings cannot be changed;
6. suspicious sequences generate evidence and stop or escalate.

Prompt filtering cannot be the only defense. Assume some injections will be interpreted and limit what they can accomplish.

Go Example: Validate a Run Policy Before Provisioning

This standard-library example rejects broad network access, unscoped writes, missing verification, and self-merge. A production policy engine would also evaluate organization, repository sensitivity, task class, and signed policy bundles.

package main

import (
	"errors"
	"fmt"
	"path/filepath"
	"strings"
	"time"
)

type RunSpec struct {
	Repository       string
	BaseCommit       string
	Branch           string
	WritableRoots    []string
	AllowedDomains   []string
	RequiredChecks   []string
	MaxDuration      time.Duration
	CanMerge         bool
	ProductionSecret bool
}

func Validate(spec RunSpec) error {
	if spec.Repository == "" || spec.BaseCommit == "" || spec.Branch == "" {
		return errors.New("repository, base commit, and branch are required")
	}
	if spec.CanMerge {
		return errors.New("agent runs cannot merge their own changes")
	}
	if spec.ProductionSecret {
		return errors.New("production secrets are not allowed")
	}
	if spec.MaxDuration <= 0 || spec.MaxDuration > 2*time.Hour {
		return errors.New("run duration is outside policy")
	}
	if len(spec.WritableRoots) == 0 || len(spec.RequiredChecks) == 0 {
		return errors.New("write scope and required checks must be explicit")
	}
	for _, root := range spec.WritableRoots {
		clean := filepath.Clean(root)
		if clean == "." || clean == "/" || strings.HasPrefix(clean, "..") {
			return fmt.Errorf("unsafe writable root %q", root)
		}
	}
	for _, domain := range spec.AllowedDomains {
		if domain == "*" || strings.HasPrefix(domain, "*.") {
			return fmt.Errorf("wildcard domain %q is not allowed", domain)
		}
	}
	return nil
}

func main() {
	spec := RunSpec{
		Repository:     "org/service",
		BaseCommit:     "4d2f7c1",
		Branch:         "agent/run-42",
		WritableRoots:  []string{"internal", "tests"},
		AllowedDomains: []string{"proxy.example.test"},
		RequiredChecks: []string{"go test ./...", "go vet ./..."},
		MaxDuration:    45 * time.Minute,
	}
	fmt.Println(Validate(spec))
}

Runtime enforcement must match this validation. A field in a run spec is not a security control unless the filesystem, proxy, credential broker, and Git provider enforce it.

Acceptance Evidence, Not Agent Self-Reporting

Evidence Bundle

Each run should return:

run_id
task_hash and trusted instruction versions
policy_version
environment_image_digest
base_commit and final_commit
credential issuances and revocations
commands, timestamps, and exit codes
network allow/deny/approval decisions
changed files and diff hash
tests, scans, and final-state checks
artifact URIs and hashes
unresolved failures and degraded states
branch and pull-request identity
teardown status

Protect integrity with append-only storage, signed statements, or platform audit controls appropriate to the threat model.

Evidence Hierarchy

No single row proves overall correctness. Use a bundle matched to the task risk.

Cancellation, Timeout, and Recovery

Remote runs fail: providers time out, a VM disappears, a test hangs, the base branch advances, or a human cancels the task.

Required Semantics

• cancellation propagates to child processes and tool calls;
• credentials are revoked even if teardown partially fails;
• leases and budgets expire server-side;
• checkpoints distinguish safe replay from external side effects;
• a resumed run records a new execution attempt;
• stale base commits trigger rebase or restart policy;
• duplicate delivery cannot create two branches or external changes;
• partial artifacts are marked incomplete, not passed.

Do not automatically retry a step that sent a message, changed a database, published a package, or modified cloud infrastructure unless the operation has an idempotency key and verified state.

Task Selection and Autonomy Levels

Autonomy should depend on risk and verifiability, not on how confident the model sounds.

Operating Metrics

Adoption and pull-request count do not establish value. Measure:

• accepted tasks per eligible task;
• first-pass gate rate;
• human correction time;
• escaped defect and rollback rate;
• p50/p95 runtime and queue time;
• compute, model, and environment cost per accepted change;
• cancellation and infrastructure failure rate;
• prompt-injection and policy-denial events;
• reviewer backlog and time to accountable approval;
• percentage of runs with complete evidence and teardown.

Compare against the previous workflow for the same task class. More generated pull requests can reduce throughput if review demand or defect risk rises.

Release Checklist

1. Every run has immutable scope, base commit, policy, and budget.
2. Workspace isolation and retained snapshots are documented.
3. Git and cloud identities are short-lived and run-scoped.
4. Production credentials are absent by default.
5. Egress is disabled or explicitly allowlisted and logged.
6. Repository and external content cannot grant capabilities.
7. Protected files, branch rules, and merge controls are enforced externally.
8. Acceptance gates run outside the agent's self-assessment.
9. Cancellation, stale base, duplicate task, and teardown failures are tested.
10. Evidence retention and deletion match repository sensitivity.
11. A human or accountable policy owner approves high-risk changes.
12. Metrics compare accepted outcomes, not generated activity.

FAQ

Are cloud agents safer than local agents?

They have a different risk profile. Per-run isolation and egress policy can be stronger than a developer laptop, while cloud storage, unattended execution, and remote credentials add new risks. Compare the actual controls.

Is a draft pull request an adequate human-in-the-loop control?

Only when branch protection, required checks, reviewers, and deployment approvals cannot be bypassed. A draft label alone is presentation state.

Should agents access the internet?

Only where task value justifies the path. Prefer no network, trusted caches, or strict allowlists; separate dependency access from arbitrary browsing.

Can secret redaction prevent exfiltration?

No. Redaction prevents some literal values from appearing in logs or model context. It cannot stop a process from using, transforming, or sending a credential. Minimize issuance and use brokers.

How many cloud agents should run in parallel?

Set concurrency from environment budgets, conflict domains, reviewer capacity, and task independence. Unlimited parallelism creates queues, conflicting branches, and unreviewable output.

Primary Sources

• OpenAI, Running Codex Safely at OpenAI — sandbox boundaries, approvals, managed egress, credential storage, rules, and agent-aware telemetry.
• GitHub, About GitHub Copilot Cloud Agent — ephemeral Actions-powered environment, branch-based work, customization, limitations, and PR outcome metrics.
• Cursor, Cloud Agents Security Overview — documented lifecycle, per-agent isolation, identity, retention, egress, secrets, prompt-injection controls, and auditability.
• Anthropic, Claude Code Security — permission architecture, prompt-injection defenses, sandboxing, and hosted cloud-session identity and branch restrictions.
• AI Code Review Automation Pipeline — evidence-based review gates after code generation.

Related Learning Path

• How to Build AI Agents — the control loop, tools, state, and evaluation beneath coding agents.
• Multi-Agent Systems — coordination and failure boundaries when several runs cooperate.
• Model Context Protocol — tool transport that still requires application authorization.
• Context Engineering — trusted instructions, repository context, and evidence selection.

Summary

Cloud coding agents are useful when a task is bounded, an environment is reproducible, acceptance is objective, and output remains a reversible branch proposal. Their value does not come from removing humans; it comes from moving execution into a controlled, observable runtime while preserving accountable approval.

Design the identity, egress, secrets, branch restrictions, evidence, cancellation, and teardown before increasing autonomy. Without those controls, "background execution" is merely unattended code execution with a persuasive interface.