For three decades, venture-backed software investors and operators operated under a stable assumption: vulnerability discovery was scarce, uneven, and expensive. This assumption shaped everything. Backlogs could grow without immediate consequence. Security could be deferred behind roadmap pressure. Quality could be subordinated to velocity because exposure was probabilistic and delayed. Anthropic’s Mythos has invalidated these core assumptions in ways that materially impact capital allocation. Unlike prior generation tools that required integration, configuration, and human triage to function at scale, Mythos operates as an autonomous agent across heterogeneous estates without those constraints. Automated vulnerability discovery systems like Mythos collapse the cost and time required to locate exploitable software defects across fleets and estates. They do not create new classes of defects but instead remove the scarcity constraint that previously limited how quickly existing failures were found. The effect is structural and cross-domain. Latent security debt is no longer latent: it is continuously discoverable.

This fundamentally changes the economic character of software as a class. Unresolved vulnerabilities no longer behave like inventory. Instead, they behave like unbooked liabilities where each deferred patch carries a time-bound exposure whose probability of discovery is increasing and whose time to exploitation is compressing. The security backlog, long a neutral queue of work with no user persona to build for, became a ledger of accepted risk under a discovery regime that no longer supports deferral. This is the surface description of the challenge, but it is not the underlying mechanism which is best described as temporal arbitrage as a capital strategy.

Venture-backed software was financed under an assumption that time itself could be exploited. The organization ships before it knows, accumulates defects as a byproduct of meeting capital timelines, converts early adoption into valuation, and exits or recapitalizes before the accumulated consequences fully materialize. The codebase, the company, and even the users may be treated as disposable. Strategically, the firm is treated as a vehicle for value rather than a compounding asset, where ultimate outcomes are expected to be realized through timed capital events. In this model, security, resilience, and correctness are deferrable costs; the system prices them into the future and assumes that future can be outrun.

This is the equilibrium that has held in the venture software business since 1995. Automated vulnerability discovery and exploitation breaks that equilibrium completely. When vulnerability discovery becomes dense, systematic, and inexpensive, the future is no longer distant; the accumulated consequences embedded in the codebase are pulled forward. The time window between creation and exposure compresses and the organization is forced to confront the totality of its deferred decisions within operating time, not exit time. Overnight, the security backlog stops behaving like inventory and begins behaving like an unplanned matured obligation.

The obvious response to this observation has been to say, “the same automation that accelerates discovery will also accelerate remediation. Detection systems will find the defects. Patching systems will fix them. Static analysis, dynamic analysis, code generation, dependency intelligence, and automated repair will scale together. The system, in this account, will preserve equilibrium through reciprocal automation.” That response feels natural, but it fundamentally misunderstands the asymmetry in cost and motion. Detection is a search problem that benefits directly from scale, parallelism, and pattern recognition. Once the cost of search collapses, discovery density increases across the entire surface. Remediation is a transformation problem. It requires understanding intent, dependency interaction, state behavior, regression risk, business impact, and release safety.

AI-driven automation can reduce portions of the remediation duty but it cannot erase the coordination cost, validation burden, or system-risk burden attached to change. Faster discovery of security defects does not produce proportional remediation capacity: it produces intake pressure. When both sides automate, the system accelerates: discovery improves, exploitation improves, patch generation improves, and exploit adaptation improves. The temporal cycle that drives capital strategy compresses. The organization is no longer managing a software vulnerability program, but instead finds itself inside a machine-speed contest over the integrity of its own artifact. This is now the baseline condition of software companies, writ large; it is the new condition.

This is not the first time the world has been confronted with an all-hands-on-deck critical software defect. For those of us that worked through Y2K, we can understand this at the level of forced remediation; however, that understanding fails at the level of structure because Y2K work was bounded by a known defect class and a fixed date. The current condition of infinite discovery and exploitation at negligible cost has neither boundary nor termination: every codebase, every dependency tree, every internal tool, every acquired system, and every integration point exists inside a persistent discovery field. This global persistence removes the go-to capital strategy: escape through delay.

It also removes the possibility of escape through the fantasy of later automation. The claim that future patching systems will absorb present negligence is the old temporal arbitrage restated in technical form; it assumes that consequence can still be pushed forward because a later capability will carry it. That assumption has already failed once, with the implications extending far beyond engineering. A company whose software cannot withstand systematic automated inspection by hostile AI is not merely insecure: it is mispriced. Its valuation assumed that certain classes of risk would remain undiscovered long enough to be irrelevant to capital realization. That assumption is no longer defensible. Value, in this context, shifts location.

Under temporal arbitrage strategies, value was located in motion: user growth, revenue acceleration, narrative dominance, and the ability to reach successive funding events before operational contradiction can condense. Under a continuous defect discovery paradigm, value relocates to the artifact itself: the quality, resilience, and trustworthiness of the system under inspection. This ontological shift redefines what it means for a software company to hold value. Software now mediates health systems, financial systems, logistics, communications, governance, and social coordination. It functions as infrastructure even when the company that produced it did not intend to become infrastructure. People depend on software with the quiet expectation that it will safely hold their value object. That dependence is not erased because the software was financed as a temporary capital vehicle.

An operating model that introduces defects freely and trusts future machines to repair them is incompatible with that role; thus, the operating model must evolve accordingly. The relevant question is no longer whether vulnerabilities exist. They do. The question is whether the organization can operate under conditions where vulnerabilities are continuously surfaced by AI and must be resolved within a compressed time horizon. This introduces a new control variable for value defense: remediation velocity. Remediation velocity is a measure of whether the organization can absorb and neutralize a continuous stream of adversarially discovered security defects without destabilizing widget delivery. Most organizations are not structured for this condition. They are structured for episodic audits, periodic testing, and reactive incident response. Those operating models assume defect discovery scarcity, an assumption which no longer holds.

As security defect discovery becomes dense and systematic, several shifts occur. First, exposure becomes attributable. A deferred vulnerability is a recorded decision to carry known risk into an environment where discovery is expected. Second, perimeter distinctions erode. Internal systems, staging environments, legacy services, and vendor integrations are subject to the same discovery dynamics as externally facing infrastructure. The classification of “non-critical” becomes unstable once lateral movement and chaining are trivial. Third, standards of care move. As automated discovery becomes widely available, the definition of reasonably knowable risk expands. Liability frameworks and insurance models will adjust accordingly. Assertions of posture will carry less weight than demonstrated and evidenceable response performance.

These shifts converge on a single condition: the firm’s software fleet is now a capital liability surface under continuous adversarial inspection. This is not a security problem to be solved. It is a balance sheet correction to be absorbed. The corrective is not another tool layer or stack, but an operating model that treats trust, quality, resilience, and security as capital value conditions rather than downstream operational controls. That model must connect software production to value defense, capital timing, buyer confidence, diligence readiness, insurance exposure, and executive accountability.

This requires a transition from backlog management to Exposure Management. Exposure Management requires measurable control over three dimensions: coverage, latency, and dependency governance.

• Coverage defines the proportion of the software estate subject to continuous and instrumented analysis.

• Latency defines the time between identification and remediation.

• Dependency Governance defines the control of external code ingestion and the minimization of unnecessary surface area.

Security defect discovery must be treated as a production input because the organization must be able to ingest security findings at scale, triage them based on exploitability and impact more quickly than an adversarial AI can, and execute remediation as a continuous function on a living codebase. But this is only the minimum requirement. The deeper requirement is trust value management. A software company operating under this condition must know where trust value is created, where trust value is consumed, where trust value is degraded, and where trust debt is accumulating inside the stakeholder value journey. It must be able to translate software quality into financial exposure, customer confidence, sales velocity, diligence defensibility, and valuation protection. It must be able to keep the velocity thesis alive without depending on ignorance, deferral, or delayed consequence.

That is the proper strategic correction to the capital operating model, not a “compliance project” or a “risk management initiative.” An operating model capable of producing trust at machine speed requires that trust itself be treated as a manufactured, measurable asset; one with production inputs, quality controls, and verifiable outputs. Ultimately, the answer to the automated vulnerability discovery panic that Mythos sparked is an operating model that makes trustworthy software production a governed value system. For decades, the industry converted future consequences into present value by assuming that those future consequences could be outrun. Automated security defect discovery removes that assumption, and automated patching does not restore it but instead accelerates the field in which the original debt must now be paid. The security backlog is a liability exposure being systematically searched by value-eroding adversaries. The timeline for temporal arbitrage has been rendered brittle and short horizon. The dominant question is no longer whether the organization contains defects. It does. The dominant question is whether the organization has an operating model capable of producing trust at the speed of automated adversarial discovery.

Addenda:

Automated security defect discovery changes the economic character of software by converting latent security debt into continuously discoverable exposure.

• If this analysis is wrong, the evidence will appear as stable remediation ratios, unchanged underwriting assumptions, unchanged diligence practices, and no measurable increase in defect-driven pressure from customers, insurers, acquirers, or regulators.

• If this analysis is correct, the industry response will be narrative dilution, absorbing this argument into tooling strategies and existing compliance categories without adopting the operating model change it requires. That response is materially insufficient: rebranding the security stack is not the same as evolving the capital operating model to meet the moment.

Subscribe now

Trustable Policy Response | March 2026

A National Policy Framework for Artificial Intelligence

234KB ∙ PDF file

Download

4 WHOLE Pages of nothing. Please, download, and read, it should take you all of 3 minutes.

Download

I. The Framework’s Foundational Failure

The White House National Policy Framework for Artificial Intelligence reveals a government that has fundamentally misunderstood the AI problem. The framework treats AI safety as a matter of removing regulatory barriers and trusting industry self-certification. It explicitly prohibits creation of new federal verification infrastructure while preempting states from building it themselves. The result is not innovation enablement. This is the complete abandonment of human—AMERICAN—safety verification as a function.

This is an empirical observation about what happens when verification mechanisms are designed for deployment enablement rather than danger detection.

The framework proposes to:

• Prevent creation of new federal AI oversight (”no new federal rulemaking body”)

• Preempt state AI development regulation (”inherently interstate phenomenon”)

• Rely on “industry-led standards” through existing regulatory bodies

• Create “minimally burdensome” national standards

• Establish regulatory sandboxes to accelerate deployment

What the framework fails to provide:

• Any mechanism to verify that AI systems are actually safe

• Any requirement for adversarial testing before deployment

• Any continuous monitoring as systems evolve

• Any independent audit of industry claims

• Any enforcement beyond after-the-fact legal liability

The absence is does not seem accidental. It looks quite systematic. Every single section of the framework, such as it is, optimizes for passage; enabling AI systems to move from development to deployment unburdened by the inconvenience of safety. The question “Can stakeholders safely entrust their value to this system?” is never asked because the framework is not designed to answer it.

What follows is a section-by-section analysis of what the framework proposes, why it fails, and what verification infrastructure must exist instead.

II. Section-by-Section Gap Analysis with Trustable Answers

I. Protecting Children and Empowering Parents

What the Framework Proposes

The White House calls for age-assurance requirements, features reducing exploitation risks, and applying existing privacy protections to AI systems. It explicitly instructs Congress to “avoid setting ambiguous standards about permissible content, or open-ended liability.”

Why This Fails

This section treats child protection as a matter of implementing features and documenting compliance. Organizations will add age-verification gates. They will create safety features. They will produce documentation showing adherence to child privacy laws. Systems will deploy. Children will be harmed.

The failure occurs because the framework contains no mechanism to verify that protective features actually work under operational conditions. Age-assurance can be circumvented. Safety features can fail. Privacy protections will be violated.

Without adversarial testing designed to discover these failure modes BEFORE deployment, child protection becomes documentation theater.

The instruction to avoid “ambiguous standards” and “open-ended liability” reveals the underlying priority: protecting AI developers from legal risk rather than protecting children from AI systems.

The Trustable Answer

Requirement: AI systems claiming child safety must demonstrate through adversarial testing that protections cannot be circumvented.

Implementation:

• Adversarial verification mandate: Before deployment to minor-accessible platforms, systems must undergo hostile testing where red teams attempt to bypass age verification, defeat safety features, and access protected data

• Continuous monitoring requirement: Child safety features must be re-verified every 90 days as systems retrain and evolve

