For AI Security Engineer · the method
How we solve it.Piece by piece, with provenance.
How the seventh role owns model and agent security on the same CSA spine — distinct from the pipeline gates, without absorbing Compliance’s register work.
Piece 1
Primary ownership on the spine
Inputs
- The Track 2 reskilling master list: each AICM control attributed to a persona owner, with a skill verb and a capability prompt
Mechanism
- Controls that secure the model, contain the agent, guard the runtime, defend training data, and attack the model before adversaries do resolve to this persona as primary
- Touches on neighboring personas (DevSecAIOps, Practitioner, Compliance) stay secondary — coordination, not ownership transfer
Outputs
- A named skill list this role reskills into — direction and next rung, never a complete how-to
Provenance: tools/reskill-persona-map.json → web/lib/reskill-master.ts (owner sample-review approved 2026-07-17).
The deeper layer — named here, shown in a walkthrough
- The full per-control attribution table and the judgment notes on boundary controls (e.g. GRC-14, AIS-14)
Piece 2
The fence with DevSecAIOps and Compliance
Inputs
- Pipeline tollgates (DevSecAIOps) and the comply-once crosswalk (Compliance)
Mechanism
- DevSecAIOps owns CI-shaped gates that catch AI failure modes at ship time; this role owns adversarial evaluation, agent boundaries, and model integrity at run and train time
- Compliance owns regime mapping and evidence reuse; bias/fairness assessment may touch this role without transferring the register
Outputs
- A clear job split the CISO can show the board: who contains a rogue agent, who gates the pipeline, who evidences the regimes
Provenance: Persona doors + /library/tollgates + /guide/compliance/method — three surfaces, one spine.
The deeper layer — named here, shown in a walkthrough
- The contested-boundary notes between MDS / AIS agent controls and pipeline gates
Piece 3
Prove on a live guard
Inputs
- A shipped guard and a fixed attack corpus with a held-out set
Mechanism
- Baseline → fit → re-score on the same corpus; the scorer that grades the guard is the same shape of check a pipeline can later wire as a gate
Outputs
- A modeled before/after with every number labeled — proof of skill direction, not a product warranty
Provenance: The StoryBond case — lib/storybond-demo.ts; evidence state modeled.
The deeper layer — named here, shown in a walkthrough
- The fit moves and corpus construction rules behind the modeled scores
Piece 4
The stack & instruments
Inputs
- 16 published instruments in three lanes — 14 testers, 3 corpora, 5 controls — validated at every build
- Python 3 stdlib-only tooling — nothing to install to reproduce a claim
Mechanism
- Shared-responsibility tags (owned / shared / inherited) join at render via the existing SSRM lens — this role does not reskill for what the provider already owns
- Lane integrity is machine-enforced: an instrument never grades its own lane, and nothing on this site says "tested" without a named instrument behind it
Outputs
- A named, reproducible instrument behind every tested claim you read here
Provenance: lib/tools-registry.ts, guarded by validate-tools in the prebuild chain; instrument detail renders in the /controls drill.
The deeper layer — named here, shown in a walkthrough
- The per-instrument wiring: which tool validates which skill, and which tool grades which instrument
- Acceptance thresholds per tester lane
- The per-control SSRM split for Model Security and agent-boundary objectives
Canonical surfaces
Application / DevSec maturity track →StoryBond prove →SSRM ownership →