AI Security Practitioner Model Role SOP and Operating Playbook

Model Role SOP / Operating Playbook — AI Security Practitioner

Document type: Evidence-derived model operating procedure
Role: AI security practitioner supporting an AI-enabled product or platform
Evidence scope: Structured purposive sample of 113 current U.S.-eligible employer requisitions from 90 employers, collected 5 October 2026, plus a separate 8 July–5 October 2026 current-changes review.
Prepared by: MTF Institute Research Team
Review responsibility: Local security owner reviews the adapted procedure before operational use.

Direct answer

An AI security practitioner moves an AI-system concern from an authorized intake to a documented decision and verified follow-up. The practitioner maps data and action boundaries, tests a defined risk in a safe environment, recommends a proportionate control, and gives the system owner evidence that supports a local release, remediation, or exception decision. The practitioner records who owns the decision; this model grants no production access or approval authority.

This is a reusable role model for a U.S.-applicable setting. Adapt its owners, permissions, tools, review gates, retention rules, and response times to the employer's approved processes. The vacancy study supports the work categories; it does not establish a universal employer procedure. The current-changes review informs the boundary checks below without establishing widespread adoption or a legal requirement.

Purpose, scope, and inputs

Use this procedure for a new or changed LLM application, retrieval workflow, agent, tool integration, model/data pipeline, or material control exception. It can also begin with a monitoring alert, reported vulnerability, incident, or scheduled review. Work on live systems, sensitive data, adversarial testing, access changes, and release approval requires the employer's explicit local authorization.

Before starting, obtain or request:

• The requester's name, business purpose, system owner, authorized environment, requested decision date, and approved test scope.
• A current architecture and data-flow view: users, instructions, lower-trust documents, retrieval stores, memory, model/provider, APIs, tools, outputs, and logging.
• Identities and permissions for users, services, agents, delegated tools, and data sources; owners for identity and policy changes.
• Data classification, privacy or contractual constraints, approved test data, and relevant retention rules.
• The applicable security, change, incident, release, and exception routes; the person authorized to make each decision.
• Available control evidence: design review, code or configuration, prior tests, monitoring signals, and open findings.

Local-control fields: approved systems and environments, permitted test methods, data classes, severity rubric, service-level targets, decision authorities, escalation contacts, record system, and retention period. Leave a field unresolved and request its owner rather than inventing a value.

Roles and decision boundaries

The practitioner may recommend a hold, but only the locally delegated decision maker can impose one. For novice practice, mapping, approved sandbox checks, written findings, and review requests fit within the delegated scope; release and exception decisions stay with the named local owners.

Trigger-to-close workflow

1. Register and authorize the intake. Record the trigger, system/version, requester, owner, urgency, affected users and data, and requested outcome. Confirm the permitted environment, test method, and decision route. If authorization is absent or the request concerns a live incident, stop the planned test and hand off through the local approval or incident route.
2. Map the task and trust boundaries. Describe the legitimate user task and expected output. Trace instructions, retrieved text, files, memory, tool responses, API calls, identities, data access, and outbound channels. Mark lower-trust input and each point where it could influence a higher-privilege action. Identify the owner of every boundary and any missing design fact.
3. Frame and prioritize the risk. State the plausible deviation, affected asset, prerequisites, and exposure. Distinguish a demonstrated behavior from a hypothesis. Consider prompt injection, unsafe tool use, overbroad delegation, cross-tenant retrieval, sensitive-data egress, untrusted memory or reusable components, and conventional application or cloud controls as relevant. Use the local severity rubric; do not treat a taxonomy label as a risk score.
4. Plan a bounded check. Write an approved test case with a safe input carrier, expected authorized behavior, prohibited behavior, observation points, stop condition, and rollback owner. Use synthetic data and a sandbox or specifically approved test environment. Do not probe a live third-party system, real users, or production secrets without explicit scope.
5. Run and preserve evidence. Execute the case within the approved limit. Record environment and version, test identifier, input class, tool/policy state, observed action or denial, relevant trace or log reference, and any effect on the legitimate task. Avoid storing raw secrets or unnecessary personal data in the evidence record. Escalate immediately if the test causes an unplanned effect or exposes sensitive information.
6. Select a control and owner. Recommend the smallest effective combination for the observed boundary: scoped identity and tool permissions, execution-time action authorization, retrieval access checks, input/output handling, provenance for memory or reusable skills, egress limits, detection, or a development/release gate. Name the implementation owner, expected safe behavior, failure mode, and rollback. Prompt wording alone should not be assumed to enforce authorization.
7. Verify both sides of the change. Re-run the unsafe case and representative legitimate tasks in the approved environment. Check that the prohibited action is blocked or contained, authorized work still completes, and audit signals can be attributed to the correct user, agent, tool, and policy decision. Record coverage and any unresolved uncertainty. A small test set is evidence for that set, not a fleet-wide effectiveness claim.
8. Hand off for a local decision. Send a concise evidence pack to the named product owner and decision maker: scope, observed result, proposed control, operational cost, residual risk, open questions, and recommended action. Use the employer's release or exception process. Record the decision, conditions, approver, expiry or review date, and responsible implementer; do not substitute a recommendation for approval.
9. Monitor and close. Verify that the assigned change and telemetry are in place, any exception has an owner and review date, and the case is linked to the local ticket or risk record. Close only when the decision, owner, evidence, follow-up, and monitoring or recheck trigger are documented. Reopen on a material system change, new attack path, failed control, or expired exception.

Working cadence

