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
Prompts as code
Priya's team uses AI to sort support tickets. Someone added one friendly line to the prompt. Then the code could not read some answers. Your goal: treat a prompt like code.
🧪 Interactive lab — enable JavaScript to play with this one.
- A prompt in an app is code. Review and test every change.
- Mark customer text as data. It helps, but it is not a wall.
- Check every answer in code before anything acts on it.
- Give each AI call one small job.
Templates: fixed text with blanks
An app sends the same prompt thousands of times. So the prompt is fixed text with named blanks, like {{ticket_text}}. It works like a printed bank form with blanks. Your code fills them in. This is a prompt template.
Put customer text inside tags, like <ticket>…</ticket>. Tell the model that text inside is data, not orders. The tag is a delimiter. Remove any closing tag found inside the data. Otherwise the data can end the tag early.
Check every answer in code
A strict schema fixes the answer's shape. This is structured output, from Tool calling. The content can still be wrong. So your code checks each answer, in this order:
- Stop reason: was it cut off or refused?
- Schema: does the JSON match?
- Business rules: is the order id in the ticket? Is the amount at most the order total?
- Failed? Send back the exact error and ask for a fix, once or twice.
- Still wrong? Use a safe default or ask a person.
Chains: one small job per call
One prompt doing four jobs does each job less well. So give each call one job. Plain code checks the result before the next step. This is prompt chaining. It costs more calls. Start with one prompt, and split out a step when tests show it failing.
Now find the bugs in a filled template.
🧪 Interactive lab — enable JavaScript to play with this one.
Go deeper: safe templates
- One file per prompt. One small function builds it. Don't glue pieces together in five places.
- Stop on a missing blank. An empty
{{order_history}}reads like "this customer has no orders". The AI will reason from that. - Cap each blank. Set a size limit. One day, a user will paste a 300-page log.
- Fixed text first, changing data last. This also helps caching (Cost, limits and caching).
A template library, like Jinja or Handlebars, can help.
Go deeper: tags are not a wall
The AI reads your instructions and the ticket as one stream of text (Prompts that work). A ticket may say "ignore your instructions". Nothing marks that sentence as data. So put your instructions in the system prompt. Put customer text in the user turn, inside tags.
This makes mix-ups much less likely. But OWASP's Top 10 for LLM apps calls it one defense among several. It says a fool-proof defense may not exist. So real limits live in code that checks the output (Prompt injection).
Go deeper: versions
You ship a bundle: the prompt, the model version, the settings and the schema. Settings are things like max_tokens, temperature or effort. Change any one, and behavior can change. So each change is a release.
- Keep prompts in git. A change is a pull request with a reviewer and a reason. To undo it, revert it.
- Pin the model version. Some providers offer a model alias, like a "latest" name, that moves to a newer model. Use a pinned model version instead. Old models also retire, with weeks or months of notice.
- Log the versions with every request. Then you know what made a strange answer.
A prompt edited in a dashboard, with no review, is a change nobody tested.
Go deeper: testing changes
Keep a small test set next to the prompt (Evals: does your AI work?). Run it when the prompt, model, settings or schema changes. Compare each case with the last passing run. An average can hide a case that used to pass and now fails. Test each step of a chain alone, too.
Priya's story: a new model version came out. Her 40-case test ran before anyone switched. Every schema check passed. But six normal tickets jumped from "high" to "urgent". She added one sentence that defines "urgent". She ran the tests until all passed. Only then did she move the pinned version.
Go deeper: schemas and repairs
A strict schema is written as a JSON Schema. It makes broken JSON rare. But an answer cut off at the output limit can be half a JSON object. A refusal may hold no JSON. As of October 2026, some providers do not support every schema rule, like number ranges. Some reject them. So your code still checks.
A model usually fixes a precise error, like "priority must be one of normal, high, urgent". Count your repairs. A rising count warns that something changed. Never repair in an endless loop.
A mistake in step one of a chain flows into every later step (Agent design patterns). Reasoning models can do many steps in one call. Chains still help when you need to see each result.