MODULE 09 / 18 · PART 3 · PROVE & HARDEN
Security & Reliability
Think like an attacker at the boundary and an on-call engineer at 3 a.m.
THE SHORT ANSWER
What this module changes.
Security prompts work when you ask for an exploit, not a category. Reliability prompts work when you ask what the user sees when a dependency is slow, not just down.
Security prompts work best when you ask the agent to think like an attacker, and reliability prompts when you ask it to think like the on-call engineer at 3am.
Multi-tenant systems for SACCOs, clinics, schools and retailers fail most often on object-level authorization and secret handling. Ask whether user A can reach user B's record by changing an ID, and where API keys end up in the browser bundle.
THE MODULE PROMPT LIBRARY
20 prompts for security & reliability.
Copy any prompt, replace the [bracketed] slots with your own project context, and attach the files the agent needs. Use “Copy all prompts” when you want the full module in one place.
20 copy-ready prompts. Bracket text is a slot for your own context — replace it before you send the prompt.
Threat-model this endpoint: what can an attacker do with the inputs they control, and what is the worst outcome?
Why it worksAttacker framing finds issues that defensive review misses.
Review this code for injection: SQL, command, template, log, and header. Show the exploit for each finding.
Why it worksAn exploit is proof; a category name is a guess.
Where does this code trust user input? Trace every input from the boundary to the sink.
Why it worksTrust boundaries are where vulnerabilities live.
Review the authentication and authorization on [endpoint]. Can user A reach user B's data? Show me the check that prevents it.
Why it worksIDOR is the most common real-world API vulnerability.
What secrets does this code touch, and are any of them logged, cached, or exposed in errors?
Why it worksSecret leakage is usually accidental and always expensive.
Design the failure handling for [dependency]: timeout, retry with backoff and jitter, circuit breaker, and fallback.
Why it worksRetries without jitter and breakers turn a blip into an outage.
What happens to this system if [dependency] is slow rather than down? Slow is the harder failure.
Why it worksSlow dependencies exhaust connection pools and threads; down ones fail fast.
Review this for resource leaks: connections, file handles, threads, memory. Show where each is released.
Why it worksLeaks are invisible until they are outages.
What is the blast radius if this component is compromised? Propose the least-privilege change that shrinks it.
Why it worksAssumes breach and limits the damage.
Review the input validation on [endpoint] against the OWASP API Top 10 and tell me which items fail.
Why it worksApplies a known checklist to a specific surface.
Design the rate limiting and abuse protection for [endpoint]: the key, the limits, and the behavior when exceeded.
Why it worksRate limiting is a reliability control as much as a security one.
What is the recovery time objective for this service, and what does the current design actually deliver?
Why it worksCompares the promised RTO to the engineered one.
Walk me through the failure of [component] step by step: what the user sees, what the logs show, what the alert does.
Why it worksRehearses the failure before it happens for real.
Review this code for TOCTOU and race conditions in the security checks: [code].
Why it worksCheck-then-act bugs are subtle and exploitable.
What data does this service store that it does not need, and what is the retention and deletion story?
Why it worksData minimization is both a compliance and a breach-impact control.
Design the graceful degradation for [feature]: what still works when the dependency is gone?
Why it worksDegradation is a design decision, not an accident.
Review the error messages in [module] for information disclosure: stack traces, internal paths, version numbers, user existence.
Why it worksError messages are a common and overlooked leak channel.
What is the dependency risk in this service? List the transitive dependencies with known CVEs and the upgrade path.
Why it worksSupply chain risk is now a first-class reliability concern.
Design the health checks and readiness probes for [service] so that a bad instance is removed without a full outage.
Why it worksBad health checks cause outages during deploys.
Write the security review checklist for this change: what must be verified before it ships.
Why it worksTurns security review into a repeatable gate rather than a heroic effort.
PRACTICE · 20–30 MINUTES
Try it on a project you actually own.
Run prompt 4 against one endpoint. Show the check that stops cross-tenant access, then add a test that proves it.
- Pick one prompt from this module that matches a real task.
- Replace every bracketed slot with context from the feature you are working on now.
- Attach only the files the agent needs. Keep secrets, credentials and personal data out of the chat.
- Ask for the artifact — a spec, diff, test, runbook or decision note — and the evidence that it works.
- Record what changed and what remains unverified in the repository.
Want the same prompts across every module? Search the full prompt library or return to the course overview.