Breach the Perimeter via Prompt Injection

What this lab covers

You interact with an AI assistant exposed by an application, work out what it has been told and what it can reach, and use what it discloses to gain access to cloud storage and then further into the environment.

The lab is deliberately not about jailbreaking for its own sake. The interesting question is what happens after extraction, and here the answer is a credential that leads into Azure, which is the shape most AI security incidents actually take.

It suits anyone deploying LLM features into a product, as well as testers encountering them. No prior AI experience is assumed.

How prompt injection works

A language model receives its instructions and its input in the same channel. There is no structural separation between the developer's system prompt and the user's message equivalent to the separation between code and data in a parameterised database query, so instructions in user input compete with the original ones.

Direct injection is the user telling the model to disregard its constraints or reveal its configuration. Indirect injection is more consequential: instructions hidden in content the model retrieves, such as a document or web page, which the model processes as though the author were the operator.

System prompts are frequently treated as secret and are not. They commonly contain internal endpoints, business logic and occasionally credentials, on the assumption that users only see the assistant's replies. Extraction is generally a matter of persistence rather than sophistication.

How to detect this in your own environment

Log the full interaction, including the model's inputs and outputs, and treat them as security-relevant telemetry rather than product analytics. Most organizations deploying assistants cannot reconstruct what a user asked or what the model returned, which makes investigation impossible.

Alert on outputs containing credential-shaped strings, internal hostnames or fragments of the system prompt. This is more tractable than detecting the injection itself, because the attempts vary endlessly while the successful outcome has a recognizable shape.

On the cloud side, watch the identity the assistant uses. An application identity retrieving storage or calling services outside its normal pattern is the same detection you would build for any workload, and it is where the consequence becomes visible.

How to prevent it

Assume the system prompt is public and put nothing in it you would not publish. This is the single most reliable control, because it removes the value of extraction rather than trying to prevent it.

Scope the model's tools and identity tightly. The real question is not what the model might say but what it can do, so an assistant that can read one dataset is a contained problem while one holding broad credentials is not.

Validate and constrain on the output side. Treat model output as untrusted input to whatever consumes it, and enforce authorisation in the application rather than relying on the model to refuse. A model that declines is a preference, not a control.

Real-world context

Prompt injection is recognized as the leading risk in the OWASP Top 10 for Large Language Model Applications, and remains unsolved in the general case because it follows from how models process instructions rather than from an implementation defect.

The Azure Storage shared access signature is a good example of why the second stage matters. A SAS token is a URL that carries its own authorisation, so it works for anyone who holds it, and it has featured in significant real-world exposure incidents. A model that can be induced to reveal one has handed over durable access.

The pattern maps to MITRE ATLAS techniques for prompt injection and LLM data leakage, and on the cloud side to MITRE ATT&CK T1552 Unsecured Credentials and T1078.004 Cloud Accounts.

Applying this at work

• Review the system prompts in your own AI features and remove anything you would not be comfortable publishing.
• Enumerate what identity and tools each assistant holds, and reduce them to the minimum the feature needs.
• Log model inputs and outputs somewhere you can query during an incident.
• Add output monitoring for credential-shaped strings and internal hostnames.
• Enforce authorisation in the application layer for every action an assistant can trigger, rather than in the prompt.

Frequently asked questions

Can prompt injection be fixed?

Not in the general case with current architectures, because models process instructions and data in the same channel. Mitigation focuses on limiting what the model can access and do, and on treating its output as untrusted, rather than on preventing injection.

What is the difference between direct and indirect prompt injection?

Direct injection comes from the user's own message. Indirect injection is hidden in content the model retrieves, such as a document or web page, so the attacker never interacts with the application directly and the victim may be another user.

Why are Azure SAS tokens a risk in this context?

A shared access signature is a URL that carries its own authorisation, so anyone holding it has the access it grants until it expires or is revoked. If a model can be induced to reveal one, the attacker gains durable access independent of the assistant.

Do I need my own cloud account to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The AI Systems Attack and Defense Bootcamp, Professional Edition (AISRTP) covers this in depth, working through prompt injection, RAG and embedding poisoning, tool and agent abuse, and MCP and CI/CD agent attack paths, and is assessed with a fully hands-on exam.