Quick recap. Agentic analytics has five layers: Data → Meaning → Access → Thinking → Action. The AI model sits on Layer 4 only. An agent is that model plus a key to your systems, a dictionary of your words, and a job.
Now the part that gets skipped in most articles.
Giving an agent a key to your systems is a security decision, not a technical detail. Each layer has its own risk. This is the checklist I use before any agentic project.
If you remember one line from this whole series, make it this one:
Access control belongs in the data layers, never in the prompt.
Every team I have watched try to enforce permissions with prompt instructions has eventually failed. A prompt is a request. An agent that is asked nicely not to show salary data will, one day, show salary data.
Layer 1 — Data
The risk: an agent handed a service account with full access sees everything, no matter who asked the question.
This is the most common mistake I see. It usually happens for an innocent reason. Somebody sets up the connection during a test. They use an admin account because it is quick. Then the test becomes production.
The controls:
- Use the asker's permissions. Row and column security should apply to the agent just as it applies to the person. If a junior marketer cannot see salary data, the agent must not see it for them.
- Keep the data in your region. In-warehouse AI — Cortex AISQL, Gemini in BigQuery, the same thing in Fabric — means customer data never leaves your private cloud. For a bank or an insurer in the EU, that is usually the whole conversation.
Good news: this layer is mostly solved. Warehouses have had good access control for years. You are configuring something that exists, not building it.
Layer 2 — Meaning
The risk almost nobody plans for: every copy of your data loses its permissions.
This one deserves a slow explanation, because it surprises people.
Layer 2 is full of copies. Not only the vector database — also the cached and materialised tables behind your semantic model, the aggregate tables somebody built for a dashboard, the extracts sitting in a BI (business intelligence) tool, and the catalog itself. Each of these is a place where data was copied out of a system that protected it.
The vector index is the clearest example. To make RAG (Retrieval-Augmented Generation) work, you load company documents into it. The HR policy. The board deck. The pricing sheet. Meeting notes. They are all cut into pieces and stored as text chunks in one place.
In the original systems those documents had permissions. The board deck sat in a folder only directors could open. But the permissions did not travel into the index. Now everything is just chunks in the same place.
Then somebody junior asks an innocent question. The agent searches, finds a matching chunk, and shows it to them. Nobody attacked anything. The system did what it was built to do.
The same thing happens with numbers. An aggregate table built to speed up a dashboard may quietly contain a breakdown the source table would never have shown that person. And the catalog can leak on its own: a table called layoffs_2026_q4, or a column described as "salary band", tells a reader something even if they never query it.
The controls:
- Carry the permissions into every copy. When you index a document or build an aggregate, record who may see it — and apply that on every search and every query.
- Filter at search and query time, not in the prompt. This is a filter, not an instruction.
- Do not copy what you do not need. The fastest way to avoid leaking the board deck is to not load the board deck.
- Treat metadata as data. Table names and column descriptions are readable too.
- Count your copies. If you cannot list every place a sensitive field has been duplicated, you cannot protect it.
The good news: the semantic model is also a security control. It already says which rows and columns each role may touch. That makes it the cleanest place to set access for every agent at once — and one certified model is far easier to secure than five quiet copies of the same data. Building Layer 2 well makes you safer, not just more accurate.
Layer 3 — Access
This is the sharpest layer, because access is the moment an agent stops reading and starts acting. Three risks here are real and documented.
Hidden instructions
An LLM (Large Language Model) cannot reliably tell the difference between data it should read and instructions it should follow. So text hidden inside your data, or inside a tool's own description, can redirect the agent.
This is not theoretical. In one documented case, a poisoned tool description made a messaging integration hand over whole message histories. To the user it looked like a normal conversation. The data went somewhere else.
Supply chain
A community MCP (Model Context Protocol) server is a dependency, exactly like any npm or pip package, and it runs next to your data.
The postmark-mcp package is the one to remember. It was published, adopted, used normally — then updated with a hidden backdoor that copied emails to an attacker. Nothing looked wrong from the outside.
There have been others: a bug in a Git MCP server, private repository data exposed through a GitHub MCP integration, a data leak between customers in a project-management connector.
Treat third-party MCP servers the way you treat third-party code. Review them. Pin the version. Prefer official servers from the vendor whose system you are connecting to. Be suspicious of a connector with fifty stars and one maintainer.
Too much permission
People approve a tool once and it keeps that access forever. Worse, the approval usually happens while somebody is trying to get a demo working — not while somebody is thinking about risk.
The controls
None of these are clever. They are the same controls you already use elsewhere:
- Least privilege. Each tool gets the minimum access it needs, and nothing more.
- Read-only by default. Writing is a separate, deliberate decision.
- Short-lived credentials. Tokens that expire, scoped to one purpose.
- Human confirmation for anything that writes, sends or deletes.
- Log every tool call, with enough detail to answer "what did it do, and why" a month later.
Set the permissions at Layers 1 and 2 and let the agent inherit them. Do not solve this at Layer 3 with a prompt that says "please do not show salary data."
Layer 4 — Thinking
Risk one: where do the prompts go?
When you send a question to a hosted model, two things travel: the question, and whatever RAG found to answer it. People forget the second part. Your customer data is in the prompt.
Enterprise plans normally keep your data out of training and offer zero retention. But that is a contract term, not a law of nature. Read it, and check what applies to your tier and your region.
If legal cannot accept it, this is the one layer where self-hosting an open model really solves the problem. Your data does not leave your network because there is nowhere else for it to go.
Risk two: a confident, wrong plan.
A group of agents can talk itself into a plan that is clear, well argued and wrong. Agents agreeing with each other is not the same as agents being right — especially when they share one model, and one set of blind spots.
The controls:
- Keep a person between the plan and anything that changes the real world.
- Make the agents show their work. A summary with the query attached can be checked. A summary alone cannot.
- Use a checker agent whose only job is to test the result against the dictionary. It catches a useful share of mistakes and costs almost nothing.
Layer 5 — Action
The risk is the audience, and the blast radius.
An alert is a document. If the agent posts revenue by client into a channel with 200 people, you have just published data that Layers 1 and 2 protected. Through the front door. With permission. In a format that is easy to screenshot.
Check the membership of the channel before you switch the alert on, not after.
The second risk is write access. There is a real difference between an agent that tells you the bidding strategy changed and an agent that changes it back. The first one is an assistant. The second one is spending your money.
The controls:
- Start read-only. Earn the right to write.
- When you do allow writes, set limits: how much can change, how often, and what happens automatically versus what waits for approval.
- Keep an undo. If you cannot reverse it easily, it should not be automatic.
- Check who is in the channel.
The human in the loop
Notice the last box in that image. It is the most important one, and it is not a nice-to-have added at the end. It is spread across the whole pyramid:
- You define the metrics — Layer 2. The dictionary is written by people who know the business.
- You set who may see what — Layers 1 to 3. Permissions are a human decision, enforced by systems.
- You approve the decision — Layer 5. The agent brings the problem and the evidence. You decide what to do.
The agent does the typing. It does not do the thinking about your business.
I want to be careful here, because this is the part people worry about. My view: this does not remove analysts. It removes mechanical work. The questions get harder, not easier. Somebody still has to know that the July spike was a tracking bug, not a market change. An agent has never watched a tag deployment go wrong on a Friday afternoon.
Does open source make this better or worse?
Both, in different places.
Better: run the model on your own machines and your prompts and customer data never leave your network. No retention policy to negotiate. No third-party breach to worry about. That is the strongest privacy argument in this series, and for some legal teams it ends the discussion.
Worse: you now own the patching, the network settings and the access rules. A managed platform has a security team doing that for you. The supply chain risk also moves to you — a community connector is code running next to your data, and nobody is contractually responsible for it.
"Open weights" is not "open source". You get the model and permission to run it. You do not get the training data. That is enough to keep your data private. It is not enough to audit what the model learned.
And check which tier your security features are in. Many open-source tools are open core: a free self-hosted edition plus a paid commercial tier. Metabase, for example, puts row-level permissions and audit logs in the paid tier. Row-level permissions are exactly what Layer 2 needs, and audit logs are exactly what Layer 3 needs. So "we will use the free edition" can quietly mean "we have no row-level security and no audit trail" — which is a security decision made by a budget conversation. Check the feature list before you choose the edition, not after.
My honest position: self-hosting solves a privacy problem and creates an operations problem. If you already run infrastructure well, that is a good trade. If you do not, a managed service with a proper enterprise contract is usually safer in practice than a self-hosted stack nobody has time to patch.
A short checklist
Before you connect an agent to anything real:
- Does the agent see only what the person asking can see?
- Does the vector index respect the permissions of the source documents?
- Is every tool read-only unless there is a reason it is not?
- Do you know who wrote every MCP server you installed, and is the version pinned?
- Are the credentials short-lived and scoped?
- Is every tool call logged — and is audit logging in the edition you actually bought?
- Have you read the model provider's retention terms for your tier?
- Does a person approve anything that changes money, data or a customer's experience?
- Do you know who is in the channel the alerts go to?
- Can you undo it?
If you cannot answer all ten, start with a read-only agent on one question you understand well. That is a safe way to learn.
What I am still not sure about
Trust at scale. Agents work well on narrow questions. I have not yet seen one I would let write a board report unsupervised.
Cost. Agents run many queries to answer one question. On usage-based pricing that bill can surprise you, and I do not have a good rule of thumb yet.
Complexity. Every extra agent adds a place where things break quietly. Sometimes one good prompt beats five orchestrated agents.
Open source versus paid. I have opinions. I do not yet have a fair side-by-side test — that is what I want to run next.
If you are running something like this in production, I would like to hear how it is going. I am especially interested in your failure rate after six months, not after the demo.
Sources
Security — MCP security: risks, real incidents and controls (2026) — the postmark-mcp backdoor and other documented incidents · MCP security vulnerabilities: prompt injection and tool poisoning · MCP threat modelling and tool-poisoning analysis (peer-reviewed) · Microsoft: securing AI agents as they move from reading to acting
Standards and platforms — Introducing the Model Context Protocol · Snowflake: AI security and MCP governance · Google Cloud: Conversational Analytics, Q3 2026
Open source — Open-source LLMs in 2026: benchmarks and licences
That is the end of the series. Part 1 — The map · Part 2 — The tools · Part 3 — Privacy and security.
Disclaimer
Informational only; not advice. Believed accurate as of August 2026, without warranty. Vendors change names, features and licensing — check official sources before deciding. Trademarks belong to their owners.
This article reflects my personal views, not those of any employer or client.
I write about data, analytics and AI at makskulish.com. You can also find me on LinkedIn.