Skip to content

Feedback: MLSecOps open companion — R1–R9 alignment mapping (seeking TWG review) #12

Description

@MHaghighian

Summary

I maintain the MLSecOps Practical Reference Guide — an open-source practitioner handbook for securing AI systems across the lifecycle (CC BY-SA 4.0):

This is not an AARM conformance submission or a claim that MLSecOps (or any product) satisfies R1–R9. MLSecOps is documentation — it describes operational controls and architecture patterns. I created a complementary mapping to help practitioners who adopt AARM find related implementation guidance in one place.

Motivation

AARM defines what a runtime security system must do (intercept → accumulate context → evaluate policy + intent → authorize → record receipts). MLSecOps aims to help security teams operationalize how related controls fit into a broader MLSecOps lifecycle — LLM/RAG, agents, SOC, governance, and release evidence.

I see strong conceptual alignment between the AARM control plane and several MLSecOps constructs:

AARM concept MLSecOps pointer
Pre-execution interception (R1) Ch.8 — Intent Gate, tool policy
Context accumulation (R2) Ch.7 (RAG/retrieval context), Ch.8 (agent memory/session)
Policy + intent alignment (R3) Ch.8 — Intent Gate
Five authorization decisions (R4) Ch.8 — allow/deny/modify patterns, HITL, scoped tools
Tamper-evident receipts (R5) Ch.11 — Evidence Pack (seeking feedback on scope vs. R5)
Identity binding (R6) Ch.2, Ch.8 (seeking feedback on depth vs. R6)
Semantic distance / drift (R7) Ch.8, Ch.10
Telemetry export (R8) Ch.10 — SOC / monitoring
Least-privilege enforcement (R9) Ch.8 — scoped tools, MCP
Threat model Ch.2 (+ OWASP Agentic, MITRE ATLAS in guide)
Implementation architectures Appendix E — architecture cards, playbooks

Full cross-ref table: https://l4tr0d3ctism.github.io/MLSecOps/references/aarm-alignment/

What I'm asking the TWG

  1. Technical accuracy — Is the R1–R9 mapping reasonable for a documentation companion, or are any rows misleading (especially R5 receipts and R6 identity binding)?
  2. Usefulness — Would the AARM community find this type of open implementation companion valuable alongside the normative spec?
  3. Gaps — Are there AARM requirements or threat classes where MLSecOps should point elsewhere or add explicit "out of scope" notes?
  4. Attribution — Any preferred wording when third-party guides reference AARM (beyond linking to aarm.dev/spec)?

What MLSecOps is not

  • Not a replacement or modification of the AARM specification
  • Not an AARM Core/Extended conformance claim
  • Not affiliated with CSA, OWASP, or NIST (synthesizes multiple frameworks with traceability)

Happy to revise the alignment page based on TWG feedback or move discussion to a Discussion thread if that fits better.

Thank you for the work on agentic runtime security as an open system category.

— Moslem Haghighian
https://github.com/l4tr0d3ctism

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions