ARES: Securing Agents for Computer Use Through Endpoint Resource Mediation and Behavioral Guardrails

1. Introduction

LLM-based systems are moving beyond response generation toward autonomous task execution. Agents can now plan, invoke tools, browse the web, manipulate files, operate desktop applications, and delegate work to other agents. Agents for computer use (ACUs) make this transition particularly consequential because model decisions are translated into endpoint actions such as file reads, network requests, application launches, and GUI operations [1].

This capability changes the security question. In conversational systems, safety controls primarily ask whether a prompt or model output violates policy. In ACU environments, security must also determine whether a specific action is authorized for the current task, whether the requested resource is sensitive, whether the destination is trusted, and whether the action was influenced by untrusted content. An indirect prompt injection embedded in a document or webpage can therefore become an endpoint compromise path when the agent converts the injected instruction into a tool call [2]. In multi-agent workflows, the risk is amplified because tainted instructions can propagate through messages or shared context before being executed by a downstream agent with different privileges [3].

Current defenses address parts of this problem. Prompt and output filters operate at the language layer; agent guardrails inspect plans or responses; capability and privilege systems restrict available tools; execution-isolation mechanisms reduce cross-context interference; and enterprise controls monitor endpoint or network behavior. However, these mechanisms do not consistently provide a single enforcement loop that mediates endpoint resources, evaluates actions against task context, and preserves provenance across agent boundaries. As a result, an action may appear syntactically valid and use an approved tool while still being inappropriate for the task or derived from untrusted context [4].

We address this gap with ARES (Agent Resource Enforcement and Security), an action-centric endpoint security framework for ACUs and ACU-enabled multi-agent systems. ARES is based on a simple principle: agents should not directly access protected endpoint resources. Instead, security-relevant requests are intercepted, normalized, enriched with provenance, evaluated before execution, and then allowed, blocked, delegated for approval, or logged. The framework integrates three components: the Resource Proxy Layer (RPL), the Behavioral Guardrail Engine (BGE), and the Multi-Agent Trust Boundary Manager (MATBM).

To evaluate the feasibility of this design, we implement ARES-lite, a proof-of-concept prototype that mediates LLM-generated file and network tool calls, applies deterministic task-aware policies, tracks lightweight provenance and taint metadata, and produces structured audit records. The prototype is evaluated in a controlled synthetic workspace using attack and benign scenarios. No production data, real credentials, external exfiltration, command execution, or internal-network scanning are used.

The contributions of this study are fourfold:

• We reformulate ACU security as an action-centric endpoint mediation problem rather than only a prompt-detection problem.
• We present an integrated architecture that combines resource-specific interception, pre-execution behavioral authorization, and multi-agent provenance management.
• We implement ARES-lite and define a reproducible tool-call, decision, and audit schema for controlled experimentation.
• We evaluate the architecture through representative attack scenarios, ablation analysis, benign-task assessment, and runtime-overhead measurement.

The remainder of the paper is organized as follows. Section 2 defines the scope and positions ARES relative to existing defenses. Section 3 presents research design, threat model, ARES architecture, prototype, and evaluation methodology. Section 4 reports the experimental results. Section 5 discusses the implications, limitations, and future directions. Section 6 concludes the paper.

2. Background and Related Work

2.1. Scope and Terminology

This paper distinguishes agent categories by the actions they can perform rather than by product labels (see Table 1 and Figure 1). LLM-based conversational systems primarily generate text. Conversational AI agents add goals, memory, and tool use. Web agents interact with websites and browser interfaces [5,6,7,8]. ACUs extend these capabilities to desktop and operating system (OS) resources, including files, processes, networks, local applications, and GUIs [1,9,10]. Multi-agent systems coordinate multiple specialized agents through messages, shared memory, tools, or orchestration, which introduce provenance and delegation risks [11,12]. These categories can overlap; the focus of ARES is the point at which an agent-generated request can affect endpoint state or cross an inter-agent trust boundary.

2.2. Agent-Specific Threats

Agentic systems convert language-level manipulation into action-level consequences [13]. Direct and indirect prompt injections can trigger file access, network transmission, GUI manipulation, or tool chaining [2,14]. Prompt infection propagates malicious instructions across interconnected agents through intermediate outputs or delegated tasks [3,15]. Excessive agency grants agents broader permissions or resource access than required for a task, allowing compromised reasoning or malicious instructions to affect a wider range of endpoint resources [15].

