Security Standard · Palantir Technologies

Mission Assurance
Security Standard

MA-S2  ·  v1.0 / May 2026  ·  4 Control Domains  ·  20 Controls

"Cyber-specialized LLMs are advancing rapidly, and adversaries are growing increasingly skilled at weaponizing them. This has expanded the attack surface for mission-critical institutions." — Shyam Sankar, CTO Palantir

ma-s2.com↗
CVS
Domain 0 · 5 controls
Continuous AI-Augmented Vulnerability Scanning
APM
Domain 1 · 4 controls
Attack Path Modeling & AI Adversarial Simulation
INV
Domain 2 · 5 controls
Real-Time Software Inventory & Domain Awareness
ARO
Domain 3 · 6 controls
Autonomous Remediation Orchestration
Architecture · 4 Domain Feedback Loop
How MA-S2 Control Domains Operate
ADVERSARY · AI-ARMED THREAT ACTORS ↓ EXPANDED ATTACK SURFACE INV D2 · 5 CONTROLS Real-time inventory SBOM · Runtime Supply chain · Air-gap "What is running?" CVS D0 · 5 CONTROLS AI continuous scanning CVE · EPSS · KEV Zero-day discovery "Find holes nonstop" APM D1 · 4 CONTROLS Attack path modeling Adversarial AI MITRE ATT&CK "Think like a hacker" ARO D3 · 6 CONTROLS Autonomous remediation Auto-patch · Fleet Rollback · Compliance "Block it automatically" SCAN TARGETS RAW FINDINGS PRIORITIZED RISK STATE UPDATE · REMEDIATED RELEASES BACK INTO INVENTORY PLATFORM TELEMETRY · CONTINUOUS · AIR-GAP READY Self-attestation alone is not sufficient
INV · Inventory
CVS · Scanning
APM · Modeling
ARO · Remediation
MA-S2 in Plain Language

"As AI becomes a hacking tool, software vendors must defend with AI too" — Palantir's new security benchmark

Why it exists — Finding vulnerabilities used to be the hardest part. Expert teams spent months on it. Now AI does it automatically, quickly, and at scale. Attackers are already using this AI. Defenders must move faster too.
The four things MA-S2 requires, in everyday language
①
Vulnerability scanning
CVS
"Find holes without stopping"
When security holes appear in software, they must be found automatically and immediately—and serious ones must be blocked before humans even step in. Quarterly checks are no longer enough.
②
Attack path modeling
APM
"Think like a hacker"
A single hole may seem minor, but chaining several can be fatal. You must simulate those connections in advance.
③
Inventory
INV
"Know in real time what is running right now"
"What software and versions are on our servers?" — If you cannot answer that in real time, you fail. That includes military-grade air-gapped networks with no internet.
④
Automated patching
ARO
"When you find a hole, block it automatically"
Discover vulnerability → patch → deploy worldwide—the process must run automatically without someone clicking through each step.
In short, existing certifications (SOC 2, FedRAMP, etc.) mean "basics are covered." MA-S2 is a higher bar asking "are you truly safe in the AI era?" Palantir proposed this as a public standard—and bear in mind their own products are built to meet it, so there is a marketing angle.
Control Domain 0
0
CVS — Continuous, AI-Augmented Vulnerability Scanning
Continuous AI-Augmented Vulnerability Scanning
You must perform continuous scanning combining AI-assisted analysis and deterministic scanning across all software components. Regardless of deployment form (containers, VMs, binaries, serverless, firmware), maintain a living record of vulnerability status across the full software footprint. Point-in-time scanning is insufficient.
CVS-0.1
Automated container and dependency scanning
Automated vulnerability scanning required for every release artifact before deployment—including the artifact itself, direct dependencies, and transitive dependencies.
Pre-deploy scan Transitive deps All artifact types
CVS-0.2
Severity classification using current standards
Classify severity with CVSS v3.x or higher (Critical / High / Medium / Low / Informational). Must cross-reference EPSS scores and the CISA KEV catalog.
  • CVSS alone → explicitly fails this control
  • EPSS: predicted likelihood of real-world exploitation
  • CISA KEV: catalog of vulnerabilities with confirmed exploitation
