An AI assistant for vulnerability work without a data leak

Vulnerability work is context heavy. An analyst spends more of a shift translating scanner output against asset ownership, threat intelligence, ticket history, and business context than reading any single advisory. That is the shape a language model can compress, and it is where "just point it at your data" quietly creates a new class of exposure while trying to reduce operational load.

The interesting data is also the sensitive data. A useful assistant needs findings, SBOMs, asset inventory, topology, ownership, ticket history, exception records, BAS results, remediation notes, and sometimes secrets or configs. Stack those and you no longer have generic prompt data; you have the organization's exposure map, the same document an attacker would pay for. If your architecture ships it to a third party model by default, the assistant has become the exfiltration path.

What follows is a reference architecture for building that assistant without becoming your own worst adversary, applying existing prior art to the vulnerability management corpus and treating the aggregated exposure map, beyond PII alone, as the crown jewel the assistant must not leak.

What is already solved

Most of the raw material for a safe AI assistant is already public. A local-first design should start by naming it.

The OWASP Gen AI Security Project's 2025 LLM Top 10 lists Sensitive Information Disclosure as LLM02:2025, moved up from six to two, which is the exact failure mode a security assistant is most likely to cause. Simon Willison's lethal trifecta, published June 16, 2025, is the sharpest threat model for this class of assistant: access to private data, exposure to untrusted content, and the ability to communicate externally. Combine all three and a prompt injection in the untrusted content can steer the private data out through the external channel. The phrasing is now widely repeated in agent security writing; uncredited use reads as plagiarism. Cite it and design around it.

NIST's AI RMF Generative AI Profile (NIST AI 600-1), released July 2024, catalogs twelve generative AI risks and gives a GOVERN, MAP, MEASURE, MANAGE spine for a security assistant. Anthropic's framework for safe and trustworthy agents adds a shared responsibility model where model, harness, tools, and environment are separate layers and only the model belongs to the vendor. Microsoft's taxonomy of failure modes in AI agents, April 2025, singles out memory poisoning as an insidious agent-specific mode, which lands hard on any assistant that persists prior sessions or retrieved evidence. For the on-prem precedent, Elastic's Security AI is the clearest example of an LLM analyst running inside a SOC on customer-controlled infrastructure with a bring your own model deployment, and generic private RAG guides already cover local embeddings, vector stores, and inference. This architecture relies on those mechanics; it does not reinvent them.

What is still open

Three things are, as of writing, genuinely uncovered by the material above, and this is where a local-first assistant for vulnerability work has to plant its own flag. Current security copilots scope to alerts, detections, or incident timelines, so no vendor treats the exposure corpus (findings plus SBOM plus topology plus ownership plus BAS) as one first-class assistant surface. No published reference architecture applies the lethal trifecta directly to vulnerability management data flows; the trifecta lives in agent security writing, while the vuln management stack is usually discussed as a data pipeline problem rather than an agent boundary problem. And existing writing about sensitive information disclosure treats PII and IP as the sensitive class, when in practice the aggregated exposure map is more sensitive than most PII a company holds.

The four boundaries

Treat the assistant as a system with four crisp boundaries. If you cannot draw them on a whiteboard, it is not ready for production security data.

Boundary 1: local data store

Findings, SBOMs, asset inventory, topology, ownership, ticket history, the exception log, and BAS results live inside the environment they describe. Nothing is copied to a vendor tenant, and nothing is silently mirrored into a cloud vector database. If compliance ever asks where the exposure map lives, the answer is one location under your control.

Boundary 2: local retrieval

Embeddings, keyword indexes, and any evidence lookup layer are built and served locally, next to the data they describe. A cloud embedding service is convenient, and it also means every substring your assistant retrieves has been shipped to a third party at least once.

Boundary 3: local inference where possible

The model that reads retrieved context is the highest risk seat in the system: it sees the crown jewels and produces free-form outputs. Run an open weights model on your own hardware for the day to day work, and reserve cloud inference for narrow, opted in requests whose payload is known to the operator before it leaves.

Boundary 4: explicit egress controls where cloud is allowed

No boundary here is absolute. When egress is allowed it goes to a named endpoint, with a redacted payload, a logged request, and a policy stating what kinds of data are permitted through. The default is deny; every exception is documented and auditable.

Together those four keep the lethal trifecta from closing: private data stays local, untrusted content is filtered before it reaches the model, and the external communication leg is the boundary you defend hardest.

Start with bounded tasks, not with autonomy

Promising an analyst a co-pilot that "does vulnerability management" is not a scope; it is an expectations trap. Start narrow, with tasks that have a clear right answer and a clear failure mode:

• Summarize a CVE against the local exposure record for a specific asset.
• Explain why a finding scored ACT or ATTEND, citing the evidence a human analyst would.
• Draft a remediation ticket that maps a finding to asset, owner, and business service.
• Compare patch and mitigation options for a finding, given the environment's constraints.
• Produce validation steps a remediation team can run after the change.
• Write a plain-language executive update for a specific exposure.

What is not on that list matters more. "Autonomously fix production" is the anti-goal, a governance failure disguised as ambition; an assistant that writes tickets and cites evidence keeps a human on the change, while one that pushes changes puts an unsupervised generative model into the change control record.

Retrieval, narrow and explainable

Retrieval is where local-first architectures live or die; dumping the database into context is the same mistake as sending it to the cloud, different vector, same failure. For a question about a finding, retrieve only that finding, its asset context, the relevant SBOM entries, the threat intel attached to it, related tickets, validation history, and approved remediation guidance. Every retrieved item should be addressable back to its source so the assistant can cite evidence a human can open. Narrow retrieval is a data minimization control: the less that reaches the context window, the less that can be steered out through an unexpected channel.

Guardrails above the model

Local does not mean unguarded. Every guardrail below sits above the model, in the harness and tool layers:

• Read-only default. Writes require an explicit action layer, not a model output that "looked like a command."
• Per-domain permissions: findings, source code, secrets, and topology are separate access scopes a user must consciously grant.
• Prompt and response logging, with the same retention you apply to security telemetry.
• Secret redaction on the way in and on the way out.
• Output citations that resolve to specific local records; if an answer cannot cite, the answer does not ship.
• Human approval on any action that touches production, closes a finding, or grants an exception.

Microsoft's memory poisoning warning applies here: any assistant that persists prior sessions or cached retrievals needs an integrity model for that store, or a prompt injected note from three weeks ago will reappear as trusted context.

Evaluate it like a security system

A useful assistant here is not the one that sounds most fluent; it is the one whose failure modes are known and bounded:

• Overstated exploitability on findings without KEV or an active exploitation signal.
• Invented patch versions when the vendor advisory is ambiguous.
• Missed KEV entries, or findings a senior analyst would escalate that the assistant downgrades.
• Secrets from retrieval documents leaking into responses.
• Permission boundaries widened by cleverly phrased requests.
• Memory persistence that lets an attacker plant instructions surviving across sessions.

Run those checks on every model change, retrieval index rebuild, and prompt update, and log the results next to your other operational metrics. You already do this for scanners and detection rules; the assistant is the same kind of system.

A quiet tie

CVEasy AI is the local-first CTEM platform for exactly this reason: the exposure map, TRIS scoring, and BASzy AI validation stay inside the customer's trust boundary, and any AI assistance is added under the four boundary pattern above. The right question is not "how do we add an assistant to vulnerability management" but "how do we add one without turning the exposure map into someone else's input stream."