Dual-Use and Security-Sensitive Risk Controls are the Nexus safeguard architecture for identifying, restricting, reviewing, correcting, excluding, and lawfully handling dual-use, cybersecurity, biosecurity, critical infrastructure, geospatial, sanctions-sensitive, export-control-sensitive, model-release, red-team, blue-team, misuse, secure-disclosure, restricted-data, defense-sensitive, classified, sanctions-prohibited, controlled-technology, and pre-publication security risks.<\/p>\n\n\n\n
Dual-Use and Security-Sensitive Risk Controls govern how Nexus handles records, systems, outputs, models, maps, data, simulations, demonstrations, dashboards, technical findings, public-safe reports, and lawful handoff materials that may create security risk if misused, overpublished, transferred improperly, or interpreted without boundaries.<\/p>\n\n\n\n
They apply to Nexus Core, Nexus Network, Nexus Universe, Nexus Registry, Nexus Reports, Nexus Rails, secure data rooms, compute-to-data workflows, cyber ranges, digital twins, AI-assisted analysis, geospatial outputs, public-safe dashboards, technical demonstrations, critical application testing, public authority learning records, sponsor and provider records, finance-readiness rooms, insurance-readiness rooms, Emergency Risk Rooms, and lawful handoff records.<\/p>\n\n\n\n
The governing rule is:<\/p>\n\n\n\n
Nexus shall make security-sensitive risk governable by record, not usable for harm. Dual-use visibility shall stop where lawful use, safety, and public-safe publication cannot be preserved.<\/strong><\/p>\n\n\n\n Some information can help resilience and enable harm at the same time.<\/p>\n\n\n\n A cyber record may strengthen defensive readiness but reveal an exploitable pathway. A digital twin may improve infrastructure learning but expose critical dependencies. A geospatial map may support planning but reveal vulnerable communities, shelters, sensitive ecosystems, or defense-sensitive locations. A biosecurity scenario may support public health readiness but risk harmful operational guidance. A model release may support transparency but enable misuse. A red-team finding may strengthen defense but become an attack manual if published incorrectly.<\/p>\n\n\n\n Nexus exists to strengthen the record, not to create new harm.<\/p>\n\n\n\n This layer ensures that security-sensitive records are classified by risk, access-controlled, need-to-know, data-minimized, public-safe-labeled, decision-use-labeled, correction-ready, and continued through Nexus Rails only where lawful and appropriate.<\/p>\n\n\n\n Dual-Use and Security-Sensitive Risk Controls are safety, security, and lawful-handling controls.<\/p>\n\n\n\n They may govern:<\/p>\n\n\n\n These controls may require restriction, redaction, aggregation, delay, staged access, secure handoff, competent review, withdrawal, archive, deletion where lawful and required, or exclusion from Nexus processing.<\/p>\n\n\n\n This layer is not a security certification or legal approval system.<\/p>\n\n\n\n Dual-use and security-sensitive controls should not be treated as security certification, export-control advice, sanctions advice, legal compliance opinion, public authority approval, defense authorization, classified-data authorization, procurement approval, technology approval, cybersecurity approval, biosecurity approval, investment advice, underwriting, financeability, insurability, or implementation authorization.<\/p>\n\n\n\n Nexus may make security-sensitive records more governed, restricted, redacted, reviewed, source-controlled, access-controlled, correction-ready, and lawfully handoff-ready. Nexus does not publish, transfer, demonstrate, operationalize, facilitate, or approve harmful, restricted, classified, sanctions-prohibited, export-controlled, or misuse-enabling information or technology.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Security controls make responsible handling possible. They do not certify, authorize, or approve security-sensitive activity.<\/strong><\/p>\n\n\n\n Dual-Use Review identifies whether data, models, methods, simulations, digital twins, geospatial outputs, cyber records, biosecurity records, critical infrastructure records, technical demonstrations, or public-safe reports may reasonably support both beneficial and harmful use.<\/p>\n\n\n\n Dual-use review may apply to cyber capabilities, AI systems, biological risk information, chemical or industrial hazard information, critical infrastructure exposure, geospatial sensitivity, security-sensitive logistics, crisis data, defense-sensitive context, controlled technology, export-control-sensitive materials, and sanctions-sensitive materials.<\/p>\n\n\n\n A Dual-Use Review Record should identify the item or output reviewed, beneficial use, foreseeable misuse pathway, sensitivity level, access restriction, publication restriction, redaction or aggregation requirement, competent review pathway, correction pathway, and Nexus Rails continuation status.<\/p>\n\n\n\n Dual-use review may result in internal restricted handling, redaction, aggregation, delay, secure handoff, withdrawal, archive, deletion where lawful and required, or exclusion from Nexus processing.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Dual-use review asks not only whether information is useful, but whether visibility makes it dangerous.<\/strong><\/p>\n\n\n\n Nexus does not enable offensive cyber use.<\/p>\n\n\n\n Nexus does not publish, teach, demonstrate, transfer, validate, or operationalize exploit pathways, malware techniques, credential theft methods, unauthorized access methods, evasion techniques, vulnerability exploitation instructions, target-selection methods, persistence methods, destructive cyber techniques, or other cyber capabilities designed or reasonably likely to enable misuse.<\/p>\n\n\n\n Cybersecurity records may support defensive readiness, cyber range learning, vulnerability management, resilience testing, secure disclosure, public-safe reporting, and lawful handoff only where they remain defensive, bounded, and non-operational for misuse.<\/p>\n\n\n\n A Cyber Offensive-Use Prohibition Record should identify the cyber-sensitive material, misuse pathway, restriction applied, disclosure pathway where applicable, competent actor for handoff, publication prohibition, correction or withdrawal requirement, and archive or deletion condition.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Nexus may strengthen defensive cyber readiness. Nexus shall not enable offensive cyber use.<\/strong><\/p>\n\n\n\n Biosecurity Review applies to records, data, models, scenarios, simulations, public health records, pathogen-related information, laboratory-related information, health-system stress records, supply-chain records, and public-safe reports that could create biological misuse, exposure, panic, or harmful operational guidance.<\/p>\n\n\n\n Biosecurity Review should consider dual-use biological risk, harmful protocol risk, pathogen or toxin sensitivity, laboratory safety implications, public health misinformation risk, privacy and health data sensitivity, crisis communication risk, public authority boundary, publication restriction, and lawful handoff pathway.<\/p>\n\n\n\n A Biosecurity Review Record should identify the biological or public health issue, sensitivity level, data category, misuse pathway, restriction applied, public-safe reporting limit, public health authority boundary, secure handoff condition, correction pathway, and continuation status.<\/p>\n\n\n\n Nexus does not provide harmful biological instructions, pathogen handling guidance, weaponization information, laboratory protocols enabling misuse, public health orders, clinical advice, disease determinations, or biosurveillance authority unless separately and lawfully authorized within a safe and competent scope.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Biosecurity review protects public health by preventing useful records from becoming harmful instructions.<\/strong><\/p>\n\n\n\n Critical Infrastructure Disclosure Limits prevent Nexus outputs from exposing vulnerabilities, dependencies, locations, operating details, security controls, failure modes, cyber weaknesses, physical access points, recovery weaknesses, or cascading failure pathways in ways that could enable harm.<\/p>\n\n\n\n A Critical Infrastructure Disclosure Limit Record should identify the infrastructure function, sensitive information category, harm pathway, owner or operator boundary, public authority boundary, security classification or sensitivity, redaction or aggregation requirement, publication restriction, secure handoff pathway, and correction pathway.<\/p>\n\n\n\n Critical infrastructure records may be public-safe only where they are aggregated, redacted, delayed, generalized, or otherwise bounded to avoid operational misuse.<\/p>\n\n\n\n Nexus does not publish operational vulnerabilities, exploit paths, sensitive facility details, security arrangements, real-time dependency weaknesses, or other information that could compromise critical infrastructure.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Critical infrastructure records must protect the infrastructure they describe.<\/strong><\/p>\n\n\n\n Geospatial Sensitivity Controls govern maps, coordinates, satellite imagery, digital twins, location layers, dashboards, mobility records, biodiversity locations, infrastructure locations, conflict-sensitive locations, shelter locations, community locations, and other spatial outputs.<\/p>\n\n\n\n Geospatial sensitivity may arise from critical infrastructure, vulnerable communities, displaced populations, shelters and protection sites, health facilities, water sources, sensitive species and habitats, cultural and Indigenous sites, military or defense-sensitive areas, conflict-sensitive areas, and operational logistics.<\/p>\n\n\n\n A Geospatial Sensitivity Control Record should identify the geospatial output, sensitivity category, precision level, exposure or harm pathway, redaction, aggregation, masking, or delay requirement, publication limit, access restriction, correction pathway, secure handoff condition, and continuation status.<\/p>\n\n\n\n Nexus does not publish precise geospatial information where public release could expose people, critical infrastructure, sensitive ecosystems, protected sites, cultural heritage, defense-sensitive locations, or crisis operations to harm.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Geospatial detail shall decrease as harm risk increases.<\/strong><\/p>\n\n\n\n Sanctions Screening identifies sanctions-sensitive actors, jurisdictions, transactions, technologies, data access, funding sources, sponsorships, provider relationships, partnership pathways, handoff pathways, and controlled interactions.<\/p>\n\n\n\n A Sanctions Screening Record should identify the actor, entity, jurisdiction, or activity screened where appropriate, screening purpose, sanctions-sensitive issue where applicable, source of concern, restriction or escalation requirement, data access condition, funding or participation condition, correction pathway, and archive or continuation status.<\/p>\n\n\n\n Nexus does not provide sanctions legal advice, sanctions determinations, enforcement findings, circumvention guidance, or authorization for restricted dealings.<\/p>\n\n\n\n Where sanctions risk is material, the activity should be paused, restricted, refused, escalated, corrected, withdrawn, archived, or routed to competent legal and compliance review.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Sanctions-sensitive activity stops at the boundary of lawful participation, transfer, funding, and access.<\/strong><\/p>\n\n\n\n Export-Control Screening identifies whether technologies, software, models, datasets, technical assistance, compute access, cybersecurity materials, AI systems, geospatial outputs, research outputs, or controlled know-how may be subject to export-control or technology-transfer restrictions.<\/p>\n\n\n\n An Export-Control Screening Record should identify the item or activity, technology or data category, jurisdictional sensitivity where known, recipient or participant sensitivity where applicable, transfer condition, publication restriction, legal review trigger, public-safe output condition, correction pathway, and continuation status.<\/p>\n\n\n\n Nexus does not provide export-control legal advice, authorize controlled exports, approve restricted technology sharing, evade controls, facilitate prohibited access, or transfer controlled technology unless lawful authority and competent review exist.<\/p>\n\n\n\n Where export-control sensitivity is material, activity should be paused, restricted, escalated, corrected, withdrawn, archived, or routed to competent legal and compliance review.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Controlled technology and data shall not move through Nexus unless lawful transfer boundaries are satisfied.<\/strong><\/p>\n\n\n\n Model Release Controls govern the release, publication, sharing, demonstration, deployment, access, documentation, weights, prompts, workflows, APIs, outputs, benchmarks, evaluations, and derived artifacts of AI systems, simulations, digital twins, cyber models, biosecurity models, infrastructure models, and crisis models.<\/p>\n\n\n\n A Model Release Control Record should identify the model or system, release purpose, capability level, misuse risk, data sensitivity, evaluation status, red-team or safety review status, access condition, publication condition, correction or recall pathway, and Nexus Rails continuation status.<\/p>\n\n\n\n Model release may be unrestricted, restricted, staged, redacted, access-controlled, delayed, withdrawn, deprecated, recalled, archived, or prohibited depending on risk.<\/p>\n\n\n\n Nexus should not release models or outputs that reasonably enable offensive cyber use, biological misuse, critical infrastructure compromise, harmful targeting, sanctions evasion, surveillance abuse, or other material harm.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n A model shall not be released merely because it works; it shall be released only where use can remain lawful, safe, and bounded.<\/strong><\/p>\n\n\n\n Red-Team Boundaries define how adversarial testing, misuse testing, vulnerability testing, model-risk testing, cyber range exercises, crisis misinformation testing, dual-use review, and safety evaluation may occur without becoming harmful instruction, unauthorized testing, offensive activity, or public exposure.<\/p>\n\n\n\n A Red-Team Boundary Record should identify the test purpose, system or model tested, authorization basis, scope, prohibited actions, data restrictions, safety controls, reporting path, disclosure limits, correction pathway, and continuation status.<\/p>\n\n\n\n Red-team activity should be scoped, authorized, logged, supervised where appropriate, non-destructive, legally bounded, and restricted from public release where methods could enable misuse.<\/p>\n\n\n\n Red-team activity should not include unauthorized access, real-world exploitation, harmful payloads, destructive testing, social engineering outside scope, target harassment, operational disruption, or misuse-enabling publication.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Red-teaming tests safeguards inside boundaries; it does not create permission for harmful conduct.<\/strong><\/p>\n\n\n\n Red-Team and Blue-Team Workflow Controls govern the interaction between adversarial testing teams and defensive response teams in Nexus cyber ranges, model-risk reviews, technical verification workflows, critical application tests, and security-sensitive simulations.<\/p>\n\n\n\n A Workflow Control Record should identify the workflow purpose, red-team role, blue-team role, authorization basis, test scope, logging requirements, escalation trigger, secure disclosure pathway, remediation pathway, public-safe reporting boundary, and correction pathway.<\/p>\n\n\n\n Red-team findings should be routed to blue-team remediation or competent disclosure channels without public exposure of actionable misuse details.<\/p>\n\n\n\n Blue-team records should document remediation, residual risk, verification status, restricted publication limits, and Nexus Rails continuation.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Red-team findings must strengthen blue-team defense, not become public instructions for attack.<\/strong><\/p>\n\n\n\n Misuse Reporting provides a governed pathway for identifying, recording, escalating, correcting, and responding to suspected misuse of Nexus records, models, data, dashboards, methods, reports, events, rooms, interfaces, partner references, sponsor references, provider outputs, or public-safe materials.<\/p>\n\n\n\n A Misuse Reporting Record should identify the suspected misuse, affected record or output, actor category where appropriate, harm pathway, evidence status, immediate restriction required, escalation pathway, correction or withdrawal action, secure disclosure or referral condition, and continuation status.<\/p>\n\n\n\n Misuse reporting should protect reporters from retaliation where possible and appropriate, preserve confidentiality where required, and avoid public amplification of harmful methods or claims.<\/p>\n\n\n\n Confirmed or credible misuse may trigger suspension, access restriction, output withdrawal, public correction, secure disclosure, archive, legal review, or referral to competent processes.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Misuse must be reportable before harm becomes normalized.<\/strong><\/p>\n\n\n\n Secure Disclosure governs the controlled communication of vulnerabilities, sensitive findings, restricted data issues, dual-use risks, model-risk findings, biosecurity concerns, critical infrastructure concerns, sanctions concerns, export-control concerns, or security-sensitive issues to competent actors.<\/p>\n\n\n\n A Secure Disclosure Record should identify the issue disclosed, recipient or actor category, disclosure basis, sensitivity level, information shared, information withheld, timing, confidentiality condition, remediation or response expectation, correction pathway, and continuation status.<\/p>\n\n\n\n Secure disclosure should avoid public release of exploit details, sensitive locations, personal data, operational weaknesses, controlled technology, classified material, or sanctions-prohibited information.<\/p>\n\n\n\n Secure disclosure does not imply that Nexus has enforcement authority, regulatory authority, cybersecurity certification authority, public authority status, defense authority, or emergency command authority.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Sensitive findings shall move through secure disclosure, not public exposure.<\/strong><\/p>\n\n\n\n Restricted Data Handling applies to data that is sensitive by law, contract, source condition, security risk, privacy risk, public authority status, humanitarian sensitivity, commercial sensitivity, export-control sensitivity, sanctions sensitivity, defense sensitivity, classified status, or dual-use risk.<\/p>\n\n\n\n A Restricted Data Handling Record should identify the restricted data category, restriction basis, data steward, lawful access basis, access controls, processing environment, sharing limits, retention and deletion requirements, public-safe output conditions, incident pathway, correction pathway, and continuation status.<\/p>\n\n\n\n Restricted data should not be copied, exported, published, reused, modeled, visualized, shared, or handed off outside the governing restriction.<\/p>\n\n\n\n Where restrictions cannot be satisfied, the data should be excluded, deleted where required, returned where appropriate, or maintained only in lawful secure custody.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Restricted data remains restricted even when it enters Nexus systems.<\/strong><\/p>\n\n\n\n Defense-sensitive data is excluded from Nexus systems, rooms, models, reports, dashboards, demonstrations, and public-safe outputs unless a separate lawful authorization, competent review, defined scope, and secure handling framework exist.<\/p>\n\n\n\n Defense-sensitive data may include military locations, operational plans, defense infrastructure, force protection information, weapons systems, classified-adjacent materials, sensitive logistics, targeting-sensitive data, intelligence-sensitive material, and other security-sensitive defense information.<\/p>\n\n\n\n A Defense-Sensitive Data Exclusion Record should identify the data category, sensitivity basis, exclusion decision, lawful authorization status, secure handling condition if authorized, publication prohibition, correction pathway, and archive or deletion condition.<\/p>\n\n\n\n Nexus does not seek, process, publish, transfer, analyze, demonstrate, or retain defense-sensitive data unless lawful authorization and competent safeguards exist.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Defense-sensitive data is excluded by default unless lawful authorization and secure handling are established.<\/strong><\/p>\n\n\n\n Classified data is excluded from Nexus systems, rooms, models, reports, dashboards, demonstrations, and public-safe outputs unless a separate lawful authorization, competent facility, cleared personnel where required, defined scope, and secure handling framework exist.<\/p>\n\n\n\n A Classified Data Exclusion Record should identify the classification concern, source condition, exclusion decision, lawful authorization status, secure handling condition if authorized, publication prohibition, incident or return pathway, and correction, archive, or deletion condition.<\/p>\n\n\n\n Nexus does not solicit, receive, process, store, summarize, publish, transfer, or retain classified data outside lawful and competent handling conditions.<\/p>\n\n\n\n If classified data is inadvertently received, Nexus should restrict access, stop processing, preserve necessary incident records, notify competent channels where appropriate, and follow lawful return, deletion, or secure handling instructions.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Classified data is not a Nexus input unless lawful classification handling authority exists.<\/strong><\/p>\n\n\n\n Sanctions-prohibited data, technology, services, access, funding, participation, or transfer should be excluded from Nexus systems, rooms, models, reports, dashboards, demonstrations, and handoff pathways.<\/p>\n\n\n\n A Sanctions-Prohibited Data Exclusion Record should identify the prohibited or restricted issue, actor, jurisdiction, item, or activity category where appropriate, exclusion basis, access restriction, transfer restriction, processing restriction, escalation pathway, correction, archive, or deletion condition.<\/p>\n\n\n\n Nexus should not process, transfer, publish, provide access to, or benefit from sanctions-prohibited data or activity.<\/p>\n\n\n\n Where sanctions-prohibited exposure is identified, the related activity should be paused, refused, restricted, escalated, corrected, withdrawn, archived, deleted where required, or routed to competent legal and compliance review.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Sanctions-prohibited data and activity shall not enter, remain in, or move through Nexus.<\/strong><\/p>\n\n\n\n Controlled Technology Handling governs any technology, software, model, dataset, technical assistance, compute access, cybersecurity material, AI system, geospatial output, research output, or know-how that may be subject to export-control, sanctions, defense, security, contractual, or lawful transfer restrictions.<\/p>\n\n\n\n A Controlled Technology Handling Record should identify the technology or item, control basis, permitted users, permitted geography or transfer conditions where applicable, access controls, sharing limits, demonstration limits, publication limits, legal review trigger, correction pathway, and continuation status.<\/p>\n\n\n\n Controlled technology should not be publicly released, transferred, exported, demonstrated, embedded, reused, or handed off unless lawful use and transfer conditions are satisfied.<\/p>\n\n\n\n Where controlled technology status is uncertain, Nexus should pause release or transfer until competent review determines the lawful handling condition.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Controlled technology may support readiness only within lawful handling, access, and transfer boundaries.<\/strong><\/p>\n\n\n\n Security Review Before Publication applies before releasing public-safe reports, dashboards, maps, digital twin outputs, model outputs, cyber records, biosecurity records, infrastructure exposure records, geospatial outputs, crisis records, sponsor materials, provider demonstrations, or technical publications that may contain security-sensitive information.<\/p>\n\n\n\n A Security Review Before Publication Record should identify the output proposed for publication, source records, security-sensitive content, dual-use concern, cyber concern, biosecurity concern, geospatial concern, critical infrastructure concern, sanctions or export-control concern, redaction or aggregation requirement, publication decision, and correction or withdrawal pathway.<\/p>\n\n\n\n Publication may proceed only where security-sensitive content has been reviewed, bounded, redacted, aggregated, delayed, restricted, or excluded as required.<\/p>\n\n\n\n Where security risk remains unresolved, publication should be refused, delayed, restricted, securely handed off, archived, or reworked.<\/p>\n\n\n\n The rule is:<\/p>\n\n\n\n Security-sensitive outputs shall be reviewed before publication, not corrected only after harm.<\/strong><\/p>\n\n\n\n Dual-Use and Security-Sensitive Risk Controls protect Nexus from misuse-enabling publication, offensive cyber enablement, biosecurity harm, critical infrastructure exposure, geospatial harm, sanctions exposure, export-control breaches, unsafe model release, unauthorized red-teaming, public exposure of sensitive findings, restricted data misuse, defense-sensitive data handling failures, classified data mishandling, controlled technology leakage, and security review failures.<\/p>\n\n\n\n They prevent:<\/p>\n\n\n\n They also protect legitimate security-sensitive readiness. They allow Nexus to support defensive learning, secure data handling, lawful review, secure disclosure, controlled access, public-safe reporting, and Nexus Rails continuation without making sensitive records usable for harm.<\/p>\n\n\n\n They are Nexus safeguards for identifying, restricting, reviewing, correcting, excluding, and lawfully handling records, data, models, outputs, demonstrations, and publications that could create cyber, biosecurity, infrastructure, geospatial, sanctions, export-control, defense, classified, or misuse risk.<\/p>\n\n\n\n No. They are not security certification, export-control advice, sanctions advice, legal compliance opinions, public authority approval, defense authorization, classified-data authorization, procurement approval, technology approval, cybersecurity approval, biosecurity approval, investment advice, underwriting, financeability, insurability, or implementation authorization.<\/p>\n\n\n\n Dual-use review asks whether a record, model, method, output, map, digital twin, cyber record, biosecurity record, infrastructure record, technical demonstration, or public-safe report may support both beneficial and harmful use.<\/p>\n\n\n\n Not where publication would enable misuse. Nexus may support defensive readiness, secure disclosure, vulnerability management, cyber range learning, and lawful handoff, but it does not publish exploit pathways, malware techniques, unauthorized access methods, or misuse-enabling instructions.<\/p>\n\n\n\n Yes, but geospatial sensitivity controls apply. Precision should decrease as harm risk increases, and precise location data should not be published where it could expose people, infrastructure, ecosystems, protected sites, cultural heritage, defense-sensitive locations, or crisis operations to harm.<\/p>\n\n\n\n Not by default. Defense-sensitive and classified data are excluded unless lawful authorization, competent review, defined scope, and secure handling conditions exist.<\/p>\n\n\n\n The activity should be paused, restricted, refused, escalated, corrected, withdrawn, archived, or routed to competent legal and compliance review. Nexus does not provide sanctions or export-control legal advice.<\/p>\n\n\n\n Model release controls govern whether AI systems, simulations, digital twins, cyber models, biosecurity models, infrastructure models, crisis models, outputs, APIs, workflows, documentation, or derived artifacts can be released, restricted, staged, withdrawn, deprecated, recalled, archived, or prohibited.<\/p>\n\n\n\n Secure disclosure is the controlled communication of vulnerabilities, sensitive findings, restricted data issues, dual-use risks, model-risk findings, biosecurity concerns, critical infrastructure concerns, sanctions concerns, export-control concerns, or other sensitive issues to competent actors without public exposure.<\/p>\n\n\n\n The core boundary is that Nexus makes security-sensitive risk governable by record, not usable for harm. Dual-use visibility stops where lawful use, safety, and public-safe publication cannot be preserved.<\/p>\n\n\n\n Dual-Use and Security-Sensitive Risk Controls protect Nexus from turning useful records into harmful capability.<\/p>\n\n\n\n They govern dual-use review, cyber offensive-use prohibition, biosecurity review, critical infrastructure disclosure limits, geospatial sensitivity, sanctions screening, export-control screening, model release, red-team and blue-team workflows, misuse reporting, secure disclosure, restricted data, defense-sensitive data, classified data, sanctions-prohibited data, controlled technology, and security review before publication.<\/p>\n\n\n\n Their core discipline is simple: Nexus may govern security-sensitive risk by record. It shall not publish, transfer, demonstrate, operationalize, facilitate, or approve information or technology where lawful use, safety, and public-safe publication cannot be preserved.<\/p>\n","protected":false},"excerpt":{"rendered":" Dual-Use and Security-Sensitive Risk Controls are the Nexus safeguard architecture for identifying, restricting, reviewing, correcting, excluding, and lawfully handling dual-use, cybersecurity, biosecurity, critical infrastructure, geospatial, sanctions-sensitive, export-control-sensitive, model-release, red-team, blue-team, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","template":"","meta":{"give_campaign_id":0,"inline_featured_image":false,"footnotes":""},"kbtopic":[552],"kbtag":[],"mkb_version":[576],"class_list":["post-13426","kb","type-kb","status-publish","hentry","kbtopic-safeguards","mkb_version-1-0-0-1"],"_links":{"self":[{"href":"https:\/\/therisk.global\/nexus-campaigns\/wp-json\/wp\/v2\/kb\/13426","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/therisk.global\/nexus-campaigns\/wp-json\/wp\/v2\/kb"}],"about":[{"href":"https:\/\/therisk.global\/nexus-campaigns\/wp-json\/wp\/v2\/types\/kb"}],"author":[{"embeddable":true,"href":"https:\/\/therisk.global\/nexus-campaigns\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/therisk.global\/nexus-campaigns\/wp-json\/wp\/v2\/comments?post=13426"}],"version-history":[{"count":0,"href":"https:\/\/therisk.global\/nexus-campaigns\/wp-json\/wp\/v2\/kb\/13426\/revisions"}],"wp:attachment":[{"href":"https:\/\/therisk.global\/nexus-campaigns\/wp-json\/wp\/v2\/media?parent=13426"}],"wp:term":[{"taxonomy":"kbtopic","embeddable":true,"href":"https:\/\/therisk.global\/nexus-campaigns\/wp-json\/wp\/v2\/kbtopic?post=13426"},{"taxonomy":"kbtag","embeddable":true,"href":"https:\/\/therisk.global\/nexus-campaigns\/wp-json\/wp\/v2\/kbtag?post=13426"},{"taxonomy":"mkb_version","embeddable":true,"href":"https:\/\/therisk.global\/nexus-campaigns\/wp-json\/wp\/v2\/mkb_version?post=13426"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Why Dual-Use and Security-Sensitive Controls Matter<\/h2>\n\n\n\n
What This Layer Is<\/h2>\n\n\n\n
\n
What This Layer Is Not<\/h2>\n\n\n\n
Dual-Use Review<\/h2>\n\n\n\n
Cyber Offensive-Use Prohibition<\/h2>\n\n\n\n
Biosecurity Review<\/h2>\n\n\n\n
Critical Infrastructure Disclosure Limits<\/h2>\n\n\n\n
Geospatial Sensitivity Controls<\/h2>\n\n\n\n
Sanctions Screening<\/h2>\n\n\n\n
Export-Control Screening<\/h2>\n\n\n\n
Model Release Controls<\/h2>\n\n\n\n
Red-Team Boundaries<\/h2>\n\n\n\n
Red-Team and Blue-Team Workflow Controls<\/h2>\n\n\n\n
Misuse Reporting<\/h2>\n\n\n\n
Secure Disclosure<\/h2>\n\n\n\n
Restricted Data Handling<\/h2>\n\n\n\n
Defense-Sensitive Data Exclusion Unless Lawfully Authorized<\/h2>\n\n\n\n
Classified Data Exclusion Unless Lawfully Authorized<\/h2>\n\n\n\n
Sanctions-Prohibited Data Exclusion<\/h2>\n\n\n\n
Controlled Technology Handling<\/h2>\n\n\n\n
Security Review Before Publication<\/h2>\n\n\n\n
What Dual-Use and Security-Sensitive Risk Controls Protect<\/h2>\n\n\n\n
\n
Frequently Asked Questions<\/h2>\n\n\n\n
What are Dual-Use and Security-Sensitive Risk Controls?<\/h3>\n\n\n\n
Are these controls security certification?<\/h3>\n\n\n\n
What is dual-use review?<\/h3>\n\n\n\n
Can Nexus publish cyber vulnerability details?<\/h3>\n\n\n\n
Can Nexus use geospatial data?<\/h3>\n\n\n\n
Can Nexus handle classified or defense-sensitive data?<\/h3>\n\n\n\n
What happens if sanctions or export-control risk appears?<\/h3>\n\n\n\n
What are model release controls?<\/h3>\n\n\n\n
What is secure disclosure?<\/h3>\n\n\n\n
What is the core boundary?<\/h3>\n\n\n\n
Key Takeaway<\/h2>\n\n\n\n