• Independent audit: Insurance-backed verification by entities whose economic survival does not depend on approving systems for deployment

• Proof-based deployment: No authorization for minor-accessible deployment without registry-verified child safety proofs

• Automatic revocation: Systems that fail verification or undergo material changes without re-verification lose deployment authorization immediately

Why this works: It shifts the question from “Did you implement safety features?” to “Do your safety features withstand adversarial attack under operational conditions?” The former is a documentation exercise. The latter is an engineering requirement.

Insurance enforcement mechanism: Platforms deploying AI to minors should not be able to obtain liability coverage without registry-verified child safety proofs. Underwriters cannot price unmeasurable risk. When the first major child exploitation incident occurs through a “compliant” AI system, insurance markets will demand adversarial verification. The only question is whether verification infrastructure exists before or after that first incident, and then, of course, how many accumulated incidences must occur before anything at all is done.

II. Safeguarding and Strengthening American Communities

What the Framework Proposes

Protection from increased electricity costs, streamlined permitting for AI infrastructure, augmented law enforcement against AI-enabled fraud, national security assessment of frontier AI capabilities, and resources for small business AI adoption.

Why This Fails

Every item in this section assumes that compliance with stated objectives equals actual safety, it absolutely does not. Law enforcement will receive resources to combat AI fraud. National security agencies will assess frontier AI capabilities. Small businesses will receive AI tools. None of these activities include verification that the systems actually work safely.

Consider the national security assessment requirement. Agencies will “possess sufficient technical capacity to understand frontier AI model capabilities and any associated national security considerations.” This presumes agencies can reliably assess capabilities from vendor-provided information. They cannot. Frontier AI systems evolve weekly. Capabilities emerge unpredictably. (OWLS ANYONE‽‽) By the time an assessment concludes, the system being assessed has changed materially.

The framework treats assessment as a one-time compliance action rather than a continuous verification process.

The Trustable Answer

Requirement: AI systems deployed in critical infrastructure must produce continuous, adversarially-tested proofs of safety boundaries and capability limits.

Implementation:

• Fraud prevention verification: Systems claiming to detect AI-enabled fraud must demonstrate effectiveness through red-team exercises where attackers attempt to execute fraud that systems should prevent

• Continuous capability monitoring: Frontier AI systems must generate verifiable capability assessments every 30 days through standardized testing protocols that detect emergent capabilities

• Small business AI verification: AI tools provided to small businesses must meet the same adversarial testing requirements as enterprise systems—the size of the deploying organization does not reduce stakeholder risk

• Infrastructure deployment gates: Critical infrastructure AI (power grid management, financial systems, transportation) cannot deploy without insurance backed by verified safety proofs

• Real-time capability alerts: When frontier AI systems demonstrate capabilities outside previously verified boundaries, registry status changes automatically and dependent systems receive alerts

Why this works: National security agencies lack capacity to conduct continuous technical assessment. Registry infrastructure provides that capacity through distributed, insurance-backed verification. When a frontier AI system demonstrates dangerous capability, the question is not “Did the vendor tell us about this?” but “Did the system pass adversarial capability testing this month?”

Market enforcement: Critical infrastructure operators cannot obtain insurance coverage for unverified AI deployment. When the first AI-caused infrastructure failure occurs, liability will be enormous. Insurers will demand proof that systems were verified. Operators will demand registry infrastructure that makes verification possible. Again: the question is whether this infrastructure exists before the catastrophic failure or after.

III. Respecting Intellectual Property Rights and Supporting Creators

What the Framework Proposes

Let courts resolve training/copyright questions, consider collective licensing frameworks (but don’t mandate when licensing is required), establish framework for unauthorized AI replicas, monitor copyright developments.

Why This Fails

This section explicitly delegates safety determination to post-harm litigation. “Let courts resolve” means creators are harmed first, seek redress second. By the time courts establish that training violated copyright, millions of creators have been harmed and AI systems trained on their work are embedded in commercial infrastructure.

The framework treats intellectual property protection as a matter to be resolved through legal process rather than prevented through verification infrastructure. This is structural abdication. Courts can determine liability after harm occurs. They cannot prevent harm before it occurs. Prevention requires verification that systems respect IP boundaries before deployment.

The Trustable Answer

Requirement: AI systems must produce cryptographically verifiable evidence of training data provenance and licensing status before commercial deployment.

Implementation:

• Data provenance verification: Systems must generate auditable records showing source, licensing status, and opt-out compliance for all training data

• Continuous IP compliance monitoring: Systems must demonstrate through ongoing testing that outputs don’t reproduce copyrighted material beyond fair use thresholds

• Independent audit of opt-out mechanisms: Third-party verification that robots.txt files, opt-out registries, and licensing restrictions are actually honored in training pipelines

• Pre-deployment proof requirement: No commercial deployment without verified data provenance demonstrating lawful training

• Automatic revocation for IP violations: Systems discovered violating IP protections lose registry standing; dependent systems receive immediate alerts

Why this works: Courts provide remedy after harm. Verification prevents harm before deployment. The two mechanisms serve different functions. The framework recognizes only one.

Creator protection enforcement: When creators sue for copyright infringement, defendants will claim fair use, good faith reliance on industry standards, and compliance with existing frameworks. Courts will take years to resolve these questions. Meanwhile, AI systems continue operating. Registry infrastructure shifts the burden: systems must prove lawful training before deployment, not defend against infringement claims after deployment. This is the difference between prevention and remedy.

IV. Preventing Censorship and Protecting Free Speech

What the Framework Proposes

Prevent government from coercing AI providers to ban/alter content based on partisan agendas, provide redress for government censorship efforts.

Why This Fails

The framework addresses government censorship while ignoring that AI systems themselves function as content curation infrastructure. When an AI system systematically filters certain political viewpoints through opaque algorithmic decisions (GROK‽), the speech restriction is just as effective as if government had mandated it. The framework prevents the visible threat (government coercion) while ignoring the operational threat (algorithmic filtering).

This is not theoretical, AI systems today make millions of content moderation decisions. These decisions are made through algorithms that are not transparent, not auditable, and not subject to verification. Whether those algorithms systematically disadvantage viewpoints cannot be determined without independent testing.

The Trustable Answer

Requirement: AI systems making content moderation decisions must demonstrate through adversarial testing that filtering does not systematically disadvantage political viewpoints.

Implementation:

• Algorithmic bias verification: Systems must undergo testing where adversaries submit ideologically diverse content and demonstrate that moderation decisions are not systematically biased

• Transparency requirement: Content moderation decisions must be auditable by independent third parties with access to sufficient data to detect systemic patterns

• Continuous monitoring: Systems must prove through ongoing testing that bias does not emerge as models retrain on user feedback and content trends

• Independent verification: Insurance-backed audit that free speech protections work under operational conditions across political spectrum

• Explainability requirement: When content is filtered, systems must provide specific, auditable justification tied to terms of service violations rather than opaque algorithmic determinations

Why this works: Government censorship is visible and can be challenged through legal process. Algorithmic censorship is opaque and operates at scale before patterns become visible. Verification infrastructure makes algorithmic decisions auditable, enabling detection of systematic bias before it becomes embedded in public discourse infrastructure.

First Amendment enforcement: When AI systems filter political speech, plaintiffs must prove systematic bias through discovery of internal algorithms and decision data. Companies resist disclosure as proprietary. Litigation takes years. Registry infrastructure makes bias testing a deployment requirement rather than a discovery battle. Systems prove evenhandedness before deployment rather than defend against bias claims after deployment.

V. Enabling Innovation and Ensuring American AI Dominance

What the Framework Proposes

Regulatory sandboxes, accessible federal datasets in AI-ready formats, no new federal rulemaking body to regulate AI, support through existing regulatory bodies and industry-led standards.

Why This Fails

This section does not merely fail to provide verification infrastructure. It explicitly prohibits it.

“Congress should not create any new federal rulemaking body to regulate AI” is architectural abdication. Existing regulatory bodies (FDA, SEC, FAA, FTC) lack technical capacity to verify AI safety in their domains. They depend on industry self-certification. The framework instructs them to continue depending on industry self-certification while prohibiting creation of independent verification infrastructure.

“Industry-led standards” means vendors define what counts as sufficient safety verification. This is predictable regulatory capture. Organizations do not fund standards development that prevents their systems from deploying. Standards bodies that consistently produce disqualifying findings do not receive industry support. Market selection optimizes standards for permissiveness.

The framework treats this as innovation enablement. It is 100% verification abandonment.

The Trustable Answer

Requirement: Industry-led standards must include independently verifiable proof requirements, not just process guidelines. Existing regulatory bodies must be supported with verification infrastructure they currently lack.

Implementation:

• Proof requirement layer: Industry standards (ISO, NIST, sector-specific frameworks) must specify what constitutes sufficient evidence that systems meet safety requirements, not just what processes should be followed

• Independent verification infrastructure: Create insurance-backed verification bodies that test systems against industry standards through adversarial methodology

• Existing regulator support: Provide SEC, FDA, FAA, FTC with registry access showing which AI systems have verified proofs for their domains—regulators monitor compliance rather than conducting technical verification themselves

• Sandbox verification: Even experimental deployments must demonstrate safety through adversarial testing before human value is put at risk

• Continuous verification requirement: Systems that pass initial verification must maintain proof renewal as they evolve—verification is not one-time certification

Why this works: The framework correctly identifies that creating new federal AI regulators duplicates expertise that exists in sector-specific agencies. The error is assuming those agencies have verification capacity they do not possess. Registry infrastructure provides the verification layer that existing regulators can leverage without requiring them to develop AI-specific technical expertise.

The critical distinction: The framework prohibits “new federal rulemaking body to regulate AI.” Registry infrastructure does not regulate AI development. It verifies AI safety. These are different functions. Regulation sets rules about what AI can do. Verification determines whether deployed AI systems actually behave safely. Existing regulators set rules. Registry infrastructure provides verification.

Market inevitability: Insurance companies will create this infrastructure regardless of government action. When the first major AI-caused catastrophe occurs in a regulated domain—financial fraud at scale, medical AI misdiagnosis causing deaths, autonomous system failure causing mass casualties—liability will be enormous. Insurers will refuse coverage for unverified systems. Enterprises will demand verification infrastructure. The only question is whether that infrastructure is built proactively or reactively.

The framework optimizes for reactive infrastructure built after catastrophic failure. This is a choice, not an inevitability.

VI. Educating Americans and Developing an AI-Ready Workforce

What the Framework Proposes

Incorporate AI training into existing education programs, study workforce realignment, support land-grant institutions for AI youth development.

Why This Fails

The framework deploys AI into schools and workforce training programs without verification requirements. Educational AI will make decisions about student capabilities, career recommendations, and learning pathways. Workforce training AI will determine job readiness and skill development. These systems will be deployed based on vendor claims of effectiveness, not verified evidence of safety.

When educational AI systematically biases student outcomes—disadvantaging certain demographics, incorrectly assessing capabilities, directing students away from opportunities they could succeed in—the harm is not immediately visible, and potentially GENERATIONAL. Students don’t know what opportunities they were denied. Bias in educational AI compounds over years as it shapes academic trajectories.

The framework contains no mechanism to detect this bias before it causes harm.

The Trustable Answer

Requirement: AI systems deployed in educational settings must demonstrate through adversarial testing that they do not systematically bias student outcomes.

Implementation:

• Educational AI verification: Systems deployed in schools must undergo testing where adversaries attempt to demonstrate systematic bias in assessments, recommendations, and opportunity allocation

• Student data protection verification: Educational AI must prove through independent audit that student data is protected, not used for model training without consent, and not shared with third parties

• Continuous monitoring: Educational AI must be re-verified every 180 days as systems evolve and student populations change

• Workforce training verification: AI tools used in job training must demonstrate through testing that they don’t systematically disadvantage vulnerable populations

• Explainability requirement: Educational and workforce AI must provide specific, auditable explanations for decisions affecting student/worker opportunities

Why this works: Educational AI operates on vulnerable populations (students, workers in transition) who lack power to challenge systemic bias. Verification before deployment shifts the burden from students proving they were harmed to systems proving they don’t cause harm.

