Data analysis agents query, join, and summarize datasets on request, often translating a plain-language question into a database query or analytics call, and their central risk is subtle: the query itself can be entirely correct and still return data the person asking was never authorized to see. A well-formed query executed against the wrong scope of data isn't a bug in the query logic. It's a permissions failure that has nothing to do with whether the SQL or API call the agent generated was technically sound, which means query correctness review, the thing most teams naturally focus on, doesn't catch this class of problem at all.
Query generation isn't the main risk, authorization is
Plenty of attention goes into whether an agent generates safe, injection-free queries, and that matters, but it addresses a different problem than authorization scope. An agent that generates a perfectly safe query against a table it shouldn't have touched for this particular user still causes a data exposure incident. Authorization needs to be enforced at the data layer itself, row-level and column-level security applied regardless of what the agent's generated query asks for, not left to the agent to self-limit based on instructions about what it's supposed to be allowed to see.
Aggregation can leak what individual records wouldn't
An agent that's correctly blocked from returning a specific customer's individual record can sometimes still leak equivalent information through aggregation, a sufficiently narrow filter combined with a count or average can effectively reveal a single data point even though no single row was ever directly returned. This is a well-known statistical disclosure risk in traditional data analysis, and it applies directly to analysis agents that construct filters and aggregations dynamically based on a user's natural-language request.
Natural language requests can smuggle scope expansion
A user asking a data analysis agent progressively broader questions, "show me this customer's orders," then "show me similar customers," then "show me everyone in this segment," can walk an agent from a narrow, authorized query into a much broader one without any single request looking like an obvious overreach. Authorization enforcement needs to apply fresh to each generated query, not accumulate permissiveness based on the conversation's trajectory.
Output can carry sensitive values into places they shouldn't go
Once an agent has queried sensitive data, what it does with the result matters as much as how it got the result. A summary that includes raw sensitive values in a shared report, a chart exported to a less-controlled destination, or a follow-up action that forwards query results to another system can leak data that was correctly scoped at the query stage but mishandled afterward.
Data lineage matters for trust in the output too
Beyond exposure risk, an analysis agent that pulls from stale, deprecated, or inconsistent data sources can produce a confidently wrong analysis that looks identical to a correct one. Tracking which specific tables, views, or snapshots fed a given analysis gives reviewers a way to sanity-check a surprising result before it drives a real decision.
Schema changes can silently break authorization logic
Row and column-level authorization rules are frequently written against a specific version of a database schema, and when that schema changes, a renamed column, a new table that duplicates sensitive data under a different name, a view that joins previously separate tables, the authorization logic doesn't automatically follow along. It's entirely possible for a data analysis agent's underlying queries to keep working correctly after a schema change while the authorization rules meant to constrain those queries quietly stop covering the new structure. Authorization logic needs to be treated as part of the schema itself, reviewed and updated in the same change process, rather than as a separate layer that gets revisited only when someone remembers to check it.
Where TELEON fits
TELEON's policy enforcement at the tool-call boundary can apply row and column-level authorization checks to data queries an agent issues, independent of how the query was generated or what the conversation's trajectory implied was acceptable, and its privacy vault tokenization helps keep sensitive values out of a model's context when the analysis task doesn't actually require the raw underlying data.
Designing aggregation-level disclosure controls and data lineage tracking for a specific analytics stack is specialized work that depends on the underlying data platform.
A short checklist
- Enforce row and column-level authorization at the data layer, not in agent instructions.
- Re-check authorization on every generated query, not just at the start of a conversation.
- Apply aggregation thresholds to prevent statistical disclosure through narrow filters.
- Review where query output goes after generation, not only how it was retrieved.
- Track data lineage so a surprising result can be traced back to its actual source.
- Watch for conversational patterns that gradually expand query scope over time.
- Tokenize or minimize sensitive raw values in the model's context where possible.
Data analysis agents make it easy to ask a good question and get a fast answer, which is exactly why authorization has to live below the query generation step rather than inside it. A model that writes a flawless query against data it should never have touched has still failed, and no amount of query quality review will catch that failure if nobody's checking scope at the data layer itself. The teams that get this right tend to treat the data platform's own access control as the actual security boundary, with the agent as just one more client subject to it, rather than treating the agent's good behavior as the thing keeping the data safe.