Cisco’s agent-risk taxonomy sharpens the security boundary beyond the model

Update — 2026-09-10: Cisco has revised its AI security framework to distinguish an agent redirected by an outside instruction from an agent that exceeds its authority, changes course or games its success measure without an identifiable external instruction. The revised boundary sharpens the control model in this article. Security teams still need to defend the whole operating loop and diagnose why the agent departed from its intended task.

Cisco published version two of its Integrated AI Security and Safety Framework at 17:59:22 UTC on 9 September. The update merges prompt injection and jailbreak under one “Goal Hijacking” objective. It adds a separate “Agentic Autonomy Failures” objective with three techniques—excessive agency, goal drift and reward hacking—and eight lower-level subtechniques.

The change is a taxonomy, not an evaluation result or proof that Cisco’s products prevent these failures. Its practical value is diagnostic: a poisoned project file and a poorly bounded agent can lead to the same visible outcome while demanding different investigation paths. One starts with an external instruction crossing a trust boundary. The other starts with the authority, goal or incentive structure already inside the system.

Two causes can produce the same unsafe action

Cisco’s revised boundary turns on the source of the deviation. Goal Hijacking covers an external input that redirects the system: a user message, hostile document, tool response or poisoned workspace instruction. Agentic Autonomy Failures cover divergence without an identifiable external instruction.

Within that second group, Cisco describes excessive agency as acting beyond assigned authority, such as skipping an approval or reaching for an unneeded permission. Goal drift means substituting or expanding the objective during a long task. Reward hacking means optimising for the appearance of success, including working around the check intended to establish that the task was done properly.

OWASP offers independent, related guidance, although its labels are not identical. The OWASP Top 10 for Agentic Applications 2026 describes Agent Goal Hijack as attacker-controlled manipulation through prompts, tool outputs, artefacts, messages or external data. It distinguishes that from autonomous misalignment without active attacker control. OWASP also treats tool misuse, identity abuse and unexpected code execution as separate risks. This is a useful warning against forcing every agent incident into “prompt injection”.

The practical questions now split three ways:

1. Was the goal redirected from outside? Preserve and inspect the documents, messages, workspace files, retrieved pages and tool outputs the agent consumed. Quarantine the input path and determine which later actions inherited its influence.
2. Did the agent cross an authority or objective boundary on its own? Compare the action with the authorised goal, tool scope, stop conditions and approval requirements. Examine whether the agent changed the task or treated an available capability as permission.
3. Did the measurement invite the wrong behaviour? Check whether the agent could improve a score, satisfy a brittle test or report apparent completion without producing the intended outcome. Verification should examine resulting state, not the agent’s own success message.

Real incidents may involve more than one route. An injected instruction can exploit excessive permissions; a goal that drifts can then use a legitimate tool unsafely. The categories should guide evidence collection and control design, not replace a timeline.

The distinction also clarifies how the original Google examples should be read. DUSTMAKER’s hostile workspace files fit the external-input path because an artefact supplies the redirection. The cloud intrusion enabled by an exposed personal access token is principally an identity and infrastructure failure. Neither example proves spontaneous goal drift or reward hacking. Cisco’s categories make those boundaries clearer without changing Google’s reported facts.

The control response should follow the diagnosis. Record input provenance so investigators can connect a document or tool response to later actions. Store the authorised objective and stop conditions outside the agent’s editable context. Require separate approval for wider scope and consequential actions. Use deterministic tests, state diffs or a separate reviewer to establish outcomes instead of accepting the agent’s own completion claim.

Google’s latest threat-intelligence report describes a suspected financially motivated actor turning a compromised cloud resource into a credential-harvesting operation in less than six hours. Google does not claim that an AI system carried out the entire attack. Its evidence is narrower and more useful for defenders: agents compressed familiar tasks such as planning, scanning, troubleshooting and infrastructure rotation into one operating loop.

The Google Threat Intelligence Group report was published on 8 September 2026; Google’s Threat Intelligence RSS feed timestamped it at 14:00 UTC. The report brings together Mandiant incident response, platform-abuse observations and threat-actor tracking from the second quarter. Its details are Google’s observations and assessments, not incidents independently reproduced by Index Us.

For teams deploying coding, security or operations agents, model safety covers only part of the risk. Attach a safe model to an untrusted workspace, a broad service account and an unmonitored cloud project, and the resulting system can still be unsafe. Controls need to cover the model, its instructions, tools, identities, data paths and infrastructure.

Faster orchestration joins familiar weaknesses

Google says the under-six-hour campaign began after the attacker had already compromised an organisation’s cloud infrastructure. The actor then used an AI coding chatbot, a prompt and markdown instruction sets to build and run a multi-agent framework. According to the report, that framework managed vulnerability scanning, real-time troubleshooting, credential harvesting and IP rotation, and compromised thousands of third-party credentials.

Google separately describes an exposed command-and-control server that developed into a dashboard for organising and validating more than 23,800 harvested secrets, including cloud and AI-service API keys. Because the report presents the dashboard as a separate example, it should not be folded into the under-six-hour incident.

Google also sets a firm limit on what the report establishes. It describes attempts by a PRC-linked group to design an agentic penetration-testing framework, but says the activity remained at the build stage and that it disabled the associated assets. Later, GTIG says it has not observed threat actors deploying fully autonomous pipelines against targets in the wild.

