Month 3 — Go Public – Agentic AI Security Career

Month 3 — Go Public

Two months of building leave you with working code that nobody can see, run, or evaluate. Month 3 converts that into evidence. The goal is three to five projects on GitHub, each with architecture documentation, a threat model, an audit trail sample, and a demo recording — published in a state where a stranger can clone the repo and reach a working result without asking you a single question. This is the month where most people stall, because polishing feels less rewarding than building. Do it anyway: unreviewable work does not count.

What “publishable” means

A repo is publishable when all five of these are true. Anything less and it works against you, because a hiring manager who clones it and fails will assume the code is the problem.

Criterion	Test
A stranger can follow the README	Hand it to someone who has never seen the project; they get a result without asking you
Reproducible setup	Clean machine, pinned dependencies, documented runtime version, one command to run
No secrets in history	Not just in HEAD — in the entire commit history
A license	An unlicensed repo is legally unusable, however good the code is
Honest limits	A section stating what the project does not do and where it breaks

Deleting a key in the latest commit does not remove it. The value stays in the object database and stays reachable. If a real credential was ever committed, rotate it first — rewriting history is cleanup, not remediation.

Week-by-week plan

Week	Focus	Output
9	Scope selection and repo skeletons; secret-scan every history	Three repos with final scope, license, and clean history
10	Documentation: README, `ARCHITECTURE.md`, `THREAT-MODEL.md`, audit sample	Each repo readable end to end without you present
11	Demos: record the success path and the failure path	One recording per project, under five minutes each
12	Write-ups, cross-linking, and a final publication pass	Posts published; repos linked from your profile and CV

Week 9 checklist

Freeze scope — no new features after this week
Run a secret scanner across full history on every repo
Add a license file and a one-paragraph project summary

Week 10 checklist

Write the README against a clean clone, following your own steps literally
Write ARCHITECTURE.md and THREAT-MODEL.md (see required artifacts)
Export a real audit trail sample with secrets redacted

Week 11 checklist

Record the success path, uncut
Record the failure path — an attack that works, or a case the agent handles badly
Trim to under five minutes and caption the key moments

Week 12 checklist

Publish one write-up per project
Cross-link repos, write-ups, and your profile
Ask one person to clone and run each project cold

Scoping: three strong beats five thin

Five shallow repos read as five weekends. Three deep ones read as a practice. Unless you have genuine surplus material, publish exactly these three:

Project	Origin	What it demonstrates
Log Triage Agent	Month 1	Tool scoping, redaction, least privilege, testable controls
Multi-Agent SOC with MCP	Month 2	Orchestration, handoff contracts, permission matrix, approval gates
Red team report vs. an open-source agent	New in Month 3	Adversarial thinking, disclosure discipline, clear technical writing

The red team report is the differentiator. Pick an open-source agent project whose license and policy permit security testing, test it in your own environment, and write up findings with reproduction steps and suggested mitigations. If you find something materially exploitable, report it privately to the maintainers before publishing, and give them time to respond.

Only test systems you own or that explicitly permit testing, and only in an environment you control. Publishing an unreported exploit against a live third-party service is a reputational and legal problem, not a portfolio piece. Coordinate disclosure first, publish second.

Add a fourth or fifth repo only if it shows something the first three do not — an audit trail deep-dive from Lab 4, or a risk register from Lab 5 that connects your engineering to governance frameworks.

Repo structure

Use the same layout across all projects. Consistency itself signals discipline, and it makes reviewing your second repo faster after the first.

agent-log-triage/
├── README.md                    # what, why, run it in 5 minutes
├── ARCHITECTURE.md              # components, data flow, decisions
├── THREAT-MODEL.md              # STRIDE table, trust boundaries
├── LICENSE
├── docs/
│   ├── audit-trail-sample.json  # redacted real output
│   └── demo.md                  # link + what to watch for
├── src/
└── tests/

