Your AI Agent Needs Grounded Answers, Not Confident Guesses

Without structure, retrieval is just expensive search.

By Ron Dovich, Chief AI Officer, and Paden Portillo, Principal Software Engineer, Brinqa

You have already done the hard part: you decided to put an AI agent to work on your security data. You ask it the question that actually matters, such as which of my exposures could get me breached this week, and it answers in seconds, fluently and with total confidence. The only question that counts is the one the agent will never volunteer on its own: did it reason over your real exposure, or did it assemble or hallucinate something that merely sounded like the answer?

That difference has almost nothing to do with the model. It comes down to what the agent is grounded in. Feed it a pile of embedded documents, and it retrieves the passages that read like your question, then guesses at how they connect. But what if you could ground your model into something trustworthy and take the guesswork out of what it's telling you?

So here is the claim this whole piece rests on: everything your agent tells you traces back to what it's grounded in. Without structure, retrieval is just expensive search. It surfaces the passages that read most like your question and hopes the model stitches them into something true. For a lot of problems, that is good enough. For deciding what to fix before someone exploits it, it is not.

We want to be precise in the other direction too, because it is easy to overcorrect. Retrieval is not the problem, and neither are embeddings. The problem is that you are asking semantic similarity, on its own, to reconstruct the structure of your data. The real question was never whether to augment the model with context. It is whether that context is grounded in how your data is actually connected.

The thing most people skip

Start with why we retrieve at all.

You could try to hand the model everything. All your context, every record, the entire environment, and let it reason over the whole pile. That is the cache-augmented approach, and it works right up until the context window overflows or the signal gets lost in the noise. In a large enterprise with hundreds of millions of findings, you hit that wall immediately.

So you get selective. You pull only what is relevant and put that in front of the model. That is the whole point of augmenting a model with retrieved context. But it raises the question almost everyone skips: how do you decide what is relevant?

Semantic similarity is the easy answer, and for a lot of jobs it is the right one. You turn your documents into embeddings, turn the question into an embedding, and pull the closest matches in vector space. That is exactly how you teach a system that "cat" and "kitten" mean nearly the same thing. It is genuinely good at meaning. What it is not good at is structure. "Reads like the question" is not the same as "is connected to the answer." A vulnerability advisory that shares vocabulary with your query is not necessarily the one sitting on a path to something your business cares about.

A graph is how retrieved context gets judicious about structure. It selects what to feed the model by how things are actually connected, not only by how alike they read. That is not a rejection of retrieval. It is retrieval that finally knows what it is reaching for.

Why does meaning-matching alone break on exposure data?

Here is a question a security team asks every day:

Find critical findings on internet-exposed assets owned by business units tagged PCI-in-scope that have no remediation ticket assigned.

Read that carefully. It has multiple hops across relationships and filters. Finding to asset, asset to owner, owner to compliance scope, finding to ticket status. Each hop is a defined relationship between two kinds of things where some of the data is filtered along the way.

Semantic similarity has no concept of a hop. It pulls the passages whose meaning resembles your query and asks the model to infer how they relate. Every inferred connection is a place where the model can invent a relationship that does not exist or quietly drop one that does. The result looks like an answer. It carries the same confident tone whether it is right or wrong. And you cannot show an auditor which records produced it, because there are no records or in the worst case, the wrong ones.

These are the failure modes practitioners can't afford to live with. Chunking destroys structure. Extraction errors compound. Results are non-deterministic. There is no lineage. None of that is a model problem. It is a grounding problem, and you do not fix it with a bigger model. You fix it with structure.

Two Graphs, Two Jobs

When we talk about a graph at Brinqa, we mean two distinct things, and conflating them is where a lot of vendor marketing falls apart. So we will name both.

The first is the data graph. Brinqa's CyberRisk Graph holds your live exposure data as typed entities and typed relationships: assets, findings, vulnerabilities, tickets, ownership, business context. Your data arrives through more than 260 connectors directly into a domain-specific data model. It is structured from the moment of ingestion. There is no chunking, no entity extraction, no guessing at edges after the fact. An asset is owned by a team. A finding is discovered on an asset. Those connections are defined and validated, not inferred. This is the graph your queries actually run against, and it is the part you cannot bolt on later. Most platforms are retrofitting AI onto data that was never modeled for reasoning. Creating the right model is the work.

The second is the schema-aware graph that helps an agent write a correct query in the first place. That is a different job, and I'll write more on it below.

Keep the two separate in your head, and most of the confusion in this space dissolves. One graph is the answer space. The other is how you reliably ask the question.