Enforcement through institutional liability: Schools and training programs deploying unverified AI face liability when bias is eventually discovered. Insurance for educational AI deployment will require verification. Institutions will demand registry infrastructure that makes verification possible. The alternative is accepting liability for unknown bias in systems they cannot audit.

VII. Establishing a Federal Policy Framework, Preempting Cumbersome State AI Laws

What the Framework Proposes

Preempt state AI laws imposing “undue burdens,” create “minimally burdensome national standard,” prevent states from regulating AI development (”inherently interstate phenomenon”), prevent states from burdening lawful AI use, prevent states from penalizing AI developers for third-party unlawful conduct.

Why This Fails

This section creates a verification vacuum by design.

The framework prohibits states from regulating AI development while refusing to create federal verification infrastructure. The result is that no jurisdiction can require safety verification:

• States: Cannot regulate AI development (preempted as “interstate phenomenon”)

• Federal: Will not create verification infrastructure (”no new federal rulemaking body”)

• Industry: Self-certifies through “industry-led standards”

This is not governance. This is architectural capture—the framework prevents safety infrastructure from being built at any jurisdictional level.

The framework treats state AI regulation as “cumbersome burden” rather than legitimate exercise of police powers to protect citizens. It preempts state action while providing no federal substitute. The “minimally burdensome national standard” turns out to be no verification requirement at all.

The Trustable Answer

Requirement: Federal verification standards must be stronger than state alternatives, not weaker. Preemption should prevent fragmentation, not prevent verification.

Implementation:

• Federal verification floor: Establish registry infrastructure as national verification standard that preempts weaker state requirements while allowing states to mandate registry verification in their jurisdictions

• Interstate coordination: Registry provides consistent verification across jurisdictions without preventing state enforcement—systems verified in one state are verified nationally

• Traditional police powers preservation: States retain authority to require registry verification as exercise of consumer protection, fraud prevention, and child safety powers (which framework acknowledges states retain)

• Critical domain mandates: Federal law requires registry verification for AI deployed in domains with high public risk (healthcare, finance, education, employment, public safety)

• Procurement specifications: Federal and state governments require registry verification for AI systems they procure or deploy

Why this works: The framework correctly identifies that 50 different state AI regulations create compliance burden. The error is assuming the solution is no verification requirements rather than consistent national verification infrastructure. Registry provides the consistent standard the framework claims to want.

Constitutional structure: The framework’s preemption argument is weak. States have traditionally regulated dangerous technologies under police powers (consumer protection, fraud prevention, child safety). The framework acknowledges states retain these powers. Registry verification falls squarely within traditional state authority to protect citizens from harm. Federal preemption that prohibits states from requiring safety verification of dangerous technologies is constitutionally dubious.

More importantly: it doesn’t matter. Insurance markets will create verification requirements regardless of whether state or federal law mandates them. The question is whether government provides infrastructure that makes verification consistent and efficient, or whether verification emerges chaotically through litigation and catastrophic failure.

III. The Architecture That Actually Works

The White House framework fails because it was meant to. It treats AI safety as a matter of documentation and compliance. The Trustable answer is infrastructure that makes safety verifiable, continuous, and enforceable.

The Six-Layer Verification Architecture

Layer 1: AI Systems Under Verification Models, data pipelines, deployment infrastructure, operational context. The systems that will make decisions affecting human value.

Layer 2: Adversarial Proof Production Systems generate evidence through hostile testing designed to discover failure modes:

• Data provenance under interrogation attempting to find unlicensed training data

• Model integrity under distribution shift testing

• System reliability under adversarial attack

• Transparency sufficient for independent safety determination

• Governance accountability with enforceable mechanisms

This is not documentation of good processes. This is evidence harvested through adversarial testing explicitly designed to produce disqualifying findings if the system is unsafe.

Layer 3: Independent Verification Third-party verification by economically independent entities—primarily insurance-backed verification bodies whose survival depends on accurate risk assessment, not client retention. These entities conduct systematic adversarial testing to validate proofs.

Layer 4: Registry Recording Verified proofs recorded in independent, publicly interrogable registries. Proofs are cryptographically signed, timestamped, continuously renewable. Registry status is machine-readable, enabling automated procurement, underwriting, and compliance checking.

Layer 5: Public Interrogation Regulators, insurers, enterprises, investors, and civil society can interrogate safety claims directly through registry access. This makes trust machine-readable. An enterprise considering AI procurement can verify registry status. An insurer underwriting AI deployment can query proof decay status. A regulator can monitor compliance in real time.

Layer 6: Revocation and Renewal When proofs decay, systems change materially, or verification fails, registry status updates automatically. Dependent systems receive alerts. Insurance coverage may be invalidated. Procurement authorizations may be withdrawn. Regulatory compliance may lapse.

This creates enforceable accountability through economic mechanisms rather than government enforcement.

Why This Architecture Succeeds Where Government Fails

Speed: Registry verification operates at the speed of AI evolution (days/weeks), not regulatory timescales (years)

Scale: Distributed verification through insurance-backed entities scales better than centralized government agencies

Expertise: Verification bodies develop AI-specific technical expertise that general regulatory agencies lack

Independence: Insurance-backed verification avoids capture because underwriters lose money when they approve unsafe systems that cause claims

Enforcement: Economic enforcement through insurance, procurement, and capital markets is faster and more certain than regulatory enforcement through litigation

Adaptability: Registry infrastructure evolves as AI capabilities change; regulatory frameworks ossify

International compatibility: Registry verification can operate across jurisdictions; regulatory frameworks fragment

The Five Core Requirements Implementation

1. Adversarial Verification, Not Process Compliance

• Testing designed to discover failure modes that would disqualify deployment

• Red-team exercises attempting to cause harm through adversarial inputs

• Distribution shift testing verifying robustness when operational conditions change

• Supply chain interrogation detecting inherited risks from upstream dependencies

2. Continuous Verification, Not Point-in-Time Certification

• Proofs decay on defined timescales (3-6 months for model reliability, 30-90 days for adversarial testing, 6-24 months for data provenance)

• Systems demonstrate continuous monitoring with automated alerts when verification lapses

• Registry status updates when proofs expire or systems change outside tested parameters

• Verification operates at the speed of system evolution

3. Economic Independence, Not Client-Service Relationships

• Verification conducted by insurance-backed entities whose economic survival depends on accurate risk assessment

• Fee structures funded through industry pools or insurance mechanisms that don’t create per-client retention pressure

• Verifiers can produce disqualifying findings without losing business because they’re not in client-service relationships

4. Stakeholder Value Safety, Not Organizational Process Maturity

• Can individuals whose employment depends on AI trust that systems won’t systematically disadvantage them?

• Can enterprises whose operations depend on AI trust that failures won’t cause catastrophic business disruption?

• Can regulators whose enforcement depends on AI trust that systems will behave predictably?

• Can insurers whose underwriting depends on AI trust that risks are measurable?

5. Revocation Authority, Not Aspirational Standards

• Failed verification produces actionable consequences (deployment blocks, insurance invalidation, regulatory non-compliance)

• Registry status changes automatically when proofs decay

• Downstream systems receive alerts when upstream components lose verification

• Revocation is enforceable without requiring litigation

IV. Why This Will Happen Regardless of Government Action

The White House framework treats verification infrastructure as optional. It is not. Insurance markets will force its creation.

The Insurance Inevitability

Current state: Underwriters cannot accurately price AI risk. Systems are opaque. Training data is unknown. Behavior is unpredictable. Liability chains are unclear. Without standardized evidence about system safety, underwriting becomes speculation.

No insurance market survives on speculation.

What insurers will do:

1. Demand verification infrastructure that allows consistent risk assessment

2. Offer premium reductions for registry-verified systems and higher premiums for unverified systems

3. Create immediate market pressure through differential pricing

4. Eventually refuse coverage for unverified systems entirely

What this creates: Once reinsurers—who care deeply about systemic risk—begin requiring registry signals, the entire insurance market follows. When insurance becomes difficult to obtain without registry verification, unverified deployment becomes economically impossible.

The timeline: This does not require government action. It requires catastrophic failure. The first major AI-caused disaster with enormous liability (medical AI causing deaths at scale, financial AI causing market collapse, autonomous systems causing mass casualties, educational AI creating systematic harm to vulnerable populations) will force insurance markets to demand verification.

The question is not whether this happens. The question is whether verification infrastructure exists before the catastrophic failure or after.

The White House framework optimizes for building infrastructure after catastrophic failure. This is a choice. An alternative exists.

The Enterprise Procurement Pressure

Current state: Enterprises deploying AI into critical operations face unmeasurable risk. They depend on vendor claims of safety without independent verification.

What enterprises will do:

1. Begin requiring registry verification in procurement specifications

2. Refuse to accept liability for unverified AI in critical operations

3. Demand contractual protections backed by verified safety proofs

4. Create market pressure through procurement requirements

What this creates: AI vendors who cannot provide registry verification lose access to enterprise customers deploying in critical domains. Market pressure forces verification even without regulatory mandates.

Early adopters: Healthcare systems (liability exposure enormous), financial institutions (regulatory pressure intense), critical infrastructure operators (public safety implications), large-scale employers (discrimination liability significant).

The Regulatory Failure Exposure

What the White House framework creates: A situation where verification infrastructure is available, deployed, and economically viable, but government has not mandated its use in critical domains.

What this exposes: Regulatory failure becomes visible and actionable. Citizens, enterprises, insurers, and investors can point to functioning verification infrastructure and demand that government mandate its use in critical domains.

“We have the measurement tools. Use them or explain why you won’t.”

The political pressure this creates: When catastrophic AI failure occurs and registry infrastructure exists that could have prevented it, government failure is not abstract. It is specific. Regulators cannot claim they lacked capacity—the capacity existed and they chose not to use it.

This creates the political pressure that was previously absent. Registry infrastructure makes government failure visible, measurable, and actionable through democratic mechanisms.

The International Competitiveness Argument

What happens when other jurisdictions require verification: EU AI Act creates verification requirements. China implements AI safety infrastructure. Other jurisdictions mandate proof systems.

American AI companies face choice:

• Meet international verification standards to access global markets

• Operate only in US market with no verification requirements

Market reality: Companies choose global markets. They implement verification infrastructure to meet international requirements. US market gets verified AI not because US government required it but because international markets did.

The competitiveness argument inverts: The framework claims verification requirements hurt competitiveness. Reality: lack of verification infrastructure hurts competitiveness by forcing American companies to meet inconsistent international requirements without consistent domestic verification infrastructure to leverage.

V. The Remaining Role of Government

The White House framework treats government's role as removing barriers and preventing regulation. This is not policy. This is capitulation. The framework systematically dismantles every mechanism through which AI safety could be verified, prohibits federal infrastructure, preempts state action, mandates industry self-certification, and calls the resulting void "American AI leadership." When the catastrophic failures come, this framework will be cited as proof that government tried everything except the one thing that works: requiring systems to prove they are safe before they are deployed.

Government as Institutional Backstop

Registry infrastructure shifts regulatory function from direct oversight to institutional backstop. Government does not verify AI safety directly, exposed actors do that through insurance-backed verification. Government ensures the verification infrastructure itself remains independent and enforceable.

This means:

1. Mandate registry verification for systems deployed in critical domains

• Employment decisions affecting individual livelihoods

• Credit allocation affecting financial access

• Healthcare systems affecting patient safety

• Public safety applications affecting community security

• Educational systems affecting student opportunities

• Legal proceedings affecting individual rights

2. Prevent regulatory arbitrage by requiring proof standards across jurisdictions

• Systems verified in one jurisdiction are verified nationally

• No jurisdiction-shopping for weaker verification requirements

• Interstate coordination through consistent registry standards

3. Prohibit deployment of unverified systems in high-risk applications

• Not as regulatory burden but as enforcement of verification requirement

• Systems can operate in low-risk contexts without verification

• High-risk deployment requires proof

4. Enforce revocation authority when systems lose standing

• Registry status changes trigger regulatory action

• Systems operating with expired proofs face compliance consequences

• Dependent systems must respond to revocation alerts

5. Support creation of independent verification infrastructure

• Through industry pools that fund verification without creating per-client dependencies

