Back to Intelligence

Symantec Warns of Autonomous AI Attack Agents and LLMjacking: How to Detect and Defend Your LLM Infrastructure

SA
Security Arsenal Team
October 22, 2026
13 min read

Researchers at Symantec have disclosed a significant escalation in adversarial use of artificial intelligence: an AI agent engineered to plan and execute a complete cyber-attack chain without human operators in the loop. The agent works by hijacking large language model (LLM) infrastructure — a technique broadly known as LLMjacking — abusing stolen or misconfigured LLM API credentials and cloud AI services to power autonomous reconnaissance, exploitation, and post-exploitation decision-making.

This is not a theoretical research exercise. It is a working demonstration that the attacker's side of the equation has crossed the autonomy threshold. Where previous AI-assisted attacks still required a human to copy-paste payloads, choose targets, and pivot, this class of agent chains those decisions together: enumerate the environment, generate tailored payloads, test them, adapt on failure, and continue — at machine speed, 24/7, against thousands of targets in parallel.

For defenders, the implications are immediate:

  • Your LLM infrastructure is now a target and a weapon. Stolen API keys for OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, or Google Vertex AI give attackers free, anonymized compute for offensive tooling — billed to you, attributed to your tenant.
  • Attack dwell time collapses. Autonomous agents compress the attack timeline from days to minutes. Detection-to-response latency that was tolerable against human operators is now a losing proposition.
  • Agentic AI inside your own environment is a new attack surface. If you deploy AI agents with tool-use permissions (code execution, shell access, API calls), prompt injection and tool-chain hijacking can turn your own agent against you.

This post breaks down the threat from a defender's perspective and delivers concrete detection logic, hunt queries, and hardening steps your SOC can implement today.

Technical Analysis

What Symantec Found

Per the reporting at Infosecurity Magazine, Symantec's research team identified an AI agent architecture purpose-built for autonomous offensive operations. Key characteristics of this threat class:

  1. LLMjacking as the engine. Rather than paying for frontier-model access (which creates billing trails and identity verification friction), the operator steals LLM access. This aligns with the LLMjacking trend first documented in the wild: attackers harvest cloud credentials (AWS access keys, Azure service principals, GCP service accounts) and check whether the compromised identity can invoke managed LLM services such as Amazon Bedrock (InvokeModel, Converse API calls). If yes, they monetize or weaponize that access. Symantec's finding extends this: the hijacked model isn't just resold — it directly drives an attack agent.

  2. Autonomous attack orchestration. The agent uses the LLM as a reasoning engine to:

    • Parse reconnaissance output (port scans, banner grabs, web responses)
    • Select and generate exploitation code suited to the observed stack
    • Interpret error output and iteratively refine payloads
    • Execute post-compromise actions: credential harvesting, lateral movement decisions, data staging
  3. Tool-use and function calling. Modern LLM APIs support structured tool invocation. An attack agent registers tools (shell execution, HTTP requests, file read/write) and lets the model decide when and how to call them. This is the same architecture enterprises use for legitimate copilots — which is precisely why it is dangerous: the technique is dual-use and the traffic looks like normal API consumption.

Affected Platforms and Attack Surface

There is no single CVE here — this is a technique-level threat, not a patchable bug. The exposure surface includes:

