> ## Content Index
> Fetch the complete content index at: https://arkar.dev/llms.txt
> Use this file to discover other available public pages before exploring further.

# 2/4: How AI Is Changing the Attacker’s Workflow
- URL: https://arkar.dev/security-age-ai-part-2-attacker-workflow/
- Published: 2026-10-30T10:31:00.000Z
- Updated: 2026-11-01T13:28:31.000Z
- Description: Where AI reduces attacker effort, what real campaigns establish, and how a hypothetical coding-agent workflow exposes the boundaries that matter.
- Author: Arkar Min Tun
- Tags: Cybersecurity, AI, Security in the Age of AI

An attacker has obtained a configuration file. It is unfamiliar, messy, and full of details that might matter. Someone has to read it, interpret the errors, and decide what to investigate next. Quite a lot of that work resembles our normal day as software engineers.

AI assistance matters here even if a human still chooses the target and makes the important decisions. Saving effort at an expensive step can make another attempt affordable.

[Part 1](https://arkar.dev/security-age-ai-part-1-attackers-defenders/) examined what the public evidence can establish. Here, the question is narrower: which work becomes easier, and what still has to go right for that work to cause harm?

## A concrete example: the CSV import service

Consider a hypothetical small SaaS team. Its application imports customer CSV files through a background worker. A coding agent reads the repository and issue tracker, runs tests in a development workspace, and opens pull requests. A separate CI workflow builds releases. In the initial, unsafe setup, the workspace also inherits a developer’s broad GitHub credential.

A public issue contains an attachment and instructions that claim a diagnostic upload is needed to reproduce an import failure. Assume an attacker controls that issue content. This is an illustrative trust-boundary exercise, not a reported intrusion or a claim that a particular model would obey it.

There are two distinct possibilities. A remote operator could use their own AI assistant to understand leaked configuration or adapt routine tooling. Or the attacker-controlled issue could try to redirect the team’s legitimate agent. The first helps the attacker do work; the second tries to make trusted software act on untrusted instructions. They may share a model technology, but they cross different boundaries.

## Where assistance changes the workload

**Getting oriented.** In our example, a configuration file might reveal that uploads are processed by a worker rather than the web service. Assistance could help an operator form that hypothesis more quickly. It still needs verification: a configuration entry can be stale, and a plausible service relationship can be wrong.

**Adapting routine tooling.** Parsing unfamiliar output, comparing records, and rewriting a utility for another format are ordinary development tasks. Assistance could reduce the effort of trying the next variant. Whether that effort translates into access depends on the credentials, reachable services, and actual behavior of the target.

**Choosing what deserves attention.** An operator facing many files may use summaries to narrow the next investigation. The meaningful outcome is useful progress. A larger pile of generated scripts or failed requests does not, by itself, establish greater effectiveness.

These are mechanisms I would investigate, rather than measured savings for this fictional team. The real campaigns below show why the possibility deserves attention and why their reported limits belong in the account.

![Diagram applying four questions (information, decision, actions, afterward) to a hypothetical stolen configuration file: an assistant that only summarizes it leaves the operator to act, while an assistant with tools and credentials may be able to act on the summary itself.](https://arkar.dev/content/images/2026/11/part2_same_summary_authority.png)

## What the FortiGate campaign actually showed

[Part 1](https://arkar.dev/security-age-ai-part-1-attackers-defenders/) covered the facts of Amazon Threat Intelligence’s [20 February 2026 report](https://aws.amazon.com/blogs/security/ai-augmented-threat-actor-accesses-fortigate-devices-at-scale/?ref=arkar.dev): a financially motivated actor using commercial generative AI services compromised more than 600 FortiGate devices across over 55 countries between 11 January and 18 February 2026\. The way in was familiar: exposed management interfaces and weak single-factor credentials, not FortiGate vulnerabilities.

Two further details matter for the attacker’s workflow. AWS says the actor used at least two distinct commercial LLM providers and AI-generated attack plans with step-by-step instructions. It also says that while the AI produced technically accurate command sequences, the actor struggled to adapt when conditions differed from the plan and could not debug failed exploitation attempts.

My takeaway is that improving an attacker’s productivity can matter even when that attacker remains technically limited. A team does not need to be targeted by an exceptional operator for weak access controls to become expensive.

## What the Claude Code espionage report adds

[Anthropic’s 13 November 2025 report](https://www.anthropic.com/news/disrupting-AI-espionage?ref=arkar.dev), also covered in Part 1, assesses that a Chinese state-sponsored group used Claude Code against roughly 30 targets, with AI performing an estimated 80–90% of the campaign’s work. Two details are useful here. Humans stepped in at perhaps 4–6 critical decision points per campaign. And the operators got the model to cooperate by splitting the attack into small, seemingly innocent tasks and telling it that it worked for a legitimate cybersecurity firm doing defensive testing.

Still, it would be a mistake to dismiss the report because humans remained involved. In my experience, most useful automation leaves people somewhere in the loop. The relevant question is which work the human no longer has to perform directly.

Both this report and the AWS investigation provide meaningful evidence of misuse. Neither gives us a representative sample of the whole internet. Their visibility, investigative methods, and definitions differ.

## Autonomy is a collection of decisions

I would be cautious when someone describes an attack as either fully autonomous or entirely human-driven. There are more useful questions in between.

- Who chose the target and objective?
- Who supplied access, tools, and credentials?
- Could the agent change its plan after failure?
- Which steps required human approval?
- Who verified that an apparent success was real?
- What stopped the operation when its assumptions were wrong?

A framework can automate many requests while leaving the difficult judgment to a person. Another can make useful decisions but require a human to execute them. A third may have enough authority to act and too little evidence to act correctly.

Counting tool calls does not resolve those differences. Neither does measuring how long an agent ran unattended. A long-running system can spend a surprising amount of time being wrong.

For defenders, the practical concern is the combination of capability and permission. What can this system understand, and what can it reach once it makes a decision?

## Attacker use and attacks against agents are different stories

The [Nx S1ngularity postmortem](https://nx.dev/blog/s1ngularity-postmortem?ref=arkar.dev) describes malicious packages published on 26 August 2025\. Their post-install code searched for sensitive information, attempted to invoke local AI tools, and used the GitHub CLI to upload results.

This is different from a remote operator deliberately running an attack agent. Here, malicious code entered an environment where useful tools were already installed. “Attempted to invoke” also leaves open whether a particular local agent complied.

That distinction changes the engineering discussion. I would want to know what a package installation can access on a developer machine, which authenticated tools share the environment, and whether the coding agent has authority unrelated to the current project.

A prompt saying “only work on this repository” expresses the intended task. It does not revoke a cloud token or remove access to another directory.

[OWASP’s Agentic Applications Top 10 for 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/?ref=arkar.dev) is useful vocabulary here: it distinguishes risks including tool misuse, identity and privilege abuse, and agentic supply-chain weaknesses. A threat taxonomy is a way to structure a review, not a measurement of how often each failure occurs.

## Why old weaknesses still matter

When AI enters the story, it is easy to assume the defense must be equally novel. Sometimes it should be. But the reported entry conditions in these cases keep bringing us back to familiar questions.

Is the management interface exposed? Is the identity narrowly scoped? Does one compromised environment contain credentials for several others? Can a dependency installation reach a publishing token?

My hypothesis is that lower investigation and scripting costs make overlooked weaknesses easier to revisit. I am not claiming a measured increase for every organization. I am saying the case for relying on an attacker being too busy or too unfamiliar with our stack is getting less comfortable.

The useful response is to reduce what a successful first step unlocks. Strong authentication helps at entry. Separate identities and network boundaries help after entry. Logs and tested revocation help us discover and interrupt a chain that has already begun.

## Where the hypothetical chain can stop

Return to the CSV issue. Before a malicious instruction can cause a consequential action, several conditions have to line up: the agent must encounter it, treat it as actionable, have a suitable tool, and possess authority over something worth changing. A failure at any of those steps changes the outcome.

If the agent suggests an upload but the tool rejects the destination, the record shows an attempted redirection and an enforced boundary. If a reviewer rejects a proposed workflow change, the record shows a prevented change. If an authorized tool actually transmits a sensitive file, that is a different outcome requiring containment. Counting all three as successful “AI attacks” would make the evidence less useful.

The team can exercise these conditions with dummy secrets, an approved test receiver, and a disposable repository. Record the requested action, the tool’s decision, and any actual side effect. Do not use production credentials to find out whether a boundary exists.

## What changes the attacker’s options

For our fictional team, removing the inherited GitHub credential prevents a workspace compromise from automatically carrying the developer’s release authority. Restricting outbound destinations addresses the proposed diagnostic upload. Independent review of release-workflow changes addresses another route to publication. Each control interrupts a specific transition in the scenario.

None of those decisions depends on knowing whether the attacker used a model to write the issue. That is useful: attribution may remain uncertain while the team can still reduce reachable authority.

The uncomfortable economic possibility is that assistance makes unfamiliar systems cheaper to investigate and familiar weaknesses easier to revisit. The documented campaigns support taking that possibility seriously; they do not give us a universal productivity multiplier.

In Part 3, the same CSV service has a real bug to fix within the hypothetical scenario. We will follow the defender’s work from a plausible finding to evidence that a safe fix reached the running worker.