CVSS v3.x+ EPSS required CISA KEV required
CVS-0.3
AI-assisted vulnerability analysis
Integrate at least one of: fine-tuned security models, general frontier models with security-specific context harnesses, or validated third-party AI scanning services into the pipeline.
  • No specific model mandated (tooling agnostic)
  • CVE database pattern matching alone is insufficient
  • New zero-day-class vulnerabilities without CVE assignment must be discoverable within the pipeline
AI integration required Zero-day discovery Beyond CVE DB
CVS-0.4
Automatic detection, mitigation, and recall on Critical findings
When Critical or High severity has a known exploit, all three must be met simultaneously.
  • Automatic detection and escalation: auto-routed to response workflows without manual intervention
  • Automatic interim mitigation: compensating controls such as network isolation, feature disablement, configuration changes
  • One-click fleet-wide recall/isolation: all environments handled in a single orchestration action. Human approval is allowed; humans must not be the execution bottleneck
Auto-escalation Interim mitigation One-action recall
CVS-0.5
Contextual vulnerability prioritization and SLA
SLAs must meet both requirements.
  • Context-based prioritization: EPSS/KEV enrichment + source/runtime reachability analysis + asset/data context (blast radius) + attack path context from APM-1.3
  • Unreachable or non-exploitable vulnerabilities may be risk-accepted via ARO-3.4 suppression (documentation required)
  • SLA definition and compliance: published SLAs by severity tier + compliance reporting via platform telemetry (manual reporting not allowed)
  • Vulnerabilities on KEV or with high EPSS require materially shorter SLAs even at the same CVSS score
Reachability analysis Contextual SLA Platform telemetry
Disqualification criteria — Domain 0
  • Only periodic manual scanning without automation
  • Vulnerability classification without EPSS or KEV enrichment
  • No AI-assisted component in the discovery pipeline
  • No automatic escalation workflow on Critical/High findings
  • No documented, measurable remediation SLA
Control Domain 1
1
APM — Attack Path Modeling & AI-Assisted Adversarial Simulation
Attack Path Modeling & AI Adversarial Simulation
Model adversaries using AI to explore multi-stage attack paths. Go beyond individual CVE-level management—model attack paths across components, microservices, and elements throughout the architecture, and handle cases where individually low-severity findings chain into high severity.
APM-1.1
Attack path modeling capability
Implement via a dedicated threat modeling platform, AI-assisted attack graph generation, or regularly reviewed manual threat modeling. Attack path modeling outputs must be technically integrated into vulnerability prioritization tools and decision-making.
Attack graph Threat modeling Prioritization integration
APM-1.2
Adversarial AI simulation
Evidence required of software tested with AI-assisted tools that simulate adversary behavior chaining vulnerabilities across attack path stages.
  • Internal red team results using AI tools
  • Third-party AI-assisted penetration test reports
  • Participation in AI-native bug bounty programs
  • Evidence beyond traditional penetration testing required
AI Red team Vuln chaining Beyond pentest
APM-1.3
Contextual triage integration
Attack path context must inform remediation prioritization. Key examples from the document:
  • Critical CVE on a component unreachable from external attack surface → may be appropriately deprioritized
  • Medium CVE on a component that is the first link in an attack path to a credential store → urgent treatment required
  • Must demonstrate triage workflows do not rely on raw CVE severity scores alone
Attack path context Reachability Beyond CVSS alone
APM-1.4
Threat intelligence integration
Incorporate current threat intelligence feeds including nation-state TTPs based on MITRE ATT&CK into attack path modeling. Static, non-updating threat models are insufficient. Must reflect major threat actor capabilities and targeting priorities for the customer industry.
MITRE ATT&CK Nation-state TTPs Dynamic threat model
Disqualification criteria — Domain 1
  • No attack path modeling capability beyond individual CVE management
  • No ongoing AI-assisted adversarial simulation
  • Triage workflows relying only on raw CVE scores
  • No external threat intelligence integrated into prioritization