You need two graphs. One is a data graph where you store the information, and the second is a schema-aware graph that is how you ask the question.

Graph semantics without the graph-database ceiling

A point that gets lost: graph reasoning is a property of your data model and your query language, not of any particular storage engine underneath. The ontology, the entity types, the relationship verbs, the attribute definitions, that is the durable asset. The engine that physically stores the data is an implementation detail you should be free to change as scale demands, and we did, precisely so we could traverse relationships across hundreds of millions of findings without hitting the operational ceiling that graph databases run into at enterprise scale.

What you keep is the semantics. Our Brinqa Query Language (BQL) exposes them directly. Its THAT HAS, THAT IS, and THAT RELATES constructs make multi-hop traversal native, so the four-hop PCI question from earlier is a single statement, not a pipeline of post-processing:

One statement. A deterministic result. The exact records that satisfied it. Full lineage back to the source data. That is the difference between an answer you can act on and a data set you have to go verify.

Where your agent plugs in

This is what makes the "bring your own AI" conversation real rather than aspirational. Through MCP, an external agent, Claude Desktop, a Copilot, Goose, whatever your team already runs to generate and execute BQL against the live risk graph. The agent does not get an embedded snapshot of your data frozen at index time. It gets live query access to authoritative, deduplicated, business-contextualized records.

A word on what is available today, because the BQL generation behind this is not new and you do not need to be on the newest release to use it. Translating a natural-language question into BQL has been part of the product across recent releases, powered by retrieval-augmented generation, and customers are running it in production right now. What we've added is a stronger engine for the hardest part of that translation: resolving join paths through a graph rather than inferring them from retrieved text. These improvements get sharper on exactly the cases that were always the hardest: deep multi-hop questions and heavily customized schemas. The way your agent connects does not change. The precision underneath it improves.

What good grounding looks like

Generating a correct BQL query against a customer's data model is harder than it sounds. The established approach is to retrieve schema documents and worked examples and let the model infer the right join path from the retrieved text. For a bounded schema with good example coverage, that works well. Where it can lose precision is in the cases that matter most at scale: novel multi-hop combinations no one wrote an example for, schemas that change, and deep type hierarchies. In all three, the retrieved corpus is either incomplete or stale, and the model is left inferring structure from text.

That is the gap we've closed. We pre-compute a directed graph over the live data model catalog, every entity, attribute, relationship, and inheritance hierarchy, cached per tenant against the current schema fingerprint. At query time, the pipeline walks that graph to resolve join paths deterministically. Ask for "tickets" and it resolves inheritance-aware, through subtypes like vulnerability tickets, automatically. Ask a question that spans intermediate models, and it computes the transitive path, Person to Asset to Vulnerability, dynamically rather than depending on someone having documented that exact combination.

Three things fall out of that:

Every join path the graph emits is valid against the current schema. A retrieved corpus can only cover the paths someone thought to write down. The graph covers every combination the schema permits.

It is resistant to change. In a multi-tenant product where each customer customizes their data model, a fixed example library goes stale the moment a tenant adds a relationship or renames a type. The graph rebuilds from the live catalog, so it is never describing a schema that no longer exists.

And it discovers paths nobody anticipated. Multi-hop traversals are computed on demand, not looked up from a library that either has the combination or does not.

Now the part that keeps us honest: this does not replace embeddings, and we did not try to make it. We still use semantic similarity where it is genuinely the right tool, for routing a query to the right area and for disambiguating attribute values, the same meaning-matching that knows "cat" and "kitten" belong together. The graph handles the narrower problem of structural path resolution, where determinism matters more than flexibility. That is the whole point. Retrieval is not the enemy, and neither are embeddings. The mistake is asking semantic similarity to do a job that belongs to structure. Put each where it belongs, and the system gets both flexible and trustworthy at the same time.

Grounding is the product

Strip away the vocabulary and the bet is simple. Answers grounded in a structured graph, where the model traverses what it is reaching for, beat answers assembled from passages that merely read right, every time the answer has to hold up. That is true in a demo. It is far more true in front of an auditor or a board, where "the model said so" is not a defensible answer and "here is the query, here are the records, here is the lineage" is.

Everyone gave their agent retrieval. The teams that come out ahead grounded it in structure. Your agent will always answer. Whether the answer is one you can defend depends on what it was grounded in.

If you want to point your own agent at a graph instead of a guess, come find us. And if you think we have this wrong, even better. Come talk with us about it.

FAQs