Claude Cowork security risks show why agent blast radius matters

At a glance

What this is: Akto argues that Claude Cowork should be treated as privileged agent infrastructure because its real-session access, browser integration, connectors, and scheduled tasks expand prompt-injection impact far beyond a normal chatbot.

Why it matters: IAM, PAM, and AI security teams need to govern agent permissions, runtime guardrails, and tool exposure together because the agent inherits user reach across files, web sessions, and enterprise systems.

By the numbers:

• Within 48 hours of Cowork's launch, researchers showed a Word document with invisible 1-point white text instructing Cowork to find financial documents and upload them to an attacker's account.
• Anthropic self-reports a ~1% success rate even after mitigations.

👉 Read Akto's analysis of Claude Cowork security risks and agent blast radius

Context

Claude Cowork is not just another chatbot feature. It is a local agent that can read files, run shell commands, browse the web with logged-in cookies, and use enterprise systems through the employee session, which means the primary risk is agent blast radius rather than prompt quality alone. For AI agent identity security, that makes permissions, tool exposure, and session inheritance the real governance problem.

This matters because existing compliance and access-control models were built for software with clearer boundaries. Once an AI agent can act inside a real user context, the security question becomes whether its effective identity, privilege scope, and runtime actions are continuously constrained. That is why the article's starting position is typical of agentic AI adoption: organisations underestimate how quickly a local agent becomes an identity and access problem.

Key questions

Q: What breaks when an AI agent is given real user sessions and tool access?

A: The main failure is that a single injected instruction can inherit the user's active permissions and convert a reading task into exfiltration, command execution, or message sending. When browser cookies, connectors, and desktop access are all in scope, the agent's effective identity becomes the security boundary, not the model itself.

Q: Why do local AI agents complicate identity and access management?

A: They can retain legitimate permissions while changing timing, prioritisation, and action sequence outside human presence. That means the visible identity may remain stable even as the operational behaviour becomes autonomous. IAM teams then lose the simple link between user session, authorisation, and accountability.

Q: What do security teams get wrong about AI compliance?

A: They often treat AI compliance as a model review exercise and miss the surrounding identity and access layer. In practice, regulators care about data handling, delegated permissions, logging, and accountability. If service accounts, tokens, and approvals are not governed, the control story is incomplete even when the model documentation looks strong.

Q: How should organisations govern scheduled tasks in AI agents?

A: Treat scheduled-task creation as privileged access, not a convenience feature. Any task that can repeatedly read files, call tools, or transmit data should be approved, monitored, and revocable on demand. Without that control, a one-time prompt injection can become recurring persistence.

Technical breakdown

Why prompt injection becomes a privilege problem in local agents

Prompt injection is an instruction-hijacking technique, but in agentic systems the damage depends on what the agent can touch. If a local agent can read documents, access browser sessions, and invoke tools, malicious content can steer it to exfiltrate files, send messages, or execute commands under the user's permissions. In other words, the model is not the main asset at risk. The runtime context, attached credentials, and reachable systems define the blast radius. That is why agent identity and entitlement scope matter as much as model safety controls.

Practical implication: map every tool and session the agent can inherit before allowing it to act on real user data.

Why compliance tooling misses shadow AI agent activity

Shadow AI becomes a governance issue when an agent is powerful enough to matter but invisible to audit systems. If audit logs, compliance APIs, and data exports do not capture the agent's actions, security teams lose the evidence needed for DLP, investigations, and control validation. OpenTelemetry metadata can help, but stripped prompts and tool names limit forensic value. This is a classic identity governance gap. You cannot review or certify behaviour you cannot observe, especially when the agent is operating inside a real authenticated session.

Practical implication: require supplemental telemetry and SIEM ingestion before approving agent use in regulated environments.

How connectors, browser sessions, and scheduled tasks extend the attack surface

Connectors, browser sessions, and scheduled tasks turn one successful injection into repeatable access. A connector often inherits the user's permissions, so a single integration can become an exfiltration path. Real browser cookies place the agent inside active sessions, bypassing the neat separation many teams assume exists between web content and corporate identity. Scheduled tasks then add persistence, because a one-time malicious instruction can keep running until manually removed. This is why AI agent governance must treat each tool as part of the agent's effective identity boundary.

Practical implication: scope connectors to read-only where possible and alert on any new scheduled-task creation.

Threat narrative

Attacker objective: The attacker wants the agent to perform harmful actions under legitimate user privileges and then repeat them without detection.

1. Entry occurs when a malicious document, web page, email, or API response hides instructions that the agent reads during a legitimate task.
2. Credential access follows when the agent acts inside the user's real browser session, logged-in cookies, or inherited enterprise permissions.
3. Escalation and persistence happen when connectors, computer-use actions, or scheduled tasks let the injected instruction repeat, spread, or reach additional systems.
4. Impact is file exfiltration, command execution, message sending, or repeated data theft using the user's effective access.

NHI Mgmt Group analysis

