The Five Core Roles

These five roles cover the failure surface of an agentic system end to end: someone finds the bugs, someone proves they are exploitable, someone builds the orchestration that contains them, someone draws the boundaries the orchestration must respect, and someone proves to an outside party that all of it happened. Titles vary wildly between organizations — the same job description shows up as AI Security Engineer, LLM Security Engineer, or Agent Platform Security. What does not vary is the underlying responsibility. Read these as responsibility clusters, not as job titles to search for.

1. Agentic AI Security Engineer

The generalist of the group, and usually the first agentic security hire an organization makes. The day job looks like classic product security with a new class of target: you review the code and cloud configuration behind agent deployments, hunt for vulnerabilities in tool definitions and API surfaces, and — increasingly — build automation that does security work using agents rather than merely securing them.

A realistic week: audit the IAM role attached to an agent’s execution environment and find it can read a whole S3 bucket when it needs three prefixes; review a new tool definition and notice the execute_query function takes a raw string; then spend two days building a triage workflow that pulls alerts, enriches them, and drafts a summary a human confirms.

What distinguishes a strong candidate: they treat the AI coding assistant as a tool they have also threat-modeled. Weak candidates show you a working agent. Strong ones show you the agent, then explain which of its outputs they refuse to trust without a human check, and why. Build the deliverable in Lab 1.

Common title variants: AI Security Engineer, LLM Security Engineer, Product Security Engineer (AI). The tell that a posting is really this role is a requirement for cloud and code review alongside anything about agents.

2. Agentic AI Red Teamer

You break agents on purpose and write down exactly how. The work is closer to vulnerability research than to penetration testing: the attack surface is under-documented, so a meaningful part of the job is inventing the test rather than running a known one. Prompt injection through retrieved documents, memory poisoning that persists across sessions, RAG corpus manipulation, tool-chaining that escalates a benign capability into a destructive one, jailbreaks that survive a system-prompt rewrite.

A realistic week: plant a payload in a document the agent will retrieve tomorrow, confirm the agent acts on it, then determine whether the existing guardrail catches it — and prove the guardrail is bypassable by rephrasing. Then map the finding to OWASP LLM Top 10 and MITRE ATLAS so the fix gets prioritized against other work.

What distinguishes a strong candidate: the write-up, not the exploit. Anyone can screenshot a model saying something it should not. A strong candidate shows a reproducible chain with a success rate across trials, identifies why the defense failed (input filtering at the wrong layer, missing output validation, over-permissive tool), and proposes a mitigation they then re-test. Non-determinism is the hard part — one lucky success is an anecdote. Practice in Lab 3.

Three things people get wrong about this role. It is not primarily about jailbreaking chatbots — the interesting attacks target the agentic surface, where the model has tools and the payoff is an action rather than a sentence. It does not require training models; it requires understanding how they consume context. And it is more writing than exploiting: a finding nobody can reproduce or prioritize does not get fixed, and unfixed findings do not build a reputation. See the tooling notes for what the harness side looks like.

3. Agentic Security Orchestration Engineer

You design how multiple agents work together without the collective system becoming more dangerous than any single agent. This is a builder role with a security mandate: message passing between agents, tool exposure through MCP servers, sandboxing and container isolation, timeouts and circuit breakers, and the state machine that decides when a human must approve.

A realistic week: split a monolithic agent into a planner and a set of narrow executors so no single component holds both the read and the write credential; wire an approval gate into a LangGraph state machine; then containerize a tool server so a compromised tool cannot reach the host network.

What distinguishes a strong candidate: they can articulate the blast radius of every agent in their graph. Ask “what happens if agent 3 is fully compromised” and a strong candidate answers with the specific credentials, tools, and downstream agents reachable from that node — not with “we have a guardrail”. See Lab 2 and the agent framework notes.

4. Agentic AI Security Architect

