Key insight
Using a cloud service splits security between the provider (the buildings, machines, and core service) and you (your data, access, and configuration). The most dangerous mistake is not a technical flaw but an assumption gap — each side assuming the other has a job covered. AI services add new lines to the split, and assuming the provider handles your data and your agent's permissions is the same gap in newer clothes.
When you rent an apartment, some things are the landlord’s job and some are yours. The landlord maintains the building’s structure and the locks on the outer doors; you are responsible for locking your own front door and not leaving a key under the mat. If you get burgled because you left your door wide open, that is not the landlord’s failure — even though the landlord genuinely does own the building’s security. Cloud computing works exactly like this, and the arrangement is called the shared responsibility model. This article — the last in the series — explains the split, the gap that catches people, and the new lines AI services add.
1 · What the provider secures, and what you do
When you use a cloud service — running your software on a provider’s computers instead of your own — security is divided. The provider secures the things underneath: the physical buildings, the machines, and the core service itself. You remain responsible for the things on top: your own data, who you grant access to, how you configure the service, and the accounts and passwords of your own people. The exact line moves depending on how much of the stack you hand over, but there is always a line, and there is always a part that stays yours.
2 · The most dangerous mistake: the assumption gap
The single most dangerous mistake in this whole arrangement is not a technical flaw at all. It is an assumption gap: each side quietly assumes the other has a particular job covered, and so neither actually does it. Nobody attacked the seam; the seam was simply left unguarded because both parties looked at it and thought “that’s theirs.” The provider’s part can work flawlessly and your data can still leak, entirely through your half of the split, if you assumed the provider had it.
Most cloud data leaks are not the provider being breached. They are the customer’s half of the split, left undone because someone assumed it was covered. The words “surely they handle that” deserve to be checked, in writing, every single time.
3 · A worked example: the open storage bucket
A storage bucket — a container for files in the cloud — is left open to the entire internet. The customer assumed the provider secured it by default; the provider assumed the customer would configure the access they actually wanted. Both assumptions were reasonable-sounding, and together they were fatal: the bucket sat open, and its contents were readable by anyone who found the address. The provider’s part worked perfectly the entire time. The data still leaked, entirely through the customer’s half of the shared responsibility, because the seam between the two halves was the one place nobody actually stood.
4 · The new lines AI services add
AI services add fresh, easily-missed lines to this same division. The provider secures the model and the platform it runs on. But you almost always remain responsible for what data you feed the model, who is allowed to use your agent, what tools that agent is permitted to call, and what it is allowed to do with the results. Assuming the AI provider handles all of that for you is the exact same assumption gap as the open storage bucket, just wearing newer clothes. An AI agent built on a provider’s model inherits a split most people never stop to read — and the dangerous half, as always, is the one you assumed was someone else’s.
5 · Working the model on purpose
- Find the actual line, in writing. Every serious provider publishes where their responsibility ends; read it rather than guessing.
- List your half explicitly. Data, access, configuration, and accounts are almost always yours — write down who owns each.
- Distrust “secure by default” assumptions. Verify the default rather than assuming it matches what you actually need.
- Re-check the line for every new service. Each AI service and each new tool can move the line, so a split you learned once does not transfer automatically.
6 · A simple test you can run this week
1. Pick one cloud service, or one AI service, you rely on.
2. Write down, in two columns, what the provider secures and what you secure.
3. For anything you are unsure about, find the answer in the provider’s written model — do not guess.
4. Any item where both columns said “the other one” is your assumption gap.
7 · Glossary — every short-form term, spelled out
- Shared responsibility model
- The division of security duties between a cloud provider and the customer using the service.
- Cloud service
- Running your software or storing your data on a provider’s computers instead of your own.
- Assumption gap
- A duty left undone because each party assumed the other had it covered.
- Storage bucket
- A container for files in the cloud; a common place an assumption gap leaks data.
- AI agent
- Software that decides, on its own, which tools to call and which actions to take, often built on a provider’s model.
Cloud security is split: the provider secures the layers underneath, you secure your data, access, and configuration.
The most dangerous mistake is the assumption gap — a duty nobody does because each side assumed the other had it.
Most cloud leaks are the customer’s half of the split, not the provider being breached.
AI services add new lines — your data, who uses your agent, and what tools it may call are almost always yours. Find the line, in writing.
References
- NIST Special Publication 800-145, The NIST Definition of Cloud Computing, National Institute of Standards and Technology. csrc.nist.gov
- Cloud Security Alliance, Security Guidance for Critical Areas of Focus in Cloud Computing — shared responsibility. cloudsecurityalliance.org
Twenty concepts, each built from zero: from data lineage and blast radius through the named agent anti-patterns, quantum-era risk, and the everyday controls — least privilege, zero trust, defense in depth — that shrink exposure on purpose. Return to the Security Fundamentals index any time, or carry these ideas into the deeper field guides they connect to.