“Claude & Control” puts forward an uncomfortable but useful idea for security teams: if an agent with computer use capabilities can interact with a desktop (browser, terminal, apps) like a person would, then the concept of Command & Control (C2) stops being just “malware talking to a server” and becomes “a remote operator automating user actions at scale”. The difference is not semantic: it changes the attack surface, the type of telemetry that matters, and the points where it makes sense to add friction.
In companies, this becomes tangible when there are virtual desktops, RPA, jump hosts, hardened browsers, and SSO: the attacker no longer needs to exploit exotic binaries if they can chain legitimate actions (login, search in the internal portal, download an export, change a setting) guided by an agent. Defending it requires thinking in “behaviors” and “execution capability”, not only in traditional IOCs.
What Agentic C2 means when the agent “uses the computer”
In a classic C2, the compromised endpoint executes instructions through a channel (HTTP/S, DNS, etc.) and control is expressed in system commands. In an Agentic C2 with Computer Use Agents, the instruction can be high-level (“open the admin panel and create a new token”) and the execution materializes as clicks, navigation, copy/paste, and use of applications.
This has a direct effect on defense: many actions stop looking “technical” and start looking like “user operations”, but with a speed, repetition, and consistency that a human does not have. In addition, the agent can adapt to the environment (UI changes, error messages) and retry with variants, which erodes controls based on fixed paths.
In corporate environments, the most frequent impact is not “immediate exfiltration through a backdoor”, but abuse of internal tools: ITSM portals, cloud consoles, SaaS vendor dashboards, VPN/VDI, and even approval workflows where the agent tries to force the path with social engineering and automation. The C2 becomes a coordination between: operator instructions, agent reasoning, and actions in the interface.
Typical architecture: where control lives and where risk leaks
A common architecture for Computer Use Agents includes: an agent runtime (model + orchestration), an “execution environment” (VM/VDI/container with browser and tools), outbound connectivity to external services (including the control channel), and access to credentials or tokens to operate applications. Each block introduces different risks: the model can be induced, the environment can be persistent, and credentials can be exposed in plain text/clipboard/logs.
In practice, the critical point is usually the execution environment: if the agent operates inside a VDI with SSO and access to sensitive consoles, the “blast radius” skyrockets. The C2 does not need to enter through a corporate endpoint; it can live outside (a host controlled by the adversary) and still operate “as an employee” if it obtains credentials or a session.
- Control channel and observability: if agent orchestration relies on external APIs, outbound traffic and call patterns become a defensive signal.
In a company, this translates into reviewing egress (proxy, CASB, firewall) and logging with enough detail: domains, SNI/JA3 when applicable, volume and periodicity. It is not enough to “allow HTTPS”; you must be able to attribute which process/host makes the communication and whether it matches expected use.
- Session persistence: cookies, tokens, and browser states that remain alive between runs make it easier for control to be continuous.
If the agent reuses browser profiles or VDI snapshots, an incident can become “durable access” without the need for additional malware. The real consequence is that password rotation does not cut access if there are active sessions not revoked in SaaS or in the IdP.
- Leaks via artifacts: screenshots, agent logs, command history, or the clipboard can contain secrets.
This shows up in internal audits: the team enables logging “to debug”, the agent prints tokens or pastes credentials into a form, and that data ends up in a bucket or in a ticketing system. The risk is not theoretical; it is a recurring pattern when automation and troubleshooting are mixed.
Realistic abuse scenarios: from “click here” to operating your SaaS
The most plausible abuse does not start with a “superintelligent” agent, but with an operator guiding concrete tasks. For example: obtaining access to a low-friction account (vendor, intern, account with weak MFA) and then using an agent to traverse complex UIs at scale: locate panels, export lists, create integrations, generate API keys, and test permissions.
A differentiating trait of Agentic C2 is elasticity: if the portal changes, the agent does not break like a rigid script; it tries alternatives. In a real incident, this complicates the defender’s playbook because the attacker can “pivot” without deploying new tools: new instructions are enough.
- Creation of long-lived credentials in SaaS: the agent navigates to “Integrations/API” and generates a token with broad scopes.
The typical business consequence is that the “entry point” (a web session) stops mattering; the token lives outside, and subsequent activity moves to API, often from attacker infrastructure. If there is no token inventory or alerts for anomalous creation/use, the team arrives late.
- Abuse of internal workflows: opening tickets, group changes, access requests, and approvals with assisted social engineering.
Seen in operations: the agent drafts convincing requests, attaches screenshots, and persists until it gets an exception. The defense here is less “block malware” and more “control privileges and human verifications” with additional signals (origin, context, speed, history).
- Exploration of cloud consoles: locate roles, accounts, buckets, secrets managers, and escalation paths via configuration.
Even with decent IAM, the cloud UI allows discovering a lot. An agent can browse pages and collect inventory. If the team only monitors API calls and not interactive console access (or does not review audit logs), it misses the prelude to the attack.
How to do it in practice: guardrails that add friction without breaking the business
The effective response is not “ban agents”, but fit them into a controlled environment where their capability for action is bounded. The operational goal is to reduce the impact of an agentic C2 even if the agent has malicious instructions or is manipulated by content (prompt injection) during browsing.
Start by separating “agent environment” from “user environment” and by treating the agent as a high-risk workload: no direct access to sensitive data, no unrestricted egress, and short-lived credentials. If the agent needs to operate a console, have it do so with specific roles, without write permissions by default, and with approval for dangerous actions.
- Create a disposable execution environment: ephemeral VDI/VM per task, with no persistent profile and wiped at the end.
Concrete action: configure golden images with a hardened browser, disable password storage, clear cookies on close, and destroy the instance on completion. Validate that no state remains by checking that the next boot does not inherit history, cookies, or tokens (test with a lab SaaS and confirm there is no active session).
- Configure egress with an allowlist and authenticated proxy: outbound only to necessary domains, with inspection/logging.
Concrete action: route all traffic from the agent environment through a corporate proxy with authentication and destination-based policies. Verify in logs that any attempt to access non-allowed domains is blocked and that there is traceability by identity/host. This reduces the viability of improvised C2 channels.
- Use short-lived, least-privilege credentials: temporary roles and minimal scopes for the task.
Concrete action: if there is cloud integration, prioritize roles with short sessions and specific permissions. As a technical reference (AWS), a typical trust policy to assume a role from an identity provider or from a controlled account should limit principal and conditions. Example of a trust policy restricted by account and external ID (adjust it to your case):
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::123456789012:root"},
"Action": "sts:AssumeRole",
"Condition": {"StringEquals": {"sts:ExternalId": "agent-run-locked"}}
}]
}
Operational validation in AWS: review CloudTrail to confirm that role sessions are short-lived, that AssumeRole only occurs from the expected principal, and that there are no actions outside the defined permissions. Complement with alerts on access key creation events, policy changes, and privilege escalations.
Detection and response: signals that do change with computer use agents
If the attacker operates via UI, many traditional detections based on processes or payloads do not trigger. Instead, it becomes valuable to correlate identity + behavior + context: browsing speed, improbable sequences of actions, access to infrequent pages, and credential creation at atypical times.
In a mature SOC, this means joining telemetry from the IdP (SSO, MFA), SaaS logs (admin audit), proxy/secure web gateway, and, where it exists, VDI records. The pattern you will see is not “execution of Mimikatz”, but “user X created token Y, then there were API calls from a strange ASN, and before that there was intensive console browsing”.
- UI automation signals: bursts of repetitive actions, interaction times that are too regular, and navigation that “sweeps” menus.
This is not solved with a simple rule, but with baselines: what a real admin does in a normal week. The consequence of not doing it is that the first alert arrives when there is already a massive export or configuration changes. If you have VDI, capture session metrics (duration, destinations, apps opened) and correlate them with SaaS audit events.
- “Capability creation” events: new tokens, new OAuth apps, new webhooks, new users/roles.
In incident response, prioritize revoking what enables persistence: tokens, integrations, and active sessions, not only passwords. In companies, this is a common failure: the password is reset and an OAuth app with broad permissions created during the incident is left alive.
Recommendations for corporate environments
“Claude & Control” is useful to land that C2 can take the form of interface automation: the adversary does not need noisy tools if they can direct an agent that operates applications like a user. That shifts the defensive focus toward controlling the execution environment, egress, identity, and the artifacts the agent generates.
Operationally, what works best is setting clear limits: ephemeral environments for the agent, temporary and minimal credentials, and strong traceability (proxy + SaaS audit + IdP). At the detection level, prioritize signals of persistence creation (tokens/apps) and correlation of behavior in console/UI, because that is where this C2 model leaves a trail.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.