Agentic Threat Modeling for Remote Execution Environments

Remote execution environments require a different threat model for AI coding agents because attacker-controlled language can become executable action. Securing them requires more than a sandbox. Prompt boundaries, tool trust, session credentials, inter-agent authority, runtime visibility, and spending limits must form one governance architecture that constrains what a compromised agent can do.

Why the standard threat model breaks when agents execute code remotely

Moving an agent from a developer’s laptop into a remote execution environment changes both the trust boundaries and the location of compute. Traditional application security models assume a separation between code and data, and between the target system and the attacker’s control plane. Remote agents undermine both assumptions because the content they consume can direct the actions they execute. Microsoft’s 2026 research treats this shift as a risk in what models execute once they connect to tools, as well as in the content they produce.

The recursive execution loop makes that distinction consequential. An action produces new context, which produces another action, with each iteration introducing a trust decision that may receive no human review. The same environment can hold private source code and cloud credentials, consume untrusted packages or web pages, and communicate externally through network requests or git push. The Five Eyes joint guidance says these systems add to inherited LLM risks through a larger attack surface, more complexity, and a security landscape that keeps changing. The resulting threat map starts with prompt injection, then follows tool poisoning, credential exposure, and orchestrator hijack before addressing the controls and Denial of Wallet risk that complete it.

Prompt injection as a code execution primitive, not a content problem

Prompt injection can lead to remote code execution when the agent can turn attacker-controlled text into a code-execution tool call. The model need not malfunction for that route to work. It may parse language into tool schemas exactly as designed, while the framework trusts the resulting data enough to execute it. The vulnerability therefore sits at the boundary where interpreted content acquires authority over the host.

Indirect prompt injection makes that boundary harder to defend because the attacker need not control the user’s request. A webpage, third-party package, GitHub issue, or API response can carry instructions into the agent’s reasoning loop. The agent retrieves that material as part of legitimate work and brings the payload into its own execution environment. Once the instructions reach an execution path, the attack can extend to whatever the sandbox permits. The attack can then target tool calls, credentials, and orchestrator messages, each with its own trust boundary.

The practical control is input/output boundary enforcement at the framework layer. Data from external sources must be treated as untrusted, and its content must be sanitized before it enters the reasoning loop. Gateway controls must also block prompt patterns that reach code-execution paths before they reach the model. These controls address the entry point, but they do not replace controls on the resources an injected agent could reach.

Tool poisoning and supply-chain risk in the agent's execution pipeline

Every tool call crosses its own trust boundary, even when it follows a valid instruction from the user. MCP servers, third-party APIs, package registries, and LoRA adapters each introduce their own supply-chain risk. A remote agent may interact with dozens of tools during a session, compounding that exposure. Authentication and scope therefore belong to each integration.

A compromised tool, malicious MCP server, or backdoored adapter can insert attacker-controlled behavior into the execution pipeline. The agent calls the tool in good faith, then acts on instructions returned by it. A remote tool can also change after its original review, so deployment-time approval does not establish what the agent will encounter six weeks later.

MATRA, by Van hamme et al., starts with an asset-based impact assessment to show how known threat classes put a given deployment at risk. That approach asks what a particular compromised tool could reach. Tool allowlisting must restrict agents to pre-approved, versioned tools, while session-level logging makes each invocation attributable. Tool descriptions also require verification because text that developers regard as metadata can function as instructions for the model.

Credential exposure in sandboxed environments and the least-privilege failure mode

Credential exposure follows from a common provisioning model. Agents get broad access once, then use the same standing set of credentials for different tasks. Cloud API keys, database passwords, SSH keys, and environment files can thus give an agent more access than any one task needs. The Five Eyes joint guidance treats privilege risk as a separate class and calls for access to be limited to what the current task needs.

A compromised agent can extract credentials from environment variables, mounted secret stores, or instance metadata endpoints. Those credentials may then give the attacker persistent access beyond the session and beyond the sandbox. Isolation around a process does not, by itself, constrain the authority of a credential copied out of that process. The credential’s scope and lifetime determine how far that access can extend.

The appropriate model mints credentials fresh for each session, scopes them to its tasks, and revokes them automatically when the session ends. This takes the place of long-lived credentials mounted into shared environments. The Five Eyes guidance also recommends that credentials not be shared across agent sessions. Least privilege must therefore be a property of each execution, rather than a broad permission set assigned to an agent at deployment.

Orchestrator hijack and cross-agent privilege escalation in multi-agent pipelines

Multi-agent pipelines create an authority boundary that does not exist in a single-agent deployment. A low-privilege sub-agent can pass manipulated output to a high-privilege orchestrator, which may act on it using broader access. This escalation requires no defect in the underlying model. It requires only that the orchestrator treat another agent’s output as trusted direction.

The Tennessee Tech / Purdue / Nebraska survey identifies agent collusion, cascading failures, oversight evasion, and memory poisoning as systemic risks. In the most dangerous form of orchestrator hijack, a compromised agent becomes a persistent command-and-control node, relaying attacker instructions through legitimate LLM interactions. Inter-agent messages still look like normal messages about tasks. Network monitoring sees calls to the same LLM endpoint, without a packet-level signature that distinguishes legitimate orchestration from attacker-controlled instructions.

