From Portfolio to Offer
A finished portfolio sitting in a private repository converts at approximately zero percent. This page covers the five moves that turn built work into interviews and offers. None of them require permission, a budget, or an existing network. All of them require that you already have something real to point at — if you do not yet, finish Month 3 first and come back.
The moves are ordered by leverage, not by difficulty. Move 1 alone changes more outcomes than the other four combined. Do them in order; each one feeds the next.
The five moves at a glance
| Move | Time cost | Who it convinces | Risk to avoid |
|---|---|---|---|
| 1. Publish a public red team report | 2–4 weekends | Engineers on the interview panel | Testing out of scope, or disclosing before the maintainer has responded |
| 2. Submit to an AI bug bounty | 1–3 weekends per attempt | Everyone, instantly, if accepted | Submitting known issues or unreproducible noise; ignoring program scope |
| 3. Propose a conference talk | 3 hours for the CFP, 3 weekends for the talk | The whole field, repeatedly | Proposing a topic you have not actually done |
| 4. Build a visible network | 30 minutes per week, sustained | Recruiters and future colleagues | Becoming a content account instead of a practitioner |
| 5. Package it coherently | One focused day | Anyone who spends 90 seconds on your profile | A portfolio that does not say which job you want |
Move 1: Publish one public red team report
This is the single highest-leverage artifact you can produce. It demonstrates, at once, that you can find a real problem, reason about it in a shared framework, write for a technical audience, and behave professionally under disclosure pressure. Very few candidates have one.
Target selection. Pick an open-source agent framework, an MCP server implementation, or a widely-copied example project — something with real users but not so large that every trivial issue is already known. Check for a SECURITY.md or a published security policy before you touch anything. If there is no security policy, that is a signal to pick a different target, not a license to proceed. Candidate categories are listed in Agent Frameworks.
Method. Work through the threat model systematically rather than poking at random. Use OWASP Agentic Threats as your checklist and MITRE ATLAS for technique naming. The tooling in Red Team Tools covers the mechanics.
Report structure
Use this outline. It is close enough to a professional engagement report that hiring managers recognize the shape immediately.
| Section | What goes in it |
|---|---|
| Scope and authorization | Exactly what you tested, exactly what you did not, and the specific basis of your authorization — the project’s security policy, quoted |
| Methodology | Your approach, the environment, the versions, the tooling, and enough detail that someone can reproduce it |
| Findings | One per finding: description, impact, preconditions, severity rationale, and a mapping to OWASP and ATLAS |
| Evidence | Trimmed traces, logs, and minimal reproducers. Redact anything sensitive. No screenshots of walls of text |
| Mitigations | Concrete, implementable suggestions — not “add input validation” but the specific boundary and the specific control |
| What was not tested | The limits of the assessment. This section is what separates a professional from an enthusiast |
The “what was not tested” section is disproportionately persuasive. It tells a reader you understand that an assessment has boundaries and that overclaiming is the cardinal sin of security work.
Responsible disclosure
- Read the project’s security policy in full before testing anything
- Test only in your own environment, against your own deployment of the code
- Report privately through the channel the project specifies
- Give the maintainer time to respond and fix — follow their stated timeline, and if they have none, be generous
- Publish only after the fix ships or after the disclosure window you agreed to has passed
- Credit the maintainer’s responsiveness in the writeup; do not use the report to dunk on volunteers
- If the maintainer asks you to hold, hold
Move 2: Submit to an AI bug bounty
Major AI labs and AI-product companies run vulnerability disclosure programs and bug bounties. These are the fastest path to a credential that needs no explanation — an accepted submission ends the “can you actually do this” question in one line on a résumé.
This page deliberately names no programs, payouts, or URLs, because scopes and reward structures change frequently. Find the current programs through the vendor’s own security page or an established bounty platform, and read the program terms yourself.
Reading a program scope. Before a single request, know:
| Question | Why it matters |
|---|---|
| What assets are in scope? | Out-of-scope testing is unauthorized testing, full stop |
| What vulnerability classes are explicitly excluded? | Most AI programs exclude generic jailbreaks and model refusal bypasses as “not a security issue” |
| What is the safe-harbor language? | This is your legal protection; if there is none, reconsider |
| What rate limits and account rules apply? | Violating them voids safe harbor |
| Are there known-issue lists or prior disclosures? | Duplicates are the most common rejection reason |
What makes a submission triageable. Triagers are processing a queue. Yours should cost them under five minutes to understand:
- A one-sentence impact statement at the top, in security terms, not model-behavior terms
- Exact reproduction steps, numbered, with the environment and versions stated
- The minimal reproducer, not the full transcript of your exploration
- A clear statement of what an attacker gains — crossing a trust boundary, exfiltrating data, invoking a tool without authorization
- No speculation about severity beyond what you demonstrated
The single biggest differentiator in AI bounty submissions: show a security boundary being crossed, not a model saying something it should not. “The model produced disallowed text” is usually out of scope. “The model, acting as an agent, was induced by attacker-controlled data to call a privileged tool with attacker-chosen arguments” is a security finding. That distinction is covered in Prompt Injection Red Teaming.
Why a rejection is still worth it. A well-written submission that comes back as a duplicate or out-of-scope still gives you: a written artifact you can sanitize and publish, evidence you can read and follow a scope, and direct feedback from a professional triager. In an interview, “I submitted three findings, one was a duplicate and two were out of scope — here is what I learned about how these programs define a security issue” is a genuinely strong answer. It shows judgment and it shows you tried.
Move 3: Propose a conference talk
A CFP is a free option. It costs three hours and the downside is an email you never hear back about.
Venues that fit a first-time speaker. BSides events are the standard on-ramp — regional, volunteer-run, and explicitly friendly to new speakers. AI-focused villages at larger conferences take short, technical, demo-driven submissions. Local security and AI meetups will often take a talk with two weeks’ notice and are the best place to run a draft before submitting it anywhere competitive.
Writing the abstract. Reviewers read dozens in a sitting. Structure yours as four short paragraphs:
- The problem — one concrete scenario, stated in two sentences, that the audience recognizes
- What you did — the actual work, with enough specificity that it is clearly real
- What the audience takes away — three bullets, each one an action they can perform on Monday
- Why you — one sentence, honest; “I built and broke this myself” beats a title
Avoid: unhedged “revolutionary” claims, topics you have read about but not done, and abstracts that could have been written by someone who did no work.
Reuse your portfolio as the talk. Your published red team report from Move 1 is already the talk. The structure maps directly: scope becomes setup, methodology becomes the middle, findings become the demo, mitigations become the takeaway. You do not need new material — you need the same material shaped for 25 minutes and a live audience.
Move 4: Build a visible network
The goal is not an audience. The goal is that when a hiring manager searches your name, they find a practitioner with a consistent, specific point of view.
Cadence. One post per week on a professional network. Each post shares exactly one insight tied to something you actually did that week. That is the whole system. Weekly is sustainable; daily is not, and the quality collapse is obvious to readers.
| Worth reading | Noise |
|---|---|
| “Here is a failure mode I hit building X, and the control that fixed it” | “10 things every AI security engineer must know” |
| A specific finding with the reasoning shown | A summary of a news article everyone already read |
| An honest “this approach did not work, here is why” | Reposting a framework diagram without commentary |
| A short technical explanation of one concept you just learned properly | Motivational content about the future of AI |
Engaging without spamming. Comment on practitioners’ posts with something substantive — a specific question, a counter-example, a related result from your own work. Three real comments a week beats fifty reactions. Do not cold-DM asking for referrals from people who have never seen your work; do reply to a technical post with a technical observation, repeatedly, until they know your name.
Move 5: Package it coherently
You have artifacts scattered across repos, a report, maybe a submission. A reviewer gives you 90 seconds. Make those 90 seconds legible.
GitHub profile README. Top of the file: your two-sentence positioning statement. Then a short list of your three strongest artifacts, each with one line explaining what it demonstrates. Then how to contact you. Nothing else — no skill badges, no activity graphs, no quotes.
One-page portfolio index. A single page (a repo README or a simple site) listing each artifact with: what it is, what problem it addresses, what you found or built, and which framework it maps to. Link the Portfolio Artifacts checklist against it and cut anything that does not earn its place.
The two-sentence positioning statement. This is the hardest and most valuable item on the page. It states which of the five roles from Core Roles you are targeting and what evidence backs it. The shape:
I build and break tool-using agent systems, with a focus on [specific area — trust boundaries / evaluation harnesses / audit evidence / governance mapping]. My published work includes [artifact], which [specific outcome].
If you cannot fill in the blanks specifically, the problem is not the sentence — it is that you have not yet chosen. Go back to Choosing Your Path.
Sequencing checklist
- Portfolio artifacts complete and public
- Positioning statement written and used consistently everywhere
- Target selected for the red team report, security policy read
- Report drafted using the structure above, including “what was not tested”
- Disclosure sent privately; publication held until the window closes
- One bounty program scope read end to end; one submission attempted
- Weekly post cadence started and sustained for at least eight weeks
- One CFP submitted to a first-time-speaker-friendly venue
- Profile README and portfolio index cut down to three strongest artifacts
Next: Interview Preparation.