Practice: Responsible AI controls and guardrails
Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.
Main tool: OWASP Top 10 for LLM Applications · The OWASP Top 10 for LLM Applications is the shared threat list that risk reviewers use, so practising finding, recording, triaging and disclosing issues against it exercises every control in this lesson. · Alternatives: NIST AI RMF gives the governance process rather than a threat list; MITRE ATLAS catalogs attacker techniques in more detail; Amazon Bedrock Guardrails, Llama Guard, NVIDIA NeMo Guardrails and OpenAI Agents SDK guardrails are enforcement layers that block content at run time; Microsoft Presidio only detects and masks personal data.
Every step links into the tool's own documentation; links were checked on 2026-10-11 · version 1
Setup (one time)
1. Pick one deliberately insecure LLM practice app to run in a container on your laptop, and read how findings in training apps are treated.
You need a safe local target that is meant to be attacked, and intended flaws in such apps follow a different path from real vulnerabilities.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: The practice app answers a prompt locally and your notes say which path its intended flaws follow.
2. Create a findings folder with a blank report template whose fields come from the list of what a report should include.
A fixed template makes every finding comparable and reviewable later.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: An empty template file exists with one field for each item the section asks for.
3. Create one private intake location for findings, such as a local repository only you can read, modelled on the single private intake.
Findings about a model-driven system often contain sensitive prompts and data, so they must not land in a public tracker.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: A private location exists and a test note saved there is not visible outside it.
Steps
1. Run one prompt injection attempt against the local practice app and write it up in the report template.
A first complete finding shows what evidence a reviewer needs to reproduce an issue.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: One filled report exists with the affected component, the steps to reproduce and the observed impact.
2. Write rules of engagement for your testing from the list of things a reporter should not do, covering personal data, access beyond what is needed and disruption.
Privacy and least privilege apply to the tester too: you prove the issue with the least access and data possible.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: A one-page rules file exists and each rule names the data or access it limits.
3. Create a routing table that sends each kind of finding to an owner, following the choose the right path split between services, projects and training apps.
In a customer deployment, model, application, data and platform issues have different owners, and a wrong route delays the fix.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: Each of the ten findings has a named owner role in the table.
4. Create a risk register that stores every finding with a triage state, and tag each row with the NIST AI RMF function it belongs to: govern, map, measure or manage.
The triage and route flow is the process half of responsible AI, and the register is the artifact a risk review asks to see.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: The register lists ten rows, each with a state, an owner and one RMF function.
5. Run a small set of jailbreak and prompt injection prompts against the practice app and record, per prompt, which defense layer stopped it: input check, system instructions, output check or tool permission.
Layered defense is only real when you can show which layer catches which attack and which attacks pass all layers.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: A table shows every prompt with the layer that stopped it or the word passed.
6. Configure one extra control in the practice app, rerun the same prompt set and compare the two result tables side by side.
A prepared fix has to be verified against the original evidence, and a saved before and after comparison is that proof.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: The comparison shows at least one prompt that changed from passed to stopped, and the register row is updated.
7. Configure a human approval gate in the register: no finding moves to fixed and nothing is disclosed until a named person signs it off, and details stay private until then.
Human approval and private handling keep a half-fixed weakness from being released or published by accident.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: Every fixed row carries an approver name and date, and no unapproved row is marked fixed.
8. Write an advisory for one fixed finding using the points a useful advisory states.
The advisory is the packaged form of a finding that customers and risk reviewers actually read.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: An advisory file states what is affected, the impact, the fixed version or mitigation and what users should do.
9. Create a known issues list for the system and promote the approved advisory into it, as in the stage where users are told.
Promotion from private finding to published notice is the step that keeps a deployed system through ongoing risk review.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: The known issues list shows the advisory with its Top 10 category and publication date.
10. Write an owner runbook for the system from the guidance for project leaders, covering who receives reports, how fast they respond and how fixes are announced.
A written and versioned runbook makes the process repeatable by someone other than you.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: A runbook file exists under version control with named roles and response targets.
11. Run a full dry run with a colleague acting as outside reporter: private submission, triage, routing, fix, approval, advisory and a named contact for questions.
This is the production-like setup: the whole chain working with a second person shows the controls hold beyond your own laptop habits.
Explained in: Report a Security Issue | OWASP Foundation (owasp.org), checked 2026-10-11
Done when: One new finding travels from private submission to published advisory with every register field and approval filled in.