A security team may recognise an AI coding assistant as approved software and still miss an attacker using it on a compromised computer. Once someone else controls a workstation or account, tools installed to help employees can also be used to inspect files, run commands or connect elsewhere.
That changes a practical decision for Norwegian management teams: when introducing an AI assistant that can act on a computer, who checks what it can reach, and who can contain the device if its activity becomes suspicious?
The answer is not to remove every useful tool. It is to make approval conditional on appropriate access, monitoring and a response that has been agreed with the people who run the service.
What Elastic observed
In a 4 November 2026 report, security company Elastic describes attackers abusing legitimate software in incidents and research from April to September. Its announcement says investigators observed commands run through Claude Code on Windows and the ChatGPT desktop app on macOS during live intrusions. In one Windows incident, the attacker connected remotely and used Claude Code to stage tools and reach an external server through a concealed connection.
This is Elastic's account of particular investigations, not a measure of how many Norwegian firms are affected. The announcement does not establish that the AI products themselves were the original entry point, nor that an AI agent independently decided to attack. A criminal using an existing tool after gaining access is a different problem from a model escaping control or a product vulnerability.
Elastic also reports that across 27 confirmed cases involving password-stealing malware, attackers logged in using stolen credentials an average of eight minutes after infection. That figure concerns those selected cases and does not establish a universal deadline, or show that AI caused the speed. It does illustrate why an alert delivered to an unattended mailbox is a weak response plan.
Approved software still needs boundaries
AI coding assistants can save developers time by finding relevant files, suggesting changes and running agreed tests. Their usefulness comes partly from access to the working environment. That same access deserves attention when an attacker has taken over an account or device.
Ask the technical owner which repositories, credentials, commands and external services the assistant can reach in the actual configuration. Separate ordinary development from production administration where feasible. Restrict access to what the work requires and review exceptions, including settings that reduce approval prompts. A written rule is not enough if the account and device still allow the action.
An assistant may generate normal high-volume activity. Simply blocking it on sight can interrupt legitimate development. Conversely, placing its name on an approved list should not silence all alerts about what it does. Joint guidance from CISA and partner agencies describes the wider problem of attackers using legitimate tools and cautions against indiscriminate blocking without context. The guidance is not an assessment of any particular AI product.
Test the response with your supplier
Consider a hypothetical Norwegian software company with a small internal team and an external IT provider. A developer uses an approved assistant to prepare changes to a customer portal. The security provider sees an unusual connection from that workstation and a request for files outside the developer's normal project. Neither observation alone proves an attack. Someone must establish whether the activity was authorised and act quickly if it was not.
Before an incident, agree on one exercise with fictional data:
- Identify the service owner, security contact and the person who can reach the developer outside office hours.
- Use an authorised test alert to check whether the provider can connect a suspicious action to the device, account and time, without relying only on the assistant's own explanation.
- Decide who may isolate the device or suspend the affected access, how evidence is preserved, and how customer work continues while the issue is investigated.
- Record when the alert was raised, when a person received it and when the agreed action was available. Set targets based on the business impact, not the eight-minute average from someone else's cases.
An isolation exercise must be arranged with the technical provider. Do not disrupt a production device or expose real credentials to prove that a response works. Test the fallback as well: a disconnected developer may need a clean device and a safe way to resume work.
NSM's supplier guidance recommends specifying security monitoring, incident handling and reporting when outsourcing IT. It is useful guidance, not a promise that a particular contract covers AI tools. Ask your provider to show what is included, when someone is available and what requires a separate agreement.
Investigate before drawing a conclusion
Not every unusual AI-assisted action is malicious. In a separate Elastic technical analysis, researchers describe agent-linked activity that exposed a local application and created persistent connections. They explain that the same evidence could reflect remote administration or something more serious, and do not label that case a confirmed intrusion. That distinction matters: the team needs enough information to act without treating every developer experiment as a crime.
An investigation should combine the relevant account, device, timing and network information with the employee's explanation. Security logs may contain sensitive material, so limit access and retention according to the organisation's assessment and applicable rules. The aim is to detect and contain misuse, not to collect every employee conversation indefinitely.
If a real compromise is suspected, follow the incident plan, preserve relevant evidence and determine whether credentials or customer systems were exposed. Changing a password alone may not close every session or access path. The technical response depends on the affected systems and should be coordinated with the responsible provider.
Give the board evidence, not an alert count
Management should assign ownership of approved AI tools, access decisions and the supplier response. A small AS can start with the assistant and workstation used for its most important customer-facing service. A larger business may need separate arrangements for development, administration and external suppliers.
The board should ask whether management can identify the highest-impact exposure, demonstrate that a serious alert reaches someone able to act, and explain the continuity trade-off if a device must be isolated. It should not investigate individual commands. The article on security alerts addresses the separate capacity needed to investigate incoming reports, while the incident response guide covers wider decisions once a breach is suspected.
Before the next supplier review, ask for one demonstration: if an approved AI tool behaves unexpectedly on a workstation tonight, who will know, who can contain it, and how will the business continue working?
Sources checked on 6 November 2026. The company and exercise are hypothetical. Elastic's observations are selected cases, not prevalence estimates. The illustration is AI-generated.