%20-%20no%20white%20space%20-%20resized-1.png?width=4164&height=948&name=logo%201%20(bold)%20-%20no%20white%20space%20-%20resized-1.png)
.png)
An employee asks Codex or Claude Code to fix a problem. The agent opens files, changes code, runs commands and may download a package. The employee remembers the request, but not necessarily every action that followed.
Security monitoring sees those technical actions—not the employee’s intention. Similar actions can appear when an attacker controls the laptop or account. As legitimate AI-agent activity grows, it becomes harder to pick out the actions caused by a real attacker.
What we are seeing at customers
We increasingly see coding agents doing more on employee laptops. A single request can result in many file changes, new processes, terminal commands, repository access and connections to other tools.
The employee can usually explain the outcome they requested: “I asked the agent to fix the build” or “I asked it to update this script.” But that does not tell security why a particular command ran, why a package was installed or why another system was accessed.
The practical problem
The employee may have started a legitimate session, but security still needs to establish whether every important action fits that task. Activity that cannot be explained cannot simply be dismissed as “the AI agent”.
Why an AI agent behaves differently from normal software
Most business software is built around defined functions. An accounting application processes invoices. A backup tool copies selected data. The input changes, but the workflow and technical behaviour remain broadly recognisable.
An AI agent receives an objective and decides which steps may achieve it. If it has permission, it can read files, edit code, run tests, start other tools, install software or use a connected system. A different problem—or even a different response from the same model—can produce a different sequence of actions.
The same type of task normally produces a familiar technical pattern.
The agent chooses the steps within the access it has been given.
This difference is becoming more important because the models, tools and integrations improve quickly. An application that behaved predictably for years may create a stable baseline. An AI agent can gain new capabilities within months, changing what normal activity looks like on the same laptop.
What security monitoring actually sees
Monitoring tools record actions. They do not automatically know whether the employee requested them, whether the agent chose them unexpectedly or whether an attacker caused them. The same signal can therefore have very different explanations.
Files or configuration changed
The agent updates code or configuration for the requested fix.
An attacker changes code, security settings or startup behaviour.
Terminal commands or new processes
The agent runs tests, builds the project or uses a local tool.
An attacker runs scripts, discovery commands or malicious tools.
Package installed or file downloaded
The agent adds a dependency needed for the task.
An attacker downloads a tool, payload or unwanted component.
Repository or connected system accessed
The agent reads an issue, updates code or uses an approved connection.
An attacker looks for source code, sensitive data or another system to reach.
None of these actions proves that an attack is taking place. The difficulty is the growing volume of legitimate activity that looks similar. If security cannot quickly connect the actions to a known employee task, genuine attacks take longer to find and investigate.
Built-in controls help, but employees can still give the agent more access
Codex and Claude Code include controls such as approval prompts, restricted file access and sandboxing. These are important. They reduce what the agent can do without the user’s knowledge or approval.
Access can still expand during normal use. An employee may select a larger folder, allow internet access, approve a command for the rest of the session or add a connection to another system. The tool is then able to reach more than it could at the start.
A simple example
The agent starts in one project folder. The employee then gives it access to the complete home folder and approves network access so the task can continue. The agent can now read unrelated company files and communicate with external services. Those two approvals have made the session much riskier.
There is another technical risk: repositories, issues, web pages and other content read by the agent can contain misleading instructions. Both OpenAI and Anthropic describe this as a prompt-injection risk. The combination of untrusted content and broad permissions deserves particular attention.
Five actions to take now
You do not need to block AI coding agents. You do need clear defaults that employees can follow and enough information to investigate unusual activity. Start with these five actions.
Find out which agents are already in use
List the coding agents, command-line tools and IDE extensions used for company work, together with their users and owners. Include tools employees installed themselves; a central software list may not show every web, extension or command-line use.
Keep each task inside one project folder
Start the agent in a dedicated project folder. Keep the employee’s home folder, shared drives, customer exports, secret files and production credentials outside it. Do not grant access to the complete laptop simply because one task needs an additional file.
Specify which actions require a second check
Require deliberate review before the agent accesses files outside the project, uses the internet, installs a package, connects another system or runs cloud, deployment or production commands. Employees should understand what they approve; proposed code and configuration changes should still be reviewed before release.
Use company accounts with limited permissions
Do not use personal accounts for company work. Review every repository, cloud login, connector or MCP server the agent can use. Check the account behind it, the data it can reach and whether it can only read information or can also make changes.
Keep the information needed for an investigation
Where the products support it, retain which employee and agent session were involved, the project used, important commands and approvals, and the endpoint alerts that followed. Tell employees how to report unexpected agent behaviour. Security should be able to connect unusual activity to a known task; activity that remains unexplained should still be investigated.
Useful AI activity should not hide a real attack
AI agents can provide real value, and their actions may be completely legitimate. The security requirement is simple: know which agents are used, limit what they can reach and keep enough records to explain important activity. Otherwise, the growing volume of authorised agent activity gives a real attacker more places to hide.
Can you explain what your AI agents are doing on employee laptops?
Tell us which tools your employees use and what they can access. We can help you make agent activity safer and easier to distinguish from a possible attack.