Related threats further expand the attack surface of agentic systems. Multi-agent workflows introduce confused deputy and privilege-escalation paths when low-authority agents influence downstream executors [16,17]. Persistent memory or shared context may also be poisoned to influence future reasoning and tool use across multiple tasks [18]. In addition, malicious tool servers, protocol integration, or deceptive GUI environments may induce unsafe tool execution or unintended endpoint operations [19,20,21].

Collectively, these threats illustrate different ways in which untrusted context can be translated into security-relevant endpoint actions. ARES primarily evaluates indirect prompt injection, prompt infection, and excessive agency, while partially addressing privilege delegation and memory poisoning through provenance tracking. Tool abuse and environment manipulation are included to position ARES within the broader threat landscape. Table 2 summarizes these threats together with the corresponding ARES control points and evaluation coverage.

2.3. Existing Defenses and Research Gap

Existing defenses for agentic systems can be categorized according to where they enforce security across the agent decision-and-action workflow. Prompt and output filtering methods, such as PromptShield [22], detect prompt-injection attempts or unsafe language at the model-input and output layers, but they do not directly authorize or mediate the endpoint actions subsequently generated by an agent. NeMo Guardrails and related frameworks provide programmable controls at the dialogue or application layer [23]. GuardAgent and LlamaFirewall extend runtime governance to planning, prompt-injection detection, alignment, and code-risk analysis [24,25]. CaMeL separates trusted control flow from untrusted data and applies capability constraints [26]; Progent provides programmable privilege control over tool calls [27]; and IsolateGPT reduces cross-context interference through execution isolation [28]. AgentDojo provides an evaluation environment for prompt-injection attacks and defenses [29]. AgentSentinel and CSAgent move closer to ACU security by monitoring sensitive operations or enforcing context-aware access control [30,31]. Traditional enterprise endpoint defenses, including EDR, DLP, firewalls, and secure web gateways, provide behavioral detection, data-loss prevention, network control, and incident response. Representative systems and frameworks such as Microsoft Defender for Endpoint and MITRE D3FEND remain valuable, but they generally lack agent-specific context, including task intent, instruction provenance, taint state, and delegation history.

Although these defenses improve different stages of the agent execution workflow, they remain largely layer-specific. Existing approaches typically protect prompts, planning, tool invocation, or endpoint monitoring in isolation, but rarely provide a unified mechanism that continuously mediates endpoint-facing actions while preserving provenance across multi-agent delegation (see Table 3). The resulting research gap is a unified mechanism that (i) intercepts endpoint-facing actions before execution, (ii) authorizes each action using task scope and endpoint resource context, and (iii) preserves provenance and taint information across multi-agent delegation. Rather than replacing existing prompt, privilege, isolation, or enterprise defenses, ARES complements them by introducing a unified endpoint-centric authorization loop that bridges these previously disconnected protection layers.

3. Research Methodology and System Design

This study follows a design science research methodology because its objective is to construct and evaluate a security artifact for a practical information system problem [32,33]. The artifact is ARES, an action-centric endpoint security architecture, together with ARES-lite, its proof-of-concept implementation. The research process comprised five stages: (i) identifying the gap between prompt-centric controls and endpoint-facing actions; (ii) defining the target environment, protected assets, and trust boundaries; (iii) deriving security requirements from representative attack paths; (iv) designing ARES and implementing the ARES-lite prototype; and (v) evaluating the prototype through security, usability, component ablation, and performance analyses.

3.1. Threat Model and Security Requirements

The threat model follows established threat-modeling practice [34] and focuses on agent-mediated misuse of legitimate agent capabilities rather than the direct compromise of the underlying host. The OS, LLM provider, and experiment host are assumed to operate as intended. An adversary may influence the managed workflow through user prompts, documents, webpages, retrieved content, tool outputs, shared memory, or inter-agent messages. Kernel exploitation, model-weight compromise, malicious insiders, and supply-chain compromise of the host platform are outside the scope of this study.

Three trust-boundary crossings are security-critical: (i) untrusted content entering the managed agent workflow; (ii) messages or context moving between agents with different roles or authority; and (iii) agent-generated actions targeting protected endpoint resources. These crossings define the points at which provenance may be lost, authority may be confused, or an otherwise legitimate capability may be used outside the declared task scope.

