LLMjacking: Response and recovery
Expanded web report · Related PDF snapshot: 22 October 2026 · PDF page 11
Research reviewed 22 October 2026 · Evidence and editorial planning guidance are distinguished below.
Start with the incident-specific sequence
Restrict unintended public access and suspend suspect credentials through the incident process. Preserve request and usage metadata while avoiding unnecessary retention of sensitive prompt contents.
Use the current primary guidance and the accountable incident lead to resolve sequencing conflicts. Coordinate parallel teams before changing shared identities or destroying evidence. Urgent containment may need to proceed before every record is collected, but the decision and evidence lost should be documented.
Restore a trusted operating path
Enforce authentication and authorisation, bounded requests and concurrency, spend monitoring and server-side tool permissions. Retire endpoints that no longer have a business owner.
- Test the operational response to usage spikes and unavailable limit services.
- Bound retries, runtime and output, and verify cancellation and denied tool operations.
- Review temporary endpoints with delivery teams after launches and demonstrations.
Verify before resuming
Test unauthenticated rejection, exhausted-budget behavior and denied tool actions. Verify that the system stops accepting expensive work when the relevant capacity boundary is reached.
Ask the operational owner to exercise the essential workflow, including background tasks and customer exceptions. Keep a short record of what passed, what failed and what remains untested. Define who may accept an exception and when it must be revisited; an exception should not disappear into a general restoration announcement.
A scenario to rehearse
Illustrative exercise, not an observed customer incident: An internal demonstration endpoint is shared publicly and begins generating provider charges overnight. The exercise measures whether usage alerts lead to a verified shutdown before the next billing review.
Keep customers informed
Use the approved message for capacity restrictions and manual support.
A support fallback and an incident trend summary without raw sensitive prompts.
Restart decision
Expose an AI service only when its owner can identify permitted users, bound resource use and interrupt abuse without depending on model cooperation.
After stabilization, review which shared dependency allowed the exposure to spread or slowed recovery. Choose a measurable improvement and an accountable owner. A new platform is useful only when its responsibilities, evidence and recovery path fit the business requirement.