Data Governance & Sovereignty What Cyber Crucible collects and never collects, how data is protected in transit, where it is processed, what can be disclosed under legal process, and how supply chain and insider risk are controlled. What data does Cyber Crucible collect — and what does it never collect? Short answer: Cyber Crucible operates under a Zero-Content Harvesting directive. It processes system operational telemetry — process execution paths, parent-child process chains, hardware execution indicators, and memory integrity states — analyzed locally on the endpoint. It does not collect, transmit, store, or process encryption keys, credentials, session tokens, or your files. Strictly excluded categories Cyber Crucible software does not collect, transmit, store, or process: Cryptographic variables — private keys, decryption keys, and application encryption keys. User credentials — user passwords, Active Directory secrets, and API private keys. Session identifiers — OAuth tokens, access tokens, refresh tokens, and session cookies. Customer content data — proprietary files, documents, database contents, email bodies, and user communications. Why full protection doesn't require harvesting content Full capability of the threat prevention software is achieved without harvesting or exfiltrating private customer content. The behavioral engine evaluates what a program is doing — which processes are reaching where, having done what beforehand — and none of that requires opening the file or reading the secret. This is the same principle behind identity protection: access is traced and analyzed without the credential itself being accessed. Where analysis happens Process execution paths, process lineage, hardware execution indicators, and memory integrity states are analyzed locally on the endpoint . Where cloud-assisted or centralized management is enabled, outbound administrative telemetry is limited strictly to the operational indicators needed for system health monitoring and security reporting. What is the difference between system telemetry and customer data? Short answer: System telemetry describes how software is behaving — which process started which, what memory looks like, whether execution patterns are anomalous. Customer data is the content your business creates and holds — files, emails, database records, credentials. Cyber Crucible analyzes the first and never collects the second. A useful way to think about it Telemetry is metadata about machine behavior . Content is the information itself . Knowing that process A spawned process B , which then attempted to read a browser credential store while showing signs of in-memory modification, is enough to identify an attack. Reading what was in that credential store is not required — and Cyber Crucible does not do it. What this means practically Behavioral analysis is performed on identity access without processing the identity information itself . Telemetry that does leave the endpoint in cloud-assisted deployments is limited to operational indicators for health monitoring and security reporting. Technical and behavioral metadata is treated as personal data only where it can directly or indirectly identify an individual — and in those cases identifiers are pseudonymized or masked. Customer control Telemetry sources are configurable. Organizations can tailor which sources are gathered, so no unnecessary information is acquired. Fields that aren't essential to threat detection are excluded or discarded. Does Cyber Crucible sell or share customer data with third parties? Short answer: No. Cyber Crucible does not share, license, trade, or disclose customer information or telemetry to any third party, and customer data is strictly not for sale under any circumstances. The commitments Zero third-party sharing — no sharing, licensing, trading, or disclosure of customer information or telemetry to any third party. Commercial monetization prohibition — customer data is not for sale, under any circumstances. No data brokering of identity or telemetry — not traded, licensed, or monetized with any party. Why this is architecturally credible Plenty of vendors make a no-selling promise. What makes this one different is that much of the sensitive material simply isn't collected in the first place. A company that never holds your decryption keys, credentials, or files has nothing in those categories to sell, share, or lose — regardless of policy. Policy can change. Architecture is harder to reverse. See also: "What can Cyber Crucible disclose if compelled by a government or court?" What can Cyber Crucible disclose if compelled by a government or court? Short answer: Nothing in the categories that matter most, because it never holds them. Cyber Crucible does not harvest, store, or retain decryption keys, user credentials, or customer files — so there is nothing of that kind to produce to any private party, government, or foreign power. Like any U.S. company it remains subject to applicable law, but it cannot produce data it never holds. "Nothing to disclose by design" This is a deliberate architectural position rather than a legal promise. Legal process can compel a company to hand over what it has. It cannot compel a company to produce what was never collected. Because Cyber Crucible does not collect or retain encryption keys, credentials, or private content, those categories are empty by design. Why this matters more than it used to Centralized security architectures create a high-value aggregation point. A vendor holding thousands of customers' keys and session tokens is a target for criminal and state-sponsored attackers alike — and can be reached through legal compulsion, sometimes without the customer's knowledge. Cyber Crucible's position on key escrow follows the same reasoning: it deliberately does not maintain a central key store, so there is no single point of failure to breach or subpoena. An honest boundary Cyber Crucible is a U.S. company and is subject to U.S. law. The claim here is narrow and specific: it cannot disclose data it does not hold. That is a statement about architecture, not a claim of immunity from legal process. How is Cyber Crucible data protected in transit? Short answer: All agent-to-server communications enforce TLS 1.3. Operational data payloads additionally use JSON Web Encryption (JWE) with unique per-agent cryptographic key pairs, so payloads cannot be intercepted or manipulated in transit. Administrative access requires key-based authentication plus OAuth 2.0 token validation. The layers Encrypted channels — all agent-to-server communication enforces TLS 1.3. Per-agent payload encryption — operational payloads use JWE with unique per-agent key pairs. Because each agent has its own key pair, compromising one transit circuit does not expose others, and inline interception or manipulation is prevented. Authenticated administration — system access requires individual key-based user authentication and OAuth 2.0 token validation, restricting administrative actions to authorized personnel. Why per-agent keys matter Transport encryption alone protects the channel. Per-agent payload encryption protects the content of the message independently of the channel — so an attacker positioned inline, or a compromised intermediary, still cannot read or alter what the agent sent. Shared infrastructure Where public or virtual private cloud environments are used for backend administration, Cyber Crucible applies strict logical tenant isolation together with end-to-end payload encryption. Cloud providers and infrastructure operators have zero visibility into operational data payloads or customer system states. Where is my data processed, and can it stay inside my country? Short answer: Yes. Cyber Crucible infrastructure can be staged so processing occurs geographically close to or within your legal jurisdiction, and a fully on-premises air-gapped deployment keeps everything inside your own network boundary with zero outbound telemetry. Sovereign staging Infrastructure can be positioned to keep processing within — or geographically near — the customer's legal jurisdiction. This is designed to support compliance with data residency mandates including the EU General Data Protection Regulation (GDPR), Saudi Arabia's Personal Data Protection Law (PDPL), UAE Federal Decree-Law No. 45/2021, and the Kenya Data Protection Act. The strongest option For organizations requiring total isolation, the on-premises model runs all backend management software inside your own physically secured server racks. Zero telemetry and zero data leave your sovereign network boundary. Because threat evaluation and process interdiction happen locally on the endpoint in typically under 200 milliseconds, protection does not depend on any external connection. Sovereignty costs nothing in defensive capability. See also: "What deployment models are available for data sovereignty?" What deployment models are available for data sovereignty? Short answer: Two. A fully air-gapped on-premises model where nothing leaves your network, and a hosted or hybrid cloud-assisted model with JWE-encrypted TLS communications to regionally staged servers. Both provide the same sub-200-millisecond local prevention. Comparison Sovereign On-Premises (Air-Gapped) Hosted / Hybrid Cloud-Assisted Data transit boundary 100% contained within customer physically secured server racks JWE-encrypted TLS communications to regional application servers Cross-border flow Zero external network flow; zero outbound telemetry Geographically localized staging to match regional boundaries Regulatory alignment Supports strict national data residency and sovereignty requirements Designed to align with global privacy directives (GDPR, PDPL, and others) Choosing between them The air-gapped model suits government, defense, critical infrastructure, and any organization under strict national residency mandates or operating disconnected environments. The hybrid model suits organizations that want centralized management and cross-fleet reporting while still keeping data within a regional boundary. Prevention is identical in both. The local Detect–Decide–Respond loop runs in the kernel on the endpoint regardless of deployment model — the difference is only where management and reporting infrastructure lives. How does Cyber Crucible manage supply chain and insider risk? Short answer: Through binding mutual NDAs for all personnel with potential access, strictly need-to-know administrative access limited to vetted staff, and a zero-tolerance mandate to isolate or immediately disengage any supplier, vendor, contractor, or employee who poses a risk to customers or their intellectual property. The controls Mandatory non-disclosure agreements — all personnel with potential access to customer operational data or management systems are legally bound by a mutual NDA prior to onboarding. Strict need-to-know access — administrative access to customer management instances is restricted exclusively to vetted personnel, and only when required to accomplish a validated business or support operation. Vendor and resource disengagement mandate — if any supplier, software vendor, contractor, or employee poses a security, privacy, or intellectual property risk to customers, Cyber Crucible actively manages and isolates that risk or disengages the resource immediately. Why insider and supply chain risk belong together Both are the same problem viewed from different angles: someone with legitimate access being the vector. Controlling it requires limiting who has access, binding them contractually, and being willing to sever a relationship quickly when risk appears — including a commercial relationship. The disengagement mandate is the part organizations most often lack. Contracts and NDAs establish obligations; the willingness to terminate a supplier immediately is what makes them meaningful. Does Cyber Crucible embed third-party libraries or foreign code? Short answer: No. Kernel sensors, drivers, and Genetic AI behavioral models are engineered in-house. No foreign state-sponsored SDKs, unverified third-party libraries, or hidden telemetry hooks are embedded in the software. Windows kernel drivers are submitted for certification under Microsoft's Windows Hardware Compatibility Program (WHCP). The engineering moat Building kernel sensors and behavioral models in-house is expensive and slow. Most vendors assemble components instead. That assembly is precisely where supply chain risk enters a security product — the tool with the deepest system privileges is also the one where an unverified dependency does the most damage. Cyber Crucible's components are proprietary and maintained internally, which removes that class of exposure rather than managing it. External validation All Windows kernel drivers undergo internal quality assurance testing and are submitted for certification under Microsoft's Windows Hardware Compatibility Program (WHCP) — independent validation of quality and tamper resistance for code running at the kernel level. No hidden telemetry There are no hidden telemetry hooks. What the software collects is documented, and the categories it never collects are explicitly enumerated. What does geopolitical neutrality mean in security software? Short answer: It means the software is built to protect your organization without embedding foreign strategic backdoors, foreign state intelligence partnerships, or mandatory cloud dependencies — so using it does not import another country's strategic interests into your infrastructure. The problem it addresses Legacy security tools often rely on centralized cloud-harvesting models that continuously exfiltrate endpoint telemetry, account details, and file system artifacts across national and geopolitical borders. That is slow against machine-speed attacks, and it creates compliance and security exposure under GDPR, Saudi PDPL, UAE Federal Decree-Law No. 45/2021, and the Kenya Data Protection Act. It also creates a question most procurement processes never ask: whose jurisdiction does my telemetry end up in, and who else can reach it there? The three components No foreign strategic backdoors — no state-sponsored code components or unverified foreign SDKs. No foreign state intelligence partnerships — customer telemetry is not shared with any third party, including governments. No mandatory cloud dependency — the software functions fully offline, so no data ever has to cross a border for the product to work. The third point is what makes the first two enforceable. A product that requires a cloud connection cannot credibly promise your data stays put.