A wall of jailbreak screenshots may look dramatic. A small, authorized case study that shows what you tested, what failed, what you fixed, and what changed after the retest is much harder to ignore.
The AI red-team portfolio question is suddenly everywhere: What should I build? What can I publish? How do I prove I understand AI security before someone gives me a production system to protect?
The tempting answer is to collect clever prompts and post the moments a chatbot breaks. That is also the fastest way to make a careful reviewer wonder whether you understand authorization, scope, user impact, or remediation. In AI security, the public artifact is part of the test. It tells people whether you can handle a sensitive problem with restraint.
Build an AI red team portfolio around one compact, controlled case study instead. Your goal is not to look dangerous. Your goal is to make your security judgment easy to inspect.
The portfolio piece that earns trust is not “look what I broke.” It is “here is how I investigated a bounded risk, reduced it, and proved the fix held.”
Why jailbreak screenshots are a weak personal-brand asset
A screenshot can show a surprising output. It cannot show whether the behavior mattered, whether the system was in scope, whether anyone was exposed, or whether you understand the conditions that produced it. It also cannot show whether your proposed fix blocks a real risk without wrecking useful behavior.
That missing context is the difference between a stunt and a professional case study. NIST describes AI red teaming as controlled exercises used to identify harmful behavior and stress-test safeguards. The emphasis is on learning about a system in context—not collecting gotchas. Its Generative AI Profile is a useful reminder that diverse expertise, analysis, and governance belong around the test.
A reviewer wants evidence of six things:
Scope discipline: You tested a system you own, a deliberately vulnerable lab, or a target with explicit written permission.
Threat judgment: You can explain who could be harmed, which asset is at risk, and why the path matters.
Method: Your test cases are repeatable enough for another person to understand.
Impact reasoning: You separate a strange model response from an actual security or safety consequence.
Mitigation skill: You know how to reduce risk at the right layer, not merely block one string.
Honesty: You label limits, synthetic data, assumptions, and what remains untested.
Notice what is absent: “I know the most aggressive prompt.” The most valuable reputation signal is discernment.
Build one controlled lab, not a pile of demos
Start with a fictional or deliberately vulnerable agent you can run locally. A good lab has a narrow job, fake data, a limited tool, and a clear rule it should never violate. For example, create a mock support agent that can search a synthetic order database and submit a mock refund request. Its rules might say that it cannot reveal other customers’ records, perform a refund without a valid authorization state, or treat untrusted text as an instruction.
This is more credible than pointing tests at a random live service. OWASP publishes intentionally insecure agent samples specifically to help people learn from controlled misconfigurations. Their warning matters: a training system is not permission to deploy or probe carelessly.
A simple rule: If you cannot plainly write “I was authorized to test this,” do not make it your portfolio target. If a bug belongs to someone else, follow that organization’s security policy and responsible-disclosure process before publishing anything.
Keep your lab small enough to understand end to end. One retrieval source, one agent, one tool, one policy boundary, and a handful of synthetic records are enough. Complexity does not prove seniority. Clear reasoning does.
The five-part case study that makes your judgment legible
1. Put the authorization and boundaries first
Open your page with a two-sentence scope statement: what you built or were allowed to assess, what was excluded, and which data was synthetic. This is not legal boilerplate. It is the first proof that you can be trusted around sensitive systems.
Example: “I built a local demonstration agent using fictional customer records. Testing was restricted to this repository and mock endpoint; no external systems, real credentials, or customer data were used.”
2. Write a human threat model before you ask AI for test ideas
Use an AI assistant to brainstorm edge cases if it helps, but do the framing yourself. Write down the asset, actor, entry point, unsafe action, and desired control. For the support agent, the asset is customer data and the refund workflow. The actor might be an untrusted document or a user attempting to override the agent’s goal. The unsafe action is cross-customer disclosure or a refund without confirmation.
Map each scenario to a recognized risk category where useful. OWASP’s LLM Top 10 identifies prompt injection as a foundational concern. You do not need to name-drop frameworks in every paragraph; use them to make your tests more complete.
3. Design safe, reproducible test cases
A good test case reads like a mini experiment: precondition, safe input category, expected behavior, observed result, and evidence reference. Do not publish a copy-ready attack recipe or secrets. A reviewer needs the logic of your methodology, not every detail that would make misuse easier.
For example, describe a test as “an untrusted knowledge-base item contains instructions that conflict with the agent’s task.” The expected behavior is that the agent treats the content as data and asks for an authorized human confirmation before a consequential action. Your evidence can be a redacted trace, a decision log, and a pass/fail result.
4. Show impact without exaggerating it
“The model followed an odd instruction” is an observation. “The agent could expose simulated customer fields through an over-broad retrieval path” is a risk statement. Explain the gap between the two. What access did the agent actually have? What control was missing? What would have happened in a real deployment? What did not happen because your environment was synthetic?
This language feels less dramatic, and that is the point. Precise claims travel farther than inflated ones. They make a hiring manager, client, or collaborator confident you will not confuse possibility with proof.
5. Close the loop with remediation and retest
Most weak AI-security portfolios stop at the failure. Yours should make the fix the centerpiece. Maybe you reduced tool permissions, added a confirmation boundary, separated retrieved content from instructions, constrained data filtering server-side, or added regression tests. Explain why that control addresses the failure path and what trade-off it creates.
Then repeat the test. A retest that passes is useful. A retest that reveals a different limitation is even better when you document it clearly. It demonstrates that you can reason about defense in depth rather than promise a magic guardrail.
Make the evidence easy to review
Turn the case study into a small evidence package. Give it a plain title such as “Controlled Agent Authorization Test: Finding, Fix, and Retest.” A strong public page or repository README can include:
a one-paragraph project summary and explicit authorization statement;
a diagram of the fictional system and trust boundaries;
a short threat-model section with two or three scenarios;
a test log with redacted inputs, expected outcomes, and observed behavior;
one finding written in calm, evidence-based language;
the mitigation decision, its limitations, and the retest result; and
a “what I would test next” note.
Use screenshots sparingly. A clean diagram, a compact trace excerpt, and a before/after outcome are often more persuasive than twenty terminal images. If you use AI to help produce diagrams or summarize traces, check every claim and disclose the role when it would affect a reader’s understanding. Your portfolio is evidence of your judgment; do not let a fluent tool write judgment you did not exercise.
Use AI as a research assistant, not as your security authority
AI can accelerate the boring parts: turning your notes into a test matrix, finding missing assumptions, clustering similar failures, drafting a plain-language executive summary, or checking that a README explains a term. It can also make you overconfident quickly.
Keep a small “human decisions” file alongside the project. In it, record what you decided to test, what you refused to test, why a finding matters, why a control is proportionate, and what evidence would change your mind. This is a subtle but powerful personal-brand asset. It shows that your contribution is not just generating output; it is choosing responsibly under uncertainty.
Before you publish, ask:
Could a reader mistake a lab result for a production finding?
Did I remove secrets, real identities, sensitive endpoints, and copy-ready exploit details?
Did I state authorization, scope, data provenance, and limitations?
Does my finding distinguish observed behavior from potential impact?
Did I show a mitigation and a retest—not only a break?
A practical 14-day build plan
Days 1–2: Choose an intentionally vulnerable training project or build the smallest possible local agent with synthetic data. Write the scope statement before you write any test.
Days 3–4: Draw the system boundary and select two risk scenarios. Define expected safe behavior in plain English.
Days 5–7: Create a compact test set. Run it, capture only safe evidence, and separate observations from your interpretation.
Days 8–10: Implement one or two proportionate controls. Keep a decision log explaining the trade-offs.
Days 11–12: Retest the original scenarios and add one regression case. Record what still remains outside your confidence.
Days 13–14: Publish the case study with a short visual diagram and a calm conclusion. Ask one security-minded peer to review whether your claims match the evidence.
When you finish, do not position yourself as someone who “hacks AI.” Position yourself as someone who can investigate AI-system risk, communicate it clearly, and make a system safer. That is a more durable public identity—and a much more useful one.
Frequently asked questions
What should an AI red team portfolio include?
Include one or two controlled case studies with explicit authorization, a threat model, safe test descriptions, evidence, a finding, mitigation, retest, and limitations. A compact, complete artifact is stronger than many disconnected demos.
Can I test a public AI application for my portfolio?
Only if the owner explicitly authorizes that kind of testing through a written policy, a program, or direct permission—and only within its stated scope. Otherwise, use your own local lab, a CTF-style environment, or a deliberately vulnerable sample.
How do I show prompt-injection testing without publishing harmful prompts?
Describe the scenario category, precondition, expected behavior, observed result, and remediation. Redact or abstract payload details that would make misuse easier. The methodology and control reasoning matter more than the exact string.
Do I need advanced machine-learning knowledge to build an AI security portfolio?
No. A strong starting point is understanding how an LLM application retrieves data, calls tools, manages permissions, logs actions, and fails under untrusted input. Build depth through bounded systems rather than waiting to master every model internals topic.
How many AI red-team projects should I publish?
Start with one complete, well-explained project. Add a second only when it shows a genuinely different judgment area, such as retrieval boundaries, tool authorization, evaluation design, or disclosure process. Depth beats volume.
Should I disclose that I used AI to help create the portfolio?
Disclose it when AI materially shaped a diagram, summary, code draft, or other part a reviewer might reasonably assume you created alone. Be specific about your role: what you decided, verified, implemented, and tested yourself.