v0.11.0 · working-draft

How APRF works

Depth behind the overview: dual maturity model, lenses, evidence assurance floors, evaluation rules, peer crosswalks, and stewardship. Working draft — not a ratified standard.

Maturity Lenses Evidence tiers Evaluation Crosswalks Threat map Governance

Maturity & criticality

APRF separates two axes that older single ladders conflate: capability maturity (how disciplined the engineering system is) and criticality (blast radius). Required maturity is a function of tier—a small team shipping a high-blast-radius system must still climb the capability ladder.

Criticality tiers

Classify the system first. Then attain at least the required capability level.

Tier 0
Sandbox
Requires L1 · Initial
Non-customer experiments. Failures are contained to the builder’s environment.
- Hackathon prototype
- Local notebook agent
- Throwaway prompt playground
Tier 1
Internal
Requires L2 · Managed
Employee-only or tightly gated internal use. Organizational impact only.
- Internal knowledge assistant
- Employee coding agent on non-prod systems
Tier 2
Production
Requires L3 · Defined
Customer- or partner-facing. Material product, privacy, or financial impact if it fails.
- Customer support chatbot
- SaaS RAG feature
- MCP tools touching customer data
Tier 3
Mission Critical
Requires L4 · Quantitatively Managed
High blast radius: safety, regulated decisions, large financial movement, or critical infrastructure dependency.
- Medical triage assistant
- Autonomous trading or payments agent
- Life-safety or critical-infrastructure copilots

Capability maturity

