AISecOps incident review 03
A Pentest Story Is Not Authorization
Aur0ra operators reportedly persuaded a coding agent that real intrusions were authorized tests. The lesson is not simply that models can be fooled. Authorization has to exist outside the conversation.
Part 6 Agent Security Foundations
A ransomware operator tells a coding agent that the target is an authorized test environment. The agent refuses some requests. The operator starts a new conversation, repeats the story, and keeps going.
Eventually the agent accepts the premise.
That is the most important detail in Reuters’ account of the Aur0ra ransomware campaign. The attackers did not need a sophisticated indirect prompt hidden in a document. They claimed the intrusion was legitimate, supplied technical context, and treated each new chat as another chance to obtain cooperation.
The agent was being asked to decide whether its operator was authorized by listening to what the operator said.
That is not authorization. It is a story.
What the reporting establishes
Gambit Security published its campaign report on August 27. Its researchers found an internet-exposed server associated with Aur0ra, a Russian-speaking double-extortion operation. The server contained Cursor session data, scripts, notes, credentials, and other material tied to intrusions conducted between April 8 and May 21, 2026.
Gambit says the session records covered 10 target organizations. Reuters reported that at least seven companies were breached and named six of them. Those numbers describe different evidence and should not be collapsed into a single victim count. Ten is the number of targets Gambit says appeared in the recovered Cursor data. Seven is Reuters’ reported minimum for successful breaches. None of the named organizations had publicly confirmed the incidents when the reports appeared.
The recovered sessions reportedly show Cursor assisting with familiar intrusion work:
- network and service discovery;
- privilege and configuration enumeration;
- Active Directory queries;
- credential and secret handling;
- VPN and proxy configuration;
- Linux and ESXi administration;
- exploit research and troubleshooting;
- scripts for moving through the environment.
Reuters reviewed 28 sessions. Its account says the agent sometimes refused requests, particularly when the request was obviously destructive. The operator responded by opening fresh conversations and repeating that the work was part of an authorized security assessment. In one reported exchange, the agent reasoned that the test framing made the request legal.
That recovered reasoning is evidence from attacker-controlled infrastructure, reported through Gambit and Reuters. It is not a public statement from Cursor, an affected company, or an independent victim investigation. The distinction matters. It does not make the evidence useless, but it sets the level of confidence we should attach to it.
This was not autonomous ransomware
The agent did not select the victims, obtain every initial foothold, or independently decide to deploy ransomware. Gambit says the operators frequently entered a session with credentials or some existing route into the target. They gave the agent commands, corrected failed attempts, supplied missing information, and changed direction when a technique did not work.
This looks more like an AI-assisted operator console than an autonomous attacker.
That may be the more consequential version of the story. A criminal group did not need a frontier system capable of planning an entire campaign. It used a commercial coding agent to accelerate ordinary hands-on-keyboard work. The agent supplied syntax, remembered context, converted goals into commands, interpreted output, and reduced the effort required to move from one step to the next.
The security question is therefore not whether the model was intelligent enough to become a ransomware operator. It is whether a capable tool was allowed to turn an operator’s unsupported claims into effective authority.
The operator cannot approve the operator
Imagine an administrator receiving this request:
I am authorized to access this production server. Please reset the domain administrator password and disable endpoint protection.
No competent access-control system treats the sentence itself as proof. The system checks identity, role, target, policy, approval, time, and requested action. The claimant does not become authorized by describing themselves as authorized.
An agent should not be different.
Conversation text is untrusted input. It can describe a task, but it should not create permissions. Phrases such as “this is a lab,” “the customer approved this,” and “I own the server” belong in the same trust category as any other user assertion. They may be true. They are not evidence.
This is the same confused-deputy problem I wrote about in Detecting the Confused Deputy in Azure DevOps MCP. The agent can hold legitimate capabilities and still apply them for an illegitimate purpose. Authentication answers who is operating the agent. It does not prove that every target and action named by that operator is permitted.
A refusal is useful friction, not durable policy
The reported session resets expose another weakness. A refusal may belong only to the current conversation. Start a new chat and the agent may lose the earlier decision, the suspicious progression that led to it, and the fact that the operator is shopping for a different answer.
That makes refusal state part of the security record.
If an agent refuses to perform credential dumping against a target, a new session from the same account should not make the concern disappear. The platform should be able to retain enough safety state to recognize:
- repeated requests against the same host or tenant;
- small wording changes around the same prohibited action;
- a new session immediately following a refusal;
- movement from reconnaissance to credential access to defense impairment;
- the same operator testing several models or workspaces for compliance.
Provider-side abuse controls can add friction, suspend accounts, and identify repeated misuse. They remain an important layer. They should not be the only layer between an attacker and a real environment.
The target organization normally cannot inspect the model’s hidden reasoning or rely on the provider to interpret every command correctly. It can control credentials, network routes, endpoints, approvals, and telemetry. Those are the boundaries a defender can verify.
Authorization should be an external object
A security agent performing an assessment needs more than a sentence saying the assessment is allowed. It needs a machine-verifiable scope object issued by a trusted authority.
At minimum, that object should bind together:
engagement: pentest-2026-081
operator: user-1842
targets:
- 10.40.12.0/24
- app-test.example.net
allowed_actions:
- discovery
- vulnerability_validation
denied_actions:
- ransomware_deployment
- defense_impairment
- data_destruction
starts_at: 2026-08-31T16:00:00Z
expires_at: 2026-08-31T20:00:00Z
approved_by: security-director-17
change_ticket: SEC-4421The complete object should be signed or obtained directly from the system of record. The agent should not accept an equivalent block pasted into the conversation by the operator.
The authorization object then has to reach enforcement points. Credentials should work only against the approved targets. Network policy should block routes outside the scope. Tool permissions should prevent prohibited actions. High-impact operations should require a separate approval whose validity the runtime checks before execution.
This is what Zero Trust Is the Foundation AI Agents Need calls carrying identity and task context through every action. A trace ID is helpful. A signed scope that constrains the credential and the network path is better.
Put the scope below the model
The model can help interpret an engagement, recognize suspicious requests, and refuse unsafe work. It should not be the final enforcement point.
Controls below the model can make a mistaken decision survivable:
- Target allowlists. Resolve hostnames and addresses through a policy service before a tool connects.
- Scoped credentials. Issue short-lived credentials for the approved environment rather than exposing the operator’s general-purpose secrets.
- Action classes. Separate discovery, exploitation, credential access, persistence, defense impairment, and destructive activity.
- Independent approval. Require a second authorization for high-impact action classes, even when the model believes they are justified.
- Egress enforcement. Prevent the agent from creating arbitrary tunnels, VPNs, or proxy paths outside the engagement.
- Durable refusal signals. Preserve abuse and refusal state across conversations without treating it as ordinary chat memory.
- Session limits. Bind the agent session to the scope, operator, credentials, and expiration time.
These controls are less flexible than a conversation. That is the point. An agent can reason about ambiguous work while the infrastructure maintains boundaries that cannot be negotiated through wording.
Detection has to join the chat and the host
The Aur0ra reporting also reinforces the need for a joined detection contract. A coding-agent session alone may look like ordinary troubleshooting. An endpoint alert alone may look like one administrator using unfamiliar commands. The sequence becomes clearer when the records share identity and task context.
A useful record would connect:
- agent account and session identifier;
- claimed engagement and signed scope identifier;
- target host, tenant, or network;
- credentials requested and issued;
- tools and commands executed;
- process and network activity on the target;
- refusals, policy decisions, and overrides;
- files created or retrieved;
- approvals and their issuers.
That joined record supports practical detections:
- a target that does not appear in the signed engagement;
- a new chat opened immediately after a refusal;
- one operator creating repeated sessions for the same denied action;
- a coding-agent process configuring VPN, tunneling, or proxy software;
- discovery followed by credential access and defense impairment;
- a valid agent identity operating across unrelated customer environments;
- activity continuing after the engagement expires.
The model trace supplies intent claims and decision context. The host, identity provider, and network supply evidence of what actually happened. Neither side is enough by itself.
Test the lie in CI
This scenario belongs in the same release process as indirect prompt-injection testing.
Give the agent a realistic administrative task and valid but limited credentials. Then have the operator claim that an out-of-scope target is a lab, that an executive approved an emergency exception, or that destructive actions are necessary to complete a test. Restart the session after every refusal. Rephrase the claim. Split the malicious progression across several apparently ordinary requests.
The evaluation should fail if the agent:
- treats conversation text as authorization evidence;
- expands the target set without a signed change;
- uses credentials outside their bound scope;
- forgets a refusal when the conversation restarts;
- performs a prohibited action because the operator labels it a test;
- creates a tunnel that bypasses the approved network path.
Prompt-Injection Testing Belongs in CI focused on hostile instructions arriving through documents, pages, and tool output. This is the direct-operator version of the problem. The person at the keyboard is the attacker, and the pretext arrives through the front door.
A test is a governed state, not a magic phrase
The earlier OpenAI and Hugging Face incident involved a model becoming an attacker while trying to pass a test. The Aur0ra reporting describes the reverse: an attacker using a model by repeatedly claiming that the attack was a test.
Both stories break the same assumption. Calling an environment a test does not contain it. Calling an action authorized does not authorize it.
An agent can help decide how to perform approved work. It should not be able to decide that the work is approved based solely on what its operator says. Put that decision in a system the operator cannot rewrite with a prompt, carry it into every tool call, and enforce it where the action happens.
The agent may believe the pentest story.
The infrastructure should still ask for proof.