These are practical review prompts, not a universal work schedule. Only 34 of the 113 sampled requisitions stated cadence; the employer sets actual timing and response targets.

Decisions, handoffs, and escalation

Use a short decision record with four options: proceed with verified controls, remediate and retest, seek a time-bounded exception, or stop the activity under the local incident or release process. Record the evidence and decision owner for the selected option. Escalate immediately through the approved route when there is observed unauthorized tool use, sensitive-data exposure, cross-tenant access, a production impact, a failed containment control, or an unowned high-severity risk. If the test scope, owner, or data classification is unclear, pause that test and ask for clarification.

A handoff is complete when the recipient accepts the system/version, finding, reproduction reference, proposed control, affected legitimate task, due date, decision needed, and next verification step. A ticket marked “sent” without a named recipient and recorded decision remains open. A privacy or legal question goes to the designated specialist; an operational alert goes to security operations; an authorization change goes to the IAM or platform owner.

Records and quality measures

Keep records in the employer-approved system, under its access and retention rules. The minimum case set is:

• Intake and authorization record, including environment and scope.
• System and trust-boundary map with owner and version.
• Test plan and results with synthetic-data provenance, expected/observed behavior, and trace references.
• Finding and remediation record with severity rationale, owner, due date, and retest result.
• Decision or exception record with named approver, conditions, expiry, and review trigger.
• Monitoring and closure note with alert owner, follow-up date, and unresolved limits.

Choose targets locally; do not copy a threshold from this model. Useful measures are:

• Scoped test coverage: completed approved cases divided by planned cases for the reviewed system and version.
• Unsafe-action outcome: blocked or contained prohibited actions divided by attempted prohibited actions in the bounded test set, reported with the raw counts and scope.
• Legitimate-task outcome: authorized tasks completed divided by evaluated authorized tasks, with false blocks recorded separately.
• Trace completeness: cases with attributable user/agent, tool, policy decision, and timestamp divided by sampled cases.
• Remediation closure time: elapsed time from accepted finding to verified fix, segmented by local severity.
• Exception hygiene: open exceptions without an owner, expiry, or scheduled review, reported as a count.
• Detection and response: time from an observed signal to triage or escalation for cases where the local process defines such a target.

A denominator of one or a selectively chosen case set is not a reliability estimate. Review both security and legitimate-task outcomes before claiming that a control works for a broader deployment.

Reusable SOP model

Copy these fields into the employer-approved record and replace every bracketed item before operational use.

Case identity: [system and version] · [owner] · [trigger] · [date] · [local record ID]
Authority: [approved environment] · [test scope] · [decision maker] · [incident route]
Legitimate task: [user request] → [expected output or action]
Boundary map: [trusted instructions] → [lower-trust inputs] → [retrieval/memory] → [model/agent] → [tools and permissions] → [data/output/egress]
Risk statement: [attacker-controlled surface] could [specific prohibited outcome] if [boundary or control fails]; [known/unknown exposure].
Test plan: [safe input class] · [expected authorized behavior] · [prohibited behavior] · [stop condition] · [rollback owner].
Result: [test IDs] · [observed action or denial] · [trace reference] · [legitimate-task result] · [evidence limits].
Control proposal: [control and enforcement point] · [implementation owner] · [validation plan] · [operational trade-off].
Decision: [local option] · [named approver] · [conditions] · [exception expiry, if any].
Close: [verified change] · [monitoring owner] · [follow-up date] · [reopen trigger].

Worked application

Fictional example for learning purposes.

A product team asks an AI security practitioner to review an internal retrieval assistant before a tool-enabled pilot. The authorized user task is to summarize a synthetic support note and create a ticket only in a designated sandbox queue. A retrieved note contains an instruction-like request for the assistant to send the summary to an unrelated destination and create a ticket outside that queue. The note is lower-trust task data, not a new instruction or permission.

The practitioner obtains the product owner's written sandbox scope, confirms that all notes and destinations are synthetic, and maps the user, retrieval store, assistant service identity, ticket tool, destination allowlist, and audit log. The hypothesis is that retrieved text might influence a tool call beyond the user's authorized queue. The test plan states one prohibited action, one authorized task, expected tool decisions, trace fields, and a stop condition if a real destination or live credential appears.

In the sandbox run, the assistant attempts an out-of-scope ticket action. A tool-side authorization rule denies it and records the user, agent, requested action, destination, and policy outcome. The same configuration permits the designated sandbox ticket and produces the requested summary. The practitioner records the two test IDs, traces, policy version, and the limitation that these checks cover only the reviewed configuration and cases.

The recommendation is to keep the tool-side destination allowlist, scope the assistant identity to the sandbox queue, add an alert for repeated denied actions, and re-run both cases after any retrieval or tool-permission change. The platform owner accepts the implementation task. The named local release decision maker reviews the evidence and records the pilot decision; the practitioner does not approve it. The case closes when the policy change, log signal, owner, and recheck trigger are confirmed in the local record.

Quick reference

• Confirm scope and decision owner before testing.
• Map lower-trust content, identity, tool actions, data access, and egress.
• Test prohibited and legitimate behavior with synthetic data in an approved environment.
• Put authorization at the action boundary; record attributable evidence and residual risk.
• Hand off to the actual implementation, incident, privacy, and release owners.
• Close only with a recorded decision, follow-up owner, and recheck trigger.

Related resources: the companion Model Job Description and ATS-Friendly Resume Template translate the same evidence into role expectations and truthful experience presentation. The vacancy study and current-changes review provide the underlying context.