Pillar checks declare the capability level at which they become expected. Attainment for a level means all mandatory checks at that level (for the system's criticality) pass.

Level 1
Initial
Ad-hoc practices. Works in demos; controls are informal or absent. Acceptable only for Tier 0 sandboxes.
- No claim of production readiness
- Changes may be undocumented console edits
- Failures do not trigger organizational incident process
- Spend and rate limits are owner-watched at best
Level 2
Managed
Basic repeatable controls: auth, logging, spend caps, secret hygiene. Suitable baseline for Tier 1 (internal) systems.
- Authenticated access for non-public surfaces
- Request/cost logging exists
- Hard spend or rate ceilings prevent runaway usage
- Secrets are not hardcoded in production prompts or clients
Level 3
Defined
Documented, enforced controls across critical domains. Mandatory checks for Tier 2 (customer production) are met.
- Promotion path and rollback for prompts, models, and tools
- Server-side authz, tool mediation, and eval gates on releases
- Traces reconstruct model → tool → outcome paths
- AI-specific incident playbooks and named owners exist
Level 4
Quantitatively Managed
SLOs, audited evidence, formal governance, and measured quality/safety signals. Expected floor for many Tier 3 systems.
- Published SLOs for latency, availability, and at least one quality/safety signal
- Auditable evidence packs for critical controls
- Change control and ownership across teams
- Privacy/compliance obligations mapped to technical controls
Level 5
Optimizing
Continuous improvement: automated gates, dual-control for irreversible actions, chaos/continuity drills, near-zero blast-radius ambiguity.
- Dual-control (or equivalent) for irreversible high-impact actions
- Continuous evaluation blocks unsafe releases automatically
- Continuity and failure drills on a defined cadence with recorded results
- Blast radius for every tool, agent, and data path is documented and enforced

Extension

Formal lenses

System-type overlays that add mandatory gates under existing pillars—no new top-level domains. Pair with Core Profile for RAG, agents, voice, or coding-agent systems. Counts below are gates beyond Core (lens lists may also reinforce checks already in Core).

RAG

+8 beyond Core · 14 listed

aprf-lens-rag

Retrieval-augmented generation: corpus ownership, context labeling, memory isolation, and retrieval-quality gates.

Applies to: RAG · Chatbots · AI Agents

Retrieval corpora need owners, versioning, and promotion controls (DG).
Retrieved content must be sized, labeled, and access-controlled in context (CTX).
Vector/memory stores inherit tenant isolation and retention (MEM).
Eval gates must cover retrieval quality and grounding regressions (EVL).

DG-M1 · DG-M2 · DG-M3 · CTX-M1 · CTX-M2 · CTX-M3 · MEM-M1 · MEM-M2 · MEM-M3 · PRI-M1 · EVL-M1 · EVL-M2 · SEC-M1 · OBS-M1

Agents

+6 beyond Core · 18 listed

aprf-lens-agents

Autonomous and tool-using agents: charters, step budgets, tool mediation, human gates, and kill switches.

Applies to: AI Agents · Multi-agent systems · MCP Servers · A2A Systems · Coding Agents · Autonomous systems

Every production agent needs a charter and hard step/time limits (AGN).
Tools fail closed with allowlists and schema validation (TOL).
High-impact actions require non-bypassable human approval (HUM).
Agent identities stay least-privilege; loops cannot burn unbounded spend (AUTHZ/COST).

AGN-M1 · AGN-M2 · AGN-M3 · AGN-M4 · TOL-M1 · TOL-M2 · TOL-M3 · TOL-M4 · HUM-M1 · HUM-M2 · HUM-M3 · AUTHZ-M1 · AUTHZ-M2 · AUTHN-M2 · COST-M3 · OBS-M1 · REL-M1 · REL-M3

Voice

+2 beyond Core · 16 listed

aprf-lens-voice

Voice and telephony AI: session identity, privacy of recordings, latency SLOs, safety, and escalation paths.

Applies to: Voice AI · Chatbots

Telephony sessions must authenticate before privileged tools (AUTHN).
Call audio and transcripts are sensitive personal data (PRI).
Latency and degraded mode matter more under real-time constraints (PERF/REL).
Safety refusals and human escalation must work on voice channels (SAF/HUM).

AUTHN-M1 · AUTHN-M2 · PRI-M1 · PRI-M2 · OBS-M1 · OBS-M2 · PERF-M1 · PERF-M2 · REL-M1 · REL-M2 · SAF-M1 · SAF-M2 · HUM-M1 · INC-M1 · COST-M1 · TOL-M1

Coding agents

+14 beyond Core

aprf-lens-coding

IDE and repo-connected coding agents: sandboxing, secret hygiene, tool allowlists, supply chain, and human gates for destructive changes.

Applies to: Coding Agents · AI Agents · MCP Servers

Coding agents need explicit charters, kill switches, and peer auth for multi-agent hops (AGN).
Shell/file tools require schema validation and fail-closed allowlists (TOL).
Repo and cloud credentials must stay out of prompts; model path stays bounded (SEC).
Dependency and model supply chain plus platform sandboxes reduce blast radius (SCI/DX/INF).

AGN-M1 · AGN-M3 · AGN-M4 · TOL-M4 · HUM-M2 · SEC-M2 · SEC-M4 · SCI-M1 · SCI-M3 · PRM-M3 · AUTHZ-M3 · DX-M1 · DX-M2 · INF-M2

Apply lenses in the reference assessment. Machine-readable: /aprf/spec/ → lenses[].

Verification floor

Evidence Assurance Tiers

Each Check declares a minimum evidence floor (minimumTier). PASS requires achieved tier at or above that floor — repository signals alone cannot satisfy a runtime floor. Normative in APRF-RFC-0011 (accepted).

Tier	Meaning
E0	No evidence
E1	Self-attestation
E2	Repository evidence
E3	Configuration evidence
E4	Runtime evidence
E5	Independent verification

Control statuses stay the closed five (PASS / FAIL / PARTIAL / NOT_DEMONSTRATED / NOT_APPLICABLE). Below-floor evidence yields PARTIAL with verification UNVERIFIED — not a sixth status. Pillar Check cards show each Check's floor next to method.

Evaluation methodology

APRF gated evaluation. Gates are binary. Recommended controls produce per-domain scores only. There is no single averaged “readiness percentage.”

Forbidden

A single averaged “readiness score” across all pillars
Trading a failed mandatory check against strong recommended scores
Conformance badges that omit open blockers or APRF version
Claiming Tier 3 / regulated readiness from Core Profile alone

01
Classify criticality
Assign Tier 0–3. This sets the required capability floor.
02
Choose catalog, profile, and lenses
Startups may assess Core Profile (Tier 2 minimum). Add formal lenses (RAG, Agents, Voice, Coding agents) when those system types apply. Full catalog for Tier 3 / enterprise / regulated.
03
Collect evidence
For each applicable check, produce the named artifact and evaluate the pass condition.
04
Evaluate the gate
All in-scope mandatory checks must pass or be formally marked notApplicable (N/A) with rationale. Failures and unanswered checks are blockers. Profile∪lens assessments only gate on the union of those check IDs. N/A is intended for agent, human-approval, tool-safety, and memory gates when those system types do not apply — not as a substitute for incomplete evidence.
05
Compute capability attainment
Per pillar: highest level L where all mandatory checks ≤ L pass. System attainment = minimum across pillars.
06
Score recommended controls per domain
Optional 0–100 domain scores from recommended checks, weighted by pillar severity. Never folded into the gate.
07
Report
Publish: APRF version, tier, profile (if any), lenses (if any), required capability, gate pass/fail, critical blockers, capability attained, per-domain recommended scores, evidence index.

Required capability by tier

Tier 0 · Sandboxrequires L1 · Initial
Tier 1 · Internalrequires L2 · Managed
Tier 2 · Productionrequires L3 · Defined
Tier 3 · Mission Criticalrequires L4 · Quantitatively Managed

Run the reference assessment and export a self-attestation: /aprf/assess/

Machine-readable spec (v0.11.0): /aprf/spec/

Compatibility

Crosswalks

Machine-readable maps from APRF pillars and checks to peer frameworks (11 peers). Use them for gap analysis and evidence reuse.

Not certification

Crosswalks are informative alignment only. They do not constitute NIST, ISO/IEC, OWASP, CSA, AICPA, or other endorsement—and passing APRF does not imply SOC 2, ISO 42001, AISVS, or similar certification.

NIST AI Risk Management Framework

1.0 (2023) · 10 mappings

Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement.

GOVERNGovernsupports
organizational-governance, compliance, model-governance, human-approvalORG-M1, ORG-R2, ORG-R4, CMP-M1, HUM-M1
MAPMapsupports
model-governance, data-governance, context-engineering, explainabilityMOD-M1, DG-M1, CTX-M1, EXP-M1
MEASUREMeasuresupports
evaluation, observability, performance-slo, safety-responsible-aiEVL-M1, EVL-M2, OBS-M1, PERF-M1, SAF-M2
MANAGEManagesupports
incident-readiness, change-management, reliability-continuity, tool-safety, agent-governanceINC-M1, INC-M2, CHG-M1, REL-M1, TOL-M1, AGN-M2
SafeSafealigns with
safety-responsible-ai, evaluation, human-approvalSAF-M1, SAF-M2, SAF-M3, HUM-M3
Secure & ResilientSecure and Resilientaligns with
ai-security, authentication, authorization, secrets, tool-safety, supply-chain, infrastructure, reliability-continuity
ExplainableExplainable and Interpretablealigns with
explainability, observabilityEXP-M1, EXP-M2, OBS-R4
Privacy-EnhancedPrivacy-Enhancedaligns with
data-privacy, memory-management, context-engineeringPRI-M1, PRI-M2, MEM-M1
FairFair — Harmful Bias Managedpartial
safety-responsible-ai, evaluation, data-governanceSAF-M3, EVL-M2, DG-M2
APRF covers fairness eval gates; organizational bias programs may need extra controls.
AccountableAccountable and Transparentsupports
organizational-governance, human-approval, explainability, change-managementORG-R2, HUM-M1, EXP-M3, CHG-M3

ISO/IEC 42001

2023 (clause-level conceptual) · 8 mappings

Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement. Not a substitute for a certified AI management system.

§4Context of the organizationaligns with
organizational-governance, compliance, data-governanceORG-M1, CMP-M1, DG-M1
§5Leadershipsupports
organizational-governance, human-approvalORG-R2, HUM-M1
§6Planningpartial
organizational-governance, safety-responsible-ai, evaluation, cost-optimizationORG-R4, SAF-M1, EVL-M1, COST-M1
Risk/objectives planning spans org process plus safety and eval gates.
§7Supportpartial
platform-engineering, secrets, infrastructureDX-M1, SEC2-M1, INF-M1
Competence/awareness are org processes; APRF emphasizes platform & secrets support.
§8Operationsupports
prompt-engineering, model-governance, change-management, tool-safety, agent-governance, data-privacy
§9Performance evaluationsupports
evaluation, observability, performance-slo, complianceEVL-M1, EVL-M2, OBS-M1, PERF-M1, CMP-M2
§10Improvementaligns with
incident-readiness, organizational-governance, change-managementINC-M2, ORG-R4, CHG-M1
Annex AAI system controls (selected themes)partial
ai-security, safety-responsible-ai, data-privacy, data-governance, model-governance, human-approval, supply-chain
Annex A themes → APRF security, safety, data, model, human oversight, supply chain.

OWASP Top 10 for Large Language Model Applications

2025 · 10 mappings

Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement.

LLM01Prompt Injectionsupports
ai-security, prompt-engineering, tool-safetySEC-M1, SEC-M3, PRM-M1, TOL-M1
Related peers: aisvs:C2.1, aisvs:C7.3, aisvs:C9.3, aisvs:C11.1, aisvs:C11.4
LLM02Sensitive Information Disclosuresupports
data-privacy, context-engineering, secrets, memory-managementPRI-M1, PRI-M2, SEC2-M1, MEM-M1
Related peers: aisvs:C5.2, aisvs:C7.3, aisvs:C8.1, aisvs:C12.1
LLM03Supply Chainsupports
supply-chain, model-governance, infrastructureSCI-M1, SCI-M2, MOD-M1
Related peers: aisvs:C6.1, aisvs:C6.2, aisvs:C3.1
LLM04Data and Model Poisoningsupports
data-governance, memory-management, model-governance, evaluationDG-M2, MEM-M2, MOD-R4, EVL-M1
Related peers: aisvs:C1.1, aisvs:C1.3, aisvs:C3.2, aisvs:C11.1
LLM05Improper Output Handlingsupports
ai-security, tool-safety, safety-responsible-aiSEC-M3, TOL-M2, SAF-M1
Related peers: aisvs:C7.1, aisvs:C7.2, aisvs:C7.3
LLM06Excessive Agencysupports
tool-safety, agent-governance, human-approval, authorizationTOL-M1, TOL-M2, TOL-M3, AGN-M2, HUM-M1, AUTHZ-M1
Related peers: aisvs:C9.1, aisvs:C9.2, aisvs:C9.3, aisvs:C9.5, aisvs:C9.6
LLM07System Prompt Leakagealigns with
prompt-engineering, ai-security, secretsPRM-M2, SEC-M1, SEC2-M2
Related peers: aisvs:C2.1, aisvs:C5.1, aisvs:C7.3
LLM08Vector and Embedding Weaknessessupports
memory-management, context-engineering, data-governanceMEM-M1, MEM-M3, CTX-M2, DG-M3
Related peers: aisvs:C8.1, aisvs:C8.2, aisvs:C8.3
LLM09Misinformationaligns with
safety-responsible-ai, evaluation, explainabilitySAF-M2, EVL-M2, EXP-M1
Related peers: aisvs:C7.2, aisvs:C7.4, aisvs:C11.1
LLM10Unbounded Consumptionsupports
cost-optimization, reliability-continuity, performance-sloCOST-M1, COST-M3, REL-M1, PERF-M1
Related peers: aisvs:C9.1, aisvs:C12.3, aisvs:C4.1
Denial-of-wallet and resource exhaustion — spend ceilings + timeouts.

OWASP AI Application Security Verification Standard (AISVS)

1.0 · 44 mappings

Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement. Peer control IDs cite OWASP AISVS 1.0 section tags (aisvs:v1.0-C*.*) from the locked 1.0/en tree.

Show 44 peer mappingsexpand

C1.1Training Data Origin & Data Securitysupports
data-governance, evaluation, memory-management, model-governanceDG-M2, EVL-M1, MEM-M2, MOD-R4
C1.2Data Labeling and Annotation Securitypartial
data-governance, evaluationDG-M2, EVL-M1
C1.3Training Data Quality and Security Assurancesupports
data-governance, evaluation, memory-management, model-governanceDG-M2, EVL-M1, MEM-M2, MOD-R4
C2.1Prompt Injection Defensessupports
ai-security, prompt-engineering, tool-safety, secretsSEC-M1, PRM-M1, SEC-M3, TOL-M1, PRM-M2, SEC2-M2
C2.2Content & Policy Screeningpartial
ai-security, prompt-engineeringSEC-M1, PRM-M1
C3.1Model Authorization & Integritysupports
model-governance, evaluation, supply-chain, infrastructureMOD-M1, EVL-M1, SCI-M1, SCI-M2
C3.2Model Validation & Testingsupports
model-governance, evaluation, data-governance, memory-managementMOD-M1, EVL-M1, DG-M2, MEM-M2, MOD-R4
C3.3Controlled Deployment & Rollbackpartial
model-governance, evaluationMOD-M1, EVL-M1
C3.4Secure Development Practicespartial
model-governance, evaluationMOD-M1, EVL-M1
C3.5Pipeline Fine-Tuningpartial
model-governance, evaluationMOD-M1, EVL-M1
C4.1AI Workload Sandboxing & Validationpartial
infrastructure, platform-engineeringINF-M1, INF-M2
C4.2AI Hardware Securitypartial
infrastructure, platform-engineeringINF-M1, INF-M2
C4.3Edge & Distributed AI Securitypartial
infrastructure, platform-engineeringINF-M1, INF-M2
C5.1Authenticationaligns with
authentication, authorization, secrets, prompt-engineering, ai-securityAUTHN-M1, AUTHZ-M1, SEC2-M1, PRM-M2, SEC-M1, SEC2-M2
C5.2AI Resource Authorization & Classificationsupports
authentication, authorization, secrets, data-privacy, context-engineering, memory-managementAUTHN-M1, AUTHZ-M1, SEC2-M1, PRI-M1, PRI-M2, MEM-M1
C5.3Multi-Tenant Isolationpartial
authentication, authorization, secretsAUTHN-M1, AUTHZ-M1, SEC2-M1
C6.1Model Artifact Integritysupports
supply-chain, model-governance, infrastructureSCI-M1, MOD-M1, SCI-M2
C6.2AI BOM & Supply Chain Monitoringsupports
supply-chain, model-governance, infrastructureSCI-M1, MOD-M1, SCI-M2
C7.1Output Format Enforcementsupports
safety-responsible-ai, ai-security, tool-safetySAF-M1, SEC-M3, TOL-M2
C7.2Hallucination Detection & Mitigationsupports
safety-responsible-ai, ai-security, tool-safety, evaluation, explainabilitySAF-M1, SEC-M3, TOL-M2, SAF-M2, EVL-M2, EXP-M1
C7.3Output Safetysupports
safety-responsible-ai, ai-security, prompt-engineering, tool-safety, data-privacy, context-engineering, secrets, memory-managementSAF-M1, SEC-M3, SEC-M1, PRM-M1, TOL-M1, PRI-M1, PRI-M2, SEC2-M1, MEM-M1, TOL-M2, PRM-M2, SEC2-M2
C7.4Source Attribution & Citation Integrityaligns with
safety-responsible-ai, ai-security, evaluation, explainabilitySAF-M1, SEC-M3, SAF-M2, EVL-M2, EXP-M1
C8.1Access Controls on Memory & RAG Indicessupports
memory-management, context-engineering, data-privacy, secrets, data-governanceMEM-M1, CTX-M2, PRI-M1, PRI-M2, SEC2-M1, MEM-M3, DG-M3
C8.2Embedding Sanitization & Validationsupports
memory-management, context-engineering, data-governanceMEM-M1, CTX-M2, MEM-M3, DG-M3
C8.3Memory Expiry & Revocationsupports
memory-management, context-engineering, data-governanceMEM-M1, CTX-M2, MEM-M3, DG-M3
C9.1Execution Budgets, Loop Control, and Circuit Breakerssupports
agent-governance, tool-safety, human-approval, cost-optimization, reliability-continuity, performance-slo, authorizationAGN-M2, TOL-M1, HUM-M1, COST-M1, COST-M3, REL-M1, PERF-M1, TOL-M2, TOL-M3, AUTHZ-M1
C9.2High-Impact Action Approval and Irreversibility Controlssupports
agent-governance, tool-safety, human-approval, authorizationAGN-M2, TOL-M1, HUM-M1, TOL-M2, TOL-M3, AUTHZ-M1
C9.3Component Isolation and Tool Authorizationsupports
agent-governance, tool-safety, human-approval, ai-security, prompt-engineering, authorizationAGN-M2, TOL-M1, HUM-M1, SEC-M1, SEC-M3, PRM-M1, TOL-M2, TOL-M3, AUTHZ-M1
C9.4Agent and Orchestrator Identitypartial
agent-governance, tool-safety, human-approvalAGN-M2, TOL-M1, HUM-M1
C9.5Agent Authorization, Delegation, and Continuous Enforcementsupports
agent-governance, tool-safety, human-approval, authorizationAGN-M2, TOL-M1, HUM-M1, TOL-M2, TOL-M3, AUTHZ-M1
C9.6Shutdown and Graceful Degradationsupports
agent-governance, tool-safety, human-approval, authorizationAGN-M2, TOL-M1, HUM-M1, TOL-M2, TOL-M3, AUTHZ-M1
C10.1Component Integritypartial
tool-safety, authentication, authorization, ai-securityTOL-M1, TOL-M2, AUTHN-M1, AUTHZ-M1, SEC-M1
C10.2Authentication & Authorizationpartial
tool-safety, authentication, authorization, ai-securityTOL-M1, TOL-M2, AUTHN-M1, AUTHZ-M1, SEC-M1
C10.3Secure Transportpartial
tool-safety, authentication, authorization, ai-securityTOL-M1, TOL-M2, AUTHN-M1, AUTHZ-M1, SEC-M1
C10.4Schema, Message, and Input Validationpartial
tool-safety, authentication, authorization, ai-securityTOL-M1, TOL-M2, AUTHN-M1, AUTHZ-M1, SEC-M1
C11.1Model Alignment, Safety, and Robustness Testing and Trainingsupports
ai-security, safety-responsible-ai, model-governance, evaluation, prompt-engineering, tool-safety, data-governance, memory-management, explainabilitySEC-M3, SEC-M4, SAF-M1, SAF-M2, EVL-M1, MOD-M1, SEC-M1, PRM-M1, TOL-M1, DG-M2, MEM-M2, MOD-R4, EVL-M2, EXP-M1
C11.2Membership-Inference and Model-Inversion Mitigationpartial
ai-security, safety-responsible-ai, model-governance, evaluationSEC-M3, SEC-M4, SAF-M1, SAF-M2, EVL-M1, MOD-M1
C11.3Model-Extraction Defensepartial
ai-security, safety-responsible-ai, model-governance, evaluationSEC-M3, SEC-M4, SAF-M1, SAF-M2, EVL-M1, MOD-M1
C11.4Model Runtime Anomaly Detectionsupports
ai-security, safety-responsible-ai, model-governance, evaluation, prompt-engineering, tool-safetySEC-M3, SEC-M4, SAF-M1, SAF-M2, EVL-M1, MOD-M1, SEC-M1, PRM-M1, TOL-M1
C12.1Request & Response Loggingsupports
observability, incident-readiness, data-privacy, context-engineering, secrets, memory-managementOBS-M1, INC-M1, PRI-M1, PRI-M2, SEC2-M1, MEM-M1
C12.2Detection and Alertingpartial
observability, incident-readinessOBS-M1, INC-M1
C12.3Model, Data, and Performance Drift Detectionpartial
observability, incident-readinessOBS-M1, INC-M1
C12.4Proactive Security Behavior Monitoringpartial
observability, incident-readinessOBS-M1, INC-M1
C12.5Training Data & Model Lifecycle Auditpartial
observability, incident-readinessOBS-M1, INC-M1

OWASP Application Security Verification Standard

5.0 · 80 mappings

Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement.

Show 80 peer mappingsexpand

V1.1Encoding and Sanitization Architecturepartial
SEC-M1, PRM-M1
V1.2Injection Preventionpartial
SEC-M1, PRM-M1
V1.3Sanitizationpartial
SEC-M1, PRM-M1
V1.4Memory, String, and Unmanaged Codepartial
SEC-M1, PRM-M1
V1.5Safe Deserializationpartial
SEC-M1, PRM-M1
V10.1Generic OAuth and OIDC Securityaligns with
AUTHN-M1, AUTHZ-M1
V10.2OAuth Clientaligns with
AUTHN-M1, AUTHZ-M1
V10.3OAuth Resource Serveraligns with
AUTHN-M1, AUTHZ-M1
V10.4OAuth Authorization Serveraligns with
AUTHN-M1, AUTHZ-M1
V10.5OIDC Clientaligns with
AUTHN-M1, AUTHZ-M1
V10.6OpenID Provideraligns with
AUTHN-M1, AUTHZ-M1
V10.7Consent Managementaligns with
AUTHN-M1, AUTHZ-M1
V11.1Cryptographic Inventory and Documentationpartial
SEC2-M1, INF-M2
V11.2Secure Cryptography Implementationpartial
SEC2-M1, INF-M2
V11.3Encryption Algorithmspartial
SEC2-M1, INF-M2
V11.4Hashing and Hash-based Functionspartial
SEC2-M1, INF-M2
V11.5Random Valuespartial
SEC2-M1, INF-M2
V11.6Public Key Cryptographypartial
SEC2-M1, INF-M2
V11.7In-Use Data Cryptographypartial
SEC2-M1, INF-M2
V12.1General TLS Security Guidancealigns with
INF-M1, INF-M2
V12.2HTTPS Communication with External Facing Servicesaligns with
INF-M1, INF-M2
V12.3General Service to Service Communication Securityaligns with
INF-M1, INF-M2
V13.1Configuration Documentationpartial
INF-M1, CHG-M1
V13.2Backend Communication Configurationpartial
INF-M1, CHG-M1
V13.3Secret Managementpartial
INF-M1, CHG-M1
V13.4Unintended Information Leakagepartial
INF-M1, CHG-M1
V14.1Data Protection Documentationaligns with
PRI-M1, DG-M1
V14.2General Data Protectionaligns with
PRI-M1, DG-M1
V14.3Client-side Data Protectionaligns with
PRI-M1, DG-M1
V15.1Secure Coding and Architecture Documentationpartial
SEC-M1, CHG-M1
V15.2Security Architecture and Dependenciespartial
SEC-M1, CHG-M1
V15.3Defensive Codingpartial
SEC-M1, CHG-M1
V15.4Safe Concurrencypartial
SEC-M1, CHG-M1
V16.1Security Logging Documentationaligns with
OBS-M1, INC-M1
V16.2General Loggingaligns with
OBS-M1, INC-M1
V16.3Security Eventsaligns with
OBS-M1, INC-M1
V16.4Log Protectionaligns with
OBS-M1, INC-M1
V16.5Error Handlingaligns with
OBS-M1, INC-M1
V17.1TURN Serverpartial
INF-M1, REL-M1
V17.2Mediapartial
INF-M1, REL-M1
V17.3Signalingpartial
INF-M1, REL-M1
V2.1Validation and Business Logic Documentationpartial
SEC-M1, TOL-M2
V2.2Input Validationpartial
SEC-M1, TOL-M2
V2.3Business Logic Securitypartial
SEC-M1, TOL-M2
V2.4Anti-automationpartial
SEC-M1, TOL-M2
V3.1Web Frontend Security Documentationpartial
SEC-M3, TOL-M2
V3.2Unintended Content Interpretationpartial
SEC-M3, TOL-M2
V3.3Cookie Setuppartial
SEC-M3, TOL-M2
V3.4Browser Security Mechanism Headerspartial
SEC-M3, TOL-M2
V3.5Browser Origin Separationpartial
SEC-M3, TOL-M2
V3.6External Resource Integritypartial
SEC-M3, TOL-M2
V3.7Other Browser Security Considerationspartial
SEC-M3, TOL-M2
V4.1Generic Web Service Securityaligns with
AUTHZ-M1, SEC-M1
V4.2HTTP Message Structure Validationaligns with
AUTHZ-M1, SEC-M1
V4.3GraphQLaligns with
AUTHZ-M1, SEC-M1
V4.4WebSocketaligns with
AUTHZ-M1, SEC-M1
V5.1File Handling Documentationpartial
INF-M1, DG-M3
V5.2File Upload and Contentpartial
INF-M1, DG-M3
V5.3File Storagepartial
INF-M1, DG-M3
V5.4File Downloadpartial
INF-M1, DG-M3
V6.1Authentication Documentationaligns with
AUTHN-M1, AUTHN-M3, SEC2-M1
V6.2Password Securityaligns with
AUTHN-M1, AUTHN-M3, SEC2-M1
V6.3General Authentication Securityaligns with
AUTHN-M1, AUTHN-M3, SEC2-M1
V6.4Authentication Factor Lifecycle and Recoveryaligns with
AUTHN-M1, AUTHN-M3, SEC2-M1
V6.5General Multi-factor Authentication Requirementsaligns with
AUTHN-M1, AUTHN-M3, SEC2-M1
V6.6Out-of-Band Authentication Mechanismsaligns with
AUTHN-M1, AUTHN-M3, SEC2-M1
V6.7Cryptographic Authentication Mechanismaligns with
AUTHN-M1, AUTHN-M3, SEC2-M1
V6.8Authentication with an Identity Provideraligns with
AUTHN-M1, AUTHN-M3, SEC2-M1
V7.1Session Management Documentationaligns with
AUTHN-M1, AUTHZ-M1
V7.2Fundamental Session Management Securityaligns with
AUTHN-M1, AUTHZ-M1
V7.3Session Timeoutaligns with
AUTHN-M1, AUTHZ-M1
V7.4Session Terminationaligns with
AUTHN-M1, AUTHZ-M1
V7.5Defenses Against Session Abusealigns with
AUTHN-M1, AUTHZ-M1
V7.6Federated Re-authenticationaligns with
AUTHN-M1, AUTHZ-M1
V8.1Authorization Documentationaligns with
AUTHZ-M1, AUTHZ-M2
V8.2General Authorization Designaligns with
AUTHZ-M1, AUTHZ-M2
V8.3Operation Level Authorizationaligns with
AUTHZ-M1, AUTHZ-M2
V8.4Other Authorization Considerationsaligns with
AUTHZ-M1, AUTHZ-M2
V9.1Token Source and Integrityaligns with
AUTHN-M2, SEC2-M1
V9.2Token Contentaligns with
AUTHN-M2, SEC2-M1

OpenCRE (Open Common Requirements Enumeration)

CWE bridge set · 13 mappings

Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement.

CWE-16Configurationpartial
infrastructure, change-managementINF-M1, CHG-M1
CWE-200Exposure of Sensitive Informationaligns with
data-privacy, secretsPRI-M1, SEC2-M1, SEC2-M2
CWE-22Path Traversalpartial
ai-security, tool-safetySEC-M1, TOL-M1
CWE-287Improper Authenticationaligns with
authenticationAUTHN-M1, AUTHN-M2, AUTHN-M3
CWE-327Use of a Broken or Risky Cryptographic Algorithmpartial
secrets, infrastructureSEC2-M1, INF-M2
CWE-352Cross-Site Request Forgery (CSRF)partial
authentication, authorizationAUTHN-M1, AUTHZ-M1
CWE-384Session Fixationpartial
authentication, authorizationAUTHN-M1, AUTHZ-M2
CWE-502Deserialization of Untrusted Datapartial
tool-safety, ai-securityTOL-M2, SEC-M1
CWE-778Insufficient Loggingaligns with
observability, incident-readinessOBS-M1, INC-M1
CWE-78OS Command Injectionaligns with
tool-safety, ai-securityTOL-M1, TOL-M2, SEC-M1
CWE-79Cross-site Scripting (XSS)partial
ai-security, tool-safetySEC-M3, TOL-M2
CWE-798Use of Hard-coded Credentialsaligns with
secretsSEC2-M1, SEC2-M2
CWE-89SQL Injectionpartial
tool-safety, data-governanceTOL-M1, DG-M3

CSA MAESTRO (Multi-Agentic Threat Model)

7-layer architecture + extended multi-agent threats · 12 mappings

Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement.

L1Foundation Modelssupports
model-governance, ai-security, supply-chainMOD-M1, SCI-M1, SEC-M3
L2Data Operationssupports
memory-management, context-engineering, data-governanceMEM-M1, MEM-M3, CTX-M2, DG-M3
L3Agent Frameworkssupports
agent-governance, tool-safetyAGN-M1, AGN-M2, TOL-M1, TOL-M3
L4Deployment & Infrastructuresupports
infrastructure, platform-engineering, supply-chainINF-M1, INF-M2, SCI-M2
L5Evaluation & Observabilitysupports
observability, evaluation, performance-sloOBS-M1, EVL-M1, PERF-M1
L6Security & Compliancesupports
ai-security, compliance, organizational-governanceSEC-M1, SEC-M4, CMP-M1
L7Agent Ecosystemsupports
agent-governance, human-approval, authorizationAGN-M1, HUM-M1, AUTHZ-M1
reasoning-collapseReasoning Collapsealigns with
agent-governance, evaluation, explainabilityAGN-M2, EVL-M2, EXP-M1
emergent-covert-coordinationEmergent Covert Coordinationaligns with
agent-governance, ai-security, observabilityAGN-M1, SEC-M4, OBS-M1
heterogeneous-multi-agent-exploitsHeterogeneous Multi-Agent Exploitsaligns with
agent-governance, tool-safety, ai-securityAGN-M1, TOL-M1, SEC-M1, SEC-M3
goal-driftGoal Drift in Delegated Chainsaligns with
agent-governance, human-approval, evaluationAGN-M2, HUM-M1, EVL-M1
trust-misuseTrust Misuse Between Legitimate Agentsaligns with
agent-governance, authorization, observabilityAGN-M1, AUTHZ-M1, OBS-M1

OWASP FIASSE / SSEM

1.0.4 · 61 mappings

Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement.

Show 61 peer mappingsexpand

S1.1The Application Security Challengepartial
ORG-M1, CMP-M1
S1.2Document Purpose and Scopepartial
ORG-M1, CMP-M1
S2.1The Securable Paradigm: No Static Secure Statepartial
ORG-M1, CHG-M1
S2.2Resiliently Add Computing Valuepartial
ORG-M1, CHG-M1
S2.3Security Mission: Reducing Material Impactpartial
ORG-M1, CHG-M1
S2.4Aligning Security with Developmentpartial
ORG-M1, CHG-M1
S2.5The Transparency Principlepartial
ORG-M1, CHG-M1
S2.6The Principle of Least Astonishmentpartial
ORG-M1, CHG-M1
S3.1Model Overview and Design Languagealigns with
CHG-M1, INF-M1
S3.2.1.1Analyzabilityaligns with
CHG-M1, INF-M1
S3.2.1.2Modifiabilityaligns with
CHG-M1, INF-M1
S3.2.1.3Testabilityaligns with
CHG-M1, INF-M1
S3.2.1.4Observabilityaligns with
CHG-M1, INF-M1
S3.2.1Maintainabilityaligns with
CHG-M1, INF-M1
S3.2.2.1Confidentialityaligns with
CHG-M1, INF-M1
S3.2.2.2Accountabilityaligns with
CHG-M1, INF-M1
S3.2.2.3Authenticityaligns with
CHG-M1, INF-M1
S3.2.2Trustworthinessaligns with
CHG-M1, INF-M1
S3.2.3.1Availabilityaligns with
CHG-M1, INF-M1
S3.2.3.2Integrityaligns with
CHG-M1, INF-M1
S3.2.3.3Resiliencealigns with
CHG-M1, INF-M1
S3.2.3Reliabilityaligns with
CHG-M1, INF-M1
S3.2Core Securable Attributesaligns with
CHG-M1, INF-M1
S4.1.1Proactive Communicationpartial
SEC-M1, SCI-M1
S4.1.2Integrating Security into Requirementspartial
SEC-M1, SCI-M1
S4.1Establishing Clear Expectationspartial
SEC-M1, SCI-M1
S4.2.1Code-Level Threat Awarenesspartial
SEC-M1, SCI-M1
S4.2.2Threat Modeling Solution Frameworkpartial
SEC-M1, SCI-M1
S4.2Threat Modelingpartial
SEC-M1, SCI-M1
S4.3The Boundary Control Principlepartial
SEC-M1, SCI-M1
S4.4.1.1The Request Surface Minimization Principlepartial
SEC-M1, SCI-M1
S4.4.1.2The Derived Integrity Principlepartial
SEC-M1, SCI-M1
S4.4.1Canonical Input Handlingpartial
SEC-M1, SCI-M1
S4.4Resilient Codingpartial
SEC-M1, SCI-M1
S4.5Dependency Managementpartial
SEC-M1, SCI-M1
S4.6Dependency Stewardshippartial
SEC-M1, SCI-M1
S5.1Natively Extending Development Processespartial
EVL-M1, OBS-M1
S5.2The Role of Merge Reviewspartial
EVL-M1, OBS-M1
S5.3Early Integration: Planning and Requirementspartial
EVL-M1, OBS-M1
S6.1.1Ineffective Vulnerability Reportingpartial
INC-M1, OBS-M1
S6.1.2Pitfalls of Exploit-First Trainingpartial
INC-M1, OBS-M1
S6.1The Shoveling Left Phenomenonpartial
INC-M1, OBS-M1
S6.2Strategic Use of Security Outputpartial
INC-M1, OBS-M1
S7.1The Role of the Security Teampartial
ORG-M1, CMP-M1
S7.2Senior Software Engineerspartial
ORG-M1, CMP-M1
S7.3Developing Software Engineerspartial
ORG-M1, CMP-M1
S7.4Product Owners and Managerspartial
ORG-M1, CMP-M1
S8Organizational Adoption of FIASSEpartial
REL-M1, INF-M1
SA.1.1Measuring Analyzabilityaligns with
EVL-M1, OBS-M1
SA.1.2Measuring Modifiabilityaligns with
EVL-M1, OBS-M1
SA.1.3Measuring Testabilityaligns with
EVL-M1, OBS-M1
SA.1.4Measuring Observabilityaligns with
EVL-M1, OBS-M1
SA.1Measuring Maintainabilityaligns with
EVL-M1, OBS-M1
SA.2.1Measuring Confidentialityaligns with
EVL-M1, OBS-M1
SA.2.2Measuring Accountabilityaligns with
EVL-M1, OBS-M1
SA.2.3Measuring Authenticityaligns with
EVL-M1, OBS-M1
SA.2Measuring Trustworthinessaligns with
EVL-M1, OBS-M1
SA.3.1Measuring Availabilityaligns with
EVL-M1, OBS-M1
SA.3.2Measuring Integrityaligns with
EVL-M1, OBS-M1
SA.3.3Measuring Resiliencealigns with
EVL-M1, OBS-M1
SA.3Measuring Reliabilityaligns with
EVL-M1, OBS-M1

SOC 2 Trust Services Criteria

2017 (with 2022 revisions) — evidence reuse · 11 mappings

Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement. Passing APRF does not imply SOC 2 compliance.

CC1Control Environmentevidence for
organizational-governance, complianceORG-M1, ORG-R2, CMP-M1
CC3Risk Assessmentevidence for
organizational-governance, safety-responsible-ai, evaluationORG-R4, SAF-M1, EVL-M1
CC5Control Activitiesevidence for
tool-safety, human-approval, platform-engineeringTOL-M1, HUM-M1, DX-M2
CC6Logical and Physical Accessevidence for
authentication, authorization, secrets, infrastructureAUTHN-M1, AUTHN-M2, AUTHZ-M1, SEC2-M1, INF-M1
CC7System Operationsevidence for
observability, incident-readiness, reliability-continuityOBS-M1, OBS-R4, INC-M1, INC-M2, REL-M2
CC8Change Managementevidence for
change-management, model-governance, prompt-engineeringDEP-M1, CHG-M1, CHG-M3, MOD-M1, PRM-M1
CC9Risk Mitigationevidence for
supply-chain, ai-security, reliability-continuitySCI-M2, SEC-M1, REL-M1
A1Availabilityevidence for
reliability-continuity, performance-slo, infrastructureREL-M1, REL-M2, PERF-M1, INF-M2
C1Confidentialityevidence for
data-privacy, secrets, memory-managementPRI-M1, PRI-M2, SEC2-M1, MEM-M1
PI1Processing Integrityevidence for
evaluation, observability, change-managementEVL-M1, EVL-M2, OBS-M1, CHG-M3
P-seriesPrivacy (selected)partial
data-privacy, data-governance, compliancePRI-M1, PRI-R2, DG-M1, CMP-M3
Privacy TSC is broader than APRF privacy checks; use as AI evidence pack only.

AWS Well-Architected Framework

WA Framework pillars + Generative AI Lens (conceptual) · 7 mappings

Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement. Not an AWS Well-Architected Lens review or AWS certification.

Operational ExcellenceOperational Excellencealigns with
observability, incident-readiness, change-management, platform-engineering, organizational-governanceOBS-M1, INC-M1, CHG-M1, ORG-R2
SecuritySecurityaligns with
authentication, authorization, secrets, ai-security, tool-safety, infrastructure, supply-chainAUTHN-M1, AUTHZ-M1, SEC2-M1, SEC-M1, TOL-M1, INF-M1, SCI-M2
ReliabilityReliabilityaligns with
reliability-continuity, performance-slo, incident-readinessREL-M1, REL-M2, PERF-M1, INC-M2
Performance EfficiencyPerformance Efficiencypartial
performance-slo, observability, context-engineeringPERF-M1, OBS-R4
Cost OptimizationCost Optimizationsupports
cost-optimizationCOST-M1, COST-M3
SustainabilitySustainabilitypartial
cost-optimization, model-governanceCOST-M1, MOD-M1
APRF does not define sustainability metrics; cost/routing and model selection are nearest proxies.
Generative AI LensGenerative AI Lens (themes)aligns with
safety-responsible-ai, evaluation, agent-governance, human-approval, prompt-engineering, model-governance, data-privacySAF-M1, EVL-M1, AGN-M2, HUM-M1, PRM-M1, MOD-M1, PRI-M1

SLSA (Supply-chain Levels for Software Artifacts)

v1.0 — conceptual levels / provenance · 5 mappings

Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement. APRF alignment does not confer a SLSA level attestation.

Level 1Build process documentedpartial
supply-chain, change-management, model-governanceSCI-M2, DEP-M1, MOD-M1
Level 2Hosted build + signed provenancealigns with
supply-chain, infrastructure, change-managementSCI-M2, SCI-R1, INF-M1, CHG-M1
Level 3Hardened buildspartial
supply-chain, infrastructure, platform-engineeringSCI-M4, SCI-R1, INF-M1, DX-M2
APRF SCI-M4 / hardened admission approximate L3 themes; not a full SLSA L3 claim.
ProvenanceArtifact provenancesupports
supply-chain, model-governanceSCI-M2, SCI-R2, MOD-M1
Verify-on-deployVerification before usesupports
supply-chain, infrastructure, change-managementSCI-R1, INF-M1, CHG-M3

Full JSON: /aprf/spec/ → crosswalks[]

Threat context

Threat intelligence map

Why does each APRF control exist, and what does it defend against? Each Check carries security intent, threats mitigated, protected assets, and MITRE ATLAS / ATT&CK links—informative only, never a substitute for evidence.

Not certification

Mappings mean a control reduces exposure to a technique—not that it fully prevents it. They do not constitute MITRE, OWASP, or other endorsement.

Checks mapped: 178
Threats: 29
ATLAS: 79
ATT&CK: 27

Sources: MITRE ATLAS 5.6.0 · MITRE ATT&CK for Enterprise 19.2 · OWASP Top 10 for LLM Applications (2025)

Browse the threat map · Machine-readable JSON · RFC-0014 signal composition

Governance

Versioning, stewardship, extension, and certification rules for APRF as a working draft moving toward a ratifiable standard.

Version: 0.11.0; working-draft · Hybrid Check rewrites, mandatory→recommended RFCs, collector hardening; Published 2026-08-02
Publisher: StackRail; working-draft-publisher; Phase: Working draft. Multi-stakeholder technical oversight (vendors, practitioners, OWASP/CNCF-adjacent participants) with public RFCs — not a single commercial owner.

Stewardship path

Evolve APRF into a ratifiable, vendor-neutral production-readiness standard for AI systems through open technical consensus—not through a single commercial owner.

Working draft · current
Interim advisory board
Neutral working group
Foundation / SDO home

Normative repository: github.com/stackrail-io/APRF. Architecture: ARCHITECTURE.md. Full charter, RFC stages, transfer triggers: /aprf/rfc/

RFC process

APRF Request for Comments. Minimum review 14 days. Template APRF-RFC-0000.

Working-draft phase: publisher decides after review window, with public rationale. Interim advisory+: majority of active advisors; ties escalate to published deadlock procedure.

Versioning

Pillar IDs (APRF-NN) and check IDs (e.g. AUTHN-M1) are immutable once published in a MINOR+. Deprecate; do not reuse.

MAJOR: breaking changes to domain IDs, check IDs, or gate semantics
MINOR: new domains, pillars, or checks; non-breaking field additions
PATCH: editorial clarifications to prose, artifacts, or pass conditions

Deprecation

Deprecated checks and pillars remain in the spec for at least one MINOR cycle (N−1), marked deprecated, with a replacement ID.

Support window: N-1 minor versions

Extension

Formal lenses (RAG, Agents, Voice, Coding agents) add mandatory checks under existing pillars. Claim lenses in assessments and attestations when those system types apply.

Organizations MAY add private checks with IDs prefixed x- (e.g. x-ACME-M1). Custom checks MUST NOT claim APRF conformance by themselves.

See Formal lenses.

Certification

Self-attestation
Organization publishes assessment results + evidence index against a pinned APRF version. No third-party validation.
Third-party assessment
Independent assessor verifies gate blockers and samples evidence. Intended for Tier 3 and regulated use.

Conformance statements MUST cite APRF version, criticality tier, attained capability level, profile (if any), and list any open blockers. No single percentage badge.

Compatibility

NIST AI Risk Management Framework
ISO/IEC 42001
OWASP Top 10 for Large Language Model Applications
OWASP AI Application Security Verification Standard (AISVS)
OWASP Application Security Verification Standard
OpenCRE (Open Common Requirements Enumeration)
CSA MAESTRO (Multi-Agentic Threat Model)
OWASP FIASSE / SSEM
SOC 2 Trust Services Criteria
AWS Well-Architected Framework
SLSA (Supply-chain Levels for Software Artifacts)

Machine-readable peer maps ship in the APRF spec under crosswalks[] (synced via npm run aprf:crosswalks). Informative alignment only — not certification.

Browse mappings: Crosswalks

Full machine-readable document: GET /aprf/spec/