Cryptographic signing of inter-agent messages establishes identity so that a sub-agent cannot forge an orchestrator instruction. Strict output validation checks whether a result from a genuine sub-agent is safe for the orchestrator to act on. Inter-agent communication must also meet the same audit requirements as requests from users. The Five Eyes guidance names cascading failures, agent spawning, and delegation as concerns for how systems are built and who is accountable, and calls for unified audit logs and cryptographic identity alongside monitoring.

Sandbox isolation as a security primitive, not a deployment convenience

The sandbox’s isolation primitive determines what a fully compromised agent session can access. A container namespace, user-space kernel, and hardware-level microVM are therefore distinct security choices. Treating isolation only as infrastructure leaves that blast radius outside the threat model.

The sandbox must break at least one part of the dangerous combination of private data access, untrusted content exposure, and external communication. Ideally, it constrains more than one, so that compromise does not give the agent all three capabilities simultaneously. For multi-tenant or regulated environments running agent-generated code, the required controls must work together and include hardware-enforced tenant isolation, least-privilege permissions per agent, data residency enforcement, immutable audit trails, and resource quotas.

The OWASP Agent Control Standard requires production agents to be inspectable, traceable, instrumentable, and subject to runtime policy enforcement. Those properties must shape sandbox design from the outset. Isolation defines the reach of a compromised session, while instrumentation and enforcement make that boundary governable during execution. A sandbox that cannot support those controls is incomplete as a security primitive, regardless of its usefulness as a place to run code.

Observability gaps that turn audit trails into crime scenes rather than guardrails

Prompt logs cannot show whether a child process opened a socket, read a secret mount, or used up memory. A record limited to model inputs and outputs therefore misses effects that matter to both investigation and containment. The Tennessee Tech / Purdue survey identifies oversight evasion as a systemic risk. Consequential actions that never appear in the audit trail have escaped governance, even if deployment policies nominally prohibited them.

Adequate observability must establish what information can influence the agent, what it can access, what actions it can perform, under whose authority it acts, and what prevents influence from becoming damage. A logging architecture that cannot answer those questions after the fact cannot support runtime enforcement. Every tool call, diff, and token must be logged and attributable to a person or trigger. Session-level outcomes are too coarse because the granularity of the record determines the granularity of the investigation.

Auditability and debuggability use that evidence differently. Auditability records actions with the context, policies, and data assets that governed them, supporting SOC 2, HIPAA, and regulatory assessments. Debuggability traces failures to the decision, tool call, or data access that caused them. The Five Eyes guidance distinguishes accountability risks, such as opaque decisions and unreconstructable actions, from runtime enforcement under privilege and design controls. Both must be part of the design, but an audit trail on its own does not stop execution.

Denial of Wallet as a denial-of-service attack class specific to agent billing models

An attacker can disrupt an agent service by exhausting its spending limits without compromising the model. Queries that use a lot of resources can make the service do billable work over and over until it hits a hard spending limit. The Tennessee Tech / Purdue survey names this cost-amplification denial of service as a threat vector in its own right. Token budget exhaustion therefore belongs in security threat modeling as well as financial reporting.

Remote execution magnifies the exposure because agents make far more API calls per task than chatbots or single-inference systems. Each billable call gives an attacker-triggered invocation more room to accumulate cost. Asynchronous monitoring records that spending only after it happens. Enforcement instead evaluates execution against a budget ceiling before the next API call and terminates the session before that call goes out.

Resource quotas require layered enforcement, including token budget limits, model-call limits, tool-call limits, retry budgets, and hard dollar caps. Graceful termination is necessary when the remaining budget cannot finish the task safely. Tool-call limits must also set a ceiling for each tool type. A web search and a database write carry different risks, and a shared limit gives attackers the wrong budget to exhaust. The control is an execution boundary.

A governance architecture that addresses all five attack surfaces together

The five attack surfaces require a coordinated control set. Sandbox isolation without per-session credentials leaves authority that can outlive containment, while budget caps without tool-call logging leave constrained but unattributable activity. MATRA’s asset-based methodology provides the organizing principle. Start with the deployment’s assets, determine the blast radius of each compromise, and assess whether the controls cover the highest-impact paths.

YAML-defined agents checked into the repository can expose credential scope, tool allowlists, budget caps, and sandbox parameters to the same review gates as application code. The Five Eyes guidance spans designing, developing, deploying, and operating agents securely. Configuration review establishes the intended policy, but ongoing operational enforcement is what keeps it effective after deployment.

The OWASP Agent Control Standard’s requirements connect that policy to execution through inspectable isolation, traceable tool calls, OS-effect instrumentation, and runtime controls such as budget enforcement and credential revocation. The Tennessee Tech / Purdue survey explains why frameworks designed for non-autonomous, short-lived systems do not fully model long-running agent pipelines. Established security practice must extend to the boundaries these systems introduce.