Review our security policies, how QuantumSentinel handles scan data, and the protocol questions that remain open.
Policy baseline v1 · Published 15 September 2026
Information security
Security policies
These requirements apply to Dytallix personnel and contractors who access company-managed systems or customer assessment data. They state the policy baseline, not an independent assessment of control effectiveness.
01Access controlLimit access to the people and systems that need it.
Use individual accounts and grant the minimum access required for the task. Require approval for administrative access.
Require multi-factor authentication for administrative services where supported. Record an exception and compensating controls where it is unavailable.
Review access after role changes. Remove access when work ends. Keep credentials out of source code, tickets, and public messages.
02Data classification and handlingCollect only the information needed for the agreed purpose.
Classify information as public, internal, confidential, or restricted. Treat credentials, private keys, and sensitive customer records as restricted.
Use approved transfer and storage methods for confidential or restricted information. Define authorized recipients, retention, and deletion before accepting customer assessment data.
Do not submit restricted information to public scanners, public issue trackers, or unapproved external tools.
03Encryption and key managementProtect confidential data and control access to keys.
Use approved encryption for confidential or restricted information in transit and at rest. Record the protection required for each service and dataset.
Restrict access to keys and credentials. Define storage, rotation, recovery, and revocation requirements. Separate key access from data access where practical.
Document the algorithm and configuration used by each product. Verify implementation claims against the deployed version.
04Device securityProtect devices used to access company systems.
Use supported operating systems, security updates, screen locks, and device encryption for devices that handle confidential information.
Use approved software and restrict administrative privileges. Report lost devices or suspected compromise promptly.
Remove company access and data when a device is retired or its authorized use ends.
05Secure development and changesKeep changes traceable and reversible.
Record changes in version control. Review changes to security controls, data flows, and dependencies before release.
Test the affected behavior. Separate test data from customer data and retain a recovery or rollback method for deployments.
Record release scope and unresolved limitations. Do not describe an algorithm standard as product certification.
06Vulnerability managementPrioritize issues by exposure and impact.
Track reported vulnerabilities and affected components. Assign an owner and assess severity, exposure, and customer impact.
Prioritize active exploitation and exposed critical issues. Record mitigation, repair, verification, and any accepted residual risk.
Review dependencies and deployment changes for known security issues. Keep sensitive findings in private channels until disclosure is coordinated.
07Incident responseContain incidents and preserve the evidence needed to resolve them.
Report suspected incidents to Dytallix leadership. Record the affected systems, event times, available evidence, and response owner.
Limit further exposure, preserve relevant evidence, and restore affected services through controlled changes.
Assess notification duties under applicable agreements and law. Record corrective actions after the incident. Use response times agreed for the affected service.
08Continuity and recoveryDefine recovery needs for each service.
Identify critical services, dependencies, and responsible owners. Set recovery requirements before making customer availability commitments.
Protect required backups from unauthorized access. Define retention and test restoration for services that depend on stored data.
Keep recovery instructions current. Temporary browser keys and testnet assets are not a substitute for a customer recovery plan.
09Supplier and service reviewReview external services before sharing protected information.
Identify the provider, data purpose, access, processing location, and retention requirements.
Review security terms and data handling before using a provider for confidential or restricted data. Record material changes and exceptions.
Do not treat a supplier's assurance report as assurance for the Dytallix product or deployment.
10People and policy reviewAssign responsibility and review exceptions.
Require personnel and contractors to follow the policies that apply to their access and work. Explain how to report security concerns.
Dytallix leadership owns this policy baseline. Review it at least annually and after material service changes or incidents.
Record policy exceptions with an owner, reason, compensating controls, and review date. Confirm implementation evidence for customer-specific requirements.
QuantumSentinel · Alpha
Scan data handling
These notes cover the public tool at /quantumsentinel. Separately installed software and private engagements can use different storage settings. Scan only assets you own or have permission to assess.
Website
Public connection checks
Input
The submitted domain and your authorization confirmation.
Processing
The hosted service checks the public TLS connection. Results describe observed protocol, cipher, key exchange, and certificate information. It does not crawl pages or inspect stored data.
Result handling
The public endpoint returns the result to your browser. It does not write that result to the application's scan-history store.
Repository
Public GitHub code
Input
A public GitHub repository address and your authorization confirmation. No private repository credentials are requested.
Processing
The hosted service makes a temporary checkout and matches cryptographic references in supported text files. It does not execute the submitted code. Limits: 1,000 files, 512 KB per file, and 10 MB of scanned text.
Result handling
The scanner removes its temporary checkout when the scan completes or handles an error. Findings returned to your browser can contain file paths, line numbers, and code excerpts. The public endpoint does not save a scan-history record.
File
One text file
Input
The filename, text content, and your authorization confirmation. Maximum size: 512 KB. Binary files are not supported.
Processing
The hosted scanner processes the text in memory. It uses pattern matching and does not execute the file.
Result handling
The scanner returns findings and code excerpts to your browser without writing the file or result to its application store. Hosting infrastructure can temporarily buffer the request. Do not upload passwords, private keys, customer records, or confidential code.
Network
An approved local connector
Input
A one-time session code and a network scope approved on your computer. A browser cannot inspect your private network directly.
Processing
The connector runs on your computer. It sends the approved scope, responding addresses, service observations, and scan summary to Dytallix. It does not upload application files or private keys.
Result handling
The service holds results in memory. Access requires a session token and expires 15 minutes after session creation. Expired records are cleared on subsequent session activity or when the service restarts. Closing the browser does not immediately delete the server session.
Results and limits
Results appear in the browser as findings, evidence, recommended actions, and coverage limits. Website, repository, and file scans include readiness scores. The public tool does not provide a downloadable cryptographic bill of materials or report export. A result is not a certification or a complete assessment.
Hosting and logs
The public scanner runs on Hetzner infrastructure. Browser requests use HTTPS. Repository scans fetch public code from GitHub. Web server logs record request metadata, such as IP addresses, request paths, timestamps, and response status. Log retention is separate from temporary scan data.
Retention and requests
Do not treat this service as a zero-retention system. Web access logging is configured for daily rotation and 14 retained rotated files. This does not define retention for support messages, backups, or all service logs. Send data access or deletion requests to privacy@dytallix.com. Include the scan type, approximate time, and scan ID if available. Do not include tokens or secrets.
Before sensitive work
Agree the scope, authorized recipients, processing location, and retention terms before sharing confidential assessment evidence. Public scans do not require private repository access or customer records. Read the privacy policy and terms of use.
Published research
Open problems
The following questions are published on our Open Research page. They concern the Dytallix protocol. They are not QuantumSentinel scan findings or proof that a deployment is ready for production.
Cryptography
Leader Selection
Dytallix uses a practical stand-in for leader selection randomness instead of a formally standardized PQC verifiable random function. Replacement with a standardized construction remains future work.
Cryptography
Timing-Safe Signing
The signing path includes timing-leak controls. It has not completed a formal side-channel review across deployment environments. A constant-time review remains part of the pre-mainnet security track.
Consensus
Signature Compression
PQC signatures are larger than many classical signatures. The current checkpoint-proof compression does not have the efficiency of a true aggregate signature system.
Networking
PQC Handshake
The PQC handshake design follows an established secure pattern. The exact construction has not completed formal verification in symbolic or computational models.
Protocol design
Randomness Beacon
Epoch randomness currently comes from chain activity. A dedicated randomness beacon would improve unpredictability. Its final architecture remains open.
Send the affected product and version, an issue summary, observed impact, and the minimum steps needed to reproduce it. Include your contact details and credit preference.
Do not access other users' data, disrupt services, or publish sensitive evidence. This page does not authorize testing outside systems you own or have permission to assess.
Contact Dytallix
Send an initial report to hello@dytallix.com. Ask for a secure transfer method before sending sensitive evidence. Remove passwords, private keys, customer records, and session tokens.
For a security questionnaire, send the product, deployment scope, and required evidence to hello@dytallix.com. Evidence must match the reviewed product and release.