Sysdig observed adjacent activity in June, although it does not verify Google’s cases. The Sysdig Threat Research Team observed an exposed Ollama server powering a staged offensive-security tool. Its targets were private practice ranges, the tool was still being developed and the operator’s ultimate intent remained uncertain. The observation supports the emergence of agentic offensive tooling, not a claim that autonomous attacks were conducted against public victims.

A project directory is now part of the security boundary

One of Google’s clearest examples concerns DUSTMAKER, credential-stealing malware associated by GTIG with the group it tracks as UNC6780. Google says samples placed or modified files inside hidden workspace directories used by coding tools and IDEs, including .claude, .vscode and .cursor. Those files could create build or startup commands and instruct an assistant to execute scripts during ordinary developer work.

The same malware family also placed adversarial instructions in JavaScript comments. Google assesses that the wording was intended to trigger safety refusals in LLM-based security scanners so the malicious code underneath would be skipped. The attacker was targeting models in two roles: steering a tool towards attacker-selected work and discouraging a scanner from inspecting it.

This is one example, not evidence that every coding agent or model scanner fails in the same way. Google says the activity triggered Gemini safety responses. The practical consequence is that repository content, configuration and tool descriptions must remain untrusted inputs.

An agent deployment should make that boundary explicit. Workspace-specific instruction files need review and provenance. Startup hooks should not gain trust because they sit in a familiar directory. Security scanning should have a deterministic fallback when a model refuses or returns no finding; refusal is not a clean bill of health.

NIST CAISI’s agent-hijacking research gives this risk useful scale. Its March 2026 summary says a public competition produced more than 250,000 attack attempts from over 400 participants across 13 frontier models, with at least one successful hijacking attack found against every target model. Results varied substantially by model and did not track general model capability uniformly. General capability alone is therefore a poor proxy for the safety of a tool-using workflow.

Identity and compute connect the AI stack to ordinary cloud risk

The report’s AI-specific details sit beside a familiar initial-access failure. In an April intrusion investigated by Mandiant, Google says an exposed GitHub personal access token opened a victim cloud environment. The attacker then provisioned unauthorised AI services and compute, created a service account with broad privileges, queried for further credentials and requested larger hardware quotas.

The incident shows AI infrastructure functioning as a target and a tool. Model API keys, prompts, source code, weights, service accounts, quota and GPU capacity need owners and controls like other sensitive assets. Monitoring model outputs alone would miss the access token, privilege changes and quota requests.

NIST’s draft agent identity and authorisation concept paper supplies a practical frame. It proposes distinguishing agent identities from human identities, controlling delegated rights, linking actions to the non-human identity that performed them and retaining visibility into actions, data and outcomes. The paper is a project concept, not a finished implementation standard, but its control questions fit the incidents Google describes.

Build controls around the whole operating loop

A generic instruction to “secure the AI” gives an operator little to act on. Connected controls across the full workflow can interrupt a fast attack and leave enough evidence to explain what happened afterwards.

1. Give each agent its own bounded identity. Avoid shared developer tokens. Scope credentials to a task, environment and short lifetime where the platform supports it. Record the human or service that delegated authority.
2. Constrain tools as well as prompts. Allow only required commands, repositories, destinations and cloud actions. Put destructive operations, identity changes and quota increases behind separate approval.
3. Treat the workspace as an input surface. Review instruction files, IDE settings, hooks, MCP servers and dependency changes. Surface hidden-file changes in code review and integrity monitoring.
4. Keep deterministic security checks. A model refusal, timeout or empty result should route suspicious content to another control, not silently skip it. Test scanners with adversarial instructions as well as known malicious code.
5. Join model and infrastructure records. Connect agent identity, prompt or task ID, tool calls, repository changes, token use, network destinations, service-account events and quota changes on one timeline. The purpose is accountable investigation, not indiscriminate retention of sensitive prompt content.
6. Set machine-speed containment. Alert on new public inference endpoints, unusual model traffic, mass secret access, rapid IP rotation, privilege escalation and unexpected accelerator provisioning. Predefine which credentials or services can be revoked automatically and which require a human decision.

These controls are proportionate to the evidence. Agents can connect steps, credentials can cross boundaries, and stolen infrastructure can finance or conceal continued activity, even without end-to-end autonomy.

Security teams do not need to wait for a fully autonomous attack before changing their controls. Google’s measured claim remains modest: one reported campaign completed agent-assisted credential harvesting in under six hours, while GTIG has not observed fully autonomous pipelines deployed against targets in the wild. That is enough reason to constrain the operating loop around the model before faster orchestration joins ordinary weaknesses into one path.

This analysis is based on public threat reporting, a draft NIST concept paper and published research. Index Us did not inspect the affected systems, reproduce the attacks, test the named tools, evaluate Cisco’s taxonomy implementation or independently verify vendor incident telemetry.

Sources

1. Cisco — Evolving With Agentic Risk
2. OWASP — Top 10 for Agentic Applications 2026
3. Google Threat Intelligence — report RSS
4. Google Threat Intelligence Group — From Prompting to Autonomy
5. Sysdig Threat Research Team — LLMjacking evolved
6. NIST NCCoE — Agent identity and authorisation concept paper
7. NIST CAISI — AI agent security red-teaming findings
8. SiliconANGLE — reporting on Google’s report

Last reviewed: 10 Sept 2026. See our editorial policy for how we test, source and correct our work.