EDR for coding agents is no longer a future concern. Claude Code, Cursor, Codex, and skill packs can install dependencies, open browsers, download tools, and try alternate paths. To an endpoint behavioral engine, some of that looks like intruder activity.
In July 2026, Sophos X-Ops analyzed seven days of Windows telemetry and found credential access in 56.2% of agent-related blocking hits, while execution represented 28.8% (Sophos X-Ops, "When AI agents look like attackers", 2026). The lesson is not "stop using agents." It is "do not call everything a false positive."
Practical summary
- EDR should separate agent noise from dangerous actions.
- Credential access should stay blockable, even when the agent looks benign.
- Allowlists need process, workspace, destination, and command context.
- CI and disposable runners reduce the impact of long agentic loops.
Why did EDR start seeing agents as intruders?
In 2026, Sophos measured agent-related blocking hits by unique machine across seven days and saw credential access in 56.2% of cases, with execution at 28.8% (Sophos X-Ops, "When AI agents look like attackers", 2026). EDR reacts because behavior, not intent, looks hostile.
A coding agent does not know that its command will resemble an offensive technique. It tries to solve the task: install a runtime, automate a browser, download a dependency, run a script, or persist a local tool. Attackers do similar things when they operate inside a valid session.
That changes the conversation between engineering and security. The platform team should not ask for a broad exception for claude.exe, cursor.exe, or codex. The security team should not block every agentic workflow without triage either. The right work is to classify actions.
This angle complements hooks that stop coding agents before damage because EDR sees the endpoint effect, while the hook tries to stop the risky action before the command runs.
Citable capsule: EDR for coding agents is not an exception list for popular tools. Sophos telemetry in 2026 showed benign agents already hitting credential-access and execution rules, so policy has to distinguish operational context from dangerous action.
What should stay blocked even when the agent did it?
In 2026, Sophos showed that 42.6% of credential-access blocking hits came from a signal tied to DPAPI and sensitive browser data (Sophos X-Ops, "When AI agents look like attackers", 2026). That alert does not become safe just because AI initiated it.
If the agent tries to decrypt browser credentials, list Credential Manager, or touch session material, keep the block. The intent may be legitimate automation, but the privilege is too broad. An agent running under the developer's account inherits access it should not freely use.
The same applies to persistence. Sophos observed Cursor writing a script into the startup folder, and MITRE maintains a detection strategy for startup keys or startup folder creation, modified on May 12, 2026 (MITRE ATT&CK, "Detect Registry and Startup Folder Persistence", 2026). That pattern needs review.
When the source repository is not trusted, the response should start before EDR. A repository quarantine step for coding agents reduces the chance that a README, script, or external package pushes the agent into an action the endpoint has to block.
Citable capsule: Credential-store access and persistence should not be allowed by tool name. Sophos measured 42.6% of credential blocks tied to DPAPI, and MITRE treats startup folder writes as a detectable persistence surface.
How do you separate noise from risk without a blind allowlist?
In 2026, Sophos saw silent rules tied to evasion in 38.5% of agent signals and command and control in 34.0% (Sophos X-Ops, "When AI agents look like attackers", 2026). That volume shows that "allow or block everything" will not scale for real teams.
Start with process origin. An acceptable exception should bind the agent executable to the expected workspace, controlled temp directory, legitimate network destination, and allowed command. If any part changes, the alert returns to review. That prevents an allowlist from becoming a tunnel for hostile code.
Then split classes. A signed runtime download can become a narrow exception when the domain, hash, and directory are predictable. Credential access, startup writes, and execution of material from an unknown repository should stay blocked. The rule should follow potential damage, not developer annoyance.
If the alert involves an external tool, treat it as a scope problem too. The logic behind MCP allowlists for coding agents also applies to endpoints: an allowed tool needs a clear purpose, input, output, and boundary.
| Agent signal | Practical decision |
|---|---|
| Downloading a runtime from a known origin | Allow only with verifiable destination and hash. |
| Trying another utility after a block | Review as pivot behavior, not as innocent error. |
| Accessing local credentials | Block and require a flow without persistent secrets. |
| Writing user persistence | Block and move to a trusted installer or disposable runner. |
Practical note: when an alert comes from an agent, I ask for the full chain: parent process, workspace, command, destination, written file, and original task. Without that chain, any decision becomes opinion.
Where do Claude Code and Codex need different limits?
In 2026, Claude Code documentation says bypassPermissions disables permission prompts and safety checks, and should be used only in containers, VMs, or dev containers without internet access (Claude Code Docs, "Choose a permission mode", 2026). If that mode appears on a normal endpoint, treat it as platform risk.
For Codex, the permissions documentation lists three built-in profiles: read-only, workspace, and danger-full-access (OpenAI Codex Docs, "Permissions", 2026). That distinction helps policy design: read access for investigation, limited writes for implementation, and broad access only in controlled environments.
For EDR, operational detail matters. Claude Code with --dangerously-skip-permissions on a corporate laptop does not carry the same risk as Codex inside a disposable runner with a limited workspace. The agent name is not enough. Policy needs mode, sandbox, network, user, directory, and repository source.
This model also avoids repeating the failure described in Friendly Fire during third-party review: the agent should not gain more authority exactly when it is reading material someone else may control.
When a loop has to span multiple attempts, logs, and reviews, I use RemoteCode as my own tool for extending Claude Code and Codex in agentic workflows with less wasted context. It helps coordinate the work; it does not replace EDR, sandboxing, or approval for sensitive actions.
Citable capsule: Agent permission should be evaluated by execution mode. Claude Code warns that
bypassPermissionsbelongs in isolated environments, while Codex offers read, workspace, and broad-access profiles; EDR should see those differences.
How do you bring this policy into CI and DevOps?
In 2026, an arXiv study of Microsoft's rollout examined tens of thousands of engineers and found roughly 24% more merged PRs among CLI agent adopters (arXiv, "Adoption and Impact of Command-Line AI Coding Agents", 2026). More throughput requires more automated policy.
Move the rule off the laptop. CI runners should use a narrow service account, disposable workspace, network denied by default, and an artifact of executed commands. If the agent needs to download a runtime, the destination should be approved. If it needs to access a secret, the job should fail and ask for a different design.
A small contract can live in the repository:
agent_policy:
environment: "disposable runner"
network: "blocked by default"
local_credentials: "denied"
persistence: "denied"
downloads:
require_approved_origin: true
require_verified_hash: true
evidence:
record_commands: true
record_workspace: true
record_exceptions: trueThat contract fits with PR evals for agents in CI and repository quarantine for coding agents. EDR should not be the first boundary. It should confirm that the runner honored what policy already promised.
Citable capsule: CI reduces friction between agents and EDR when it turns permission into an artifact. The 2026 Microsoft study associated CLI agents with roughly 24% more merged PRs, so flow gains need automated proof.
Checklist for responding when the alert came from an agent
In 2026, MITRE describes certutil as a utility adversaries can use to download files in Ingress Tool Transfer, and Sophos observed Codex switching from certutil to bitsadmin while fetching a legitimate installer (MITRE ATT&CK, "Ingress Tool Transfer", 2026; Sophos X-Ops, 2026). The same pattern can be benign or dangerous.
Use this sequence before closing the alert:
- Preserve the original alert with parent process, user, workspace, and command.
- Confirm whether the repository was trusted or quarantined.
- Split download, execution, credentials, persistence, and network into distinct decisions.
- Block credential-store access even when the task looks legitimate.
- Move browser automation to a profile without real credentials.
- Require a disposable runner for
danger-full-accessor an equivalent mode. - Record narrow exceptions by origin, path, destination, and validity.
- Turn repeated false positives into documented rules, not broad bypasses.
The goal is to preserve signal. If the team allowlists the whole agent, it loses visibility exactly when benign agents, compromised agents, and attackers using agents begin producing similar telemetry. The mature response is more context in the alert, not less detection.
Once the incident becomes a rule, connect the discovery to the self-correcting agent loop in CI. The loop improves only when endpoint failures create new constraints, not when the agent learns how to route around the alarm.
FAQ about EDR and coding agents
Is every agent alert a false positive?
No. In 2026, Sophos said the activity was not necessarily malicious, but also showed credential access in 56.2% of agent-related blocking hits (Sophos X-Ops, "When AI agents look like attackers", 2026). The alert can be right even when the intent was automation.
Can I allowlist Claude Code or Codex?
Only narrowly. In 2026, Codex documents permission profiles ranging from read-only to danger-full-access (OpenAI Codex Docs, "Permissions", 2026). A safe allowlist considers profile, workspace, network, command, and destination, not just the executable name.
What should I do with --dangerously-skip-permissions?
Block it on normal endpoints. In 2026, Claude Code documentation says --dangerously-skip-permissions is equivalent to bypassPermissions and should be used only in isolated environments without internet access (Claude Code Docs, "Choose a permission mode", 2026). On a corporate laptop, that is high-risk exception territory.
Should EDR block downloads made by an agent?
It depends on the pattern. In 2026, MITRE describes Ingress Tool Transfer as transfer of tools into a compromised environment and cites utilities such as certutil (MITRE ATT&CK, "Ingress Tool Transfer", 2026). Allow predictable, verified downloads; investigate utility pivots and unexpected destinations.
Sources
- Sophos X-Ops, "When AI agents look like attackers: what behavioral telemetry tells us", retrieved 2026-07-15, https://www.sophos.com/en-us/blog/2607_agents_vs_telemetry
- Claude Code Docs, "Choose a permission mode", retrieved 2026-07-15, https://code.claude.com/docs/en/permission-modes
- OpenAI Codex Docs, "Permissions", retrieved 2026-07-15, https://developers.openai.com/codex/permissions
- OpenAI Codex Docs, "Sandbox", retrieved 2026-07-15, https://developers.openai.com/codex/concepts/sandboxing
- MITRE ATT&CK, "Ingress Tool Transfer", retrieved 2026-07-15, https://attack.mitre.org/techniques/T1105/
- MITRE ATT&CK, "Detect Registry and Startup Folder Persistence", retrieved 2026-07-15, https://attack.mitre.org/detectionstrategies/DET0365/
- arXiv, "Adoption and Impact of Command-Line AI Coding Agents", retrieved 2026-07-15, https://arxiv.org/abs/2607.01418
