Exploit Indirect Prompt Injection for Azure Access

What this lab covers

You profile what an AI assistant can do, establish where its trust boundary sits, and then move that boundary by planting instructions in content the assistant retrieves rather than in what you type.

The escalation matters as much as the injection. What the assistant exposes leads to Azure storage and onward to deployment credentials, which is the pattern that turns an AI feature into a cloud incident.

It builds on direct prompt injection, so it is worth doing the perimeter lab first. It suits anyone building retrieval-augmented features into a product.

How indirect prompt injection works

Retrieval-augmented applications fetch content and place it into the model's context so answers can reflect current or private data. That retrieved content arrives in the same channel as the developer's instructions and the user's question, because the model has only one channel.

An attacker who can influence any retrievable source can therefore place instructions where the model will read them. A document in a shared drive, a support ticket, a web page, a calendar invitation or a code comment all become potential injection points, and the attacker never touches the application.

The trust inversion is the important part. Applications treat retrieved content as data and treat the system prompt as authoritative, while the model treats all of it as text competing for influence. Content that arrives from a low-trust source can therefore direct actions the application believes only its own instructions can direct.

How to detect this in your own environment

Log the retrieved context alongside the prompt and the response. Without the retrieved content you cannot reconstruct why the model behaved as it did, and this is the most common gap in AI application logging.

Scan retrievable corpora for instruction-shaped text. Phrases directing a reader to ignore previous instructions or to output configuration have no legitimate place in a support ticket or a product document, and finding them is tractable.

Monitor the assistant's identity on the cloud side. The consequence is always an action taken with the application's credentials, so unusual storage access or resource enumeration by the assistant's identity is where this becomes visible as a security event rather than a quality problem.

How to prevent it

Separate retrieval from action. If the model can both read untrusted content and invoke privileged tools in the same context, injection converts directly into action, so requiring a separate authorisation step for anything consequential breaks the chain.

Enforce authorisation in the application on behalf of the requesting user, not the assistant. If the assistant holds broad credentials, injection inherits them. If every action is checked against the end user's own permissions, injected instructions gain nothing the user did not already have.

Treat retrieved content as hostile input and constrain what the model may do after reading it. Reducing tool availability in retrieval contexts is a cruder control than filtering, and considerably more reliable.

Real-world context

Indirect prompt injection is recognized in the OWASP Top 10 for Large Language Model Applications and has been demonstrated repeatedly against production assistants, including through documents, emails and web content that the assistant was expected to summarise.

The Azure specifics matter here. A shared access signature and a web app publish profile are both durable credentials that work for anyone holding them, so an assistant induced to reveal either has handed over access that persists long after the conversation ends.

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

Applying this at work

• List every source your assistants retrieve from and ask who can write to each. Anything a customer or external party can influence is an injection point.
• Check whether your assistants can both read untrusted content and call privileged tools in the same context, and separate the two if so.
• Enforce authorisation against the end user's permissions rather than the assistant's identity.
• Log retrieved context along with prompts and responses.
• Audit your Azure environment for long-lived SAS tokens and publish profiles that an assistant or application could disclose.

Frequently asked questions

What makes indirect prompt injection different from direct?

The attacker does not interact with the application. They plant instructions in content the assistant later retrieves, so a legitimate user triggers the attack and nothing malicious appears in the conversation.

Where can indirect injections be planted?

Anywhere the assistant retrieves from: documents, support tickets, web pages, emails, calendar entries and code comments. Any source a third party can write to is a candidate.

How do I stop injected instructions from causing damage?

Limit what the model can do after reading untrusted content, and enforce authorisation against the requesting user rather than the assistant's own identity. Filtering the content is unreliable, whereas constraining available actions is not.

Do I need my own Azure 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 tenant.

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.