IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Ship safely
Priya's billing assistant is almost ready for the public. First, Zara checks how it could go wrong. Your goal: find the weak spots and close them before launch.
🧪 Interactive lab — enable JavaScript to play with this one.
- Treat the AI's reply like text from a stranger.
- An image in a reply can leak data without a click.
- Set usage limits, or one person can run up a huge bill.
- Your system prompt is not a secret.
- Say it is an AI. Offer a way to reach a person.
The reply is untrusted
Anyone who puts text in front of the model can steer its reply. That includes a stranger who wrote a page the model reads. You met this in Prompt injection. Guardrails catch only some of it. So check the reply in code before it goes anywhere. Using a reply without checks is improper output handling.
Images can leak data
A reply can hold an image with a web address. When the chat shows it, the browser loads that address. A hidden instruction can make the model put private data into the address. This is markdown image exfiltration. The fix: don't load images from replies, or only from your own sites.
Put a limit on usage
A script or a bug can send so much work that the bill becomes the problem. It is like a tap left open all night. This is denial of wallet. Each kind of leak in your budget needs its own limit.
Four leaks are running tonight. Give each one the limit that stops it.
🧪 Interactive lab — enable JavaScript to play with this one.
Go deeper: where the reply goes
The damage depends on where the reply goes.
| Reply goes to | What can go wrong | Defense |
|---|---|---|
| A web page | An attacker's script runs in your page, as the user. This is cross-site scripting (XSS). | Escape by default. Clean markdown with a sanitizer that allows only listed tags. |
| A database | The query reads or deletes too much. This is SQL injection. | The model picks from fixed queries. Code fills in the values. The model never writes raw SQL. |
| A shell or code runner | The attacker's command runs on your server. | Never run a reply directly. Use a sandbox with no secrets and no network. |
| A file path, URL or email | Reading other users' files or internal addresses. | Allow-lists, fixed folders, escaping. |
The model only writes text. Your code decides what that text may become (Tool calling and structured output).
Go deeper: images, links and CSP
Treat links like images. Show the full address, and don't auto-load previews.
A Content Security Policy is a message from your server to the browser. It lists the sites a page may load images and scripts from. It is a backup, not a fix. In 2023, a researcher showed this leak in Google Bard. Bard's policy allowed images from Google sites. The data went out through a Google Apps Script page.
The deeper cure is in Prompt injection: break up the lethal trifecta.
Go deeper: limits that stop a big bill
OWASP calls this risk "Unbounded Consumption". The fixes are normal engineering:
- A daily quota and a rate limit for each user.
- Caps on input size, reply length (
max_tokens) and agent steps. - Timeouts.
- Spend alerts and a hard monthly limit with your AI provider.
- Bot checks on anything that needs no sign-in.
Put costly features behind sign-in. Then each quota belongs to a person. An alert only tells you. A hard limit on the whole account stops every user, too. See Cost, limits and caching.
Go deeper: injection and the system prompt
No prompt wording stops injection every time. So a fooled model must not be able to do much (Build an agent).
Assume people will read your system prompt. OWASP says it should not be a secret or a security control. Keep keys, internal addresses and customer data out of it. A rule like "only discuss the user's own account" doesn't protect anything. Your code must check who owns the data.
Check input and output for harmful content (Guardrails and jailbreaks). Plan for sensitive topics, like pointing a user in crisis to real help.
Go deeper: trust and testing
- Sign users in. Quotas and investigations need to know who the user is.
- Say it's AI. The EU AI Act requires this since August 2, 2026, unless it is obvious (Safe AI at work).
- Respect personal data. India's DPDP Act asks for clear consent (Regulations & certifications).
- Offer a person when asked, when the stakes are high, or when the user is stuck.
- Own what it says. In 2024, a Canadian tribunal held Air Canada responsible for its chatbot's advice (AI rules at work).
Before launch, attack your whole app. This is red-teaming. Try jailbreaks, hidden instructions, images, links and a script that floods the costliest feature. Each attack that works becomes a test you rerun.
Asking the model not to write links is not a fix. An attacker can override it. Real limits run in your code.
Try the free PortSwigger labs for AI apps. Then check your app against the OWASP Top 10 for LLM apps. Only test systems you own or have permission to test.