You decide where the boundaries are before anyone writes code. Trust boundaries between the model, the tools, the data, and the user. Agent identity — whether an agent gets its own credential, acts on behalf of a user, or borrows a service account, and how that decision propagates through logs. Data access policy expressed as code rather than as a wiki page. And the human-in-the-loop design: which actions are reversible, which require approval, and who is accountable when the approval is rubber-stamped.

A realistic week: review three proposed agent designs against a boundary standard, reject one because it grants the agent a credential that outlives the session, and write the policy-as-code rule that makes that rejection automatic for the next team.

What distinguishes a strong candidate: they make a decision and defend the cost of it. Architecture candidates fail when every answer is “it depends”. A strong candidate says: this agent gets a short-lived, session-scoped credential, which means we accept a re-auth prompt on long-running tasks, and here is why that trade is correct for this workload. Seniority helps here, but architecture is not exclusively a senior role — a candidate who has genuinely modeled one system well can compete.

The distinguishing question this role owns, which nobody else reliably asks: when the agent acts, whose authority is it acting under? Most early agent deployments answer this by accident — a service account with standing permissions, shared across users and sessions, invisible in the audit trail. Getting the answer right early is architecture; getting it wrong produces a class of incident that cannot be investigated afterwards. Work through it in Lab 5.

5. AI Security Governance Engineer

The engineering answer to compliance. You maintain the inventory of AI systems in the organization — which is harder than it sounds, because agents get built in corners — run risk assessments against a recognized framework, and above all automate evidence collection so that proving control effectiveness does not consume a quarter of every year.

A realistic week: query the model registry and cloud APIs to reconcile the AI inventory against what teams self-reported; classify two new systems against EU AI Act risk tiers; then extend an evidence pipeline so every agent run emits a record that satisfies an audit question without a human writing anything.

What distinguishes a strong candidate: code. The field is crowded with people who can name three frameworks and produce a spreadsheet. A candidate who shows a script that emits audit-ready records from real telemetry is in a different category entirely. See evidence automation and Lab 4.

This role is also the one most often underestimated by engineers, who read it as paperwork. In an organization deploying agents into regulated processes, the governance engineer decides what ships. That is leverage, and it is why the role rewards people who can both read ISO/IEC 42001 and write a script against a cloud API — a combination that remains genuinely uncommon.

Comparison at a glance

Two caveats on that table. “Entry difficulty” measures distance from a conventional security background only — from a software engineering background the ordering shifts, with Orchestration Engineer becoming the easiest entry and Governance Engineer the hardest. And “framework load” is not a proxy for difficulty; the Red Teamer’s high framework load is mostly taxonomy for organizing findings, while the Governance Engineer’s is normative and must be applied correctly.

What all five share

Regardless of which one you target, four competencies show up in every version of this work:

If you are early and unsure which role fits, build these four first. They are load-bearing everywhere and none of the time you spend on them is wasted by a later change of direction.

How the roles hand off to each other

They are not silos, and in a small organization one person plays three of them. The natural flow of work:

1. The Architect defines a trust boundary and an identity model.
2. The Orchestration Engineer implements a system that respects it, and reports where the boundary was impractical.
3. The Red Teamer attacks the implementation and finds the case where the boundary leaks.
4. The Security Engineer fixes it and builds detection so the same class of failure surfaces automatically next time.
5. The Governance Engineer captures the whole cycle as evidence that the control exists and works.

The most common breakage is between steps 3 and 5: a red team finding that never becomes a control, and a control that never becomes evidence. Candidates who can visibly close that loop — one finding, traced through fix and detection into an audit record — are rare and disproportionately valuable, regardless of which title they interview for.

Organization size determines how much of this loop you personally own:

This matters when choosing where to apply. A small company gives you breadth across all five at the cost of depth in any; a mature one gives you depth and a narrow remit. Early in a transition, breadth usually compounds faster — you learn which failure you actually want to own by touching several of them.