Control Domain 2
2
INV — Real-Time Software Inventory & Domain Awareness
Real-Time Software Inventory & Domain Awareness
Maintain a complete, real-time, machine-readable inventory of all software components across every environment where software operates. Must be continuously updated, not generated on demand, and cover heterogeneous environments including air-gapped.
INV-2.1
SBOM at release (Software Bill of Materials)
Every release artifact must ship with a machine-readable SBOM in SPDX or CycloneDX format.
  • Include explicit version pins for direct and transitive dependencies
  • Range versions (e.g. ≥1.0.0) not allowed — exact versions required
  • Must provide SBOMs for current and prior releases
SPDX / CycloneDX Exact version pins Machine-readable
INV-2.2
Continuous runtime inventory reconciliation
Capability to continuously reconcile each deployed release SBOM with actual runtime state in each deployment environment.
  • Component in runtime but not in SBOM → automatic alert
  • Component in SBOM but not in runtime → automatic alert
  • Must work across heterogeneous environments including limited or intermittent connectivity
Continuous reconcile Drift detection Auto-alert
INV-2.3
Environment-level deployment visibility
Machine-readable API plus human-operable tools required per environment providing:
  • Exact deployed release version
  • Most recent successful deployment timestamp
  • Most recent scan timestamp for that deployed version
  • Open findings status for that environment
Machine-readable API Per-environment Open findings
INV-2.4
Supply chain visibility
Security posture visibility across the upstream software supply chain beyond first-party code.
  • Evidence of upstream SBOM collection
  • Upstream vulnerability monitoring
  • Supplier security attestation requirements applied
  • All source components including white-label tools
Supply chain Upstream SBOM Supplier attestation
INV-2.5
Air-gapped and disconnected environment coverage
Inventory and monitoring capabilities must extend to disconnected, air-gapped, and limited-connectivity environments.
  • Inventory systems requiring continuous external connectivity → fails this control
  • Sync inventory updates when connectivity is available
  • Must define maximum allowed drift between last known and current state
Air-gapped Offline support Sync on connect
Disqualification criteria — Domain 2
  • No machine-readable SBOM for current and prior releases
  • No continuous runtime reconciliation capability
  • No environment-level deployment visibility via API
  • No comprehensive supply chain visibility beyond first-party code
  • No continuous inventory coverage for air-gapped or disconnected environments
Control Domain 3
3
ARO — Autonomous Remediation Orchestration
Autonomous remediation orchestration
Must have capability to autonomously orchestrate remediation actions across the full deployment fleet. Includes patch deployment, rollback of vulnerable releases, environment-specific finding suppression, etc. Human approval may be required, but humans must not be the bottleneck.
ARO-3.1
Automated patch deployment
Capability to automatically deploy patch releases to affected environments after scan validation and approval workflows.
  • Zero-downtime deployment where operationally required
  • Rollback capability tested and documented; recovery time objective (RTO) demonstrated
  • Consistent, rapid expected rollback RTO
Auto-deploy Zero-downtime Rollback RTO
ARO-3.2
Fleet-wide remediation orchestration
Capability to orchestrate patch deployment across the full fleet from a single control plane.
  • Simultaneous or controlled sequential rollout to all customer environments
  • Fleet-wide orchestration including disconnected and air-gapped environments
  • One control plane → N heterogeneous environments
Single control plane Fleet-wide Air-gap included
ARO-3.3
Compliance-aware change management
Remediation orchestration that models and complies with per-environment requirements.
  • Model and automate approval requirements, change freeze windows, authorization constraints (FedRAMP, IL5/IL6)
  • Compliance with operator-defined deployment policies
  • When per-environment constraints conflict with security remediation actions, orchestration layer must automatically resolve conflicts