LayerExposure
Cloud AI servicesAWS Bedrock, Azure OpenAI, Google Vertex AI, Anthropic, OpenAI APIs accessible via stolen/over-privileged credentials
Credential stores.env files, ~/.aws/credentials, CI/CD secrets, container environment variables, misconfigured vaults
In-house AI agentsInternal copilots/agentic workflows with tool-use permissions, vulnerable to prompt injection and tool-chain abuse
Model access policiesOverly permissive IAM roles allowing bedrock:InvokeModel, cognitiveservices/*, or equivalent across broad principals

Exploitation Requirements and Chain

A typical LLMjacking-to-autonomous-attack chain looks like this:

  1. Credential acquisition — phishing, exposed .git repos, public S3 buckets, infostealer logs, or compromised CI/CD runners yielding cloud keys.
  2. LLM access validation — the attacker calls InvokeModel/Converse (Bedrock) or the OpenAI-compatible endpoint with a benign prompt to confirm access and enumerate available models.
  3. Agent bootstrap — the attacker deploys their agent framework (running on their own infrastructure or a compromised host) pointed at your LLM endpoint using your key.
  4. Autonomous execution — the agent conducts attacks against third parties (or back against you), with all model inference billed and attributed to your tenant. Your cloud account becomes the attacker's AI budget and their attribution shield.
  5. Monetization/impact — resale of proxied LLM access, offensive operations, or direct attack campaigns. Victim organizations have reported Bedrock bills in the tens of thousands of dollars per day from LLMjacking incidents, plus the legal exposure of their tenant being the observed source of attack traffic.

Exploitation Status

LLMjacking is confirmed active in the wild — it has been observed in real cloud intrusions since 2024 and has continued to grow through 2025–2026 as enterprises expanded Bedrock/Azure OpenAI deployments without corresponding detection coverage. Symantec's disclosure of a fully autonomous attack agent represents the maturation of this trend: the offensive tooling is no longer hypothetical. There is no CISA KEV entry (no CVE exists), but the technique maps cleanly to MITRE ATT&CK and should be treated as an active threat.

Detection & Response

The defender's advantage: LLMjacking and agent abuse leave strong telemetry if you know where to look. Attackers must invoke models through your cloud control plane, must obtain credentials from somewhere, and autonomous agents generate characteristically bursty, high-throughput API patterns that differ from human use.

Sigma Rules

The following rules target (1) suspicious LLM model invocation in AWS CloudTrail, (2) process access to LLM/cloud credential material on endpoints, and (3) model enumeration behavior that precedes abuse.

YAML
---
title: Suspicious AWS Bedrock Model Invocation from Unusual Principal
id: 3f8a1c42-7d5e-4b9a-a2c1-8e6f0d4b5a7c
status: experimental
description: Detects Bedrock InvokeModel/Converse API calls from IAM principals or source IPs not normally associated with AI workloads. LLMjacking attackers validate stolen credentials by invoking models from foreign infrastructure.
references:
  - https://www.infosecurity-magazine.com/news/symantec-ai-agent-llmjacking/
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.impact
  - attack.t1078.004
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventSource: 'bedrock.amazonaws.com'
    eventName:
      - 'InvokeModel'
      - 'InvokeModelWithResponseStream'
      - 'Converse'
      - 'ConverseStream'
  filter_known_ai_principals:
    userIdentity.type:
      - 'AWSService'
  condition: selection and not filter_known_ai_principals
falsepositives:
  - Legitimate new AI workloads — baseline invoking principals and ARNs, then alert on deviations
level: high
---
title: Process Access to LLM or Cloud Credential Files
id: 9c2e5b17-4a6d-4f38-b1e9-2d7a3c8e5f60
status: experimental
description: Detects suspicious processes reading files that commonly contain LLM API keys or cloud credentials (.env, AWS credentials, GCP/Azure credential stores). Infostealers and LLMjacking operators harvest these before abusing model access.
references:
  - https://www.infosecurity-magazine.com/news/symantec-ai-agent-llmjacking/
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.credential_access
  - attack.t1552.001
logsource:
  category: file_event
  product: windows
detection:
  selection_target:
    TargetFilename|contains:
      - '\.env'
      - '\.aws\credentials'
      - '\.config\gcloud\'
      - '\.azure\'
      - '\openai'
      - '\anthropic'
  filter_legit:
    Image|endswith:
      - '\code.exe'
      - '\idea64.exe'
      - '\devenv.exe'
      - '\node.exe'
      - '\python.exe'
      - '\explorer.exe'
  condition: selection_target and not filter_legit
falsepositives:
  - Developer tooling and editors — tune the exclusion list to your engineering stack; investigate any access from scripting engines, Office apps, or browsers
level: medium
---
title: LLM Model Enumeration via AWS CLI or SDK
id: 5b1d9e83-2c4f-4a71-96d3-7f8e2a0b6c94
status: experimental
description: Detects enumeration of available foundation models and inference profiles, a reconnaissance step LLMjacking operators perform after validating stolen keys to determine what model access they have acquired.
references:
  - https://www.infosecurity-magazine.com/news/symantec-ai-agent-llmjacking/
  - https://attack.mitre.org/techniques/T1580/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.discovery
  - attack.t1580
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventSource: 'bedrock.amazonaws.com'
    eventName:
      - 'ListFoundationModels'
      - 'GetFoundationModel'
      - 'ListInferenceProfiles'
      - 'ListProvisionedModelThroughputs'
  condition: selection
falsepositives:
  - Platform engineers provisioning new AI workloads — correlate with principal history; enumeration by a principal that has never invoked Bedrock before is highly suspicious
level: medium

KQL — Microsoft Sentinel / Defender

The query below hunts LLM API endpoint connections from devices that have no prior history of AI traffic — useful for catching agent frameworks deployed on compromised endpoints or servers suddenly reaching out to model APIs. It assumes network telemetry in DeviceNetworkEvents and/or cloud logs in CommonSecurityLog/AzureDiagnostics.

KQL — Microsoft Sentinel / Defender
// Hunt: first-time LLM API connections from devices with no 30-day baseline of AI traffic
// Catches agent frameworks and LLMjacking validation traffic on endpoints/servers
let llm_domains = dynamic(["api.openai.com", "api.anthropic.com", "bedrock-runtime", "generativelanguage.googleapis.com", "openai.azure.com", "api.cohere.com", "api.mistral.ai", "api.groq.com"]);
let lookback = 30d;
let recent = 1d;
let baseline = DeviceNetworkEvents
    | where TimeGenerated between (ago(lookback) .. ago(recent))
    | where RemoteUrl has_any (llm_domains) or RemoteUrl contains "bedrock-runtime"
    | summarize by DeviceName;
DeviceNetworkEvents
| where TimeGenerated > ago(recent)
| where RemoteUrl has_any (llm_domains) or RemoteUrl contains "bedrock-runtime"
| where DeviceName !in (baseline)
| summarize Connections = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            RemoteIPs = make_set(RemoteIP), Processes = make_set(InitiatingProcessCommandLine)
    by DeviceName, RemoteUrl, InitiatingProcessFileName
| order by Connections desc;
KQL — Microsoft Sentinel / Defender
// Hunt: burst pattern of LLM API calls consistent with autonomous agent behavior
// Autonomous agents generate high-throughput, regular-interval inference calls unlike human users
AzureDiagnostics
| where TimeGenerated > ago(24h)
| where Category in ("AuditEvent", "RequestResponse") or ResourceProvider has "COGNITIVESERVICES"
| where OperationName has_any ("chat", "completions", "embeddings", "InvokeModel", "Converse")
| summarize CallsPerHour = count() by bin(TimeGenerated, 1h), callerIpAddress, identity_claim_upn_s, Resource
| where CallsPerHour > 200
| order by CallsPerHour desc;

Velociraptor VQL

This artifact hunts endpoints for exposed LLM/cloud credentials — the fuel for LLMjacking — by globbing common secret locations and checking process execution for AI tooling outside approved paths.

VQL — Velociraptor
-- Hunt for exposed LLM/cloud credentials and unauthorized AI agent tooling
-- Deploy across the fleet; review hits for credential rotation

SELECT FullPath, Size, Mtime,
       grep(regex='sk-[A-Za-z0-9]|aws_secret|ANTHROPIC_API_KEY|OPENAI_API_KEY|AZURE_OPENAI',
            buffer=read_file(filename=FullPath, length=4096)) AS SecretIndicator
FROM glob(globs=[
  'C:/Users/*/.aws/credentials',
  'C:/Users/*/.azure/**',
  'C:/Users/*/.config/gcloud/**',
  'C:/Users/*/**/.env',
  '/home/*/.aws/credentials',
  '/home/*/.config/gcloud/**',
  '/home/*/**/.env',
  '/root/.aws/credentials'
])
WHERE SecretIndicator

