Respond to LLMjacking With an Evidence-Linked Exposure Review

Why exposed model infrastructure needs an incident playbook

On October 21, 2026, Symantec described an autonomous offensive agent captured by an AI honeypot. The researchers said its instructions searched for exposed model endpoints, attempted to shift inference costs to victims and equipped the agent with 74 offensive tool definitions. The captured prompt was designed for up to 100,000 unattended steps. Those details describe one observed tool, not every probe against an AI service.

The same research reported more than 127,000 requests to the honeypot from tens of thousands of addresses during the monitoring period, dominated by model-endpoint reconnaissance, stolen-key spraying and exposed-configuration probes. An open endpoint can be a self-hosted model server, an AI gateway in front of paid accounts, a test relay or an MCP server connected to tools.

A focused Firecrawl search on October 24 returned the Symantec analysis prominently and multiple independent reports dated October 21–23. That is a current public-interest signal, not evidence that a particular organization was breached, a traffic estimate or a promise that this article will rank.

1. Build the exposure register from authoritative records

Start from approved records rather than scanning the internet from an analyst laptop. Export model-serving deployments, API gateway routes, load balancers, cloud IPs, DNS names, certificate records, service catalogs, MCP registrations, provider accounts and billing projects. Add the owner, environment, authentication control, network boundary and expected request pattern for every candidate.

Ask an enterprise-approved assistant to normalize only sanitized metadata. Suggested prompt: “Reconcile these approved inventory exports into one row per AI endpoint. Cite every source record. List owner, environment, public route, authentication method, upstream provider or local model, expected callers and missing evidence. Do not reproduce secret values or infer that an endpoint is safe.”

Expected output: a review queue that helps humans locate gaps. The assistant cannot prove whether a host is reachable, whether a credential is valid or whether a request was malicious. A platform owner and security reviewer must confirm each row.

2. Separate observations from hypotheses

For each endpoint, preserve request logs, gateway decisions, identity events, cloud network records, provider usage, token or GPU consumption and configuration history under the incident plan. Record collection time and retention limits. Do not execute suspicious payloads, replay attacker requests or contact infrastructure identified in threat reporting.

Use the assistant to link claims to evidence: “For each endpoint, list observed activity, source record, timestamp range, expected baseline, anomaly and unresolved question. Mark any statement without a cited record as a hypothesis.” Reviewers should reject fabricated certainty and keep absent telemetry as an unknown.

Unexpected spend, unusual source ranges, denied requests or a public listener are useful leads. None alone proves that an attacker controlled the model. Preserve the distinction between exposure, attempted use and confirmed unauthorized use.

3. Contain access and cost without destroying evidence

Use approved cloud, gateway and identity controls to remove unintended public reachability, require strong authentication, restrict allowed callers and cap resource consumption. Where business service must continue, route through a managed gateway with explicit identities, rate limits and bounded tools instead of leaving a model listener open.

Rotate keys and revoke sessions that were reachable from an exposed gateway or host. Include upstream model-provider tokens, cloud identities, MCP credentials and downstream service credentials supported by evidence. Perform changes from clean administrative systems and record the old identifier, owner, change event and rejection test without storing the secret value.

Containment should run in three lanes: boundary, identity and observability. Closing a firewall path while leaving a leaked provider key active—or rotating a key while an unauthenticated listener remains public—does not finish the job.

4. Prove old paths fail and expected work still succeeds

Test from an authorized location that the former public route is closed or now demands the intended control. Confirm an old token or session is rejected without placing it in a prompt. Then verify the approved workload using a synthetic, non-sensitive request and check that billing, rate limits and monitoring behave as expected.

Suggested closeout prompt: “Compare the before-and-after register. Cite the network check, revocation event, successful authorized request, usage baseline and monitoring rule for each endpoint. List any endpoint lacking one of those records as open.”

Keep a follow-up window for spend, unusual sources and repeated authentication failures. Symantec’s research supports assuming exposed AI services will be found and tested; it does not supply a universal dwell time or a safe monitoring duration for every environment.

Response checklist and realistic limits

AI can reconcile records and draft reviewer-ready questions, but it cannot establish forensic truth from incomplete telemetry, decide legal notification obligations or operate production controls without authorization. Escalate confirmed or suspected unauthorized use through the organization’s incident, privacy, legal and provider-support processes.

• Inventory model servers, gateways, relays, test endpoints and MCP services.
• Keep secrets, raw prompts and customer data out of the assistant.
• Close only after independent network, identity, workload and monitoring checks.