Compliance-aware FedRAMP / IL5/6 Auto-conflict resolve
ARO-3.4
Vulnerability suppression with audit trail
Formal mechanism for time-bounded risk acceptance suppression of specific vulnerabilities + complete audit trail.
  • Suppressions subject to automatic expiration
  • Audit trail available on request
  • Linked to CVS-0.5 contextual prioritization (document rationale for risk-accepting unreachable vulnerabilities)
Time-bounded Audit trail Auto-expire
ARO-3.5
Developer–operator workflow integration
Where development (patch production) and operations (deployment approval) are organizationally separate, measurable timestamps for three milestones required:
  • Vulnerability discovery: identification and developer assignment
  • Patch available: when resolved version is available for deployment
  • Deployment approval: operator approval per affected environment
  • Slack messages, email, code review discussion → out of scope for this control
3 milestones System of record Timestamped
ARO-3.6
Remediation metrics and reporting
Generate remediation reports on agreed cadence via platform telemetry including:
  • Mean time to remediate (MTTR) by severity tier
  • SLA compliance rate
  • Open findings by severity and age
  • Suppression inventory
  • Fleet-wide deployment coverage
MTTR by tier SLA compliance Platform telemetry
Disqualification criteria — Domain 3
  • No automated patch deployment
  • No autonomous fleet-wide orchestration capability
  • No compliance-aware change management
  • No formal, auditable suppression mechanism
  • No MTTR and SLA compliance reporting via platform telemetry
Attestation and evidence requirements
✓
Third-party audit reports
Audit deliverables reviewed by independently qualified assessors
✓
Platform-generated telemetry
Automatically generated metrics and operational data (manual reporting not allowed)
✓
Architecture documentation
Architecture documentation reviewed by qualified independent assessors
✓
Contractual SLA commitments
Contractual SLA commitments including defined measurement methodology
Self-attestation alone is insufficient. Self-attestation without supporting evidence is not permitted.
7 essential software procurement evaluation questions
1
Describe your automated vulnerability scanning process. When in the release pipeline does scanning occur? What tools are used, and does it include AI-assisted discovery of novel vulnerabilities beyond known CVE pattern matching?
→ CVS-0.1 · CVS-0.3
2
How do you classify and prioritize vulnerabilities? Do you incorporate EPSS scores and the CISA KEV catalog beyond CVSS scores?
→ CVS-0.2 · CVS-0.5
3
Describe your software inventory capability. Can you provide a real-time, machine-readable inventory of running versions for every permutation across all environments where software is deployed, including air-gapped? How is this inventory kept current?
→ INV-2.1 · INV-2.2 · INV-2.3 · INV-2.5
4
Have you tested your software with AI-assisted adversarial simulation chaining vulnerabilities across multi-stage attack paths? Describe the methodology and provide summary results or third-party attestation.
→ APM-1.1 · APM-1.2 · APM-1.3
5
How do you orchestrate patch deployment across the fleet? Can you deploy patch releases to all affected customer environments from a single control plane? What is your demonstrated rollback time?
→ ARO-3.1 · ARO-3.2
6
Who is responsible for vulnerability remediation for the product, and how long does it take from identification to patched deployment in customer environments?
→ ARO-3.5 · ARO-3.6
7
How does your remediation process account for customers with air-gapped, classified, or compliance-constrained environments? Can you demonstrate automated compliance-aware change management across those environments?
→ ARO-3.2 · ARO-3.3 · INV-2.5
Relationship to existing frameworks
SOC 2 Type 2 FedRAMP Moderate FedRAMP High DISA IL5 DISA IL6 NIST SP 800-53 ISO 27001 + MA-S2

Vendors with existing frameworks are expected to have foundational controls in place. MA-S2 addresses the next tier of security requirements driven by the spread of AI-native attack vectors. The two are complementary; MA-S2 does not replace existing frameworks.