The data engine is one of three announcements. Brinqa also introduced an AI Exploitability Agent that reasons over that data to identify which exposures attackers could actually chain together, along with enhancements to BrinqaIQ. The underlying Business Wire release is dated September 30, 2026, and VMblog published it on October 1.
The pitch is easy to follow. Checking the claims takes more work.
The data engine: one big number from one customer
Brinqa says it redesigned its data engine to unify, deduplicate and enrich incoming exposure data for its CyberRisk Graph in minutes rather than hours, even as customers add more data sources. The practical goal, according to the company, is that when new findings arrive, whether from a scanner run, a cloud change or a major Patch Tuesday, teams can re-evaluate risk across their entire environment on demand instead of waiting for the next scheduled processing cycle.
The headline figure: in one production customer deployment, the engine processed roughly 150 million source records and 700 million relationships, more than 4 TB of data, in 17 minutes and 15 seconds. Brinqa says that run covered the full pipeline: integration, unification, deduplication, enrichment and lifecycle processing.
That's a big number. Note what's missing, though:
- One deployment. This is one customer's result, not a benchmark across customers.
- No baseline. Brinqa doesn't give the old processing time for that customer, so "hours to minutes" has no measured before-and-after.
- No test details. The customer isn't named, and there's no hardware, data mix or independent validation.
Brinqa also says that because full processing now takes minutes, the platform has room to go deeper on every run, with richer enrichment and more complete mapping of the relationships between assets, exposures and controls. That's plausible as an engineering argument. Time saved in the pipeline can go into extra analysis. But it's a design goal, not a measured result.
Section summary: Faster full reprocessing makes your priority list less stale. The 17-minute figure is a vendor-reported result from one deployment, not a guarantee.
The AI Exploitability Agent: attack paths instead of CVSS alone
The bigger idea is the agent. Brinqa says it goes beyond severity scores to show which exposures an attacker could chain together. Here's what the company says the agent does:
- Maps attack paths. It links vulnerabilities and misconfigurations in the order an attacker would use them, from initial access through lateral movement and privilege escalation to impact.
- Checks paths against your controls. It compares those paths with the network and security controls in your environment to judge which are likely exploitable.
- Finds choke points. These are single fixes that close several attack paths at once.
- Scores with threat intel. It uses public and private intelligence, including exploit availability and ransomware activity, to produce a risk score. Brinqa says each score comes with an explanation you can audit.
This direction is right for the industry. Anyone who has watched a "critical" CVSS 9.8 sit on a server nobody can reach, while a "medium" on an internet-facing jump box gets exploited, knows severity scores alone mislead. Brinqa had previewed this agent months ago. In a blog post about joining Anthropic's Cyber Verification Program, it said the agent brings adaptive prioritization with calculated reachability. The same post said an AI Remediation Agent would ship in the same quarter. That agent isn't part of this announcement.
Some caution is fair. Brinqa has published no accuracy figures, no false-positive or false-negative rates and no test method. "Likely exploitable" is a model's judgment, not proof. The announcement also doesn't say whether the agent's recommendations run automatically or need human approval. Brinqa's own blog sums up the risk well: a model produces answers at the same confidence level whether the underlying data is complete or garbage. That's a good argument for the data rebuild, and also a good reason to test the agent before you trust it.
Section summary: Reachability-aware scoring is the right goal. Until independent results exist, treat the agent's output as a strong hint rather than a ruling.
PlexTrac: checking that the fix worked
The third piece comes from an acquisition. Together with Brinqa's acquisition of PlexTrac in the third quarter, these updates give security teams the full continuous threat exposure management (CTEM) loop in one place. They can understand where to focus, decide what to do next and verify whether the fix worked. Brinqa's acquisition page calls PlexTrac a validation and reporting platform for offensive security and penetration testing teams.
Pen testers and red teams record their findings in PlexTrac and coordinate retests after remediation. Those retest records can show whether a prioritized exposure was really exploitable and whether the fix held. That's a sensible link between prioritization and testing. It doesn't mean every exposure gets tested, though. Your verified coverage is only as wide as your offensive team's capacity.
BrinqaIQ and MCP: notes for admins
This is the most useful part for hands-on readers. With the latest enhancements, users ask for data in plain language, research CVEs and manage platform automations through BrinqaIQ Assistant and BrinqaIQ MCP. In practice, that covers:
- Generating Brinqa Query Language (BQL) queries from plain English
- Looking up CVE context
- Launching, resuming, cancelling and checking the status of flows and automations
Brinqa presents this as part of its "Bring Your Own AI" strategy. On its BYOAI page, the company says teams can use Brinqa's native AI agents out of the box, or bring an existing AI agent and connect it directly to Brinqa's governed exposure data via API or MCP.
Brinqa's v12 documentation includes details the announcement leaves out. If you're thinking about pointing an AI client at your exposure data, these matter:
| Item | What Brinqa's documentation says |
|---|---|
| Version requirement | The current setup needs Brinqa Platform 12.3 or later, with the MCP endpoint at /brinqamax/mcp. Earlier versions use a legacy configuration. |
| Supported clients | Any MCP-compatible client. Examples named include Claude Desktop, Cursor and GitHub Copilot in VS Code. |
| Authentication | An API token sent in an Authorization header |
| Permissions | Every tool call inherits the token owner's role-based and data-level permissions |
| Scope | Only BrinqaIQ capabilities are reachable through MCP, not the wider platform APIs |
| Flow exposure | Flows are opt-in through an "API & MCP Access" toggle. Automations are not gated: all of them can be discovered and launched. |
| Confirmation | The in-platform Assistant asks for confirmation before acting. External MCP callers get no server-side confirmation, so your MCP client has to ask the user. |
The last two rows deserve attention. A token belonging to a broadly privileged user, combined with an MCP client that runs tools without asking, means an AI agent can launch any automation in the instance. A short checklist:
- Issue tokens from least-privilege accounts. Don't use an admin's personal token.
- Check every automation for anything you wouldn't want an agent to trigger, since automations skip the access toggle.
- Enable "API & MCP Access" only on flows you've deliberately approved for agents.
- Set your MCP client to require approval before write actions. Brinqa's docs say launching a button flow is a write action that creates real work.
Checking the 2,700-CVE claim
The release sets the scene with a striking statistic: Microsoft alone has disclosed roughly 2,700 CVEs through the first three quarters of 2026, more than double its largest full year on record.
That figure comes from Brinqa, not Microsoft, and the most recent official Microsoft number we could find is lower. Microsoft's July 2026 Secure Future Initiative progress report says the company had published 1,989 CVEs, annotated with CWE and CPE data. The release's "first three quarters" window runs past July, so the two counts don't strictly conflict. Still, Microsoft's July checkpoint doesn't confirm 2,700 or the "more than double" comparison.
The broader trend is real. Microsoft's 2026 Digital Defense Report, released October 1, says nearly 40,000 CVEs were published across the industry in the first half of 2026. It also puts the median time from discovery in the wild to weaponization well below 24 hours, while enterprise remediation of critical external vulnerabilities can take 30 to 60 days. Note that the 40,000 figure covers all vendors, not just Microsoft. It's also the strongest argument for what Brinqa is selling: if exploits arrive in under a day and fixes take a month, your prioritization had better run on current data.
Should you care?
If you run a large vulnerability program that combines Defender, Qualys, Tenable, cloud posture tools and a pile of CMDB records, the problems Brinqa is targeting are real: duplicate findings, stale priorities and fixes nobody verified. Faster reprocessing after Patch Tuesday, reachability-based scoring and pen-test retests linked to remediation tickets form a sound design.
What's missing is independent proof. The speed figure comes from one deployment, the agent has no published accuracy data, and the CVE statistic in the release doesn't match Microsoft's latest official count. If you're evaluating it, ask Brinqa for processing times on data like yours. Run the Exploitability Agent's top recommendations against your own red team's findings. And before any AI client connects through MCP, lock down tokens, flows and automations.
References
- Brinqa Cuts Exposure Data Processing Time from Hours to Minutes - VMblog VMblog · Fri, 02 Oct 2026 00:00:00 GMT
- Brinqa Joins Anthropic's Cyber Verification Program brinqa.com
- Flow and Automation Management · Brinqa Documentation docs.brinqa.com