The Secure AI Starter Kit: Download the Code and Field Guide

AI SECURITY · BLOG 22

The series ends with something you can run: a small offline project, a setup and operations guide, and a one-page map of all 17 parts.

The series is complete – start with a runnable lab

Blog 21 followed a request from identity checks through retrieval, model response, and tools. This final part, Blog 22, closes the 17-part AI Security Series with a compact reference project you can download, inspect, test, and run on your own machine.

The zip uses fictional records and Python’s standard library. It needs Python 3.11 or newer. It makes no hosted model call and requires no account, API key, or paid service. That makes the first run predictable, including when you are offline.

Run it in a few minutes

Download and extract the zip. If Python 3.11 or newer is installed, the easiest start is the local test screen: on Windows, double-click Start Secure AI Starter.bat; on macOS or Linux, run this from the extracted folder:

python3 -m secure_ai_demo --ui

Your browser opens a simple local page with question, tenant, and role fields. Click Run question to see a citation or abstention, Run approval walkthrough to try the supervisor-only action, or Run all security tests to check the complete suite. The page listens on your computer only; press Ctrl+C in the launch window to stop it.

If you prefer the terminal, run the checks and the default retrieval example directly:

python -m unittest discover -v
python -m secure_ai_demo

The default command returns a citation when a permitted fixture matches the question. With weak evidence, it abstains. The action example reads a fictional incident, asks for a one-time approval for one target and one status change, then shows that replay is blocked.

What the project puts into practice

The 24 offline tests check these paths, including malformed fixtures, oversized questions, role denial, citation selection, abstention, stale records, approval binding, and one-time use. Run them before and after each change; add new cases from failures rather than relying on a single happy-path example.

A practical real-world use case: repeated MFA failures

Imagine a security operations centre (SOC) analyst receives a report of repeated MFA prompts after an employee signs in from a new device. The analyst needs a safe first-response checklist while keeping account changes under human control.

Example question: “What should I check for repeated MFA failures?”

python -m secure_ai_demo --question "What should I check for repeated MFA failures?"

In the offline lab, the responder filters the fictional records by tenant and role before ranking. It returns a short excerpt with citation A-RUNBOOK-01: check the approved identity-provider sign-in log, verify the user through the service desk, preserve the event window, and follow the incident escalation policy. The runbook explicitly says not to disable MFA based only on an AI suggestion.

A human analyst performs those checks and follows the organisation’s incident process. If an incident status needs to change, the example requires supervisor approval for one exact, version-bound transition; it then blocks a replay of that approval. The walkthrough command is:

python -m secure_ai_demo --role supervisor --action-demo

This is a realistic operational scenario, but the downloadable project uses fictional data and deterministic offline logic. It has no live identity provider, real incident records, or model call. Before adapting the pattern, connect it to verified server-side identity, tenant-filtered storage, a durable human-approval service, and reviewed monitoring and retention controls.

Use the guide to adapt it safely

The companion PDF gives the complete folder walkthrough, expected output, how to change the fictional corpus, and a practical test and monitoring checklist. It also names the substitutions a real service needs: verified user identity instead of CLI flags, tenant filters enforced at storage, durable approval state, privacy-reviewed telemetry, and an explicitly reviewed model adapter.

The guide includes a deployment boundary checklist and a short incident path. It does not promise that copying the code secures a production deployment. Real systems need a threat model and controls tested against the services, data, identity provider, model provider, and operational process they actually use.

A map of all 17 parts

The second PDF compresses the whole series into a single readable page. It links the foundations and governance topics to system controls, hands-on implementation, measurement, and operations. Use it to orient a new teammate or plan a reading path; each blog remains the detailed explanation for its topic.

Start with AI Security Foundations (Blog 06), then move through data boundaries, prompt injection, RAG, evaluation, and guarded tools. The final three posts cover safe agent permissions (Blog 20), monitoring (Blog 21), and this runnable handover (Blog 22).

Finish with an evidence-based next step

Run the tests, change one fictional record, then add a test for the behaviour you expect. If a control matters in your own service, implement it at the trusted boundary and verify it there. A passing local example is a starting point for a review, not a release decision.

Thank you for following the series. The articles and final downloads are intended to make AI security easier to discuss, test, and improve one control at a time.