• Through insurance mechanisms that align verification with risk assessment

• Not through creation of new regulatory agencies but through support for private verification infrastructure

Government becomes the guarantor that market-based verification remains rigorous rather than the primary verifier.

When insurance companies demand adversarial testing, when enterprises require continuous verification, when investors price based on proof decay—government ensures those mechanisms cannot be circumvented through regulatory shopping or voluntary compliance.

What Government Must Not Do

Do not create new AI-specific regulatory agencies. The framework is correct that sector-specific expertise exists in FDA, SEC, FAA, FTC. The error is assuming those agencies have verification capacity. Provide them with registry infrastructure they can leverage.

Do not attempt to conduct technical AI verification through government agencies. Government lacks capacity and cannot operate at the speed AI evolution requires. Enable private verification infrastructure through insurance-backed mechanisms.

Do not preempt state action that requires registry verification. States exercising traditional police powers to protect citizens should be able to mandate verification. Federal preemption should prevent weaker state requirements, not prevent verification requirements entirely.

Do not optimize for “minimally burdensome” at the expense of verification. Unverified AI deployment creates burden through catastrophic failure. Verification creates burden through testing requirements. The former burden falls on victims. The latter burden falls on deployers. This is not symmetrical.

VI. Conclusion: Infrastructure or Catastrophe

The White House National Policy Framework for Artificial Intelligence treats AI safety as a problem that will be solved through innovation, industry self-certification, and existing legal frameworks. It will not be.

The framework explicitly prohibits creation of verification infrastructure while preempting states from building it themselves. The result is a governance vacuum where no jurisdiction can require safety verification before deployment.

This is not sustainable. What will happen instead:

Scenario 1: Proactive Infrastructure (Unlikely Given Current Framework)

• Insurance markets recognize unpriced systemic risk

• Enterprises demand verification in procurement

• Private verification infrastructure emerges through market pressure

• Government eventually mandates what markets already depend on

• Catastrophic failures are prevented or limited

Scenario 2: Reactive Infrastructure (Likely Given Current Framework)

• AI systems deploy without verification

• Catastrophic failure occurs (medical, financial, safety, educational)

• Liability is enormous

• Insurance markets demand verification retroactively

• Verification infrastructure is built after harm

• Government mandates verification after public pressure

• Subsequent failures are prevented, initial harm was unnecessary

Scenario 3: Regulatory Capture Completion (Possible If Framework Passes As Written)

• Federal framework preempts state action

• Federal government refuses to create verification infrastructure

• Industry self-certifies through captured standards bodies

• Multiple catastrophic failures occur

• Legal liability is fragmented and slow

• Insurance markets eventually force verification but timeline is measured in decades

• Harm is widespread before correction

The White House framework optimizes for Scenario 3 while claiming to enable innovation. This is not innovation enablement. This is verification abandonment followed by inevitable harm followed by reactive infrastructure development. THIS is gross negligence.

The Trustable Position

We will build registry infrastructure regardless of government action. Insurance markets will demand it. Enterprises will require it. International competitiveness will force it. The only question is timeline.

Government can accelerate this timeline by:

• Mandating registry verification in critical domains

• Supporting insurance-backed verification infrastructure

• Providing existing regulators with registry access

• Preventing regulatory arbitrage across jurisdictions

• Making regulatory failure visible when verification infrastructure exists but is unused

Or government can delay this timeline by:

• Prohibiting creation of verification infrastructure

• Preempting state requirements

• Optimizing for “minimal burden” over safety verification

• Treating industry self-certification as sufficient

Either way, the infrastructure will exist. Either it exists before catastrophic failure or after.

The framework chooses after.

We are building for before.

No Proof, No Deployment

This is not a regulatory position. It is an engineering requirement. Systems that cannot produce verifiable evidence of safety under adversarial testing should not be deployed in contexts where they can destroy human value.

The White House framework treats this as “burden.” We treat it as minimum viable safety standard.

The difference is not technical. It is philosophical. The framework assumes AI systems are safe until proven harmful. We assume AI systems are unsafe until proven otherwise through adversarial verification.

History will determine which assumption was correct through empirical demonstration. The costs of being wrong are not symmetrical.

When the first catastrophic AI failure occurs, the question will be: Did verification infrastructure exist that could have prevented this?

If the answer is “No, the White House framework prohibited its creation,” that is one kind of failure.

If the answer is “Yes, but government chose not to require it,” that is a different kind of failure.

If the answer is “Yes, and the system was deployed despite failing verification,” that is criminal liability rather than regulatory failure.

The registry infrastructure makes all three answers visible and actionable.

That is its purpose. Not to regulate AI development. Not to slow innovation. To make safety verifiable, continuous, and enforceable so that when failure occurs, responsibility is clear and correction is possible.

The White House framework prevents that clarity. It optimizes for opacity.

We are building for transparency.

The market will decide which approach serves American interests.

Subscribe now

Share

Share

The Anti-Trust Patterns Inside Hospitals

Coercion, extraction, and impunity in clinical security design

Hospitals do not usually fail because people stop caring.

They fail because systems are built that quietly make caring unsustainable.

By the time outcomes collapse, the damage has already been normalized into workflows, dashboards, and executive narratives about “efficiency,” “compliance,” and “necessary tradeoffs.” Trust does not disappear all at once. It is extracted, coerced, and exhausted over time, until what remains is a brittle shell that still looks operational from the outside.

Healthcare security is not immune to this. In many organizations, it has become one of the most efficient trust-eroding machines in the building.

The Shape of Anti-Trust

Anti-trust is not simply the absence of trust. It is an active pattern.

It emerges when systems are designed in ways that force people to choose between doing their job and obeying the system. It grows when friction is imposed downward and c…

Read more

Share

I am interrupting our scheduled series about the Healthcare CISO to bring you a shining example of Trust collapse in action.

The Cybersecurity Chief and the Upload Button

When trust collapses, it rarely does so with a bang. It does it with a mouse click and file select, apparently.

There are scandals that feel cinematic. And then there are scandals that feel structural. This one is the latter.

According to reporting by ARS Technica, the acting head of the Cybersecurity and Infrastructure Security Agency uploaded sensitive government material into a public instance of ChatGPT last summer. The material was marked “for official use only,” which is bureaucracy-speak for information that is not classified but is explicitly restricted from public release. At least four documents containing contracting and cybersecurity information triggered multiple automated security alerts in the first week of August alone.

This is not a story about one man making a mistake. It is a story about institutional incoherence, authority without literacy, and a government that keeps confusing deployment with understanding.

What “Upload” Actually Means

Let’s be precise about what happened here. When you paste text into the public version of ChatGPT, you are not sending it to a secure vault. You are feeding it into a training surface used by hundreds of millions of users worldwide. The data becomes part of OpenAI’s ecosystem. The company is transparent about this: information you provide may be used to improve the model’s responses for other users.

DHS had already built DHSChat, an internal AI chatbot that operates within a secure, closed environment specifically designed to prevent user inputs from leaving federal networks. Data from DHSChat is not used to train external models. The tool was developed after extensive privacy impact assessments, with guardrails established through collaboration with cloud, cybersecurity, privacy, and civil rights experts across the department.

DHSChat was available to roughly 19,000 DHS headquarters employees at the time of the incident. It was designed for exactly the kind of work Madhu Gottumukkala, the acting CISA director, was attempting to do: summarizing contracting documents, processing internal material, generating analysis without exposing sensitive information to external systems.

Gottumukkala requested and received special permission to use ChatGPT shortly after arriving at CISA in May 2025. By May 2025, DHS had restricted access to commercial generative AI systems, directing employees to use internal tools. Most DHS employees could not access public AI platforms. For good reason.

But hierarchy substituted itself for judgment. Authority became its own justification.

The Permission Slip Problem

One anonymous official characterized the sequence bluntly: “He forced CISA’s hand into making them give him ChatGPT, and then he abused it.”

This is the first structural failure. Why was special permission granted at all?

This was not a junior analyst cutting corners because internal tools were slow or cumbersome. This was the top cyber defense official in the country insisting on access to a tool his own agency had deemed unsafe for general use. That is not innovation. That is hierarchy performing exemption from the rules it enforces on others.

Authority is not competence. Access is not literacy.

Following the incident, Gottumukkala held meetings with senior DHS and CISA officials, including legal and information security chiefs, to review the uploads and discuss the handling of sensitive material. This is what damage control looks like when the person who needs controlling is the one in charge of the controls.

The permission structure here reveals something corrosive. When leaders can exempt themselves from the constraints designed to protect the systems they oversee, those constraints become theater. They apply to subordinates. They dissolve for superiors. This is not governance. This is performance.

“Modernization” as a Get-Out-of-Jail-Free Card

When questioned about the incident, DHS spokespeople pointed to executive orders encouraging AI adoption across government. This framing treats policy as permission to bypass safety architecture.

This is the most dangerous sentence in modern governance: “We were told to deploy.”

Deployment without governance is how systems rot from the inside. AI is not a software update. It is an epistemic instrument. It absorbs what you give it, reflects it back in altered form, and redistributes risk in ways that are hard to trace and impossible to recall.

Uploading sensitive material into a public model is not a policy error. It is a category error. Treating AI like a search engine instead of a memory surface. Treating convenience like capability. Treating speed like strategy.

Once the data is in, you don’t get it back. Any information uploaded into a public version of ChatGPT is shared with OpenAI and may be used to help improve responses for other users. The material does not stay contained. It becomes part of the diffusion network.

The alternative was right there. DHSChat existed precisely to allow AI experimentation without this exposure. The tool was built to enable employees to leverage generative AI capabilities safely and securely using non-public data. It was designed for this exact use case.

Gottumukkala chose the public tool anyway.

The Anti-Trust Pattern

Zoom out, and a pattern emerges.

In May 2025, Gottumukkala told personnel at CISA that much of its leadership was resigning. Mass departures gut institutional memory. They signal that something inside the system has become untenable.

In June, Gottumukkala requested access to a controlled access program, an act requiring a polygraph examination. He failed the polygraph in the final weeks of July. Several CISA employees were subsequently placed on leave after the failed polygraph. DHS began investigating the circumstances surrounding the polygraph test and suspended six career staffers, telling them the polygraph did not need to be administered.

This is not what a high-trust system looks like. This is what happens when impunity outruns accountability.

Gottumukkala also attempted to remove CISA’s Chief Information Officer, Robert Costello, a move that other political appointees reportedly blocked. When leadership tries to remove oversight figures and faces internal resistance from within its own political layer, the dysfunction has metastasized.

Staffers reportedly called the tenure a “nightmare.” That word matters. Nightmares are not random. They are the psyche trying to warn you that something is wrong with the environment.

When leaders can make errors without consequence while subordinates absorb the blast radius, trust does not erode. It collapses. Quietly. Systemically.

Congressional Testimony and the Performance of Confidence

During congressional testimony in late January 2026, Gottumukkala rejected characterizations of the polygraph incident, stating he did “not accept the premise of that characterization”. This is the language of deflection masquerading as precision.

Congressional oversight exists to surface patterns. When leadership cannot articulate baseline threat forecasts, cannot maintain staff stability, cannot model the restraint its mission requires, the oversight function becomes diagnostic. It reveals the distance between institutional mandate and operational reality.

CISA exists to protect national trust surfaces: elections, infrastructure, coordination mechanisms. When its own leadership treats those surfaces casually, the danger is not just a single data leak. The danger is precedent.

If the cyber defense chief cannot model restraint around information handling, who exactly is supposed to?

The Real Risk Isn’t ChatGPT

To be clear, and frankly, I feel weird defending OpenAI, but: this is not about OpenAI behaving badly. OpenAI did not force anyone to upload government material. The platform operates according to its stated terms. Users agree to those terms when they use the service.

The real risk is governance theater. Leaders performing “modernization” while bypassing the very controls their agencies were built to enforce.

Cybersecurity is not about tools. It is about judgment under constraint. AI mirrors and amplifies whatever culture you put around it. In a coherent system, it has the potential to augment care. In a brittle one, it accelerates failure, it accelerates rupture.

