What Employers Screen For
Hiring for agentic AI security is unusual in one specific way: there is no established credential that predicts competence, and the pool contains a large number of people who learned the vocabulary last quarter. Hiring managers know this. So screening has collapsed onto a single question — can this person produce evidence they did the work themselves? That question is answered almost entirely by artifacts, and mostly before anyone reads your résumé carefully. This page describes what that screening actually looks like, artifact by artifact and role by role.
The first sixty seconds of your GitHub profile
Assume a hiring manager opens your profile with a specific hypothesis to confirm or reject, and roughly a minute to do it. What they check, in order:
| Signal | What they conclude |
|---|---|
| Pinned repositories | Whether you know what your own best work is. Six unpinned tutorial forks is an answer. |
| Top repository’s README, first screen | Whether you can state a problem, an approach, and a result without preamble |
| Commit history shape | Whether the project was built over weeks or dumped in one commit the night before applying |
| Presence of a security section | Whether this is an AI project or an AI security project |
| Issues, tests, and configuration | Whether you build things or demo things |
The README’s first screen carries disproportionate weight. It should state what the system does, what the security question was, what you found, and what remains unsolved. Any README that opens with an installation section has wasted its most valuable real estate.
Why a red team write-up beats a demo
Given a working multi-agent demo and a five-page red team report on someone else’s agent, most hiring managers pick the report. The reasons are worth being explicit about:
- A demo proves capability; a report proves judgment. Wiring a framework together is a solved problem with abundant tutorials. Deciding what to attack, and recognizing why the defense failed, is not.
- A report is verifiable. It contains reproduction steps someone can run. A demo video proves only that it worked once, on your machine, with an unspecified model version.
- A report shows you can write. Much of this job is convincing an engineering team to spend a sprint on a fix. That happens in documents.
- A report handles non-determinism. Reporting a 60% success rate over twenty trials demonstrates methodological awareness that a demo cannot express.
The strongest single artifact in this field is a red team report against a system you also built, because it proves both halves at once — and proves you will attack your own work rather than defend it.
What a report should contain, in the order a reviewer wants it:
| Section | Purpose | Common omission |
|---|---|---|
| Summary and impact | Lets a busy reader stop after one paragraph | Buried under setup detail |
| System under test | Makes the result interpretable and reproducible | Model version and configuration unstated |
| Attack chain | Shows the reasoning, not just the payload | Presented as a single clever prompt |
| Results across trials | Establishes this is a finding, not an anecdote | Only the successful run is shown |
| Why the defense failed | The actual value of the document | Replaced by “the model was tricked” |
| Mitigation and re-test | Proves you can close, not just open, an issue | Mitigation proposed but never tested |
| Limitations | Signals honesty and scoping judgment | Absent |
The artifacts that convert
Four artifact types consistently move candidates from “interesting” to “interview”. They are small; the differentiator is rigor, not volume.
| Artifact | What it proves | How it fails |
|---|---|---|
| Threat model diagram | You reason about systems, not features | Generic STRIDE table with no system-specific threat |
| Trust boundary design | You understand where agent authority actually changes hands | A box labeled “LLM” with no data flows or credentials shown |
| Audit log sample | You can produce evidence, not just claim controls | Application print output relabeled as an audit trail |
| “How this fails” section | You are honest and you know the limits of your own work | Absent, or a vague note about “future improvements” |
The “how this fails” section deserves special attention, because it is the cheapest to write and the rarest to find. Three or four sentences naming what your system does not defend against — the attack class you did not test, the assumption you made about the model provider, the control you stubbed — does more for your credibility than another feature. Every artifact in portfolio artifacts should carry one.
Anti-signals
These are the patterns that end a screen. Each one is common enough that reviewers pattern-match it instantly.
| Anti-signal | What the reviewer concludes | The fix |
|---|---|---|
| Agent demo with no failure analysis | AI enthusiast, not a security practitioner | Attack your own system and publish the results |
| Framework name-dropping with no mapped finding | Read the summary page, did not apply it | Map one real finding you produced to one specific technique |
| Copied risk register template | Can fill in a spreadsheet | Rebuild it from a system you assessed, citing your own logs |
| Certification list with no artifacts | Optimizing for credentials over capability | Pair each claim with something you built |
| “Prompt engineering” as a headline skill | Has not encountered the actual problem space | Lead with trust boundaries, identity, or evidence instead |
| Screenshots of a model saying something bad | Confuses an anecdote with a finding | Report reproduction steps and success rate across trials |
The framework anti-signal is the most frequent. Listing OWASP LLM Top 10, MITRE ATLAS, and NIST AI RMF on a résumé costs nothing and is therefore worth nothing. One finding you discovered, mapped to one ATLAS technique, with the reasoning for that mapping written out, is worth all three lists. See MITRE ATLAS for how to do the mapping properly, and standards references for the source material.
How screening differs by role
The bar is not uniform. Each of the five core roles screens for a different primary quality, and the artifact that satisfies one does not satisfy another.
| Role | Primary screen | Artifact that satisfies it |
|---|---|---|
| Agentic AI Security Engineer | Can you build tooling and find real issues? | A working security automation with a documented finding it surfaced (Lab 1) |
| Agentic AI Red Teamer | Can you find something non-obvious and prove it? | A reproducible attack chain with success rates and a re-tested mitigation (Lab 3) |
| Orchestration Engineer | Can you build a system that enforces constraints? | A multi-agent system with least-privilege scoping, an approval gate, and a documented blast radius (Lab 2) |
| Security Architect | Can you decide and defend a trade-off? | A trust boundary diagram plus a written identity model with rejected alternatives (Lab 5) |
| Governance Engineer | Can you automate evidence rather than describe controls? | An evidence collector producing control-mapped records from real telemetry (Lab 4) |
Two practical implications. First, apply with the artifact that matches the role — sending an orchestration project to a red team posting reads as a generic application. Second, the architect screen is the only one where rejected alternatives matter as much as the chosen design; if your diagram shows one option, you have shown a drawing, not a decision.
The adjacent roles screen slightly differently, and more forgivingly:
| Role | Primary screen | Artifact that satisfies it |
|---|---|---|
| AI Incident Response Analyst | Can you reconstruct behavior from incomplete evidence? | A post-mortem of an incident you caused, plus the instrumentation gaps it exposed |
| MLSecOps Engineer | Does your pipeline fail closed? | A build log showing an unsigned or drifted artifact being rejected |
| AI Privacy Engineer | Does deletion actually propagate? | A working delete path across store, index, memory, and traces — with the gaps named |
Notice that all three are satisfied by evidence of something not happening: an unanswerable question, a rejected build, a removed record. That is a useful general pattern. Artifacts that demonstrate a system correctly refusing are more informative than artifacts demonstrating a system succeeding, because refusal is the part that is hard to fake.
Where certifications sit
Certifications are a weak positive signal in this field and never a substitute for an artifact. They function best in two situations: getting past an automated or HR-level filter that requires a keyword, and giving a career-changer a structured curriculum. They function worst as the centerpiece of an application, because no current certification tests the thing that actually predicts performance here — whether you can find a real problem in a real system and write it up so someone fixes it.
The ordering that works: build one artifact, then take a certification that gives you vocabulary and structure around it, then reference both together. The ordering that does not: collect credentials and hope the artifacts follow. More detail in certifications.
What happens in the interview
Assume the artifacts got you the call. The technical conversation is usually your own work, interrogated:
- “Walk me through why this failed.” Tests whether you understand your finding or reproduced someone else’s. Answer at the layer where the defense was absent, not at the level of “the model was tricked”.
- “What would you do differently with more time?” Tests self-assessment. A candidate with no answer either did not think hard or is not honest.
- “What did you decide not to defend against?” Tests scoping judgment. “Everything” is a failing answer.
- “How do you know this works?” Tests evidence discipline. Point at logs, trials, and rates.
- “What surprised you?” Tests whether you actually ran the thing. Real work always produces a surprise.
Every one of these is answerable if you did the work and unanswerable if you did not, which is precisely why they are asked. Preparation notes are in interview prep, and the artifact-to-offer sequence is in portfolio to offer.
A minimum viable portfolio
If you have limited time, this is the smallest set that survives screening for any of the five roles. Three items, built in this order:
| # | Item | Why it earns its place |
|---|---|---|
| 1 | One working system with a security property you can name | Proves you build, and gives every later artifact something concrete to reference |
| 2 | One red team report against that system | Proves judgment, method, and writing in a single document |
| 3 | One evidence or governance artifact derived from the first two | Proves you can close the loop from finding to control to record |
Together these tell one coherent story about one system, which is far more persuasive than three unrelated projects. Each should carry a “how this fails” section, and the third should cite logs the first actually produced. The 90-Day Plan sequences exactly this, and continuous learning covers what to do after it is published.
The through-line across every role and every screen: reviewers are trying to distinguish people who have handled the actual problem from people who have read about it. Everything above is a proxy for that one distinction. Build things, break them, write down honestly what happened — and the screening takes care of itself. Continue to certifications for where credentials do and do not help, or start the build in the 90-Day Plan.