Hiring for AI security means testing for a specific, still-rare skill set: candidates who understand prompt injection, data leakage, insecure tool access and agent abuse as engineering problems with layered mitigations, not as headlines. Most teams don't need a dedicated AI security hire at first, they need engineers and security staff who carry these skills, and interviews that can detect them.
The threat areas to cover
- Prompt injection: untrusted content steering the model, especially indirect injection via retrieved documents, emails and web pages.
- Data leakage: models revealing system prompts, other users' context, or sensitive training/retrieval data.
- Agent permissions: tool-using systems with more access than the task needs, one hijacked step becomes real damage.
- Supply chain: unvetted models, poisoned datasets, malicious tool definitions and dependencies.
- Classic appsec still applies: authentication, tenancy isolation and logging around AI endpoints.
Interview probes that reveal depth
- 1'Design defenses for an assistant that reads customer emails and can call APIs.' Look for layered thinking: input handling, least-privilege tools, output validation, human gates on high-risk actions.
- 2'Can prompt injection be fully solved?' Strong answer: no, so contain it, limit blast radius, don't trust model output as authorization.
- 3'How would you red-team our feature?' Good candidates enumerate attack paths unprompted and mention testing it continuously, not once.
- 4Ask for a war story: an AI-specific vulnerability they found or fixed, and what changed structurally afterward.
Who to hire, and when
- Early: raise the bar in existing roles, every AI engineer should reason about injection and least privilege.
- Growth: add a security engineer with real LLM exposure, or upskill your appsec lead with dedicated time.
- Agentic scale: once agents act on production systems and customer data, a dedicated AI security owner stops being optional.
