Cyberattacks and AI: protecting access to company data

The IZZY team first encountered this tactic on LinkedIn more than a year ago: a compromised account proposed a project, then asked us to install software for a technical assignment. We now see similar attempts regularly across our professional network.

Developers at established companies are also targeted for the access their devices give to source code, pipelines and production systems. For a business commissioning code or adding an AI feature, protection starts with three decisions: what may run on a work device, which data the application may reach, and what evidence is required before release.

1. How AI helps attackers reach company data

AI can assist with target research, drafting and localising deceptive messages, developing or debugging malicious code, building and maintaining attack infrastructure and processing stolen material. The advantage can be faster preparation, adaptation and repetition without a new exploit. AI services are also targets when their credentials give access to data or computing resources.

• Impersonation and token phishing. Compromised or cloned profiles, tailored messages and synthetic voices or video can support a false identity. Phishing-as-a-service kits such as EvilTokens, which Microsoft disrupted in September 2026, have combined AI-assisted message preparation with device-code phishing: the victim uses a legitimate sign-in page to authorise the attacker’s session. Verify the request through independently obtained contact details; the profile and authentication page do not establish whose request it is.
• Fake software and ClickFix. ClickFix disguises code execution as a repair or verification step. Campaigns have distributed information stealers such as MacSync and Atomic Stealer (AMOS) through macOS lures. Lumma is another information stealer used to collect sensitive data from devices.
• Remote administration. Attackers can abuse legitimate remote monitoring and management tools, including ScreenConnect. Remote control and information theft are different capabilities: recognising a support product does not authenticate its operator or justify access to the machine.
• Dependencies and agent tools. Malicious package versions can execute during installation. Agent plugins can run code with the user’s privileges, while MCP connections let AI applications reach external tools and data. Examine what executes and which identities it can use before trusting the resulting code change.

These mechanisms do not require AI. Its documented use in parts of an operation does not establish its involvement in every lure, including the approach received by IZZY.

2. Review the first execution before the pull request

Software supplied for a technical assignment can use a developer’s credentials before there is a change to approve.

Before running unfamiliar material, establish its origin and why execution is necessary. Inspect installation scripts, editor tasks, extensions and dependencies. Use an agreed disposable environment without production credentials or personal browser sessions; control mounted folders and network access. A container with access to the host’s files and credentials still exposes those resources.

Secret scanning and dependency analysis help with this inspection, but neither certifies an unfamiliar project as safe. The decision is whether the proposed execution has a justified, limited scope. A later pull-request approval cannot undo access already granted during setup.

If suspicious code has already run, involve the IT or security responder and preserve the messages, installation details and logs. Coordinate investigation and any identity/session containment from a clean device. A password change alone does not establish recovery, and a backup cannot recall copied data.

3. Secure code review: choose methods for the unresolved risk

When access controls are unverified, including in AI-generated code, a baseline review examines the relevant application flow and existing controls. A diff review examines a bounded change and its effects on those controls. Use threat analysis to prioritise assets and consequences, data-flow analysis to follow information across trust boundaries, and business-logic review to challenge who may perform an action. A small diff can depend on a much larger, unexamined permission model.

Choose the human format to expose those assumptions. Peer pull-request review suits a bounded change with enough context. Use a walkthrough or pair review when the path needs reconstructing together. A structured inspection assigns preparation, criteria and finding owners for consequential changes. None compensates for a reviewer who lacks the relevant domain or security expertise.

An export spanning several services, sensitive-data exposure or unresolved access questions can justify separately scoped specialist testing. Specify the uncertainty it must resolve rather than ordering an undefined “security check”. Our guide to scoping an application pentest covers what to agree before the test.

4. Invoice export: test the access rule, then accept the evidence

Consider an AI-built invoice export added to an existing customer portal. In this hypothetical example, checks take place on the company’s own staging environment with two synthetic customer accounts.

Define the actor, data and action. Customer A may export A’s invoices, never B’s. An unauthenticated visitor may export neither. Name any administrative exception. Logging in establishes identity; the server must enforce the invoice-access rule on each request.

Choose the review around that rule. Start with baseline and data-flow review of inherited authorisation: identity, customer selection, database query, export job and stored file. Then examine the export diff for changes to those controls. Prioritise cross-customer tests against the agreed invoice-ownership rule.

Test permitted and prohibited access. Test A’s permitted export, A’s attempt to obtain B’s invoices, an unauthenticated request and direct access to the generated file. Where session expiry or role removal affects export rights, define the expected policy and test it. A hidden button provides no evidence about the server or download endpoint.

Inspect response bodies and downloaded files against the rule. A success status does not prove authorisation; an error status does not prove customer data was withheld.

For the same check across requests, exports, files and realtime notifications, see Can customer A access customer B’s data?.

Keep enough evidence to review acceptance. Record the commit/build, relevant configuration, scope, account roles, test cases, actual responses and useful application traces. Link findings to corrections and retests on the corrected build. Mark unexecuted cases and unanswered questions explicitly. Agree requirements before testing; OWASP ASVS can help turn the scope into testable criteria.

5. Check the deployed system and the operating boundary

Source review does not describe everything in production. Compare the release with the actual runtime, installed dependencies, CMS components, integrations and deployment settings. For known vulnerabilities, establish whether affected versions are present and reachable, what the consequence could be and which fix or containment is available. Traditional scanners and known-exploit techniques remain relevant to attackers.

A vulnerable component may need a targeted correction or update. A wider replacement requires its own justification; our modernisation guide explains how to compare the work and acceptance evidence.

Name who receives security alerts and who can suspend the affected workflow. Where an agent inherits shared credentials or starts work in another service, stopping its interface may leave that authority or work active. Our guide to stopping one AI tool examines that boundary.