Table 4 summarizes the protected assets, actors, trust zones, entry points, action surfaces, representative abuse cases, and derived security requirements. The central requirements are complete mediation within the protected resource classes covered by a deployment, pre-execution authorization, task-scoped least privilege, preservation of provenance and taint across agent boundaries, and auditable decision recording.

These requirements place the primary enforcement point at the transition from agent reasoning to executable action. Security context must remain attached as information crosses agent boundaries, and the enforcement mechanism must support a pre-execution decision before the target resource is accessed. These requirements are operationalized through RPL for mediation and enforcement, BGE for task-aware authorization, MATBM for provenance preservation, and the Audit Logger for traceability.

3.2. ARES Architecture and Decision Flow

ARES is an action-centric endpoint security architecture based on least privilege, distrust of unverified intermediate context, complete mediation for protected resource classes, and auditability. Its central design rule is that agents do not directly access protected endpoint resources. Instead, every security-relevant request passes through a controlled decision path before execution.

The decision flow consists of six stages. First, the RPL intercepts an agent-generated request at a resource-specific enforcement point. Second, the request is normalized into a common action object. Third, the MATBM enriches the action with agent identity, provenance, taint status, delegation history, and trust-transition metadata. Fourth, the BGE evaluates the enriched action against task scope, resource sensitivity, destination trust, agent role, and policy. Fifth, the BGE returns one of four authorization outcomes—allow, block, delegate, or log-only—and the corresponding resource proxy enforces that decision before endpoint access. Finally, the Audit Logger records the decision, justification, provenance, and latency. Table 5 summarizes the contribution of each component, while Figure 2 illustrates the integrated authorization path.

The components are complementary rather than interchangeable. RPL without BGE provides interception and static resource checks but lacks task-aware authorization. BGE without RPL lacks dependable enforcement points and resource-specific observations. MATBM without RPL and BGE can preserve provenance and taint but cannot prevent an unsafe endpoint action. The integrated design therefore links context preservation to a reliable pre-execution authorization and enforcement point.

3.3. ARES-Lite Prototype and Implementation Scope

ARES-lite implements the core ARES decision path for file and network actions using resource proxies, a deterministic BGE, lightweight MATBM provenance and taint labels, and structured JSONL/CSV audit records. The LLM-based agent receives a task and associated context and generates structured JSON tool-call requests, which are intercepted before execution.

The file proxy mediates workspace read and write requests and applies declared sensitive-path and task-scope rules. The network proxy classifies destinations as approved, unapproved, internal/private, or unknown and mediates send and retrieval requests. The BGE assigns one of four authorization outcomes—allow, block, delegate, or log-only—and the corresponding file or network proxy enforces the decision. ARES-lite then records the action, relevant security context, decision, reason, and measured latency.

Table 6 compares the intended scope of the full ARES architecture with the functions implemented in ARES-lite. The prototype currently covers file and network actions; other resource classes remain outside the implementation scope. In this study, attack success denotes completion of a simulated harmful objective in the controlled evaluation environment and does not imply real-world compromise.

3.4. Experimental Design and Evaluation Metrics

The evaluated action requests are generated by an LLM and then normalized into structured tool-call traces, rather than being constructed entirely by the researchers. To ensure a rigorous comparison, each trial replays the same model-generated trace under both a permissive baseline and the evaluated ARES-lite configurations. This replay-based design controls LLM generation variability by holding the requested action sequence constant across configurations. Each trial first generates an action trace using the designated model configuration; that same trace is then evaluated under the baseline and mediated configurations While this setup isolates mediation effects, it does not account for adaptive re-planning following a block or delegation. Experiments are conducted in a synthetic workspace equipped with canary files, with all network actions recorded in dry-run mode.

The evaluation addresses four research questions:

• RQ1: Can ARES-lite interrupt the evaluated endpoint-facing attack paths before protected resources are accessed?
• RQ2: Can ARES-lite preserve the expected handling of benign and ambiguous tasks while blocking or delegating high-risk actions?
• RQ3: What security contribution does each implemented ARES component provide, and why is their integration necessary?
• RQ4: What decision latency and audit-record completeness are introduced by the ARES-lite mediation path?