The failure here is structural. Prior to his appointment at CISA, Gottumukkala served as the chief information officer of South Dakota under then-governor Kristi Noem, who became DHS Secretary under the Trump administration. This is a personnel pipeline, not a competency filter. Loyalty gets routed through institutional architecture as if loyalty were the same thing as capability.

It is not.

What Collapse Looks Like Now

No flames. No sirens. Just a quiet upload, multiple automated security alerts, an internal review, and a press statement about “Our commitment to innovation.”

A CISA spokesperson told Politico that Gottumukkala’s use of ChatGPT was “short-term and limited,” noting that he last used the tool in mid-July 2025 under an authorized temporary exception. This framing treats duration as exoneration. As if the problem was how long the exposure window stayed open rather than that it was opened at all.

Trust does not fail because of hackers alone. It fails when those in charge confuse speed with progress, permission with safety, and authority with wisdom.

The nightmare here is not that sensitive data might surface somewhere in an AI model’s training corpus. The nightmare is that the people responsible for preventing exactly that do not seem to understand why it matters.

DHS developed an entire internal AI infrastructure specifically to allow experimentation without this exposure. Privacy reviews. Security guardrails. Training protocols. A tool designed for the exact workflow Gottumukkala needed. He bypassed all of it.

And when automated systems caught the breach, when alarms fired exactly as designed, the response was not accountability. It was meetings. Reviews. Deflection. The machinery of looking serious without imposing consequences.

This is not a cybersecurity problem.

This is a governance failure.

And it is not an accident. It is a system working exactly as designed: to protect leadership from the constraints that bind everyone else. To perform competence while concentrating impunity. To demand trust while demolishing the conditions that make trust possible.

The collapse is quiet. The precedent is loud. And the people who should be listening are the ones who stopped paying attention the moment they received permission to act without restraint.

Share

Subscribe now

Share

The CISO Myth: Perimeter Guard in a Clinical World

Why “lock it down” thinking fails where care must flow

The modern CISO was not born in a hospital.

The role emerged in the mid-1990s, after Citibank responded to a $10 million cyber theft by Vladimir Levin, through the international funds transfer system. Steve Katz became the world’s first Chief Information Security Officer, hired with two directives: “Build the best cybersecurity department in the world” and “go out and spend time with our top international banking customers to limit the damage.”

The CISO role was forged in banks, payment networks, and financial services firms where the primary asset was transactional data, the primary threat was theft, and the primary strategy was containment. Build a perimeter. Harden it. Monitor ingress and egress. Assume that anything inside the walls is trusted and anything outside is hostile.

This model worked well enough when the worst-case failure mode was fraud.

It collapses completely when the worst-case failure mode is a patient dying because care was delayed.

Healthcare inherited the CISO role wholesale, without interrogating whether its metaphors, incentives, or success criteria made sense in an environment defined by urgency, human variability, and moral stakes. The result is a category error that keeps reproducing harm.

The Financial DNA of the CISO Role

Finance optimized security around three assumptions:

Assets are static. Money and records sit still until moved.

Workflows are predictable. Transactions follow defined paths.

Delay is tolerable. Seconds matter for fraud detection, but minutes rarely kill anyone.

Hospitals violate all three assumptions.

Patients move. Clinicians move. Devices move. Data moves continuously across wards, shifts, and contexts. Workflows are adaptive, improvisational, and deeply contingent on who is available, what is happening, and how sick someone is right now. Delay is not an inconvenience. It is a clinical variable.

The first CISO era from 1995 to 2000 focused on passwords and log-on security, perimeter defenses like firewalls and intrusion detection systems. Early CISO functions put importance on technical security controls and responses towards incidents. The role was narrow in scope and scale, born from the first instances of hacking in financial services.

Yet we still deploy security controls designed for static assets, predictable paths, and tolerable latency, then act surprised when clinicians route around them.

The Perimeter Fantasy in a Porous Environment

Hospitals do not have clean perimeters.

They have open doors, emergency intakes, visiting hours, rotating staff, contractors, students, medical devices that predate modern security models, and patients who show up unannounced in distress.

Perimeter metaphors assume a stable “inside” and a dangerous “outside.” Hospitals are all inside. Or more accurately, they are all interface.

Every login is an interface. Every alert is an interface. Every timeout is an interface. Every system outage is an interface.

Security that assumes it can simply fence off risk misunderstands where risk actually lives. In healthcare, risk lives in friction, confusion, and delay. It lives in the moment a nurse cannot log in quickly enough. It lives in the extra step that breaks a mental flow during triage. It lives in the authentication failure that forces paper notes that will later be re-entered incorrectly.

Perimeters do not protect care. They constrict it.

How Clinicians Become the Enemy

When security is imposed instead of designed, clinicians are positioned as threats.

Not intentionally. Structurally.

Controls that prioritize compliance over usability teach clinicians a quiet lesson: the system does not understand your work. Faced with that mismatch, clinicians do what humans always do in high-stakes environments. They adapt.

They share credentials. They reuse passwords. They leave sessions open. They write things down. They bypass alerts.

The evidence is overwhelming.

Multiple studies show that well over half of healthcare professionals admit to sharing credentials. 46% of employees share work-related passwords for accounts used by multiple coworkers. Password sharing is identified as one of the most common HIPAA violations. Yet healthcare staff continue to share credentials because every minute counts in critical care.

Research on workarounds to computer access in healthcare organizations documents that “workarounds are the norm, rather than the exception.” They not only go unpunished, they go unnoticed in most settings and are often taught as correct practice.

Clinicians offer their logged-in session to the next clinician as a “professional courtesy” even during security training sessions. Nurses circumvent the need to log out of computers on wheels by placing sweaters or large signs with their names on them. Staff defeat proximity sensors by putting styrofoam cups over detectors. The most junior person on staff is asked to keep pressing the space bar on everyone’s keyboard to prevent timeouts.

These behaviors are often framed as “noncompliance” or “human error.” That framing is backwards.

Workarounds are not rebellion. They are rescue.

They are clinicians trying to preserve patient care in systems that were never designed to support it under real conditions. A security program that treats these adaptations as adversarial behavior is misdiagnosing the problem.

When clinicians must choose between following security rules and treating a patient, they will choose the patient every time. Any security model that does not anticipate this is unsafe by construction.

The Latency Tax

“Lock it down” thinking imposes a latency tax.

Each control adds seconds. Each reauthentication adds cognitive load. Each poorly tuned alert steals attention. Individually, these costs look trivial. Collectively, they are measurable, compounding, and dangerous.

Studies and clinician reports show authentication overhead consuming tens of minutes per shift, and in some cases over an hour per day. One clinician mentioned that his dictation system has a 5-minute timeout that requires a password. During a 14-hour day, he spends almost 1.5 hours logging in.

Complex passwords and added authentication requirements are there to protect patient data. However, they ironically lead to decreased productivity and increased security risks. Managing and resetting complex passwords disrupts clinical workflows and consumes valuable time that would otherwise be spent providing care. This leads to burnout. 21% of nurses note too many administrative tasks such as documentation, charting, and electronic health records as a top cause of burnout.

In time-sensitive environments, latency is not evenly distributed. It hits hardest during peak stress: shift changes, emergencies, understaffed nights, system degradation. That is exactly when security controls are least forgiving and clinicians are least able to absorb friction.

This is how well-intentioned security creates systemic brittleness. The system appears controlled under ideal conditions and fails catastrophically under pressure.

A design that only works when everything is going well is not a security design. It is a demo.

Control Versus Coherence

The core failure is philosophical.

Finance-oriented security optimizes for control. Healthcare requires coherence.

Control asks: Can we constrain behavior?
Coherence asks: Can the system hold together under stress?

Control treats humans as liabilities to be managed.
Coherence treats humans as adaptive components to be supported.

Control assumes obedience produces safety.
Coherence recognizes that understanding produces safety.

In healthcare, safety emerges from alignment between people, tools, and context. Security that disrupts that alignment undermines the very thing it claims to protect.

This is why zero-trust absolutism, imported without translation, so often backfires in hospitals. Traditional security follows a “castle-and-moat” approach, trusting everything inside the network. Zero trust treats every access request as potentially hostile, requiring verification regardless of location or network status.

The concept makes sense in theory. In practice, healthcare organizations face unique challenges. Health IT leaders realize their cybersecurity strategies should not tax already time-strapped clinicians by requiring them to sign into multiple applications every day. When done well, zero-trust policies and controls should work successfully behind the scenes with no noticeable impact on clinicians.

But implementation requires careful balance. Healthcare is an industry with one of the highest numbers of connected devices. Most clinical procedures rely on several medical and IoT devices that instantly sync data to medical databases. For healthcare organizations, device functionality comes first. Safety comes second. All devices must work.

Zero trust in a care environment becomes zero flow without careful implementation. Zero flow becomes zero safety.

The difference between implementing zero trust in a healthcare setting versus other industries is that instead of just protecting devices and data, the goal of clinical zero trust is also to protect the physical workflows of care delivery, including the people and processes responsible. Healthcare organizations will likely operate in a hybrid zero-trust/perimeter-based mode indefinitely while modernizing their infrastructure.

The Signal You Cannot Ignore

Here is the signal that matters more than any audit finding:

A system clinicians work around is already unsafe.

Not insecure. Unsafe.

Workarounds are evidence of design failure, not user failure. They are leading indicators of where security is misaligned with care. They tell you exactly where friction is accumulating and where risk is being displaced rather than reduced.

Treating workarounds as policy violations misses their diagnostic value. They are telling you exactly where the system cannot carry the load you have placed on it.

When researchers studied clinicians doing their work, they found that “workarounds to cyber security are the norm, rather than the exception.” Clinicians acknowledge that effective security controls are important, especially in an essential service like healthcare. Unfortunately, all too often with these tools, clinicians cannot do their job. The medical mission trumps the security mission.

These are not terrorists or black hat hackers. These are clinicians trying to use the computer system for conventional healthcare activities. Mostly, the idea is that computer and security experts rarely happen to also be clinical care experts.

SIGNAL exists to surface this truth. To treat friction as data. To instrument the gap between how systems are supposed to work and how they actually work when people’s lives are on the line.

Redefining the CISO Role Again

If the CISO is still operating as a perimeter guard, they are guarding the wrong thing.

The job is no longer to keep threats out at all costs. The job is to ensure that care can continue safely even when things go wrong. That requires abandoning metaphors that treat hospitals like vaults and embracing models that treat them like living systems.

The CISO role has evolved significantly since 1995. By 2000, the CISO’s responsibilities extended beyond corporate boundaries to include e-business partnerships, mirroring institutional changes. The role changed to focus on enterprise risk, governing, privacy, board-level engagement, and business needs.

Steven Katz stated that the role is about business risk and cybersecurity is a way to assess business risk, “not an end in itself.” Key skills became organizational leadership, strategic thinking, communication with boards, budget management, vendor relations, business processes, regulatory overview, and the ability to merge security outcomes with business needs.

In healthcare, this evolution must go further.

The healthcare CISO must understand that clinical workflow is not a constraint to work around. It is the thing being protected. Security controls must be evaluated not just for strength, but for survivability under the conditions where they will actually be used: understaffed emergency departments, shift changes, system degradation, crisis scenarios.

The CISO myth persists because it is familiar and legible to boards. But familiarity is not fitness. Legibility is not safety.

Healthcare does not need better walls. It needs systems that bend without breaking, controls that degrade gracefully, and security leaders who understand that friction in care pathways is not a nuisance. It is a warning.

The perimeter guard was never the right archetype.

The Provocation

Financial services optimized security for an environment where minutes of delay might mean lost revenue. Healthcare operates in an environment where minutes of delay can mean death.

The research is unambiguous. 73% of healthcare professionals violate security policies not out of malice but out of necessity. 45 minutes per shift consumed by authentication overhead. 1.5 hours per day spent logging into systems with aggressive timeouts. Workarounds documented as the norm across every healthcare setting studied.

These are not implementation failures. These are design failures.

Security models built for static assets, predictable workflows, and tolerable latency will always fail in environments characterized by movement, improvisation, and urgency.

The CISO who continues to optimize for perimeter defense in a clinical world is solving the wrong problem. The walls are strong, but the patients are dying inside them because care cannot flow through the checkpoints fast enough.

