CISA Secure by Design AI Pledge: A Year In, Evidence Is What Is Missing
The Cybersecurity and Infrastructure Security Agency launched the Secure by Design pledge in May 2024 with seven commitment categories aimed at software vendors. CISA extended the pledge to AI-specific commitments through 2024 and 2025 under the broader Secure by Design AI initiative. The signatory count grew rapidly across the major software and AI vendors. The pledge commits signatories to specific outcomes against vulnerability reduction, multi-factor authentication adoption, default password elimination, vulnerability disclosure transparency, evidence of CISA Known Exploited Vulnerability remediation, security patch cadence, and security headers usage. The AI extensions cover provenance, training data integrity, model card publication, and incident transparency.
A year into the pledge, the signatory count is high. The evidence supporting the commitments is uneven. The categories where evidence remains weakest are the AI-specific commitments around provenance, training data integrity, and access governance over model outputs. The reason these categories are weakest is not signatory intent. The reason is that the architectural primitives required to produce the evidence are not common in vendor deployments.
What the pledge actually asks for
The Secure by Design AI commitments ask signatories to demonstrate that AI systems and the data they depend on are governed under cryptographic provenance, traceable lineage, and access policy bound to data classification. The commitments do not specify a particular technical architecture. The commitments do specify that the outcomes be evidenced.
For provenance, the commitment is that the origin of training data and the origin of model artifacts be verifiable through cryptographic means rather than through assertion. For training data integrity, the commitment is that the training data set used to produce a model be traceable to the data sources, the transformations, and the access decisions that shaped the set. For access governance over model outputs, the commitment is that outputs containing sensitive information be subject to enforcement at the release point, not at the application boundary downstream.
The evidence categories are familiar to data-centric architecture. They are the same categories that NIST SP 800-207, the CISA Zero Trust Maturity Model 2.0, the NSA Zero Trust Implementation Guideline Data Pillar v2, and the NIST AI Risk Management Framework 1.0 functions all converge on. The evidence does not require new primitives. The evidence requires the primitives to be applied to AI data and model artifacts at the same depth that the primitives are applied to documents and database rows.
Where vendor evidence falls short
The pattern across published vendor commitments and published evidence is consistent. Signatories articulate the commitment. Signatories produce documentation of internal processes that support the commitment. Signatories publish security artifacts (model cards, training data summaries, governance policies) that describe the commitment outcomes. Signatories do not, in most cases, produce architectural evidence that the commitment is enforced.
The gap is the gap between process and architecture. A vendor process can produce policy documents that describe how training data is acquired, vetted, and transformed. The process does not produce cryptographic lineage of the training data set. The process can produce model cards that describe model behaviors and limitations. The process does not produce attribute-bound access control over model output flows. The process can produce vulnerability disclosure programs. The process does not produce evidence that vulnerabilities in the AI supply chain were detected, contained, and remediated under cryptographic verification.
The pledge does not require that evidence be cryptographic. The architectural direction of CISA Secure by Design, NIST AI RMF, and the broader regulatory direction emerging through 2025 and 2026 does. The vendors that converge on architectural evidence ahead of the regulatory requirement are the vendors that arrive at the next pledge revision in a position of strength.
What data-centric architecture supplies
A data-centric architecture in which training data, model artifacts, and model output flows are wrapped as ZTDF objects produces the evidence categories the pledge identifies as commitments. Provenance is the content-addressed storage record over the training data set. Lineage is the Merkle-tree chain of read and write events across the data set. Access governance is the ABAC evaluation at the policy enforcement point over each release event involving the model and its outputs.
Lattix Technologies implements this pattern at the data object level. Training data objects carry their own encryption keys wrapped under attribute-bound policy. Model artifacts produced from those training data sets inherit policy markings traceable to the source data. Model output flows that contain sensitive information traverse the PEP at release, where the requesting principal's attributes are evaluated against the output's policy. The Merkle-tree lineage chain records every release event in tamper-evident storage.
The architecture produces direct evidence for the pledge commitments. The provenance evidence is the content-addressed identifier on the training data set. The lineage evidence is the chain over read and write events. The access governance evidence is the audit chain over release decisions. None of the evidence requires reconstruction from heterogeneous logs.
What vendors should be doing in the next 90 days
Three operational priorities matter for vendors that signed the Secure by Design AI pledge.
The first is the gap analysis against the pledge commitments. For each commitment, what evidence is the vendor currently able to produce. For each commitment, what evidence would an external auditor accept as sufficient. The gap deliverable identifies where process evidence and architectural evidence diverge.
The second is the architectural posture decision for AI data. AI training data, model artifacts, and model outputs that are stored in conventional storage with conventional access controls produce process evidence. AI training data, model artifacts, and model outputs that are wrapped as policy-bound data objects produce architectural evidence. The architectural decision in 2026 determines the evidence posture for the pledge revision cadence in 2027 and beyond.
The third is the audit instrumentation. Audit logs that depend on the integrity of the application infrastructure are logs that an attacker present in that infrastructure can rewrite. Lineage records anchored cryptographically in storage outside the application infrastructure are records that survive. The integrity of the audit chain is the integrity of the pledge evidence.
How this aligns with the broader regulatory direction
The CISA Secure by Design pledge, the NIST AI Risk Management Framework, the EU AI Act high-risk requirements, the executive order direction on AI safety, and the emerging state-level AI legislation across the U.S. all converge on the same evidence categories. Data provenance. Training set lineage. Access governance over model outputs. Incident reporting backed by technical evidence rather than process attestation.
The architectural investment that produces evidence against the CISA pledge produces evidence against the rest of the regulatory portfolio simultaneously. The investment in 2026 compounds across the regulatory direction of the next several years.