What Is AI Security Engineering? The 14-Domain Map for Securing AI Systems

Slug: what-is-ai-security-engineering-14-domain-map Effective Date: 2026-05-17 Version: v1.0 Author: David Wolf Status: Draft Minimum Target Length: 2,000 words

AI Security Engineering is what happens when teams stop treating AI as a feature label and start treating it as a system with boundaries, owners, controls, and evidence. The role exists because modern AI adoption crosses product security, data security, identity, cloud, detection, and governance at the same time.

1. Why This Matters

The market keeps asking one person to explain the whole stack. That only works when the work is mapped clearly. Without a domain map, teams end up with vague ownership, weak handoffs, and controls that are impossible to test.

2. Core Concept

The useful definition is simple: AI Security Engineering turns AI risk into architecture, controls, telemetry, evidence, and decision rights. It is not a slogan for AppSec with new nouns. It is a way to make AI systems reviewable.

3. Threat Model or Failure Model

• No one owns the AI inventory, so no one can prove which models, tools, and data flows need review.
• Governance teams write policy without engineering artifacts, so the policy never becomes a control.
• Security teams focus on prompts while the real risk sits in retrieval, tool access, or action authority.
• Executives ask for AI approval without an evidence model, so decisions become theater.

4. Framework Mapping

Map the 14-domain model to OWASP LLM Top 10, NIST AI RMF, MITRE ATLAS, CSA AI Controls Matrix, and ISO 42001. The point is not framework bingo. The point is to make one operating model visible across product, data, identity, and monitoring.

5. Engineering Controls

• Create a living AI inventory with owners, boundaries, data classes, model classes, and approval states.
• Define who can train, deploy, retrieve, call tools, and ship outputs into production workflows.
• Require testable controls for prompt injection, data leakage, tool abuse, and rollback.
• Instrument logs and traces so the system can explain what happened after an incident or review.

6. Tooling

• Use inventories, risk registers, eval harnesses, trace stores, and review workflows.
• Pair the tooling with a change process so models and prompts do not bypass review.
• Keep the evidence in systems that auditors and engineers can both read.

7. Evidence and Observability

• Evidence should show the control, the test, the owner, and the result.
• A diagram is not evidence by itself. A diagram plus test results and approval logs is evidence.
• Use traceable artifacts that show when the system changed and who accepted the change.

8. Operating Model

The operating model works when product security, MLOps, data, legal, GRC, and SOC know where the handoffs are. One team owns the decision. Other teams own the controls. The review path should be boring and repeatable.

9. Common Mistakes

• Treating AI governance as a policy-only program.
• Treating one security team as the owner of every AI risk.
• Using the word AI without defining the boundary.
• Confusing framework language with implementation.

10. Practical Example

A team ships an assistant that reads a knowledge base, calls a ticketing tool, and writes a response to customers. The 14-domain map makes the risks obvious: retrieval authorization, tool authority, output safety, logging, and incident response all need owners before launch.

11. Governance and Claim Caveats

• Sponsor support does not influence methodology, scoring, findings, chart outputs, or editorial conclusions.
• Job-description intelligence and public hiring signals are directional signals, not proof of internal security maturity.
• Psychometric outputs are role-language evidence, not diagnosis.
• Avoid accusatory company-level language.
• Avoid product endorsement language.

12. Conclusion

The domain map matters because AI security is already a multi-team operating problem. Once the work is mapped, the controls become easier to assign, test, and explain.

Implementation Checklist

• Build an AI inventory.
• Assign owners for each domain.
• Tie policy to controls.
• Add evals and traceability.
• Review tool permissions.
• Document approval paths.
• Define rollback criteria.
• Keep caveats visible.
• Review claims before publication.
• Update the map as the stack changes.

Source Notes Needed

• OWASP LLM Top 10 for LLM Applications.
• NIST AI Risk Management Framework.
• MITRE ATLAS.
• CSA AI Controls Matrix.
• ISO/IEC 42001.