# AI Security Practitioner Model Job Description

Adapt an evidence-derived AI security practitioner job description covering responsibilities, work products, technical skills, authority and local hiring decisions.

**Build practical AI security capability:** [Open the course and enrol](https://mtfinstitute.com/programs/ai-security-prompt-injection-llm-risk/#enroll)

**Resource type:** model job description  
**Evidence geography:** United States  
**Evidence scope:** Structured purposive sample of 113 current U.S.-eligible vacancies from 90 employers reviewed 5 October 2026, plus a separate 90-day current-changes review; not a nationally representative labor-market estimate.  
**Accepted source SHA-256:** `1d0781d8d78ec56aeb2b9f0d9de0cdc77b5e6cd7360757fa7efafc989afd84e1`

## Model Job Description: AI Security Practitioner

**Document type:** Evidence-derived, reusable job-description template; not a live vacancy or universal employer policy.  
**Evidence scope:** Current United States employer requisitions reviewed 5 October 2026: 113 distinct requisitions from 90 employers, sampled purposively.  
**Source basis:** [U.S. vacancy study](https://mtfinstitute.com/insights/ai-security-us-vacancy-requirements-2026/) and [current-changes study](https://mtfinstitute.com/insights/ai-security-prompt-injection-agent-controls-2026/).  
**Prepared by:** MTF Institute; local hiring manager and security owner must review the adapted version.  
**Document date:** 5 October 2026.

## Direct answer: what is this role?

An AI security practitioner helps the owner of an AI-enabled product or platform understand and reduce security risk across instructions, retrieved content, identities, data, model or agent behavior, tool actions and the surrounding application. The work combines threat modeling, authorized evaluation, implementable controls, monitoring and clear handoff. The employer must define the exact system, seniority, permissions, decision rights and work rhythm before using this model.

## Why these responsibilities appear here

In the 113 reviewed U.S. requisitions, **79 explicitly assign security architecture or control implementation**, 57 AI-system threat modeling or security review, 40 sensitive-data exposure or exfiltration control, 39 agent tool/action authorization, 38 AI-security detection/monitoring/incident response and 37 guardrail or runtime-policy design. The categories overlap. Prompt-injection or jailbreak *testing as an assigned duty* appears in 11, while prompt-injection attack or defense is *mentioned in any coded context* in 80. The model therefore covers the wider AI security role without treating every mention as a duty. These sample counts do not estimate U.S. hiring prevalence. The matrix also gives a separate employer sensitivity check: architecture/control implementation occurs at 65 of the 90 employers, threat modeling/review at 50, and agent action authorization at 36.

## Reusable model — complete local fields before posting

### Position and purpose

**Job title:** [AI Security Practitioner / locally approved title and level]  
**Team and reporting line:** [team; manager; security governance owner]  
**Workplace and employment terms:** [U.S. location or approved remote scope; employment type; employer-provided terms]  
**Systems in scope:** [named AI products, internal agents, retrieval services, model platforms and supporting applications]  
**Authorized environments:** [development, test and production access separately stated]  
**Purpose:** Help [team] identify trust and permission boundaries in [systems], test defined security questions within approved scope, design or review proportionate controls, and provide evidence that the responsible owner can use to act.

### Core responsibilities

- Map the flow of user requests, system instructions, retrieved documents, tool responses, stored memory, sensitive data and agent actions; identify who can alter each surface and which permissions it can influence.
- Conduct or contribute to AI-system threat models and security architecture reviews, connecting LLM-specific risks to application, API, identity, cloud and data controls.
- Plan and perform **authorized, bounded** prompt-injection, jailbreak or adversarial evaluations in synthetic or employer-approved test environments. Record the attacker-controlled surface, intended deviation, expected boundary, observed behavior and legitimate-task impact. Do not test unowned systems or use real secrets or customer records in examples.
- Review agent identity, delegated authority, tool allowlists, resource scopes, human approval points and action attribution. Recommend controls that enforce decisions outside model-generated text where appropriate.
- Review retrieval and context handling, data exposure, model or data-pipeline dependencies, third-party components and reusable agent skills where those are in the local system scope.
- Design, implement or review guardrail and runtime-policy patterns with engineers; test both unsafe-action prevention and acceptable completion of authorized work.
- Define useful telemetry and detection signals, investigate control failures with the appropriate operations team, and contribute evidence to incident handling when assigned.
- Translate findings into specific risk statements, implementation guidance, owner handoffs and retest criteria; explain tradeoffs without implying that a proposed control removes all risk.
- Support the local development and release process through scoped reviews and evidence. Apply the employer's actual approval, exception and escalation routes.

### Expected work products

- A system and trust-boundary map or threat model identifying assets, lower-trust inputs, privileged actions, assumptions and control owners.
- A reproducible, authorized evaluation plan and result showing expected versus observed behavior, test limits and any effect on legitimate work.
- A security architecture review or control recommendation with implementation owner, validation evidence and residual risk.
- A guardrail, authorization or reference-policy pattern appropriate to the local workflow.
- Detection or monitoring requirements, incident evidence or a handoff to the team responsible for response.
- A concise risk assessment or evidence pack for the local decision maker.

These are model outputs to select and rename locally. In the source sample, guardrail policies/reference patterns were explicitly assigned in 35 requisitions; adversarial test results and threat models in 15 each; detection signals and architecture reviews in 13 each. No requisition was coded as expressly requiring a *named* remediation ticket or release/exception decision record, so this model does not claim either is a universal employer deliverable.

### Hard skills and methods

- Understand LLM applications, agents, retrieval-augmented generation and tool invocation well enough to identify data, instruction and permission boundaries.
- Apply threat modeling, secure design and adversarial evaluation to a concrete AI-enabled workflow; distinguish a demonstrated failure from a plausible hypothesis.
- Use application/API security, identity and authorization, data protection, cloud/platform security and secure coding or scripting as the technical foundation for AI controls.
- Specify and validate scoped permissions, policy decisions, logging, detection and incident evidence.
- Write repeatable test conditions, document control limits and translate results into a developer-ready change or an owner decision.

The matrix records skills in **any coded context**, assigned duties and required/preferred applicant criteria separately. For example, identity/authentication/authorization is mentioned in 81/113 requisitions and prompt-injection attack/defense in 80/113; neither figure means every employer lists the capability as a mandatory qualification. Adapt the required criteria below to the exact level and employer screening standard.

### Observable working behaviors

- Ask a system owner for missing architecture, access, intended user behavior and decision context before assessing risk.
- Collaborate with developers, platform engineers, AI/research staff, security operations and other named owners to verify a finding and agree on a feasible repair.
- Explain the specific failure path and repeatable check in writing; separate observation, inference, severity rationale and residual uncertainty.
- Prioritize with the owner by impact, exposure, feasibility and business constraints; document tradeoffs and the person responsible for a decision.
- Provide guidance and follow through with a retest or documented handoff; escalate an active incident through the local response route.

These actions make behavioral skills assessable. Cross-functional collaboration is mentioned in any coded context in 72/113 requisitions, developer guidance in 55, clear written findings in 29 and incident coordination/escalation in 20; mentions are not performance measurements.

### Tool and system categories

The local role may use model/agent and retrieval environments; API and application test harnesses; identity and policy-enforcement systems; cloud, container and CI/CD security tools; code and infrastructure-as-code review; logging, SIEM and incident tooling; and risk or work-tracking systems. List the employer's actual approved products, languages, repositories and access levels here: **[local tool inventory]**. The aggregate research does not normalize individual product or language frequencies and supports no universal vendor stack.

### Experience and level

**Select and edit one local level:** [entry-level contributor under review / independently operating engineer / senior or staff designer and reviewer / specialist researcher].  
**Minimum evidence for this posting:** [job-related experience, demonstrable artifacts or equivalent route, as approved by hiring manager].  
**Required criteria:** [locally verified foundations, methods and systems needed on day one].  
**Preferred criteria:** [locally verified additional experience; label clearly as preferred].

The vacancy sample mixes engineer I, engineer, research, senior, staff, principal and lead roles. It states seniority in 71/113 requisitions, experience in 85/113 and education in 35/113. It does not support a universal degree, certification or years-of-experience threshold. For a beginning contributor, assign a bounded workflow, approved test environment and named reviewer; reserve production changes, release decisions and unsupervised incident action for formally authorized roles.

### Interfaces, authority and escalation

**Primary interfaces:** [product/application owner], [AI/platform engineering], [IAM/DevSecOps], [security operations/incident owner], [privacy/compliance as relevant], [risk or release decision maker].  
**May decide independently:** [specific technical tasks and approved test scope].  
**Must obtain approval for:** [production access or change, adversarial test scope, new agent permissions, sensitive data use, release or exception decision].  
**Escalates to:** [named incident channel/owner for active harm], [named security owner for material unresolved risk], [named release owner for decision or exception].  
**Required handoff record:** [approved tracking system, evidence fields and follow-up owner].

These are local fields because decision authority is stated in 45/113 reviewed postings and escalation in only 9/113. The research does not grant a generic AI security role final sign-off or a universal right to block a release.

### Work cadence

- **Daily or as assigned:** Coordinate on active engineering reviews, inspect relevant alerts or test results, update findings and handoffs.
- **Weekly or per development cycle:** Review changed AI workflows, permissions, retrieval sources and control evidence with the responsible owners; track remediation and retest status.
- **Monthly or per local governance cycle:** Reconcile recurring risk themes, control drift, owner decisions and material changes in the system inventory.
- **Event-driven:** Assess new agents, tools, data connections, memory functions, model changes and major releases; support an incident or external finding through the approved response process.

The schedule is a **local adaptation scaffold**, not a measured standard. Cadence is explicitly stated in only 34/113 requisitions; postings illustrate pre-release evaluation, iterative engineering, ongoing monitoring and incident-triggered response. Set actual service levels, review frequency and on-call duties locally.

## Local adaptation checklist

- Replace every bracketed field with an approved employer fact and remove tasks outside the real system scope.
- Choose one level and align required versus preferred qualifications with that level; retain alternative experience routes only if the employer accepts them.
- Name the exact AI workflows, data classifications, tool permissions, test environment and authorized systems.
- Name the control, remediation, incident and release decision owners; set approval and exception routes.
- Confirm expected outputs, approved tool stack, practical work rhythm and any on-call responsibility with the hiring manager.
- Review the description with product, security, privacy and people teams as locally appropriate; publish it as a vacancy only through the employer's normal process.

## Evidence and currency note

The role model reflects the [accepted U.S. vacancy research](https://mtfinstitute.com/insights/ai-security-us-vacancy-requirements-2026/) and [independent 90-day changes research](https://mtfinstitute.com/insights/ai-security-prompt-injection-agent-controls-2026/) available on 5 October 2026. Recent OWASP material, NIST project updates, vendor guidance and controlled research make agent authorization, memory and reusable-skill provenance, runtime policy, and safe evaluation environments timely review topics. They do not establish mandatory U.S. rules, universal employer adoption or guaranteed control effectiveness. Refresh the local version against current systems and source status before use.

## Connected role pathway

- [ats resume template](https://mtfinstitute.com/insights/ai-security-engineer-ats-resume-template/)
- [model job description](https://mtfinstitute.com/insights/ai-security-practitioner-model-job-description/)
- [role sop operating playbook](https://mtfinstitute.com/insights/ai-security-practitioner-role-sop-operating-playbook/)
- [Vacancy evidence](https://mtfinstitute.com/insights/ai-security-us-vacancy-requirements-2026/)
- [Current-practice analysis](https://mtfinstitute.com/insights/ai-security-prompt-injection-agent-controls-2026/)

**Study the AI security work cycle:** [Open the course and enrol](https://mtfinstitute.com/programs/ai-security-prompt-injection-llm-risk/#enroll)

Canonical URL: https://mtfinstitute.com/insights/ai-security-practitioner-model-job-description/