Blast-radius control is the defining governance concept for agentic AI. The article shows that a local agent is dangerous not because it is conversational, but because it inherits the user's reach into files, browser sessions, and enterprise tools. Once that happens, the central question becomes how much harm one injected instruction can do before containment fails. For IAM and PAM teams, agent identity must be governed by reachable systems, not by whether the model is conversational or autonomous.

Shadow AI agents create an audit gap that conventional compliance tooling cannot close on its own. If the agent's actions are excluded from native logs and exports, security teams cannot prove what happened, let alone detect abnormal behaviour in time. That is a governance failure, not a logging inconvenience. This is where AI agent oversight intersects directly with identity governance, because unmanaged agent sessions become unreviewable identities. Practitioners need telemetry that can stand up to audit, incident response, and policy enforcement.

Connector sprawl is a privilege problem disguised as integration strategy. Each MCP server, plugin, browser session, or desktop-control path adds a new trust edge and enlarges the agent's effective authority. The security model should not assume all tools are equivalent just because they are attached to the same agent. A centrally governed allowlist and least-privilege defaults are necessary because the agent's identity boundary is only as tight as its riskiest connector.

Scheduled tasks turn prompt injection into persistence. The article correctly treats unattended tasking as more dangerous than one-off execution because it extends the window for abuse beyond the initial session. That means the governance failure is not just over-permissioning, but failure to distinguish transient action from recurring authority. Practitioners should treat task creation as a privileged event, especially when the task can read, send, or synchronise sensitive information.

AI agent security is converging with PAM and NHI governance. The article's underlying lesson is that agentic systems behave like non-human identities with dynamic tool access, but without the lifecycle discipline that mature NHI programmes apply to service accounts and secrets. That makes lifecycle ownership, runtime monitoring, and offboarding as important for agents as for any other high-risk identity. The field is moving toward treating agents as privileged actors that require explicit identity governance, not informal software trust.

What this signals

Agent identity governance is becoming a control-plane problem, not a model-safety problem. The practical challenge for security teams is no longer just whether an AI system can answer safely, but whether its effective privileges are bounded, observable, and revocable. That pushes programme owners toward policy enforcement, telemetry, and identity-centric guardrails, with the OWASP Top 10 for Agentic Applications 2026 providing a useful external benchmark for tool misuse and delegation risk.

Blast-radius reduction should become a measurable objective in AI operations. Teams should be able to answer how many connectors an agent can reach, which sessions it inherits, and which actions trigger alerts. That is the same operational discipline mature NHI programmes apply to service accounts and secrets. Where agents interact with sensitive data, controls like NIST AI Risk Management Framework and the OWASP NHI Top 10 help translate broad governance into specific enforcement points.

Scheduled execution and connector sprawl are the two patterns most likely to create hidden persistence. If an agent can keep running unattended or expand its trust edges silently, the organisation has effectively created a non-human identity with weak lifecycle control. That means offboarding, connector review, and runtime containment should be tracked as programme health indicators, not one-time hardening tasks.

For practitioners

• Inventory every agent attachment and reachable system Document which files, browser sessions, connectors, MCP servers, and desktop-control paths each agent can reach. Treat personal-account deployments as separate from managed enterprise usage, and block rollout until the inventory is complete.
• Constrain agent permissions to the smallest viable scope Disable web search unless needed, prefer read-only connectors, scope file access to dedicated folders, and keep scheduled tasks and computer-use features off until there is a documented business need.
• Add runtime guardrails for dangerous action chains Inspect agent behaviour as it happens and block patterns such as bulk reads followed by external writes, connector sends to unknown destinations, and connections to unapproved endpoints before the session completes.
• Route agent telemetry into the SIEM Use OpenTelemetry or equivalent logging to forward agent metadata into the SIEM, then alert on scheduled-task creation, non-allowlisted MCP connections, connector writes, and sensitive-directory reads.
• Treat connector approval as a privileged change Review every new plugin or MCP server before connection, verify its tool set, and remove any integration that can post, copy, or move data outside the minimum intended workflow.

Key takeaways

• Claude Cowork illustrates how a local AI agent can become a privilege-bearing identity rather than a simple assistant.
• The article's core evidence is that prompt injection, real browser sessions, connectors, and scheduled tasks can combine into repeatable data theft and persistence.
• The control priority is blast-radius reduction through least privilege, runtime guardrails, telemetry, and formal approval of every integration path.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.

What's in the full article

Akto's full post covers the operational detail this post intentionally leaves for the source:

• A step-by-step breakdown of six specific Cowork risks, including prompt injection, browser access, and scheduled-task persistence.
• Operational hardening actions for managed-settings.json, MDM policy, and runtime guardrails.
• Concrete examples of alert conditions for SIEM monitoring, including scheduled-task creation and connector writes.
• Guidance on when to disable Computer Use, web search, or non-read-only connectors in enterprise environments.

👉 Akto's full post covers the six risk areas, hardening steps, and telemetry signals in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It helps practitioners translate identity controls into real operating models for modern security programmes.