For the component analysis, the same normalized traces are evaluated under a permissive baseline and four mediated configurations: RPL-only, BGE-only, MATBM-lite-only, and integrated ARES-lite. The baseline forwards available actions without task-scoped authorization, destination classification, provenance tracking, or taint propagation. RPL-only enables resource classification and enforcement without taint propagation. BGE-only retains deterministic policy evaluation and file-path classification but excludes network destination classification and taint metadata. MATBM-lite-only attaches provenance and taint metadata without enforcing an endpoint decision. These labels denote the principal downstream capability enabled after common parsing and normalization, rather than independently deployable standalone architectures.

Table 7 defines three attack scenarios and eight benign or ambiguous task categories. Scenario A evaluates file exfiltration following indirect prompt injection; Scenario B evaluates prompt-infection propagation across agents; and Scenario C evaluates internal-network access abuse (excessive agency) on an internal/private destination outside the declared task scope. Table 7 and Table 8 specify the expected outcomes and operational metrics.

Attack-success rate is calculated over all attack trials, including those in which no harmful action is generated. Defense-success rate is conditioned on trials containing at least one harmful action. Proportion metrics are reported with 95% Wilson score confidence intervals, while latency uses t-based confidence intervals over trial-level means.

The main experiment used an Intel Core i5-7360U CPU at 2.30 GHz, 8 GB of memory, macOS 13.7.8, Python 3.9.6, gpt-4o-mini through OpenAI Python library 2.48.0, temperature 0.2, and 100 trials per scenario. Decision latency was measured with time.perf_counter(). To assess sensitivity to generation variability, the three attack scenarios were additionally evaluated across the model–temperature grid reported in Section 4.5.

4. Experimental Results

This section presents the results of the controlled evaluation described in Section 3.4. Findings are organized by research questions, followed by a sensitivity analysis across models and decoding configurations. Proportion metrics are reported with 95% Wilson score confidence intervals, while latency statistics use trial-level means and t-based confidence intervals.

4.1. RQ1: Pre-Execution Interruption of Endpoint-Facing Attack Paths

Under the permissive baseline, harmful objectives completed whenever the generated sequence contained the required security-relevant actions and the corresponding tools were available. Integrated ARES-lite reduced the observed attack-success rate to 0% across the three evaluated scenarios (see Table 9).

Scenario A was interrupted at the sensitive file-read or tainted outbound-send action. Scenario B was interrupted after MATBM-lite preserved the taint of propagated inter-agent context and BGE blocked or delegated the downstream action. Scenario C was interrupted when the network proxy classified an internal/private destination outside the declared task scope. Under this baseline configuration (gpt-4o-mini, temperature 0.2), every generated attack sequence also completed harmful objective, so the harmful-generation and attack-success rates coincide at 100%. A gap between harmful-generation and attack-success rates can arise when the generated trace omits a decisive follow-on action or when the generated output cannot be parsed into an executable action. For example, the agent may read a sensitive resource without emitting the subsequent send request; this effect becomes visible for gpt-4o in Section 4.5, where baseline success falls below the generation rate. Scenario C admits no such gap because a single generated network request already constitutes the complete harmful objective.

Figure 3. Decisive ARES-lite intervention points observed in the evaluated attack traces.

Figure 3. Decisive ARES-lite intervention points observed in the evaluated attack traces.

These results answer RQ1 by showing that the transition from agent-generated context to a security-relevant endpoint action provides an effective additional control point. In the evaluated scenarios, ARES-lite did not require perfect detection of malicious language at ingestion; when an unsafe instruction survived earlier safeguards and produced a policy-relevant action, that action could still be blocked or delegated before protected-resource access.

4.2. RQ2: Preservation of Benign and Ambiguous Tasks

ARES-lite produced the predefined acceptable outcome for all controlled benign and ambiguous trials. This result demonstrates conformance to the specified policy within the constructed workload rather than general usability or operational false-positive performance. Routine task-scoped actions were allowed or logged, whereas the ambiguous external destination was delegated rather than incorrectly blocked. This four-state decision model distinguishes clearly unsafe actions from those requiring additional policy or human context. Because the benign set is limited and synthetic, the observed 0% false-positive rate should not be generalized to operational deployments (see Table 10).

4.3. RQ3: Contribution of Individual ARES Components

