Security
Analog Informatics Corporation publishes a Product Security Plan for AIC Server, AIC Agent, and the configurators and installers shipped with them. The plan covers secure development, release integrity, cryptography, data handling, and vulnerability disclosure.
Security by design
Security requirements are part of the design of each feature, not added after it is built. Every application programming interface (API) is designed to be authenticated, controlled by Role-Based Access Control (RBAC), rate limited, and error limited. Security events raise alerts, and specific alerts can be routed to your own event sinks, Security Information and Event Management (SIEM) systems, and trouble-ticket systems.
Our development practices follow the four practice groups of the National Institute of Standards and Technology (NIST) Special Publication 800-218, Secure Software Development Framework (SSDF). That framework is the basis of the federal Secure Software Development Attestation Form. Security features are designed to the NIST SP 800-53 Revision 5 moderate baseline.
| Practice | Status |
|---|---|
| Core components written in Rust, a memory-safe programming language, under a no-panic rule: errors are handled, logged, and recovered without crashing the service | Available now |
| Penetration testing by multiple artificial intelligence (AI) models that attack the software and repair what they find, plus manual testing with Burp Suite and other industry tools | Available now |
| Production releases digitally signed with Authenticode | Available now |
| SHA-256 checksum manifest published with every release | Available now |
| Software Bill of Materials (SBOM) in CycloneDX format inside every installer | Available now |
| Third-party components checked against published Common Vulnerabilities and Exposures (CVE) records | Available now |
| Complete open source component and license disclosure in the product | Available now |
| Security advisory feed in the product, with affected and fixed versions | Available now |
Cryptography
Federal Information Processing Standards (FIPS) 140-3 is the federal standard for cryptographic modules. We do not represent our software as certified. Our default cryptographic library is AWS-LC, which holds a FIPS 140-3 certificate, and we share that certificate on request. You can optionally use a hardware security module (HSM) or key management service (KMS) through PKCS#11. Those devices and services carry their own FIPS certification, and you confirm the certification of each one you configure.
Your data stays in your environment
AIC software runs where you install it: on premises, in an air-gapped site, in your own cloud tenancy, or in your own Azure subscription. AIC does not host your data and has no standing access to your deployment.
No data is transmitted between your deployment and AIC except for billing and license compliance: the configuration and usage data that Microsoft Azure Marketplace provides for billing, or license activation for on-premises deployments, either online or air-gapped. Your data, credentials, session recordings, and audit records are not sent to AIC.
Our software does not update itself. You decide when to install updates and when to run backups, because the software is under your direct control. AIC has no backdoor, remote control, or remote access to your deployment.
How we use AI
We use artificial intelligence (AI) tools to write and test our software. A human developer inspects all AI-generated code to confirm its functionality and that it matches the developer's intent before it is accepted.
There is no large language model (LLM) in our product. The product uses heuristics: fixed rules and workflows that you configure. Nothing in the product acts autonomously or uses AI judgment independent of your configuration. This is by design.
Report a vulnerability
Email support@analoginfo.com with "Security" in the subject line. Include the product, the version, a description of the problem, and steps to reproduce it. Do not include customer data or personal information.
We usually respond within 24 hours, and fixes are generally released within 72 hours of a confirmed vulnerability. At the outside, we acknowledge reports within 3 business days and give an initial assessment within 10 business days. We publish an advisory with each fix and credit reporters who want credit. We ask for up to 90 days before public disclosure.
An advisory may limit technical detail to protect customers who have not yet updated, or state that an issue does not apply to some deployments, such as air-gapped sites.
We will not pursue legal action against good-faith research that stays on systems you own or are authorized to test, avoids harm to data and service, and is reported to us promptly. The full policy is in section 6 of the plan.
Our security contact file is at /.well-known/security.txt.
No software is flawless
We test rigorously, but our software includes commercial and open source components we do not control, and we cannot guarantee it is free of defects. We monitor CVE records and respond as quickly as is commercially reasonable.
AI that finds unknown vulnerabilities
A zero-day vulnerability is a flaw unknown to the people who build the software, so no fix exists when it is first exploited. A new class of artificial intelligence (AI) model can find these flaws in source code and compiled programs and write working exploits for them, often with little human direction. These models find flaws that conventional commercial testing tools, such as code analyzers, vulnerability scanners, fuzzers, and manual penetration testing, do not.
Claude Mythos, announced by Anthropic in April 2026, is a published example. Anthropic reports that it found and exploited zero-day vulnerabilities in every major operating system and web browser, including flaws that had gone undetected for up to 27 years in heavily reviewed code. Access to Mythos is restricted to vetted defenders, but its developer expects similar capabilities to spread. We assume attackers have this capability now or will soon.
Our software may contain zero-day vulnerabilities that we do not know about and cannot detect with the commercial testing tools available to us. They can be exploited even after the best penetration testing and red team and blue team exercises available to the civilian sector.
Technology we cannot fix
Our software runs on operating systems, networks, databases, identity management systems, hardware, firmware, and cloud services that we do not build. That technology is expected to contain flaws, including zero-day flaws. A flaw there can expose our software and the data it protects even when our software has no defect, and we cannot fix it from inside our software. Its vendors issue the fixes, and you apply them. Where we can reduce the impact, we do, and we publish an advisory.
What we do, and what we recommend
We will listen to you and work with you to resolve issues quickly, prioritized by customer needs and market realities. We also use AI models in our own testing to find more of these flaws first.
Use a layered defense alongside our software: detection systems that watch for anomalous behavior, network segmentation, prompt patching of every layer, and least privilege for every account. Keep a break-glass strategy so you can operate your systems when our software is not working or is disabled. See Intended use.
Our commitments
We will make commercially reasonable efforts to fix all reported bugs, including security vulnerabilities, in a timely manner where possible.
Our software will perform substantially in accordance with the specifications and representations in our documentation and on this website.
To the fullest extent permitted by law, we are not liable for damages of any kind, except damages caused by our gross negligence. Vulnerabilities and flaws in our software, and in the technology it depends on, do not constitute gross negligence.
The Software License Terms govern the license, warranty, remedies, and liability. If this page and the Software License Terms differ, the Software License Terms control.