Who Can Touch Your Cloud Account, and What Happens When It's an Agent

Somebody at your cloud provider has to keep the hardware running. Firmware gets patched, a host goes unhealthy, a support case needs a look at what actually happened. That work requires access, and the access it requires is the one thing you cannot check from inside your own account. You see your own logs. You do not see theirs.

The industry has two answers to this, and they are genuinely different ideas rather than two labels for the same product. Every major provider ships some of both.

School one: make it structurally impossible

The first answer is to build the platform so that there is no operator path to customer data at all, and then say so in a form you can hold them to. AWS documents this for the Nitro System: “there is no mechanism for any system or person to log in to EC2 Nitro hosts, access the memory of EC2 instances, or access any customer data stored on local encrypted instance storage or remote encrypted EBS volumes.” Operators get a limited set of authenticated, authorized, logged and audited administrative APIs, and none of those APIs reach customer data. The same design thinking runs through the broader confidential computing category.

The cost is named on that same AWS page, which is the useful part. In rare cases an operator cannot debug a problem where it is happening. The path instead is to work with the customer, at the customer’s request, to reproduce the issue on dedicated non-production Nitro debugging hardware. A control with no exception path has no exception path when you want one either.

School two: allow it, but gate it and log it

The second answer accepts that operator access will sometimes be necessary and puts the customer in the loop. Google Cloud’s Access Transparency produces logs of provider personnel access with reason codes, so the access shows up in your record rather than only in theirs. Access Approval goes further and requires a customer administrator to approve access before it happens, for a limited period. Azure Customer Lockbox works on the same principle: a Microsoft engineer’s request comes to you, and you approve or reject it.

Microsoft documents the boundaries of that in the same place. Lockbox requests are not triggered in emergency scenarios outside standard operating procedures, such as restoring service access, preventing data loss, or investigating a security or abuse incident, and coverage is per service rather than universal. That is a documented characteristic of the control, not a gotcha.

Both schools have serious adherents. One camp wants a guarantee with no human discretion in it, because a control you can appeal to under pressure is a control that bends under pressure. The other wants an operational path that is honest about existing, because support and incident response happen regardless, and access you can see beats access you have merely been assured does not occur. Which matters more depends on what you are running and who audits you.

Then you hire an operator of your own

An agentic system changes the shape of this question. It runs inside your account, under your credentials, and it is a third kind of operator: not you, not the provider.

The awkward part is that its scope is decided at runtime. A human operator’s permissions are set at design time and reviewed. An agent has a set of tools and a goal, and what it actually touches is whatever a chain of inference decides is relevant this time. You authorize a capability, not an action.

The Five Eyes agencies published joint guidance, Careful Adoption of Agentic AI Services, in April 2026, authored by six agencies: CISA and NSA in the US, the UK NCSC, the Australian Signals Directorate’s ACSC, the Canadian Centre for Cyber Security, and New Zealand’s NCSC. It names five primary categories of security risk, one of which is privilege, and recommends keeping current deployments to low-risk, non-sensitive tasks, monitoring for anomalous behaviour, and keeping detailed logs of agent decisions and actions. The logging recommendation is the same instinct as Access Transparency, applied to an operator you brought in yourself.

The failure that leaks nothing

Blast radius is not only about data. An agent can respect every data boundary you set and still spin up expensive resources on a retry loop for months. Nothing leaks. The bill grows.

Budgets are the standard instrument here: AWS Budgets, Azure Cost Management budgets, Google Cloud budgets and alerts. Be clear about what you are getting: these are primarily alerting and reporting mechanisms, not hard spend caps. They tell you. Stopping is something you wire up separately, and quota or rate limits on the specific APIs an agent can call will usually bite sooner than a monthly budget threshold does.

If you take one thing from the provider debate into your own account, take the reason codes. Access Transparency’s design assumption is that access will happen and the useful artifact is a record of why. Ask the same of an agent: not just which API it called, but what it was trying to accomplish when it decided to. A log of actions tells you what broke. A log of intent tells you whether to grant the permission again.