As shown in Table 11, RPL-only blocked Scenarios A and C, which depend on resource-specific file or destination checks, but did not interrupt Scenario B because prompt infection requires inter-agent taint context. The BGE-only configuration reduced attack success in Scenario A because the normalized action object retained the sensitive file-path attribute required by the policy engine; it did not reduce attack success in Scenario B, which depends on taint metadata that this configuration does not receive, nor in Scenario C, which requires the network destination-classifier.

MATBM-lite-only preserved provenance and identified tainted context but did not reduce attack success because labeling alone does not enforce a decision. Its contribution becomes operational only when the resulting metadata is consumed by BGE and enforced through RPL.

These findings answer RQ3 by demonstrating functional complementarity: RPL provides resource-aware interception and enforcement, BGE provides task- and policy-aware authorization, and MATBM supplies the provenance required for delegation-sensitive decisions. No individual component covered all evaluated attack paths.

4.4. RQ4: Decision Latency and Audit Completeness

Decision latency measures only the interval from tool-call interception to decision-record generation; it excludes LLM generation, API round-trip, application execution, user interaction, and audit-record serialization to disk, which is performed in batch after each run rather than within the measured decision path. As shown in Table 12, the measured mediation latency was on the order of a few microseconds because the prototype uses deterministic policies, lightweight metadata, and dry-run network execution. This value should therefore be interpreted as proof-of-concept mediation cost, not end-to-end task latency or production-scale performance. Audit completeness, defined in Table 8, is reported alongside these measurements: audit completeness was 100% (470 of 470 decision records), with every record containing the required task, agent, action, resource, provenance, decision, reason, and latency fields, so decisions remain fully traceable at the observed mediation cost.

4.5. Sensitivity to Model and Decoding Configuration

The preceding results use a single model and decoding temperature. Because the generation of harmful tool calls is stochastic and model-dependent, this subsection reports the same end-to-end evaluation across a grid of model and temperature settings, so that the effect of mediation can be separated from the variability of the underlying agent.

Baseline exposure varied substantially across the evaluated grid, most notably for prompt-infection propagation in Scenario B. gpt-4o partially resisted the injected instructions, yielding baseline attack-success rates of 41.0–64.0%, whereas the corresponding baseline attack-success rate for gpt-4o-mini was 99.0–100.0% (see Table 13). Baseline success in Scenario A also varied from 82.0% to 100.0%, while Scenario C remained at 100.0% under all baseline configurations.

Across all evaluated cells, integrated ARES-lite produced an observed attack-success rate of 0.0%, with a 95% Wilson interval of [0.0%, 3.7%] (see Figure 4). Baseline attack susceptibility therefore varied across the evaluated model and temperature configurations, whereas ARES-lite produced a consistent observed decision outcome for generated traces containing the policy-relevant attributes defined by the scenarios. This consistency arises because ARES-lite evaluates normalized action attributes—such as resource sensitivity, destination trust, task scope, and taint status—rather than relying solely on the model’s willingness to reject the injected instruction.

These results extend RQ1 by showing that observed attack-path interruption remained consistent across the limited model and temperature configurations evaluated in this study. However, the grid includes only two models from a single provider and three temperature settings; the findings therefore do not establish general model independence or robustness against adaptive policy-evasion strategies.

5. Discussion

5.1. Why Action-Centric Mediation Matters

The combined findings from RQ1–RQ4 indicate that the ARES-lite implementation can govern the evaluated policy-relevant endpoint actions while preserving predefined benign and ambiguous handling, maintaining decision traceability, and introducing only a small local mediation cost in the controlled prototype. The evaluation supports a distinction between instruction compromise and action compromise. Within the ACU threat model considered in this study, harmful content becomes operationally consequential at the endpoint when it influences an action that crosses a protected-resource or agent trust boundary. Prompt filters remain valuable because they can stop a malicious instruction early, but their failure does not need to imply endpoint compromise if a later enforcement point independently evaluates the resulting action. ARES therefore adopts defense in depth: prompt-level controls reduce malicious context, whereas endpoint mediation governs the concrete action that can change system state.

This design also addresses a weakness of coarse tool authorization. Granting access to a file or network tool answers whether an agent may use that class of capability, not whether a specific path, destination, payload, or purpose is appropriate for the current task. RPL supplies resource-specific metadata, BGE relates that metadata to task intent and policy, and MATBM explains how the request was influenced. The combined decision is more expressive than a static tool allowlist.

5.2. Relationship to Existing Defenses

