Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Here’s our guide on how to make OpenClaw safe and secure to run.

Developers work in a few core loops: writing code, committing changes, installing dependencies, and increasingly working alongside AI in the editor. Aikido Expansion Packs are built around those moments. They let you add focused security capabilities to Aikido that run locally, inside your IDE, and fit naturally into how developers already work. Each pack addresses a specific part of the workflow and does not require new tools, new pipelines, or new processes.

The International AI Safety Report 2026 is one of the most comprehensive overviews to date of the risks posed by general-purpose AI systems. It’s compiled by over 100 independent experts from more than 30 countries, and shows that while AI systems are performing at levels that seemed like science fiction only a few years ago, the risks of misuse, malfunction, and systematic and cross-border harms are clear. It makes a compelling case for better evaluation, transparency, and guardrails.

Compliance evidence only works if it reflects the current state of the system. At Aikido, we’ve always treated compliance as a byproduct of good security, not a separate exercise teams need to prepare for. That’s why Aikido integrates with multiple compliance platforms. The goal is simple: let teams use the security data generated in Aikido wherever they run their compliance programs, without changing how they work or maintaining parallel processes.

Aikido Package Health surfaces the true health of an open source package with a single score. It helps devs understand stability, maintenance quality, and supply-chain risk before installing a dependency. Aikido Package Health is a public service that assigns a clear Health Score to open source packages. It gives you an honest signal about which dependencies are well-maintained and safe to adopt, and which ones might need extra scrutiny before you pull them into your project. The goal is simple.

The difference between a secure organization and a breached one depends on how well security is embedded into the Software Development Life Cycle (SDLC). Is security a built-in capability, or was it added after the core architecture was already in place? When it’s the latter, security is scattered and breaches happen.

Open source is one of the best things to ever happen to software development. It is also one of the easiest ways to accidentally ship legal obligations you did not sign up for. Most teams know they rely heavily on open-source dependencies. Fewer teams know exactly what licenses those dependencies use, what obligations come with them, or how those licenses travel through transitive dependencies and container images. That gap is what we call open-source license risk.

Every financial entity operating in the European Union must comply with the Digital Operational Resilience Act (DORA). DORA focuses on whether systems can withstand, respond to, and recover from ICT-related disruptions and whether this can be demonstrated with evidence. For engineering, security, and risk teams, this introduces a practical requirement. Operational resilience must be observable in live systems, continuously tested, and traceable over time.

Insecure Direct Object References, commonly referred to as IDORs, remain one of the most common and damaging classes of application vulnerabilities. Despite being well documented and widely understood at a conceptual level, they continue to appear in real production systems, particularly in modern, API-driven applications.

We’re making a fundamental change to how teams use SAST. SAST in the IDE is now free. This means developers can run SAST scans directly inside their editor, with real-time feedback and project-wide visibility, using the same analysis engine and SAST rules as Aikido. Detection runs automatically as developers work, without limiting coverage at the detection layer.