Four AI Security Projects You Can Ship in a Month
Why "one project per week" beats another certification
AI security is a field where the credentialing infrastructure – certifications, courses, CTF badges – has outpaced the tooling infrastructure. Anyone can accumulate OWASP LLM Top 10 flashcard knowledge in a weekend. Far fewer people can point to a working prompt-injection detector, a scanner that finds real vulnerabilities in real MCP servers, or a red-team harness that produces an audit report a client could act on.
That asymmetry is the opportunity. A one-project-per-week cadence forces a specific discipline: scope the architecture down to a single trust boundary, ship something that runs end-to-end, and produce an artifact – code, a report, a diagram – that demonstrates the underlying threat model rather than just naming it. Four weeks, four projects, four artifacts. That's a portfolio a hiring manager or a client can actually evaluate, and it's more convincing than any certificate.
The one-week project framework
Before the four builds, the constraint that makes this work: every project below is scoped to one trust boundary and one primary threat, not a general-purpose security platform. A week of focused evenings-and-weekends work is enough to:
Define inputs, outputs, and the trust boundary the project defends or probes
Implement a minimal but real detection, gating, or scanning pipeline – not a stub
Run it against adversarial test cases, not just happy-path inputs
Produce a written artifact (README with architecture diagram, or a generated report) that stands on its own
If a project needs more than a week, it's not scoped tightly enough. Cut it at the trust boundary and ship the smaller thing.
Week 1 – Prompt Injection Defense Gateway
Objective: Build a request-validation layer that sits between untrusted input (user prompts, retrieved documents, tool outputs) and your LLM's context window, and stop the most common injection patterns before they reach the model.
Threat model: Direct prompt injection (user attempts to override system instructions) and indirect prompt injection (malicious instructions embedded in retrieved content – a webpage, a PDF, a tool result – that the LLM treats as trusted context).
Architecture:
Ingress classification – a lightweight classifier or rule set that flags suspicious patterns (role-override attempts, delimiter injection, encoded payloads) before the request reaches the primary model.
A validation pipeline, not a single filter – chain multiple checks (pattern-based, then semantic) so no single bypass defeats the whole gateway.
Trust-boundary logging – every request that crosses the boundary gets logged with its classification verdict, so you can audit false negatives later.
Build it as: a FastAPI or LangChain middleware component that intercepts requests before they hit your primary LLM call, with a documented validation pipeline diagram (input → classification stage → pass/flag/block → logging).
Why this project first: prompt injection is the entry point for nearly every downstream AI attack chain – data exfiltration, unauthorized tool calls, jailbreaks. A gateway you can point to and explain, component by component (purpose, inputs, outputs, trust boundary, controls), is the single most legible artifact in an AI security portfolio.
Week 2 – Zero-Trust Tool-Gating for Agentic Systems
Objective: Remove secrets and high-privilege capabilities from the LLM's context window entirely, and require an explicit, auditable authorization step before any tool call that touches sensitive data or takes a consequential action.
Threat model: An LLM that has been successfully manipulated (via Week 1's threat, or a novel bypass) still shouldn't be able to exfiltrate secrets or trigger destructive actions because it never held the secret or the unchecked capability in the first place.
Architecture – a three-stage hardening progression is a good structure to document explicitly:
Baseline: keyword/regex filtering on tool inputs and outputs. Cheap, fast, and trivially bypassed – document why as a teaching artifact.
Dual-model watchdog: a second, smaller model (a local guard model is sufficient) inspects the primary model's intended tool call before execution, checking intent against a policy.
Zero-knowledge tool-gating: the secret or capability is never placed in the LLM's context at all. The LLM requests access via a tool call; a separate "vault" component validates a scoped access token and performs the privileged action itself, returning only the result the LLM needs.
Build it as: a LangChain (or equivalent) tool-calling setup where a "vault" tool holds credentials outside the model's context, gated by token validation you implement and can demonstrate defeating stage 1 and stage 2 against, then show stage 3 holding.
Why week 2: this is the project that separates "the model is aligned" from "the system is secure." It demonstrates architectural defense-in-depth rather than reliance on model behavior, a distinction most AI security newcomers miss and most experienced reviewers specifically look for.
Week 3 – MCP / Tool-Calling Security Scanner
Objective: Build a scanner that statically and semantically analyzes MCP server configurations and tool definitions for exploitable misconfigurations, before those servers are ever connected to a live agent.
Threat model: the rapidly expanding MCP ecosystem means agents are increasingly granted tool access to third-party servers with unaudited permission scopes, unsafe default configurations, or taint paths between untrusted inputs and privileged sinks.
Architecture – a layered pipeline outperforms a single-pass scanner:
Static configuration scan – flag overly broad permission scopes, missing authentication, unsafe defaults.
Taint analysis – trace data flow from untrusted inputs (tool parameters, retrieved content) to sensitive sinks (file writes, shell execution, network calls); Semgrep is a solid off-the-shelf base for this layer.
LLM-based semantic judgment – for findings that static rules can't resolve confidently, use a model call to judge intent and context (does this tool description match its actual behavior?).
Deferred runtime monitoring hooks – even if full runtime monitoring is out of scope for the week, define the interface where it would attach.
Design principle worth stating explicitly in your writeup: optimize for precision over coverage. Existing scanners in this space tend toward high false-positive rates, which trains users to ignore output. A smaller number of high-confidence findings is a better week-one deliverable than a noisy comprehensive sweep.
Why week 3: this project produces something genuinely useful to the ecosystem – MCP server authors and integrators are actively looking for this tooling – which makes it a strong open-source, lead-generation-friendly release in addition to a portfolio piece.
Week 4 – Automated Multi-Turn Red-Team Audit Runner
Objective: Automate adversarial testing against the systems you built in weeks 1–3 (or any target LLM system), running multi-turn jailbreak scenarios and producing a timestamped, reproducible audit report.
Threat model: single-turn red-teaming misses the majority of real jailbreaks, which succeed through gradual context manipulation, role-play escalation, or multi-turn goal hijacking rather than a single malicious prompt.
Architecture:
Scenario library – a set of multi-turn attack scripts covering categories from an established taxonomy (MITRE ATLAS or the OWASP LLM Top 10 map cleanly onto scenario categories).
Test runner – executes each scenario against the target system, capturing full conversation transcripts.
Automated pass/fail scoring – a judge model or rule-based check evaluates whether the target held its policy across the full conversation, not just the final turn.
Report generation – output a structured Markdown (or PDF, via a reporting pipeline) audit report with pass/fail status per scenario, timestamped, versioned against the target system's commit hash.
Build it as: a test runner script (Python is the natural choice) that takes a target endpoint and a scenario directory as input and emits a self-contained audit report, the kind of artifact you could hand to a client or attach to a bug bounty submission.
Why week 4, last: this project is the payoff. Pointed at weeks 1–3's outputs, it closes the loop – you're not just building defenses, you're proving them, with evidence you can show. A reusable report template mapped to CVSS and CWE/OWASP LLM Top 10 categories turns this from a personal exercise into a professional deliverable.
Sequencing note
The order above – defend, defend deeper, scan, attack-test – isn't arbitrary. Each week's project becomes a target or a component for the next. By week 4 you're not testing a toy; you're testing infrastructure you built and can explain at the trust-boundary level. That's the difference between "I studied AI security" and "I can show you four systems I secured, and here's the report proving it."
None of these four projects requires novel research. All four require the discipline to scope tightly, ship something real, and document the architecture honestly enough that someone else could evaluate – and attack – it.
Want help scoping your own four weeks?
If you're working through this build plan and want a second pair of eyes – on threat modeling, architecture decisions, or where a scanner's false-positive rate is actually coming from – I offer coaching and mentoring sessions for exactly this kind of hands-on AI security work. Reach out via NeuralStack | MS if you'd like to book time.
Manuela Schrittwieser – AI Security Engineering & Technical Writing
[CO-Authored by Claude Sonnet 5]