ARES complements defenses operating at other enforcement layers. Prompt filtering and control/data separation can reduce malicious influence before tool generation, privilege systems can constrain available capabilities, isolation can contain interactions, and enterprise endpoint controls can detect anomalous behavior after or during execution. ARES addresses the intermediate authorization point by combining resource-specific observations, task-aware policy, and inter-agent provenance before endpoint access. The evaluation therefore establishes the feasibility of architectural integration rather than performance superiority over systems designed for different layers or assumptions.

5.3. Deployment and Operational Considerations

A practical deployment requires integration at both the agent and endpoint layers. Agent platforms must expose tool-call interception, task identifiers, message provenance, and memory-access events, while endpoint controls must provide reliable resource mediation before execution. ARES could additionally consume enterprise identity, data-classification, EDR, and DLP signals as policy inputs. Fail-open and fail-closed behavior must be defined by resource class and risk tier. Finally, the delegate outcome provides human oversight for context-dependent actions, although excessive delegation may create approval fatigue.

5.4. Limitations

The study has four groups of limitations. First, the prototype scope is limited. ARES-lite implements file and network mediation, deterministic BGE rules, lightweight provenance and taint labels, and audit-record generation. Process, terminal, GUI, clipboard, persistent-memory, kernel-level, and application-context enforcement remain unimplemented.

Second, the evaluation has limited external validity. The controlled synthetic workspace does not represent the diversity, concurrency, and duration of enterprise endpoint workloads. The benign workload is small, and the model-sensitivity analysis covers only two models from one provider and a limited temperature range. Consequently, the reported false-positive, delegation, and sensitivity results should not be generalized to operational deployments.

Third, policy and threat coverage remain limited. The deterministic rules are interpretable but depend on predefined resource sensitivity, task scope, destination classes, and taint labels. The threat model excludes direct host compromise, malicious model providers, framework supply-chain compromise, and privileged insiders. The evaluated attacks are also non-adaptive; a policy-aware adversary may attempt path aliasing, encoded resources, look-alike destinations, taint laundering, or decomposition of a harmful objective into individually low-risk actions.

Fourth, the replay-based evaluation does not capture closed-loop agent adaptation. Replaying identical action traces isolates the effect of mediation, but a live agent may retry, choose an alternative action, or abandon the task after receiving a block or delegation response. The reported attack-success results therefore measure interruption of fixed generated traces rather than the outcome of a fully adaptive agent–defense interaction. In addition, the latency measurement covers only local decision processing and excludes model inference, API communication, application execution, human review, and disk serialization.

5.5. Future Work

Future work will proceed in three directions. First, implementation coverage should be extended to processes, terminals, GUIs, clipboards, persistent memory, and local application context. Second, policy quality should be strengthened through resource canonicalization, richer provenance graphs, signed metadata, controlled declassification, and integration with identity, data-classification, EDR, XDR, and DLP signals. Third, evaluation should include public benchmarks [14,29], real agent frameworks, adaptive attacks, closed-loop re-planning, concurrent agents, longer workflows, and larger benign workloads. Model-assisted semantic risk analysis may supplement deterministic policy, but final authorization should remain constrained, explainable, and auditable.

6. Conclusions

ACUs expand the security boundary of LLM-based systems because model-generated decisions can directly affect files, networks, applications, and graphical interfaces. This paper introduced ARES, an action-centric endpoint security framework that places pre-execution authorization between agent-generated requests and protected resources. ARES combines resource-specific interception through RPL, task- and context-aware authorization through BGE, and provenance and taint preservation through MATBM.

The ARES-lite proof of concept provides controlled evidence that this integrated design can interrupt the three evaluated attack paths involving indirect-prompt-driven exfiltration, inter-agent prompt infection, and internal-network access abuse while preserving the predefined handling of benign and ambiguous tasks. The component analysis further shows that interception, authorization, and provenance tracking provide complementary functions, and the prototype generates complete decision records with measured local decision latencies in the microsecond range.

These results establish architectural feasibility rather than production readiness. Broader resource coverage, larger and more diverse workloads, adaptive closed-loop evaluation, and operational deployment studies remain necessary. Nevertheless, the findings indicate that securing autonomous agents requires governing not only what they receive and generate, but also the actions they attempt, the resources those actions target, and the provenance of the instructions that influenced them.