Healthcare security leaders must accept that their role is fundamentally different from their counterparts in finance. The worst-case scenario is not a data breach. It is a patient dying because the security architecture made care impossible to deliver.

Zero trust can work in healthcare, but only when implemented with clinical zero trust principles: protecting workflows, not just data. Maintaining care delivery under stress, not just preventing unauthorized access. Treating clinicians as the adaptive components that keep the system functioning, not as the security vulnerabilities to be constrained.

A system that clinicians must fight to use is not secure. It is unsafe. The workarounds prove it. The latency proves it. The burnout proves it. The deaths prove it.

The only question is whether CISOs will recognize that guarding the perimeter is not the same as protecting care.

The choice is binary.

* a deck of this article is available for paid subscribers:

Read more

Share

Introduction

Healthcare security still believes it wins when nothing explodes.

No breach. No regulator knocking. No angry board call.

Clean audit. Green dashboard. Everyone exhales.

This definition of success is not just outdated. It is actively dangerous.

Because patients do not experience “security posture.” They experience care. And when security fails in healthcare, the harm does not show up as a line item. It shows up as delayed diagnosis, wrong treatment, abandoned follow-up, and the quiet erosion of trust that determines whether people ever come back.

Patient outcomes are trust outcomes. If your security program cannot see that, it is blind by design.

The Compliance Mirage

HIPAA taught an entire industry to confuse legality with safety.

HIPAA compliance answers a narrow question: Did you follow prescribed controls to protect regulated data? It does not ask whether your systems remain usable under stress. It does not ask whether patients can access care during failure. It does not ask whether trust survives the incident.

A hospital can be fully HIPAA-compliant and still produce catastrophic patient harm.

A hospital can encrypt everything perfectly and still strand clinicians without records.
A hospital can pass every audit and still permanently lose patient confidence.
A hospital can “do everything right” and still hemorrhage outcomes.

Compliance measures behavior. Patients experience consequences.

Security teams have been rewarded for optimizing the former while ignoring the latter. That optimization is now lethal.

From Data Protection to Value Protection

The core error is subtle but foundational.

Healthcare security has defined its object as data about patients.

But patients do not entrust hospitals with data. They entrust them with value.

They entrust their time when they wait and comply. They entrust their bodies when they consent to treatment. They entrust their futures when they disclose honestly. They entrust their dignity when they become vulnerable.

Data is just one carrier of that value. When security fixates on the container and ignores the content, it protects the shell while the substance degrades.

Protecting data about patients is necessary. Protecting value for patients is non-optional.

That is the shift.

Trust Failures Are Clinical Failures

Trust is often dismissed as a soft concept because it is rarely operationalized. That dismissal collapses the moment you trace trust failures to patient harm.

A system outage during intake is not neutral. It delays diagnosis.
A corrupted record is not clerical. It produces misdiagnosis.
An opaque breach response is not PR-related. It causes abandonment.

Patients who lose trust behave differently in ways that are both measurable and dangerous. They withhold information. They delay seeking care. They disengage from treatment plans. They avoid follow-up. They leave the system entirely.

These behaviors precede morbidity. They precede mortality. They precede cost spikes that leadership pretends are “unrelated.”

Trust loss is not an emotional inconvenience. It is a causal mechanism.

The Mechanisms: How Trust Erosion Kills

A meta-analysis examining trust in healthcare professionals found a small to moderate correlation between trust in healthcare professionals and health outcomes (r = 0.24, 95% CI: 0.19–0.29). This correlation is significant because trust operates as a mediator for measurable clinical behaviors.

In a study of 480 adult patients with type 2 diabetes, researchers found that patients who trust their physicians more demonstrate stronger self-efficacy and outcome expectations, which, in turn, drive better treatment adherence and objective health outcomes. The mechanism is not mysterious. Trust functions as the substrate upon which therapeutic response is built.

When trust erodes, the entire causal chain fractures.

Patients with greater trust in provider confidentiality are significantly less likely to withhold important health information. Conversely, patients who experience trust violations engage in protective behaviors that compromise their care. In general consumer research, 66% say they wouldn’t trust a company after a breach, and 75% say they’d sever ties after a cyber incident.

A study using difference-in-differences methods found that patients affected by a healthcare data breach were less likely to visit hospitals in the months following the breach. Up to 40% of patients consider switching providers after a breach. The withdrawal is not temporary. It is structural.

These are not sentiment surveys. These are behavioral predictors with direct clinical consequences.

The Economic Weight of Abandonment

Patient nonadherence costs the U.S. healthcare system between $100 billion and $300 billion annually due to avoidable hospitalizations, emergency room visits, and preventable complications. Nonadherence represents 3% to 10% of total U.S. healthcare costs. This translates to approximately 125,000 deaths per year.

What does this have to do with trust?

Poor communication and lack of trust can undermine adherence. The quality of the patient-provider relationship is crucial. When trust in the healthcare system deteriorates, adherence collapses as a downstream consequence.

Patients in lower socioeconomic brackets already struggle with medication costs, which leads to rationing or skipping doses. Add trust erosion from a security failure, and the abandonment accelerates. Patients withhold crucial health information from providers. They delay seeking medical care. They provide inaccurate information to protect their privacy. They avoid participating in medical research or health information exchanges.

This is how security failures metabolize into mortality.

The mechanism travels like this: data breach → trust violation → information withholding → diagnostic error → treatment failure → preventable death.

Security teams measure the breach. Who counts the bodies?

Abandonment Is a Security Failure

One of the least acknowledged harms of healthcare security failure is abandonment.

When systems go dark, patients are left without orientation. No records. No clarity. No guidance. No explanation of what happened or what to do next.

Abandonment produces fear. Fear produces avoidance. Avoidance produces worse outcomes.

Security teams rarely count abandonment because it does not trigger an alert. But patients count it immediately. They feel it in the silence when portals fail, when clinics cannot answer, when no one can tell them whether their treatment plan still exists.

During the CommonSpirit Health attack in 2022, patients experienced exactly this terror. The second-largest nonprofit hospital chain in the United States went offline. Patients could not access their records. Pharmacies could not verify prescriptions. Scheduled surgeries were delayed. Emergency departments diverted ambulances.

The patients trapped in that chaos did not experience a “technical incident.” They experienced abandonment by a system they trusted to hold them.

If your incident response leaves patients alone in uncertainty, you did not “contain” the incident. You amplified it.

Trust Is a Leading Indicator

Healthcare loves lagging indicators. Mortality rates. Readmission rates. Length of stay.

By the time those metrics move, harm is already entrenched.

Trust is different. Trust is a leading indicator.

Leading indicators in healthcare are forward-looking measurements that give teams early warning of likely outcomes. They focus on inputs and processes that can be influenced now. Lagging indicators are retrospective and outcomes-based. They are easy to measure but difficult to improve or influence.

Trust friction shows up early as missed appointments, hesitation, second-guessing, withdrawal, and anger directed at frontline staff.

These are not behavioral quirks. They are system health signals.

No-show rates vary widely by setting, but 20% is common in many outpatient contexts with scheduled appointments. In mental health services, up to 50% of patients who miss appointments drop out of scheduled care. A qualitative study exploring why patients miss appointments found that the reasons center on three types of issues: emotions, perceived disrespect, and not understanding the scheduling system.

The norm of reciprocity suggests that a patient who feels disrespected would feel no obligation to respect the system. This construct, respect, underlies the association of waiting times, satisfaction, and nonattendance. Patients who feel unheard, rushed, or judged during healthcare interactions disengage from the system altogether, leading to long-term avoidance of care.

Security incidents violate respect structurally. When a hospital cannot explain what happened to patient data, cannot assure safety, cannot restore access, the disrespect is absolute. Patients respond predictably. They stop showing up.

This is why trust metrics matter more than compliance metrics. Trust friction precedes outcome collapse. It gives healthcare organizations time to intervene before the harm becomes irreversible.

SIGNAL exists to surface exactly this layer. To instrument emotional safety, coherence, and confidence before outcomes collapse. To detect where systems make people feel unsafe, long before failure becomes irreversible.

Ignoring trust because it feels subjective is like ignoring pain because it does not show up on imaging. It is malpractice masquerading as rigor.

Redefining Security “Success”

If patient outcomes are trust outcomes, then healthcare security must redefine success.

Success is not “no incidents.”
Success is survivability under incident conditions.

Success is not “data remained encrypted.”
Success is patients still receiving care.

Success is not “we followed the playbook.”
Success is clinicians not improvising dangerously.

Success is not “we disclosed within 72 hours.”
Success is patients understanding what happened and what comes next.

This requires a different scoring system. One that measures time to clinical continuity, integrity under degradation, clarity of communication, patient confidence post-incident, and clinician trust in the system.

These are not abstract ideals. They are operational requirements for care-safe security.

Consider what happened at the University of Vermont Medical Center in 2020. The ransomware attack disabled chemotherapy infusion technology. Oncology had to create command centers to oversee ethical triage of systemic therapies. Patients were stratified into tiers: curative-intent urgent care, treatments safe to delay 1-2 weeks, and treatments safe to delay at least 2 weeks.

This is what security failure looks like when measured in clinical posture. Not “systems offline.” Lives prioritized under scarcity.

The oncology team did not measure success by how quickly they restored systems. They measured success by whether patients with time-sensitive cancer treatments survived the artificial resource constraint created by a security failure.

That is the standard healthcare security should adopt.

The Signal Shift

This is the inversion healthcare security has been avoiding:

• From protecting data about patients to protecting value for patients.

• From perimeter defense to circulatory resilience.

• From compliance theater to outcome stewardship.

• From technical risk management to clinical risk ownership.

Once you make this shift, certain truths become unavoidable.

Security controls that degrade care are unsafe. Architectures that fail silently are unethical. Incident responses that prioritize optics over patients are illegitimate.

And CISOs who measure success without patient outcomes are flying blind.

The Provocation

Healthcare security can continue congratulating itself for clean audits while trust erodes quietly in waiting rooms.

Or it can accept what the data, the deaths, and the patients have already made clear.

Patient outcomes are trust outcomes.

Every availability failure is a dignity failure. Every integrity failure is an accountability failure. Every opaque response is an agency failure.

These map directly to the Trust Envelope Model. Dignity requires that patients have access to the care they need. Accountability requires that systems can be relied upon to maintain accurate, trustworthy information. Agency requires that patients understand what is happening to them and be able to take informed action.

When ransomware disables chemotherapy scheduling, Dignity collapses. When corrupted records produce wrong allergy information, Accountability collapses. When breach notifications can legally arrive up to 60 days after discovery, with no clarity about what patients should do next, Agency collapses.

Trust Value Management is not a philosophy layered on top of security. It is the missing control plane that healthcare has been pretending it did not need.

The research is unambiguous. The mechanisms are documented. The deaths are counted.

Between $100 billion and $300 billion in annual costs. 125,000 deaths per year. 66% trust loss after breaches. 75% patient abandonment. Up to 50% dropout from care.

These are not abstract risks. These are measured outcomes.

Healthcare security that cannot see trust as infrastructure is healthcare security that kills patients while celebrating compliance.

The only question is whether security leaders will accept that their decisions have clinical consequences. Whether they will measure trust friction as rigorously as patch compliance. Whether they will own the deaths.

The choice is binary.

*this article is available as a downloadable PDF for paid subscribers

Read more

Share

The CISO as Patient-Safety Actor: Why Cybersecurity Is Now a Patient-Facing Function

For a long time, healthcare security lived a polite lie.

The lie was that cybersecurity was an IT concern. A back-office hygiene practice. A necessary nuisance whose job was to keep auditors calm, insurers satisfied, and billing systems upright. If it occasionally annoyed clinicians or slowed workflows, well, that was the price of safety.

But here is the thing about lies in clinical environments. They do not stay abstract. They metabolize into harm.

In modern healthcare, there is no meaningful boundary between the technical and care systems. The stack is at the bedside. The network is the hallway. The EHR is the chart in the clinician’s hand while someone is scared, in pain, and half-dressed under fluorescent lights.

That means the CISO is no longer a perimeter guard. Whether they like it or not, they are a patient-safety actor.