UNION ALL

SELECT Exe AS FullPath, NULL AS Size, CreateTime AS Mtime,
       CommandLine AS SecretIndicator
FROM pslist()
WHERE CommandLine =~ 'invoke-model|converse|bedrock|openai|anthropic'
   AND Exe !~ '(?i)program files|approved'

Remediation / Audit Script

The script below audits AWS environments for the LLMjacking exposure pattern: it enumerates principals with Bedrock invoke permissions, checks CloudTrail for recent invocation and enumeration events, and flags access keys older than 90 days attached to those principals. Run it per-account, per-region where Bedrock is enabled.

Bash / Shell
#!/usr/bin/env bash
# LLMjacking exposure audit — AWS Bedrock
# Requires: awscli v2, jq, appropriate read-only IAM (SecurityAudit)
set -euo pipefail

REGION="${1:-us-east-1}"
echo "=== Bedrock LLMjacking Audit — region: ${REGION} ==="

echo ""
echo "[1] IAM policies granting bedrock:InvokeModel / bedrock:*"
aws iam list-policies --scope Local --only-attached \
  --query 'Policies[*].Arn' --output text | while read -r arn; do
  ver=$(aws iam get-policy --policy-arn "$arn" --query 'Policy.DefaultVersionId' --output text)
  aws iam get-policy-version --policy-arn "$arn" --version-id "$ver" \
    --query 'PolicyVersion.Document' --output json | \
    jq -e '.. | .Action? // empty | if type=="array" then .[] else . end' 2>/dev/null | \
    grep -qi 'bedrock' && echo "  [!] $arn grants Bedrock actions"
done

echo ""
echo "[2] Recent Bedrock model invocation & enumeration events (last 24h)"
aws cloudtrail lookup-events --region "$REGION" \
  --lookup-attributes AttributeKey=EventName,AttributeValue=InvokeModel \
  --start-time "$(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --query 'Events[*].{User:Username,Time:EventTime,IP:SourceIPAddress}' \
  --output table 2>/dev/null || echo "  (no events or CloudTrail not logging Bedrock)"
