Why LLMs invent Vault properties (and how to fix it)

Ask a language model to work with the properties of a file in Vault and watch what happens. It answers fast, with absolute confidence, and with an impeccable list of properties. The problem shows up when you compare that list against your real Vault: several of those properties do not exist. They never did.

Not a bug, the nature of the model

The typical reaction is to assume the model failed. But an LLM does not query your server: it completes patterns. During training it saw thousands of PDM systems, documentation, forums and code samples. If the property Approval status appears frequently in that universe, the model will offer it to you with complete naturalness, even if your Vault never had it.

Seen that way, the behavior is coherent: the model does exactly what it was built to do. Predict the probable. The probable and the true often coincide. In a production PDM, often is not enough.

Where it becomes dangerous

While the model just talks, an invented property is an anecdote. The risk appears when the agent has write access. Writing to a property that does not exist, or worse, pushing a value with the wrong data type into a similar-looking property, turns a statistical hallucination into corrupted data inside the system that governs your product.

And there is an extra trap: these errors do not explode immediately. They surface weeks later, when a report comes out empty or a release gets blocked, and by then nobody remembers which operation introduced them.

The fix is structural, not a prompt

The first temptation is to write a better prompt: tell the model not to invent. It helps very little. The model's memory does not distinguish between what it saw in your Vault and what it saw on the internet. The real fix lives outside the model, in the agent's architecture.

In VaultPilot, which we built together with Avant Leap, it works like this: every operation that mentions a property is validated against the real Vault schema before it runs. We check that the property exists, that the data type matches and that the user has permission over it. If something does not line up, the operation never even reaches the dry-run: it stops with a clear message about what does not exist and which real alternatives there are.

The model remains free to propose. The schema decides which proposals are real. That division of labor is what turns an LLM into an engineering tool.

The general rule, beyond Vault

This pattern applies to any system where an AI agent touches data that matters: never let the model define reality. Reality is defined by the schema, the API or the database, and the model adapts to it. When you evaluate any AI tool for engineering, ask exactly this: what does it validate its operations against before executing them. If the answer is the model itself, keep it away from production.

Has an AI ever invented fields, functions or properties for you with total confidence? I am interested in the story: write to me and let's talk about it.