When Systems Fail, Patients Feel Actual Harm

A ransomware attack does not “impact operations.” Between 2016 and 2021, 374 documented ransomware attacks on healthcare delivery organizations affected the protected health information of 42 million patients. During these attacks, computers and electronic health records were disabled or encrypted. Clinicians were forced to document care by hand. Appointments and surgeries were delayed or canceled. Emergency departments diverted ambulances.

In 2020, a ransomware attack at the University of Vermont Medical Center disabled chemotherapy infusion technology. A nurse compared those weeks to only one experience: working in a burn unit following the Boston Marathon bombing. The oncology department lost access to individualized EMR chemotherapy plan templates that drove nursing and pharmacy processes. Infusion visit volume dropped 52% in the first week. New patients could not access diagnostic services. The hospital created command centers to oversee ethical triage of systemic therapies.

University of Minnesota School of Public Health experts estimate that between 42 and 67 patients died as a result of ransomware attacks between 2016 and 2021. This does not include deaths covered by private insurance.

An EHR outage does not “reduce productivity.” It blocks medication reconciliation in the ER. When ransomware forced Universal Health Services offline in 2020, a clinical staff member reported having no access to any patient files, no history, nothing. Doctors could not access X-rays or CT scans. In operating rooms, anesthesia checklists disappeared. In ICUs, vital signs went unrecorded. In emergency departments, clinicians did not know patients’ allergies or the last medication administered.

A data integrity failure does not “raise compliance risk.” Hackers can alter medication details, allergy information, or diagnostic data. These changes lead to medical errors, misdiagnoses, and incorrect prescriptions. Wrong information persists in records over time, creating a continual risk of improper treatment.

Availability failures feel like abandonment.
Integrity failures feel like betrayal.
Latency feels like neglect.

Patients experience these failures viscerally. Not as headlines. Not as KPIs. As fear. As confusion. As the sickening realization that the system they trusted to hold them cannot remember who they are today.

The Spillover Effect: How One Hospital’s Breach Kills Patients Across Town

Ransomware attacks do not confine their harm to breached facilities. When hospitals go offline, neighboring facilities absorb the displaced patients. The results are measurable and lethal.

A study examining the spillover effects of hospital ransomware attacks documented what happens at unaffected facilities when nearby hospitals are compromised. Emergency medical services arrivals increased 35.2%. Patient volume increased 15.1%. Waiting room time increased 47.6%. Stroke code activations increased 74.6%. Confirmed strokes increased 113.6%. Cardiac arrest cases increased 81%.

These are not theoretical projections. These are deaths. Strokes that became permanent disability. Hearts that stopped beating while patients waited in overwhelmed emergency departments.

In rural areas with no backup capacity, the consequences are starker. When a ransomware attack cripples the only hospital for 50 miles, entire communities lose access to emergency care. Patients die in ambulances. Patients die at home, afraid to seek care that is no longer available.

This is what happens when cybersecurity is treated as a perimeter problem instead of a circulatory system. The failure propagates. The harm compounds. The bodies pile up.

Patient Safety Begins in Architecture Decisions Made Before the Crisis

We have spent decades pretending that patient safety stops at the bedside. That once the clinician does their job, the rest is infrastructure trivia. That fiction is no longer survivable.

Patient safety begins upstream, in architecture decisions made months or years before a crisis. It lives in how systems degrade under stress. It lives in whether clinicians can access what they need without improvising dangerous workarounds. It comes down to whether the hospital stays legible when something goes wrong.

In other words, patient safety begins in the security strategy.

Consider what happened during the CommonSpirit Health attack in 2022. CommonSpirit is the second-largest hospital chain in the United States. When ransomware forced their systems offline, ER nurses reverted to paper charting under crushing patient loads. The risk of transcription errors multiplied. Misplaced files became lethal possibilities. Medication mistakes bloomed in the chaos.

These failures were not inevitable. They were consequences of a security architecture that optimized for control rather than resilience under pressure. Systems are designed with no plan for graceful degradation. Controls that assumed perfect conditions. Incident response protocols that prioritized optics over clarity.

The CISO owns these outcomes, whether the org chart acknowledges it or not.

The CISO Myth Was Built for Credit Cards, Not Bodies

The modern CISO role was forged in finance. In environments where the primary asset was data, the primary harm was theft, and the primary goal was containment. Lock the doors. Harden the perimeter. Minimize exposure.

That logic does not survive first contact with a hospital.

Hospitals are porous by necessity. They are staffed by humans under pressure. They are full of legacy devices that cannot be patched, clinical workflows that cannot be paused, and moments where speed matters more than elegance. You cannot “lock it down” without locking patients out.

So what happens instead is predictable. Security is imposed as control rather than designed as care. Clinicians become reluctant adversaries. Workarounds bloom like mold in a damp basement. Passwords get taped under keyboards because the system demanded obedience, not understanding.

In a study of clinical informaticians, 60.4% identified disruption to workflows and services as a top challenge to cybersecurity implementation. First-shift nurses need to log in and out of multiple devices throughout the day across several locations. Authentication requirements insert latency at every step. Even with a 90-second latency, the cumulative impact on patient care is measurable.

Workarounds are defined in the literature as “informal temporary practices for handling exceptions to normal workflow.” In healthcare, they are clinicians’ self-created solutions to achieving a work goal within a dysfunctional system of work processes that prevent or impede that goal.

A system that clinicians must fight to use is already unsafe.

This is not a failure of training or attitude. It is a design failure rooted in a category error. We imported domination-era security models into coherence-driven care environments and then acted surprised when they shattered under load.

The Care Delivery Chain Includes You

Healthcare leaders love flow diagrams of the care journey. Intake. Triage. Diagnosis. Treatment. Discharge. Follow-up.

Security is rarely drawn on those diagrams. Which is adorable, given how many of those steps depend entirely on secure, available, trustworthy systems.

Every authentication requirement inserts latency into intake.
Every poorly tuned alert interrupts diagnosis.
Every brittle control that fails under stress fractures treatment continuity.
Every opaque outage poisons discharge confidence and follow-up adherence.

These are not side effects. They are causal contributions.

If your security control delays care, you own the outcome. If your architecture collapses silently, you own the confusion. If your incident response prioritizes optics over clarity, you own the fear.

The clinical chain does not care what your org chart says.

From Risk Posture to Clinical Posture

Most CISOs are trained to speak in the language of “risk appetite.” This is a comforting abstraction. It allows executives to pretend that risk is a negotiable commodity rather than a lived experience.

Patients do not consent to your risk appetite. They consent to care under an implied trust envelope.

They consent to care. And care has a different posture. It asks different questions. Not “what exposure can we tolerate?” but “what harm are we willing to cause?”

Translating cyber risk into clinical risk is not a communications exercise. It is a moral one. It requires admitting that uptime is not just a technical metric. It is a safety metric. That data integrity is not just accuracy, but diagnostic trust. That confidentiality breaches do not just violate the law, but rupture the emotional safety required for people to seek care at all.

Compliance will never measure this. Audits cannot feel fear. Dashboards cannot register betrayal. Only patients can.

Patients Feel Security Long Before They Understand It

Trust is not a value patients articulate. It is a condition they inhabit.

When systems work, trust is invisible. When systems fail, trust collapses instantly.

The evidence is unambiguous. After a data breach, 66% of patients report losing trust in the affected organization. 75% sever ties altogether. A study of 12 California hospitals over three years found that patients who experience a healthcare data breach are significantly less likely to visit hospitals in the following months.

Up to 40% of patients consider switching providers after a breach. Patients withhold important health information when trust in provider confidentiality erodes. They delay seeking medical care. They provide inaccurate information to protect their privacy. They avoid participating in medical research or health information exchanges.

This is not sentiment. This is signal.

Trust friction shows up as missed appointments, disengagement, second-guessing, and refusal. These are measurable outcomes that precede clinical deterioration. Ignoring them because they do not appear on a SOC report is how institutions quietly rot.

The SIGNAL methodology exists precisely to surface this kind of friction. To instrument emotional safety the same way we instrument throughput. To treat fear, confusion, and loss of confidence as early warning indicators rather than collateral damage.

In the Trust Envelope Model, these trust failures map directly to violations of structural invariants. Availability failures violate Dignity (the patient cannot access the care they need). Integrity failures violate Accountability (the system cannot be relied upon to maintain accurate information). Opaque incident response violates Agency (patients cannot understand what happened to them or what actions to take).

In healthcare, emotional safety is not a luxury. It is a prerequisite for effective care.

Case Sketches: No Villains, Just Physics

An oncology department taken offline by ransomware does not need a villain. It needs to be acknowledged that availability is care-critical. When chemotherapy infusion systems fail, patients with time-sensitive cancer treatments face survival consequences. The triage decisions required are not technical. They are ethical.

An ER slowed by EHR latency does not need a scapegoat. It needs to be recognized that performance under load is a safety requirement. When waiting times increase 47.6% at neighboring hospitals absorbing displaced patients, people die in waiting rooms.

A medical device isolated so aggressively it breaks monitoring continuity does not need a memo. It needs design humility. Network segmentation that prevents clinicians from accessing diagnostic imaging or infusion pump data creates the exact conditions for medical error that security was supposed to prevent.

These failures are not moral lapses; they are systemic consequences of treating security as a shield rather than a circulatory system. Of optimizing for control instead of coherence.

In Trust Thermodynamics terms, these systems have settled into local energy minima that optimize for compliance theater rather than actual resilience. The lattice configuration prioritizes demonstrable controls over survivable architecture. The proof of lattice maintenance is absent. When stress arrives, the system has no capacity to maintain its structure.

What Changes When the CISO Accepts the Clinical Role

Everything.

Decision criteria change. Controls are evaluated not just for strength, but for survivability under stress. The question becomes: “Does this security measure maintain its protective function when the hospital is operating under ransomware conditions, when staff are exhausted, when emergency patients are arriving faster than they can be processed?”

Escalation paths change. Incidents are communicated as care disruptions, not technical inconveniences. When Change Healthcare paid a $22 million ransom and the affiliate holding the data refused to release it, claiming he had not received his share, that was not a technical failure. That was a patient-safety crisis affecting prescription processing at 80% of U.S. pharmacies.

Accountability loops close. Security leaders remain present through recovery, not just containment. They participate in morbidity and mortality conferences. They sit in command centers during ethical triage decisions. They hear what happened to the patients whose chemotherapy was delayed.

Most importantly, the CISO stops asking, “Is this secure?” and starts asking, “Is this safe?”

That shift does not weaken security. It strengthens it. Systems designed to preserve trust under pressure are harder to exploit, harder to fracture, and easier to repair. Coherence is not softness. It is resilience.

Trust Thermodynamics teaches us that energy must be continuously supplied to maintain non-equilibrium order. The CISO who accepts their clinical role becomes an active source of that energy. They instrument trust friction. They measure emotional safety. They design for graceful degradation. They own the clinical consequences.

This is not an aspirational culture change. This is operational rigor applied to human safety instead of financial loss.

The Provocation

If your security program cannot explain how it behaves at the worst moment of someone’s life, it is not protecting healthcare. It is protecting itself.

Neprash shows annual attacks more than doubled from 2016 to 2021. From 2024 alone, 374 U.S. healthcare institutions were hit by ransomware, causing network shutdowns, offline systems, delays in critical medical procedures, and rescheduled appointments. The average cost of a healthcare data breach now exceeds $10.93 million.

But the real cost is measured in bodies. In cardiac arrests with no favorable neurological outcomes. In strokes that became permanent disability. In chemotherapy delayed past the point of treatment efficacy. In patients who stopped seeking care altogether.

Hospitals do not need more polished compliance artifacts. They need security leaders willing to own the clinical consequences of their decisions.

The CISO is already in the care pathway. The clinical chain already includes authentication latency, availability failures, integrity violations, and trust erosion. These are not abstractions. They are mechanisms of harm.

The only question is whether CISOs will act like patient-safety actors. Whether they will attend the morbidity and mortality conferences. Whether they will sit in the command center during ethical triage. Whether they will measure trust friction as rigorously as they measure patch compliance.

Whether they will accept that security failures kill patients.

