Where does my data security responsibility end when using Agentic AI?
We are evaluating an Agentic AI platform for internal workflows. The vendor says they handle infrastructure security, patching, network isolation, and service availability.
What I am trying to understand is where our responsibility actually stops.
In practice, the agents will read internal documents, call external APIs, and act on behalf of users in a few systems. The provider keeps repeating the shared responsibility model, but that phrase gets vague very quickly.
A concrete point: providers may secure the platform itself, but 45% of data leaks still happen because customers misconfigure access, storage, connectors, or logging on their side. So if an agent exposes sensitive data due to a bad permission setup or an overly broad tool policy, is that fully on us? Or is there a reasonable boundary where the provider should also prevent obviously unsafe configurations?
I am not asking for legal advice. I am asking from an engineering and operations perspective: where do you draw the line in real deployments?
Answers
Bastian Wolf
(Edited)
A simpler rule:
If the agent touched your data, your permissions, or your business process, assume you still have responsibility.
The provider can absolutely help by:
But none of that removes your need to validate who can do what through the agent.
I would also be careful with the phrase "misconfiguration". It sounds like a minor settings issue. In reality it often means one of these:
That is not just configuration. That is governance failure expressed as configuration.
Eva Hartmann
(Edited)
Good point. We had an incident review where "misconfiguration" made it sound accidental and narrow, but the root cause was really ownership failure.
Bastian Wolf
(Edited)
Yes. "Misconfiguration" is often the final symptom, not the first cause.
Nora Albrecht
(Edited)
There is also a basic procurement mistake hidden in the question.
Do not ask "where does responsibility end?" first.
Ask "which controls are non-transferable?" first.
For most companies using Agentic AI, these are non-transferable:
Once you define that list, the responsibility boundary becomes less philosophical.
In other words: stop trying to locate a clean line. Build a control matrix.
Provider column:
Customer column:
Shared column:
That usually gets stakeholders out of the abstract debate.
David Rehm
(Edited)
This is the answer I would hand to management. "Build a control matrix" is less likely to trigger a circular conversation.
Nora Albrecht
(Edited)
Exactly. People ask for a boundary line because it feels simpler, but operational security is usually a table, not a line.
Henrik Falk
(Edited)
From an operations angle, your responsibility ends only where your control ends.
That sounds obvious, but it helps in audits.
Ask of every failure mode:
If yes, then you own it operationally.
For Agentic AI specifically, I would track four separate surfaces:
1.Input risk
What data enters the model and from where.
2. Execution risk
What tools the agent can call and with which credentials.
3. Output risk
Where generated content can go.
4. Persistence risk
What gets stored, for how long, and who can retrieve it later.
Teams often focus only on input privacy and forget that output and persistence are just as dangerous.
So no, your responsibility does not end when the provider says "the infrastructure is secure". That is the starting line, not the finish line.
Leonhard Dietz
(Edited)
The four-surface split is useful. We kept mixing storage retention issues with prompt filtering issues and ended up with muddy ownership.
Katharina Ebert
(Edited)
I would add model routing too if the platform can silently switch between models or regions. In some organizations that becomes a compliance issue fast.
Henrik Falk
(Edited)
Agreed. I mentally put that under persistence / control plane behavior, but it is worth calling out separately if the platform abstracts it away.
Tobias Krämer
(Edited)
I would split this into "can the provider prevent it?" and "can the customer validate it?"
If the answer to both is yes, then both sides own part of the risk.
Example: an agent is configured with write access to production systems and no human approval step. That is obviously dangerous. The customer created the risk, but the provider could still reduce blast radius by offering sane defaults:
So I do not fully agree with the strict version of "misconfiguration is always the customer's fault". That is too clean and does not match how real platforms work.
A mature provider should make unsafe states harder to reach. A mature customer should not rely on the provider to save them from bad governance.
Operationally, I would define the boundary like this:
The part many teams miss is ongoing review. They configure once, then six months later the agent has ten more connectors, three more privileged groups, and nobody remembers why.
Jan Böhm
(Edited)
This matches what we saw internally. The initial configuration was not the problem. Permission drift was.
Sabine Keller
(Edited)
I agree with this answer more than the first one. Shared responsibility has to mean something concrete, otherwise it is just liability shifting.
Tobias Krämer
(Edited)
Right, but I still would not confuse platform guardrails with accountability. The provider can reduce risk without becoming the owner of your bad access model.
Anna-Maria Schuster
(Edited)
You should assume your responsibility ends later than the sales material suggests.
For engineering purposes, the provider is usually responsible for the security "of" the service, while you remain responsible for the security "in" the service.
In an Agentic AI setup, that usually means the provider owns things like:
You still own at least these:
If your agent can read a payroll bucket because someone mapped the wrong group to the wrong connector, that is almost certainly your failure, not the provider's.
Where I would draw the boundary is this:
1. If the platform is compromised despite correct use, that is provider territory.
2. If the platform behaves as designed, but you gave it dangerous permissions, that is customer territory.
3. If the platform allows a configuration that is predictably unsafe and does not warn, block, or document it, then responsibility is shared, but you still absorb most of the operational damage.
So the practical answer is: your responsibility stops at the provider's control plane and underlying managed infrastructure, but it does not stop at agent behavior. Agent behavior is mostly downstream of your own policies, scopes, and integrations.
Treat Agentic AI like a very fast junior admin with API keys. That framing is usually enough to reset expectations."
Felix Brandt
(Edited)
Treat Agentic AI like a very fast junior admin with API keys.
That is the most useful one-line model I have seen for this. Especially the part about agent behavior not being "provider-owned" just because the agent runs on their stack.
Miriam Vogt
(Edited)
I would add one more item: data egress policy. A lot of teams get RBAC mostly right and then forget the agent can still send output to a webhook, SaaS ticket system, or email connector.
Anna-Maria Schuster
(Edited)
Yes. Good addition. In practice I treat outbound paths as separate trust boundaries, not just features.