Latest in AI
Firecrawl Alexandria Adds Cybersecurity Data for Coding Agents
A new vulnerability-data pack gives coding agents better sources, but finding an advisory and proving a fix are still different jobs.
Firecrawl added cybersecurity data to Alexandria on October 29, giving coding agents access to vulnerability information for dependency checks. The company advertises coverage of more than 400,000 vulnerabilities. The useful change is access to security evidence inside an agent's workflow, not a guarantee that the agent can safely fix every finding.
What the cybersecurity data pack includes
Firecrawl's release note names six sources: the National Vulnerability Database, the CVE Program, CISA's Known Exploited Vulnerabilities catalog, the GitHub Advisory Database, Red Hat Security Data and OSV.dev. It describes using the data from Codex and Claude Code to check dependencies and work on fixes.
The company says records may be normalised by Firecrawl and explicitly states that use of the NVD API does not mean the product is endorsed or certified by NVD. The 400,000-plus figure is a vendor-stated coverage count, not a count of vulnerabilities in any particular repository.
Alexandria itself is not new. Firecrawl introduced the broader knowledge-access product in September. This update adds a security-focused collection of sources to that existing system.
How Alexandria fits into an agent workflow
The Alexandria documentation describes a discovery-and-execution process: find a relevant tool, inspect its inputs and response format, then call it. It supports the CLI, MCP and API-based workflows. Discovery is free; execution uses the price listed for each tool.
That means there is no single cybersecurity-query price established by this announcement. A team should inspect the selected tool's terms and execution cost rather than assume that access to public underlying records makes every mediated request free.
The important engineering detail is to preserve the source record alongside the agent's interpretation. A useful finding should identify the package, installed version, affected range and the advisory it relies on. Without that trail, a confident warning is difficult to verify or reproduce.
Finding a record is not proving exposure
A vulnerability record can be relevant without demonstrating that a particular application is exploitable. The installed package version, enabled features and deployment configuration all affect the next question an engineer needs to answer.
For example, an agent may find an advisory for a dependency and suggest upgrading it. Before accepting the patch, the team still needs to establish whether the installed version is affected, whether the proposed version addresses the issue and whether the upgrade changes application behaviour. Retrieving a current advisory makes those checks better informed; it does not perform them automatically.
The reverse matters too. An empty search result is not evidence that a codebase is secure. It may reflect an incomplete query, an unsupported source or a failure to match the package correctly. Tool errors and absent records should remain visible rather than being converted into a clean bill of health.
Where this becomes useful
The strongest use is a reviewable chain from dependency to advisory to proposed change to test result. A coding agent can help assemble that chain quickly, while a team retains control over what gets merged and deployed.
Start with a bounded dependency review and require evidence for each proposed update. Separate research from modification, and separate a passing build from proof that the reported issue is resolved. Those boundaries make it easier to find where a mistaken assumption entered the workflow.
Firecrawl's release makes security data easier to reach from the same environment that edits code. The next useful improvement is not more confident patching language. It is making every suggested fix easier to trace back to an actual finding and verify against the application it changes.
I'm Paras. I work at the intersection of AI, engineering and distribution.
I help technical teams explain developer tools and complex AI workflows clearly, without losing the details that make them trustworthy.