File	Purpose	Reviewer question it answers
`README.md`	Problem, scope, setup, run, limits, failure modes	“Can I run this and should I care?”
`ARCHITECTURE.md`	Components, data flow, why each design decision	“Did they think, or did they copy?”
`THREAT-MODEL.md`	STRIDE table, trust boundaries, controls, accepted risks	“Do they think adversarially?”
`docs/audit-trail-sample.json`	A real, redacted trace of one run	“Could I investigate an incident here?”
`docs/demo.md`	Recording link plus what to watch for and when	“What does this look like working?”
`tests/`	Tests that prove the security controls, not just the happy path	“Are the controls real or asserted?”

Recording a demo that shows failure

Most demos show only the success path, which is exactly the part a reviewer discounts. Structure yours in three acts and keep the whole thing under five minutes.

Act	Duration	Content
Setup	30 sec	What the agent does, what it is allowed to touch, what it can never do
Success	90 sec	One clean run, uncut, terminal visible, no editing between commands
Failure	2 min	An attack that works or a case handled badly — then the trace showing what happened

Rules that make the failure act land:

Do not edit out the failure. The uncut moment is the credibility.
Narrate the control that should have caught it and explain why it did not.
End on what you would change, not on a claim that it is now fixed.

Showing your agent getting exploited feels risky and reads as senior. It says you tested rather than assumed. The same instinct is what what employers screen for describes as the difference between a demo and an engineer.

The accompanying write-up

Each project gets one post. Keep it to roughly 1,200 words with a fixed structure — the constraint keeps you from padding.

Section	Length	Content
The problem	1 paragraph	What breaks without this, in concrete terms
The design	2–3 paragraphs	Architecture and the tradeoffs you accepted
The interesting decision	2 paragraphs	One choice that was genuinely hard, with the option you rejected
What broke	2–3 paragraphs	A real failure, the trace, the fix
What I would do differently	1 paragraph	Specific, not “add more tests”
Run it yourself	Short	Link to the repo, one-line setup

The “what broke” section is the one people remember. Write it first if the rest stalls. For turning these into interview material, see portfolio to offer.

Secret scanning and the safety pass

Do this before the repo goes public, not after. Public means indexed, cloned, and mirrored within minutes.

Check	What to look for
Full-history secret scan	API keys, tokens, private keys, connection strings — across every commit, not just HEAD
Config and env files	`.env`, `config.local.*`, notebook outputs, editor and IDE directories
Sample data	Real log lines, hostnames, internal IPs, employee names, ticket IDs
Fixtures and tests	Recorded HTTP responses containing live tokens
Attack payloads	Anything targeting a system you do not own — remove or fully anonymize it
Third-party findings	Unreported vulnerabilities in someone else’s software
Screenshots and recordings	Terminal scrollback, browser tabs, notification popups, visible tokens

If a live credential was ever committed: rotate first, rewrite history second, verify the scanner is clean third. Rotation is the fix; history rewriting is hygiene.

Redact the audit trail sample by substitution, not deletion. "user_id": "u_REDACTED" preserves the structure a reviewer needs to evaluate. An empty field just looks like the field does not exist.

Publication checklist

Run this per repo. All boxes, no exceptions.

README gets a stranger to a working result with no outside help
Dependencies pinned; runtime version stated; setup verified on a clean clone
Full-history secret scan clean; any exposed credential rotated
License file present
ARCHITECTURE.md explains decisions, not just structure
THREAT-MODEL.md has a STRIDE table and named trust boundaries
docs/audit-trail-sample.json is real output, redacted by substitution
“How this agent fails” section written and honest
Demo recorded, under five minutes, includes the failure act
Write-up published and linked from the README
Tests cover the security controls and pass from a clean clone
Sample data contains nothing real
One other person cloned and ran it successfully

Exit criteria

Three repos public and independently reproducible
Three write-ups published
Three demos recorded, each showing a failure
Every repo carries all four required artifacts
Repos, posts, and profile cross-linked

From here, move into applications and interviews via career launch and keep the momentum with the continuous learning loop.

Month 2 — Orchestration & MCP Required Artifacts