Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
What breaks when AI agents read enterprise data: stale descriptions, access scoped for humans, tangled lineage, and where automated metadata management is safe.
Updated on
Agentic systems fail in a way that is easy to miss, because they rarely fail loudly. A pipeline that breaks throws an error. An agent that misreads a column returns a confident answer in the right format, and the answer is wrong in a way that nobody catches until a decision has already been made on it.
The reason sits in metadata. Every enterprise runs on a large body of shared understanding that was never written down: which of the four revenue tables is the one finance uses, which customer table still contains test rows, that the status column changed meaning after the billing migration. People carry that knowledge and apply it without noticing. An agent has access to none of it, so it uses the only thing available, which is whatever the metadata management layer says.
That is why automated metadata management stops being a productivity project the moment agents are in production. Metadata becomes an operational control on what the agent computes, and the failures below are the ones that show up first.
| What breaks | Why it happens | What it costs | The control that prevents it |
|---|---|---|---|
| A description that stopped being true | Meaning changed at the source and nobody updated the description, because for humans the change spread by conversation | Confident wrong answers that reconcile to nothing, and a slow loss of trust in every agent output | A last verified date on every description, with a change in the source column marking the description stale automatically |
| Read access to something the agent should not see | Permissions were scoped for people who knew which tables not to open | Sensitive fields inside outputs and prompts, and a disclosure that is hard to bound after the fact | Access granted to the agent identity per asset, not inherited from a human role, with sensitivity declared on the asset |
| Two agents writing to the same asset | Agents were given write access independently and neither run knows the other exists | A result nobody can explain, and an investigation that has to be done by reading logs | Column level lineage that records agent writes, plus one declared owner per writable asset |
| One agent output feeding another agent | Chained agents pass results forward with no record of what was assumed at each step | Small errors compounding into large ones, with no way to find where it started | An audit trail linking every output back to the inputs, prompts and tools that produced it |
| Metadata written faster than anyone can review it | Agents generate descriptions, tags and classifications at machine speed against a review process built for a few dozen changes a week | Either a review queue nobody clears, or unreviewed machine text treated as authoritative | Provenance on every metadata field and a confidence threshold that routes only low confidence writes to a person |
An analytics team migrated billing last quarter. The status column in the subscriptions table used to carry active, cancelled and trial. After the migration it carries seven values, and two of the old ones now mean something narrower. The engineers knew. The analysts found out within a week. The description in the catalog still says what it said in 2023.
A person querying that table notices the unfamiliar values and asks someone. An agent does not, because it has no expectation to violate. It reads the description, maps the values the description implies, and reports churn that is wrong by whatever share of accounts sits in the new statuses. The output is well formed, so it passes review.
The cost runs well past one bad number, because the error is invisible and repeatable. Every run reproduces it, downstream reports inherit it, and when someone eventually notices, the organisation has no way to tell how long it has been wrong. Recovery costs far more than the description would have.
The control is a freshness contract on meaning, not just on data. Every description carries a last verified date and the name of who verified it. Any change to the source column definition, its data type, or the distinct values it carries marks the description stale, and an asset with a stale description is either withheld from agents or served with an explicit warning attached. This is a rule most catalogs can enforce today and almost nobody switches on, because for human readers a slightly old description was never a problem.
Enterprise read permissions are usually broader than anyone would design from scratch. An analyst gets read access across a warehouse schema because narrowing it every time costs more than it saves, and because the analyst knows not to open the table holding raw applicant records or the one with unmasked payment identifiers. The permission was never the control. Professional judgement was.
Give an agent that same role and the judgement disappears while the permission remains. The agent searches for anything relevant to its task, finds the table, and uses it. Sensitive values then appear in outputs, in prompt context sent to a model provider, and in whatever the next agent in the chain consumes. There is no malice and no bug. The system did exactly what the access grant permitted.
The cost is a disclosure whose boundary is hard to establish afterwards. Answering which records were exposed, to whom, and through which downstream system requires reconstructing agent activity that was probably not logged at the level a regulator will want.
Two controls fix it together. First, agents get their own identity with permissions granted per asset rather than inherited from a human role, which also makes agent access auditable as a set instead of as scattered grants. Second, sensitivity is declared on the asset itself so that the restriction travels with the data instead of living in the head of whoever normally reads it. The inventory of which agents exist and what each is entitled to reach belongs in an agent registry.
Write access is where agentic systems stop resembling analytics. One agent enriches customer records from a support system. Another updates the same records from a billing reconciliation. Both were approved separately, both run on their own schedule, and neither knows the other exists.
The record that results is a mixture. Some fields came from one run, some from the other, and some were overwritten twice in an order that depended on timing. Lineage that tracks table to table dependencies will show both sources feeding the target and stop there, which is accurate and useless. It cannot say which run set the value that is currently in the field.
The cost lands in the moment when someone has to explain a specific record. In a regulated environment that question comes from a supervisor with a deadline attached, and the answer has to be reconstructed by hand from application logs, if those logs were kept.
The control has two parts. Column level lineage has to record agent writes with the same fidelity as pipeline writes, including which agent, which run and which timestamp set each field. And every writable asset needs one declared owner who approves what may write to it, which is the check that would have caught the second agent before it ever ran.
Chained agents are where small errors become expensive ones. A classification agent labels accounts by segment. A pricing agent consumes those labels. A reporting agent summarises the pricing output for a committee. Each step is individually reasonable and each step discards the uncertainty of the one before it.
A label assigned with moderate confidence arrives at the next agent as fact, because the interface between them carries a value and not a confidence. By the third step the committee sees a single number with no indication that it rests on an inference made two systems earlier from a description that may itself have been stale.
The cost is the investigation. Without a trail linking each output to its inputs, finding the origin of a wrong number means re-running steps and guessing, and the practical result is that most organisations do not find it. They correct the visible symptom and the cause stays in place.
The control is an audit trail at the agent layer rather than the table layer: every output recorded with the inputs, prompts, tools and other agent outputs that produced it, so a result can be traced backwards in one query. This is what agent lineage does, and it is the difference between believing a chain behaved and being able to show it. A second, cheaper control helps immediately: propagate confidence between agents and require a low confidence input to be flagged rather than consumed silently.
The previous four failures are about agents reading metadata. This one is about agents writing it. Once an agent can generate descriptions, tags, classifications and relationships, it will produce more metadata changes in a day than a stewardship team has historically handled in a quarter.
Every organisation that hits this point takes one of two paths, and both are bad. Either each generated change goes into a review queue, which grows faster than it drains until the queue is abandoned, or generated metadata is published directly and machine written text becomes the authoritative description of assets nobody checked. The second path is more common because the first one visibly fails.
The cost of the first is a stalled programme. The cost of the second is subtler: plausible descriptions that are wrong in small ways, which then feed the agents in break one. Machine written metadata that is never verified is not a shortcut to a documented estate, it is an undocumented estate that looks documented.
The control is to stop treating review as a gate and start treating provenance as the record. Every metadata field carries who or what wrote it, when, and on what evidence. Machine written fields are visibly marked as such wherever they are displayed or served to an agent. Confidence decides routing, so high confidence inferences publish immediately and low confidence ones go to the declared owner. And a wrong field can be reverted and traced, which is what makes publishing first acceptable at all.
Underneath all five failures is one shift. Metadata was designed as documentation for humans, who read it with context, scepticism and the option to ask a colleague. Agents read it as instruction, literally, with none of those three. Three properties change from nice to necessary as a result.
Descriptions have to be machine readable, which means stating what the field contains, its unit, its grain and its permitted values rather than describing the field in prose. "Monthly recurring revenue in USD, excluding tax, at the account grain, as of the last day of the month" is usable. "Key revenue metric for the business" is not, and no model will improve it.
Ownership has to be resolvable programmatically. An agent that hits an ambiguous or restricted asset needs to route the question somewhere, and a name typed into a free text field years ago does not resolve to a person who still works there. Ownership belongs in a structured field that points at a current identity.
Freshness matters far more than it used to, for the reason stated at the start: an agent will not sense that something looks wrong. A stale description that a human reader would have quietly corrected becomes a systematic error, so the age of a description is now a quality signal in its own right.
| Metadata property | What a human reader tolerates | What an agent requires |
|---|---|---|
| Description | Prose, approximate, sometimes empty. The reader fills gaps from experience | Explicit contents, unit, grain and permitted values, with no gap to fill |
| Ownership | A name in a text field, or asking around until someone answers | A structured reference to a current identity that can be resolved without a human |
| Sensitivity | Convention and judgement about which tables not to open | Declared on the asset and enforced at the access layer for the agent identity |
| Freshness of meaning | Slightly out of date is harmless because the reader notices drift | A last verified date, because nothing in the run will notice drift |
| Lineage | Table to table is usually enough to answer where this came from | Column level, including which agent run wrote which field |
| Deprecation | Word of mouth. Everyone knows not to use the old table | An explicit deprecated flag, or the agent will keep using it forever |
Metadata cannot be maintained by hand at the size of a modern estate, so automation is not optional. The useful question is not whether to automate but which fields automation can be trusted with. The dividing line is stable: a system can infer what is observable in the data or in behaviour around it, and it cannot infer what someone has to decide.
Anything computable from the data itself is safe to generate and refresh automatically, because it can be recomputed and checked. Anything that encodes an intention, an obligation or an accountability is a declaration, and a system that generates it is guessing at something with consequences.
| Metadata field | Safe to generate automatically | Who or what should set it |
|---|---|---|
| Schema, data type, nullability, cardinality | Yes | Automated scan on a schedule. Recomputable, so an error is self correcting |
| Profile statistics, distributions, freshness of data | Yes | Automated observation. Also the cheapest early warning that meaning has changed |
| Usage: who queries an asset, how often, in which reports | Yes | Automated from query history. Better evidence of importance than any manual rating |
| Table to table and column level lineage | Yes | Parsed from queries and pipeline code. Manual lineage is out of date on the day it is written |
| Suggested tags and probable sensitive fields | Partial | Pattern detection proposes, and the declared owner confirms. High recall, imperfect precision |
| Draft descriptions of technical fields | Partial | Generated from schema, sample values and usage, then published with provenance and a low confidence route to review |
| Business meaning and definition of a metric | No | A named person. Two teams defining active customer differently is a decision, not a pattern in the data |
| Ownership and accountability | No | Declared and kept current. Inferring an owner from commit history gives you the last person who touched it, not the person answerable for it |
| Sensitivity classification of record | No | Declared by the data owner with compliance. Detection proposes the candidate, the declaration carries the obligation |
| Certification that an asset is approved for use | No | A person accepts responsibility. Automatic certification means nobody accepted anything |
Three automations look attractive and cause more damage than the manual work they replace. They are worth naming because each one is currently being sold as a feature.
| Automation | How it fails | Safer design |
|---|---|---|
| Publishing generated descriptions with no provenance marker | Machine text becomes indistinguishable from verified text, so nobody can tell what has been checked and the estate looks documented when it is not | Publish immediately, but mark the source and confidence everywhere the description is shown or served, and let owners promote a field to verified |
| Automatic sensitivity classification that also enforces access | A false negative silently exposes data, and unlike a false positive nobody reports it | Detection proposes and a declaration enforces. The classifier opens a task, it does not change a permission |
| Inferring ownership from activity such as commits or query volume | It returns the most active user, who is usually not accountable and often has left, and the record then looks maintained | Declared ownership tied to a current identity, with activity used only to suggest a candidate to a human |
| Agents updating their own metadata after a run | The system that made the change also writes the record of the change, so an error and its description agree with each other | Agent writes are recorded by the platform, not by the agent, and reviewed as a set by the asset owner |
These controls are ordered by how much they reduce risk per unit of effort. A team that implements the first four has removed the majority of the exposure described above.
Sequencing matters more than completeness. The controls above are the data layer of a wider programme, and the decisions about which agents are approved, who signs for them and what evidence a regulator will ask for sit one level up, in agentic AI data governance.
Decube covers the layer these failures happen in. The catalog holds declared ownership, sensitivity and descriptions with provenance, so an agent reads a field that someone is accountable for rather than a paragraph of unattributed prose. Automated profiling and quality monitoring supply the observable metadata continuously, which is also the signal that a column has changed meaning. Column level lineage records how a value was produced, including writes that came from agents, and Decube data governance carries the access and policy controls above it.
The part worth being honest about is that no platform can declare business meaning, ownership or sensitivity for you. Those three are decisions, and a tool that generates them is generating an opinion with your organisation's name on it. What a platform should do is make the declarations cheap to record, impossible to lose, and visible to every agent that reads the asset. If you want to see how that works against your own estate, request a demo.
Automated metadata management is the practice of generating and maintaining metadata by observing the data estate rather than by documenting it manually: schemas, profiles, freshness, usage and lineage are collected continuously, and suggested tags and draft descriptions are proposed for confirmation. It works because those fields are observable and recomputable. It does not extend to business meaning, ownership, sensitivity classification or certification, which are decisions a named person has to declare.
AI metadata management covers two directions that are often confused. One is using AI to produce metadata, such as generating descriptions or proposing tags. The other is producing metadata good enough for AI to consume, which means machine readable descriptions with unit and grain, ownership that resolves programmatically, declared sensitivity and a last verified date. The second direction is the one that decides whether agents give correct answers.
Automated metadata tagging inspects column names, data types, sample values and query patterns, matches them against pattern libraries and learned models, and proposes tags such as personal data, financial data or a business domain. Treat the output as a proposal rather than a decision: recall is high and precision is imperfect, so tags should open a confirmation task for the declared owner instead of directly changing access permissions.
Look for four capabilities rather than a brand: automated profiling that runs continuously, column level lineage parsed from queries rather than maintained by hand, provenance on every generated field so machine written metadata is visibly marked, and access control that can be scoped to an agent identity. Decube covers all four in one platform. Atlan and Alation are the established catalog options and Monte Carlo is strongest on observability, so the right choice depends on whether your gap is documentation, detection or agent readiness.
The requirement is a platform that combines automated quality checks, a policy layer that can enforce declared sensitivity, and metadata tagging that proposes rather than enforces. Decube combines quality monitoring, catalog and governance in one product, which matters here because quality alerts and metadata live in the same place. When the three sit in separate tools, the evidence a supervisor asks for has to be assembled by hand across all of them.
At minimum: a description stating contents, unit, grain and permitted values, a last verified date on that description, a declared owner that resolves to a current identity, a declared sensitivity classification enforced at the access layer, column level lineage that includes agent writes, and an explicit deprecation flag. An agent will not sense that something looks wrong, so every piece of context a human reader supplies from experience has to be written down.
Agentic AI data management is managing a data estate on the assumption that autonomous agents read and write it, not only people and pipelines. In practice it changes three things: access is granted to agent identities per asset instead of inherited from human roles, lineage has to record agent writes at column level, and metadata quality becomes a correctness control because agents act on descriptions literally.
Adoption is concentrated in organisations that already had a catalog and lineage in place, because agents need that layer to work at all. In regulated sectors such as banking, insurance and financial technology, where supervisors including OJK in Indonesia, APRA in Australia, MAS in Singapore and the NAIC in the United States expect evidence of control, deployments typically start with metadata agents that propose descriptions and tags for human confirmation rather than agents with write access to production data.
The control this article keeps returning to is that an agent action should pass the same permission and approval gate a human action would. In this one minute walkthrough Trusty reads the profiling results for a table, finds two columns holding negative values with no monitor watching them, proposes a monitor with a recommended test type and threshold, and creates it only after an explicit allow once or deny. The same session shows it answering a structural question by rendering a lineage diagram inside the chat and explaining the transformation. Watch it if you want to see what an approval gate on agent writes looks like in a working product rather than in a policy document.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Book a 30-min demo with us and see how lineage, quality, governance, and compliance come together in a single platform.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)