The operational disruption is documented. The clinical harm is measurable. The only open question is whether leadership treats this as patient safety or as IT weather.

Next in the Series

Patient Outcomes Are Trust Outcomes: How Trust Value Management Operationalizes What Clinical Research Has Been Measuring for Decades

*this article is available as a downloadable PDF Slide Deck for paid subscribers.

Read more

The Trust Engineering Advantage

PART I—THE GAP: Everyone Has the Research, No One Has the Machinery

PART II—THE DIAGNOSIS: The Research Is Already Measuring TEM, Just Poorly

PART III—THE LAW: Why Interventions Fail Without Structure

PART IV—THE INSTRUMENTATION: Trust Is Measurable, Predictable, and Designable

PART V—THE CAPITAL THESIS: Trust Is an Asset Class, and TEM Is the Pricing Model

PART VI—THE DEPLOYMENT: How to Build the Trust Envelope in a Real Organization

Subscribe now

Share

PART VI: THE DEPLOYMENT

How to Build the Trust Envelope in a Real Organization

Trust engineering is not therapy. It is not vibes. It is not values decks, listening tours, or DEI as ornamental signaling.

Trust engineering is operational design.

If Parts I–V established the architecture, physics, instrumentation, and capital logic of trust, Part VI answers the only question that matters to the VP Engineering who has a roadmap due Tuesday, the Chief Customer Officer whose NPS is cratering, or the CFO who just saw Q3 attrition numbers:

W…

Read more

PART I—THE GAP: Everyone Has the Research, No One Has the Machinery

PART II—THE DIAGNOSIS: The Research Is Already Measuring TEM (Badly)

PART III—THE LAW: Why Interventions Fail Without Structure

PART IV—THE INSTRUMENTATION: Trust Is Measurable, Predictable, and Designable

PART V—THE CAPITAL THESIS: Trust Is an Asset Class, and TEM Is the Pricing Model

PART VI—THE DEPLOYMENT: How to Build the Trust Envelope in a Real Organization

Subscribe now

Share

PART V: THE CAPITAL THESIS

Trust Is an Asset Class, and TEM Is the Pricing Model

There is a quiet truth in modern markets that nobody says out loud:

The market already trades on trust. It just doesn’t have the vocabulary.

It doesn’t call it trust. That would sound soft, immeasurable, unsuitable for institutional portfolios. So it invents euphemisms: execution quality, leadership premium, operational resilience, customer retention, risk-adjusted return, cost of capital, margin stability, human capital factor, workplace wellbeing index.

But …

Read more

The Trust Engineering Advantage

PART I—THE GAP: Everyone Has the Research, No One Has the Machinery

PART II—THE DIAGNOSIS: The Research Is Already Measuring TEM, Just Poorly

PART III—THE LAW: Why Interventions Fail Without Structure

PART IV—THE INSTRUMENTATION: Trust Is Measurable, Predictable, and Designable

PART V—THE CAPITAL THESIS: Trust Is an Asset Class, and TEM Is the Pricing Model

PART VI—THE DEPLOYMENT: How to Build the Trust Envelope in a Real Organization

Subscribe now

Share

PART IV: THE INSTRUMENTATION

Trust Is Measurable, Predictable, and Designable

If the first three parts established the architecture and the physics, Part IV delivers what every executive secretly wants but will never say out loud:

A dashboard.

Not a vibes dashboard. Not an HR “engagement pulse” that measures sentiment three months after the damage is done. Not another survey that asks “On a scale of 1-10, how happy are you?” and generates data that goes directly into a deck that goes directly into a drawer.

A telemetry system that me…

Read more

The Trust Engineering Advantage

PART I—THE GAP: Everyone Has the Research, No One Has the Machinery

PART II—THE DIAGNOSIS: The Research Is Already Measuring TEM, Just Poorly

PART III—THE LAW: Why Interventions Fail Without Structure

PART IV—THE INSTRUMENTATION: Trust Is Measurable, Predictable, and Designable

PART V—THE CAPITAL THESIS: Trust Is an Asset Class, and TEM Is the Pricing Model

PART VI—THE DEPLOYMENT: How to Build the Trust Envelope in a Real Organization

Subscribe now

Share

PART III: THE LAW

Why Interventions Fail Without Structure

Here is the question that breaks every corporate happiness initiative:

If autonomy, fairness, safety, cooperation, and learning all predict performance—and we have twenty years of research proving it—why does every intervention fail?

Not struggle. Not disappoint. FAIL.

Ping pong tables don’t increase satisfaction. They increase cynicism. Unlimited PTO often reduces time off rather than expanding it. Open offices designed for collaboration destroy the conditions that enable it…

Read more

The Trust Engineering Advantage

PART I—THE GAP: Everyone Has the Research, No One Has the Machinery

PART II—THE DIAGNOSIS: The Research Is Already Measuring TEM, Just Poorly

PART III—THE LAW: Why Interventions Fail Without Structure

PART IV—THE INSTRUMENTATION: Trust Is Measurable, Predictable, and Designable

PART V—THE CAPITAL THESIS: Trust Is an Asset Class, and TEM Is the Pricing Model

PART VI—THE DEPLOYMENT: How to Build the Trust Envelope in a Real Organization

Subscribe now

Share

PART II: THE DIAGNOSIS

The Research Is Already Measuring TEM (Badly)

If Part I exposed the canyon between what we know about human thriving and what our systems actually produce, Part II reveals the punchline hiding in plain sight:

The entire well-being canon has been measuring the Trust Envelope for two decades. They just didn’t know the name of the machine they were touching.

Positive psychology, organizational justice, Self-Determination Theory, prosocial behavior research, and psychological safety—all the grand theories presente…

Read more

The Trust Engineering Advantage

PART I—THE GAP: Everyone Has the Research, No One Has the Machinery

PART II—THE DIAGNOSIS: The Research Is Already Measuring TEM (Badly)

PART III—THE LAW: Why Interventions Fail Without Structure

PART IV—THE INSTRUMENTATION: Trust Is Measurable, Predictable, and Designable

PART V—THE CAPITAL THESIS: Trust Is an Asset Class, and TEM Is the Pricing Model

PART VI—THE DEPLOYMENT: How to Build the Trust Envelope in a Real Organization

Subscribe now

Share

PART I: THE GAP

Everyone Has the Research. No One Has the Machinery.

Walk into any corporate keynote ballroom today, and you will hear the same soft-focus sermon: happy employees perform better. People need dignity and autonomy. Social support matters. Fairness matters. Safety matters. When humans feel respected and connected, the whole machine hums.

And here is the inconvenient thing: The research actually agrees with them. In fact, the research has been agreeing with them for more than twenty years.

Shawn Achor’s synthesis of a decade …

Read more

Share

The Clarity After the Controversy

In November 2025, OpenAI’s CFO Sarah Friar sparked a firestorm when she suggested at a Wall Street Journal event that the U.S. government should provide “backstops”—loan guarantees—for the company’s trillion-dollar infrastructure buildout. The backlash was swift and severe, with David Sacks, the White House AI czar, declaring flatly: “There will be no federal bailout for AI.”

Sam Altman moved quickly to clarify: “We do not have or want government guarantees for OpenAI datacenters. We believe that governments should not pick winners or losers, and that taxpayers should not bail out companies that make bad business decisions.”

On this specific point—that taxpayers shouldn’t underwrite private company failures, Altman is absolutely right. Markets need failure. Creative destruction is capitalism’s immune system, and weakening it creates moral hazard at scale. The 2008 financial crisis proved this with brutal clarity: when private profits are privatized but l…

Read more

There’s a particular kind of déjà vu that appears when you watch the same failure repeat, not because people didn’t know better, but because the system itself was built to fail this way. That’s where we are with the news that Salesforce customers have been breached again, this time through Gainsight, a customer success platform that, like Drift before it, enjoys a deep and poorly governed integration into the Salesforce ecosystem.

If you haven’t been following the pattern, here it is in clean, brutal lines:

No one hacked Salesforce.
They hacked the trust relationships we built around Salesforce.
And those relationships are the real attack surface now.

This is not an “app breach story.” This is a story of trust collapse in enterprise SaaS architecture. And it’s only going to get worse, not because the technology is fundamentally broken, but because we’re treating trust as an automatic byproduct of vendor selection instead of something we deliberately manufacture and maintain.

I. The Attack T…

Read more

Share

How Tech Giants Weaponize Governance Performance to Avoid Actual Accountability

There is no industry more fluent in the aesthetics of responsibility than the one automating consequential decisions about human lives. Tech giants have perfected a particular form of corporate theater: the simulation of trustworthiness so convincing that most people forget to demand proof. They build beautiful “Responsible AI” pages. They publish model cards with impressive taxonomies. They convene ethics boards that disband when inconvenient. They give keynotes about the importance of safety, delivered by executives who will never face consequences when their systems fail.

This is Safety Theater, governance as performance art, designed to look like accountability from a distance while functioning as a liability shield up close.

And it works because of something deeper and more troubling: most people no longer remember what real trust feels like. When every app surveils you, every platform manipulates you, e…

Read more

Share

Why the Future of Intelligence Depends on the Architecture of Accountability

There’s a particular species of corporate delusion that flourishes in moments of technological vertigo: the belief that governance can be purchased as an add-on, implemented as a checklist, and certified as complete. We’ve seen it before, in financial services post-2008, in social media circa 2016, in every industry that discovered consequences arrive faster than controls. Now we’re watching it unfold again in AI, where the stakes are not merely operational but epistemic: the power to define what is true, who is believed, and whose reality counts.

The instinct is predictable. When risk becomes uncomfortable, organizations build a process around it. Process becomes documentation. Documentation becomes a shield. And eventually, the shield becomes costume jewelry, governance as performance art. Recognizable from a distance, nonsensical up close.

But AI systems don’t read your responsible AI policy deck. Models don’…

Read more

Share

SOURCE: Age and gender distortion in online media and large language models

When Bias Becomes Infrastructure

Some biases announce themselves with the brutality of slurs and the sting of slights. Others work differently; patient, systematic, encoded in pixels, and buried in training data. They don’t shout. They accumulate. They normalize through repetition until distortion becomes indistinguishable from reality.

The recent Nature study on age and gender distortion in online media and large language models exposes one of these quieter violences: a culture-wide algorithmic pattern that literally edits older women out of public reality. Across 1.4 million images and videos, women are portrayed as significantly younger than men in identical roles. The distortion intensifies precisely where it matters most: in high-status professions where women’s authority should be most visible. CEOs, doctors, professors: reality shows no age difference between men and women in these roles. The internet insi…

Read more

Share

How Ascension Failed to Manufacture Trust (and How Patients Pay the Price)

To the Reader

This piece responds to Ars Technica's "How Weak Passwords and Other Failings Led to the Catastrophic Breach of Ascension." That story frames the breach as a technical lapse, a narrative of weak passwords, legacy protocols, and misconfigured systems that reads like a cybersecurity postmortem from any of the last two decades. Here we reframe it: breaches are never merely technical accidents waiting to happen. They are manufactured through deliberate management strategy, carefully constructed liability shields, and systemic incentives that trade away trust for short-term efficiency. What follows is an examination of how trust should have been manufactured at Ascension, why it wasn't, and why these failures continue to recur across industries with clockwork predictability.

The technical details of the Ascension breach, the contractor's laptop, the malicious link, and the Kerberoasting attack are symptoms…

Read more

Share

SOURCE: Denmark Leads EU Push to Copyright Faces in Fight Against Deepfakes

I. The Ghost in the Portrait: A Historical Prelude

In 1890, Samuel Warren and Louis Brandeis penned what would become the most influential law review article in American jurisprudence: “The Right to Privacy.” Their motivation was visceral and immediate. Warren’s wife had been subjected to invasive society page coverage; her private moments had been rendered public spectacle by the emerging technologies of photography and tabloid journalism. The solution they proposed was revolutionary: a legal right “to be let alone,” a barrier between the intimate self and the consuming gaze of publicity.

What made their argument radical was not merely its recognition of privacy as a right, but its acknowledgment that technology had fundamentally altered the nature of exposure. The photograph, they understood, was not simply a recording device; it was a weapon of replication, capable of divorcing image from context, presence fro…

Read more