Rolling Out in October: Prove It, Fix It, Block It

Most security programs get bogged down somewhere between finding an issue and closing it: deciding which findings are real enough to act on, fixing them without pulling developers out of their tools, and stopping new risks from arriving through dependencies in the meantime.

AISLE takes security teams from finding to fix. And this month, four new capabilities make that path shorter:

• Proof of exploitability for web apps and APIs. See evidence that an attacker can actually exploit a vulnerability in your running application so your team can focus on the findings that matter.
• Reproducible proof for memory-safety bugs. Each suspected flaw in systems code comes with a reproducer anyone can run, so engineers only spend time on real issues.
• AISLE MCP server. Bring findings into the AI coding agents your developers already use, so issues get fixed on the spot, in the editor.
• AI package firewall. Block malicious open-source packages before they reach a laptop or a build.

Prove It

Proof of exploitability for web apps and APIs

Product security teams get hundreds of code findings for each application. Even when the findings are real, they are not equal, and a code finding alone can't tell a team whether an attacker can exploit the flaw in their app.

AISLE's new proof of exploitability feature answers that question with evidence. AISLE starts from a vulnerability it finds in your source code. With your authorization, an AI agent then sends targeted requests to your running web app or API, in a test environment you provide, and tries to trigger that exact flaw. When the exploit works, AISLE attaches the proof to the issue: the requests, the responses, and the observed effect.

For your team, that means:

• Prove the vulnerability. Security and development teams can replay every exploit.
• Start with what you can prove. AISLE does not close findings it can’t exploit. It marks the ones it could, so your team knows where to start.
• Code first. Black-box testing starts with no knowledge of the code. AISLE already knows where the flaw is and how to reach it, so every test is targeted.

Proof of exploitability works on web applications and APIs, both internal and public.

Reproducible proof for memory-safety bugs in systems code

Memory-safety bugs are among the most dangerous flaws in software. A buffer overflow or a use-after-free can let an attacker read secrets or take control of a system. They are also hard to confirm: an AI model can say "this looks like an overflow," but a maintainer needs more than a "maybe."

AISLE turns suspected bugs into proofs that a machine can check. For each candidate, AISLE's agent builds the project from source, instruments it with memory sanitizers, creates an input that drives the program to the vulnerable code, and confirms both the crash and the sanitizer report.

The result is a reproducer that anyone can run, so defenders get actionable evidence rather than an unverified AI report. (The AISLE research team presented our approach at Offensive AI Con 2026.)

Systems code (C and C++ libraries, parsers, network services) gets far less attention in AI security than web applications, yet securing it requires the same level of effort.

Fix It

AISLE MCP server: security findings in your AI coding agent

Developers work in the IDE and, increasingly, with AI coding agents. Security findings have always lived in other tools. To fix an issue, a developer leaves the editor, logs into another dashboard, copies the details, and returns to the IDE. That round trip is often enough friction to delay fixes until a Jira ticket arrives.

The AISLE MCP server puts findings in front of developers where they already work, so fixes get made right away instead of waiting on a ticket. Developers can connect AISLE to AI agents that support the Model Context Protocol (MCP) standard, such as Claude Code and Cursor.

For your team, that means:

• Fix without leaving the editor. The coding agent reads the open issues for the repository and the details of each one. You simply tell your agent to fix it, review the change, and continue working.
• Security fixes become part of normal work. Build your own skills by telling the coding agent: "Before you change a file, get all open AISLE issues for this code and fix them in the same pull request."
• No manual status updates. AISLE already watches the main branch. When the fix is merged, AISLE marks the issue as fixed.
• No shared API keys. Each developer signs in with their own AISLE login and sees only what they can see in the AISLE dashboard.

Agents start with read access to AISLE data. More actions are on the way.

Block It

An AI package firewall for your open-source dependencies

Attackers now publish malicious code straight to public registries. They use typosquatted names, take over maintainer accounts, and hide credential theft in install scripts. A developer laptop or a CI job installs the package in seconds, and the payload often runs before anyone looks. AI coding agents make this worse: they now install packages on their own, often with no human review.

AISLE's package firewall sits between your developers, agents, build systems, and the public registries. Every package request goes through AISLE.

For your team, that means:

• Malicious package detection. AISLE's AI analyzes the code and metadata of each new package version and blocks malicious packages before they reach a laptop or a build.
• Cooldown for new releases. Many malicious releases are caught and removed soon after they are published. AISLE holds new versions back for a cooldown period you define. It can also block versions with published advisories above a CVSS score you choose.
• Fast onboarding. Change one registry URL in your npm, pip, or Cargo configuration. AISLE then onboards the packages your repositories already use.
• One control point. The firewall fits teams that pull from many public registries with no central control. It also fits teams whose internal registry caches packages but does not check them for malicious intent.
• Preview of what gets blocked. Monitoring mode shows which packages your teams and agents install, and what AISLE would block, before you turn enforcement on.

The firewall supports npm, PyPI, and Cargo, with more registries coming.

Build With Us

These new capabilities provide solutions to problems that keep vulnerabilities in production:

• Unclear what to fix first? Start with what you can prove.
• Developers live in their editors and don’t want to tab-toggle? Bring the findings to them.
• Malicious code arriving through dependencies? Stop it at the door.

We build AISLE alongside our customers who use it every day. The best ideas on this list came from them.

If these capabilities would help your team, talk to us and tell us what you'd like to see next. We'd love to build it with you.