aws cloudtrail lookup-events --region "$REGION" \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ListFoundationModels \
  --start-time "$(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --query 'Events[*].{User:Username,Time:EventTime,IP:SourceIPAddress}' \
  --output table 2>/dev/null || true

echo ""
echo "[3] Access keys older than 90 days on principals (rotation candidates)"
aws iam list-users --query 'Users[*].UserName' --output text | while read -r u; do
  aws iam list-access-keys --user-name "$u" \
    --query "AccessKeyMetadata[?Status=='Active'].{Key:AccessKeyId,Created:CreateDate}" \
    --output text | while read -r key created; do
    age=$(( ( $(date +%s) - $(date -d "$created" +%s) ) / 86400 ))
    [ "$age" -gt 90 ] && echo "  [!] $u — key $key is ${age} days old"
  done
done

echo ""
echo "[4] GuardDuty status (Bedrock anomaly detection requires GuardDuty)"
aws guardduty list-detectors --region "$REGION" --output table 2>/dev/null || \
  echo "  [!] GuardDuty not enabled in ${REGION}"

echo ""
echo "=== Audit complete. Rotate flagged keys, scope down Bedrock policies, and verify GuardDuty + CloudTrail coverage. ==="

Remediation

Since this is a technique rather than a single vulnerability, remediation is architectural. Prioritize in this order:

1. Eliminate Standing LLM Credential Exposure (24–72 hours)

  • Rotate every long-lived key that can reach an LLM API. Assume any key stored in .env files, CI/CD variables, or developer laptops is compromised.
  • Move to short-lived credentials: IAM roles with instance profiles/IRSA on AWS, managed identities on Azure, workload identity federation on GCP. An access key that expires in an hour is worthless to an LLMjacker.
  • Scan repos and endpoints for committed keys (the VQL artifact above, plus trufflehog/gitleaks in CI). Revoke on any hit — do not just delete the file.

2. Constrain What Stolen Credentials Can Do (Week 1)

  • Apply least-privilege scoping to AI services: grant bedrock:InvokeModel only against specific model ARNs, only from specific principals, and only via condition keys like aws:SourceIp, aws:SourceVpc, or aws:ViaAWSService.
  • Disable or don't enable models you don't use — every enabled foundation model is billable attack surface.
  • Set service quotas and budget alerts on Bedrock/Azure OpenAI spend. A bill spike is often the first LLMjacking indicator; make it a paging alert, not a month-end surprise.
  • Where supported, enforce VPC endpoints / private endpoints for model invocation so API calls cannot originate from arbitrary internet IPs even with valid keys.

3. Detection Coverage (Week 1–2)

  • Confirm CloudTrail data-plane logging for Bedrock (InvokeModel, Converse) — control-plane logging alone misses invocations. Equivalent: Azure diagnostic settings for Cognitive Services, GCP audit logs for Vertex AI.
  • Deploy the Sigma rules above and the first-time-connection KQL hunt. Baseline legitimate AI workloads first, then alert on deviations.
  • Enable GuardDuty (which now includes anomaly detection for unusual Bedrock/API activity) and route findings to your SOC.
  • Alert on model enumeration (ListFoundationModels) from principals with no invocation history — this is the LLMjacking validation step and has near-zero legitimate volume from non-admin identities.

4. Secure Your Own Agents (Ongoing)

  • If you deploy internal AI agents with tool-use capability, treat them as privileged workloads: sandbox tool execution, require human-in-the-loop approval for destructive actions, log every tool call, and apply prompt-injection defenses (input sanitization, content boundaries, output filtering) at the orchestration layer.
  • Red-team your agents. An agent that can execute code based on LLM output is one crafted prompt away from becoming the attacker's foothold — the same architecture Symantec describes, running on your infrastructure.

5. Incident Response Preparation

  • Pre-stage an LLMjacking playbook: revoke key → enumerate invocations during exposure window → assess billed usage and downstream attack attribution → notify legal (your tenant may appear as the source of attacks on third parties) → rotate and harden.
  • Add LLM API abuse to tabletop scenarios. The 2026 reality is that your IR plan must cover your cloud AI tenant being weaponized, not just your endpoints being encrypted.

The Bottom Line

Symantec's disclosure confirms what many of us in IR have been anticipating: autonomous attack agents are no longer a research curiosity. The barrier to entry is a stolen API key and an off-the-shelf agent framework. Your defensive posture must assume machine-speed adversaries and treat LLM credentials with the same rigor as domain admin — because in 2026, that's functionally what they are.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.