Improve your SecOps with Priam Cyber AI's AVA: an AI-driven Virtual Analyst

For a service provider, the most valuable thing the team produces is not a detection or a closed case. It is the accumulated understanding of each customer's environment: which alerts are noise on which hosts, who owns which asset, what was done the last time a pattern showed up, and why. That knowledge is also the most fragile thing the team owns. It walks out the door when an analyst leaves, and it erodes every time the shop swaps a SIEM or an EDR. Paolo Di Prodi, co-founder and CEO of Priam Cyber AI, spent this session with LimaCharlie's Matt Bromiley arguing, mostly by demonstration, that the knowledge layer deserves to be a system of its own, one that sits above any individual sensor and survives changes to the tools underneath it. That is the lens worth using to judge AVA, the AI-driven virtual analyst Priam ships as a LimaCharlie Marketplace extension.

The case for separating knowledge from sensors

Di Prodi's framing comes from more than a decade in cyber security, much of it spent watching response work done inefficiently. His thesis is not that AI should replace the analyst. It is the opposite: automate the boring parts so people are freed for the work that needs judgment. AVA, which stands for advanced virtual analyst, consumes LimaCharlie telemetry and detections and adds the operational layer most providers end up improvising, namely case management, asset management, users and roles, and task tracking. Each customer gets a dedicated instance deployed in AWS, with control over the region, after an onboarding form, an approval, and a 30 day trial.

The architecturally interesting decision is what AVA refuses to be tied to. Di Prodi is blunt that a real shop runs more than one tool: an EDR, a SIEM, log forwarding from other products. AVA normalizes everything it ingests into the STIX object model, so whatever source plugs in gets converted into a common language. The payoff is twofold. Disparate vendors stop speaking past each other, and the provider keeps a compliant export of its own data even if it decides to leave AVA itself. As Di Prodi put it, every time you change your SIEM or your EDR you lose part of that knowledge, but with this approach it stays within your company. For a provider whose margin depends on not relearning the same environment every time staff turns over or a vendor contract lapses, that portability is the whole argument, not a footnote to it.

Why this is built for multi-tenant operators

Almost every design choice on display reads as a concession to how an MSSP or MDR actually works rather than how a single in-house SOC does. Subscribed organizations appear automatically in a dropdown, so an analyst moves between client environments from one interface instead of switching products per customer. The multi-tenancy and retention concepts carry over directly from LimaCharlie, a point Bromiley reinforced: it is plug and play, but also plug and go, because the operator does not have to learn or maintain two separate models of the same data.

User and role management inherits the same posture. You start with an administrator account, add users who may sit outside LimaCharlie or on a different regional team, and assign them to groups mapped to SOC functions like monitoring, threat hunting, and incident response. Bromiley drew the explicit parallel to LimaCharlie's ACLs: roles scope what each analyst can see and do, and work can be reassigned or permissions changed quickly as alerts arrive. Di Prodi sketched where this is headed, with alerts routed by type, a suspicious network connection to a network analyst, a suspicious process to a malware analyst, though that allocation is a future capability rather than something shown working.

What the analyst actually touches

The center of the product is alert grouping, and it is the clearest expression of the efficiency thesis. Machine learning combines related alerts into stories so that two analysts do not unknowingly investigate the same activity from different starting points, which Di Prodi identified as one of the most common ways response teams waste effort. He gave the concrete version from experience: the same user on a different machine, logging in and downloading content, looks like two separate investigations until someone realizes it was always one. Each group surfaces a summary with extracted MITRE ATT&CK tags, host details such as a Debian Linux workstation, and detection counts, alongside a knowledge graph that links the organization ID, the detection or sighting, the responsible process, and the account behind it. Bromiley made the fair point that the graph sharpens as detection volume rises, and that seeing connections drawn out helps junior analysts grasp what is hard to read in plain text. Di Prodi was honest about its current limits, noting it is not yet as feature rich as Maltego, though the STIX compliance underneath it is the part that matters for normalization.

From a group an analyst opens a case, attaches assets and artifacts, takes Markdown notes, and assigns tasks with priorities and dependencies. AVA also asks teams to record incident impact in financial terms, which Di Prodi argued is the language that actually moves a manager or a customer: being able to say you handled ten cases this month and quantify the damage avoided. That impulse to make the work legible to whoever is paying for it runs through the reporting plans too, scheduled snapshots of open and closed cases and false positive and true positive rates, emailed to a SOC manager or a client on a cadence. Bromiley noted that for an MSSP or MDR, the ability to hand customers those metrics is one of the most requested things he hears.

Two ideas point at where this becomes more than a tracking tool, and both are still ahead rather than shipped. The first is direct LimaCharlie integration, so a response action like terminating a process or collecting a payload could be issued from the same interface, with the system learning from those interactions to suggest steps on similar future cases, something closer to a SOAR that infers playbooks from behavior rather than requiring them to be written. The second is the stress meter, an attempt to fold the human's state into the data by correlating workload and alert volume with self-reported stress, on the reasoning that an exhausted analyst feeding sloppy tags poisons the machine learning that depends on clean input. It is early and admittedly rough, but it is an honest acknowledgment that the knowledge layer is only as good as the people maintaining it. For a provider, that is the same bet in a different form: the durable value is the institutional memory, and the entire point of a system like this is to make sure it belongs to you rather than to your tools or your turnover.