There is a seductive demo making the rounds in cloud security right now. A tool finds a misconfiguration, reasons about it, and fixes it on the spot. No ticket, no human, no waiting. It looks like the future, and in a narrow sense it is. But watch what it requires to work: a role in your account that can change things, held by the vendor, standing by at all times, waiting to act on the tool’s own judgment.
That is the part nobody puts on the slide. The fix is impressive. The permission behind it is the most dangerous object in your cloud.
We build a security platform, and we made a deliberate choice about this. CloudDefender is read-only by default. When a change genuinely needs to happen, we never reach for a standing write role. We reach for access that is opt-in, scoped by you, and bounded in either time or blast radius. This piece is the reasoning behind that line, because it is a line every team evaluating security tooling should be drawing on purpose rather than by accident.
The risk is standing authority, not writing itself
It is easy to hear “read-only” as a religion and stop thinking. The honest position is more useful. Writing to an account is not evil. Somebody has to fix the public bucket, close the open security group, and enable the encryption. The question is who holds the ability to do that, how broad it is, and how long it lasts.
A standing broad write role fails on all three. It is held by a third party, it is broad because nobody scopes a fix role tightly when they are in a hurry, and it lasts forever because it is attached to the integration. Now combine that with automation. A tool that both decides a resource is dangerous and holds the credentials to change it is a very efficient way to take down a production workload on a single confident wrong answer. The blast radius of a mistake is no longer one analyst clicking the wrong button. It is a machine acting at scale on a model’s certainty.
The uncomfortable part is that the standing role is dangerous even when the tool is perfect. A credential that can change your account is a target the moment it exists. If the vendor is breached, that role is now the attacker’s role. You did not just trust the tool’s judgment. You extended your account’s trust boundary to include the tool’s entire security posture, its employees, its supply chain, and its incident response. Most teams would never sign that deal if it were written down plainly. They sign it anyway because it arrives disguised as a convenient feature.
Read-only by default is enough more often than you think
Start from the assumption that the platform can look but not touch, and a surprising amount of value survives. Detection does not need write access. Triage does not need write access. Ranking, clustering, deduplication, and prioritization are all pure reads. The entire job of turning a wall of findings into a short, ordered list of what matters is a read-only job.
Even remediation mostly is. When a finding deserves a fix, a security platform does not have to be the thing that applies it. It can produce the fix as code. A CloudFormation template, a Terraform module, a service control policy, or a copy-paste CLI command, generated for that specific finding, that you review and launch in your own account. The platform writes nothing. You keep the deploy in your own change process, your own pipeline, your own approvals. The tool contributes the expertise. You contribute the authority, because it was always yours.
This is not a downgrade from the autonomous-fix demo. It is the same fix, minus the standing role and minus the risk that the tool applies it to the wrong resource at the wrong time. You trade a few minutes of human review for the elimination of an entire class of catastrophic failure. For most changes, that is a trade any sane operator makes.
When you do need write, borrow it. Do not keep it.
Some workflows genuinely benefit from the platform making the change, and pretending otherwise is just dogma. Scheduled cost and hygiene actions are the clearest case. If you want idle instances stopped every night, generating a template you deploy by hand every evening is absurd. Something should just do it.
The answer is not a standing broad role. It is a role scoped so tightly that even full compromise of it buys an attacker almost nothing. Two patterns do this well.
The first is tag scoping. A managed-execution role that can stop and start EC2 instances, but only instances the customer explicitly tagged for it, can do exactly one narrow job and is blind to everything else in the account. The customer decides what is in scope by applying a tag, and can remove a resource from scope by removing the tag. The permission is real, the write is real, and the blast radius is a set the customer controls by hand. That is a defensible amount of authority because it is small and legible.
The second is time scoping, which is the subject of a companion piece on just-in-time access. Instead of a role that can always act, you broker short-lived credentials that a customer approves for a specific task and that expire on their own in minutes. Nothing stands by. There is no long-lived key to steal because the credential did not exist five minutes ago and will not exist five minutes from now. Backup and recovery workflows follow the same logic: a single, tightly-scoped, opt-in role the customer deploys in their own account, doing one job, off unless they turn it on.
The through line is simple. Authority should be borrowed, scoped, temporary, and granted by you, never held broadly and indefinitely by us.
Three tests every write capability should pass
If a security vendor asks for the ability to change your account, put the request through three tests before you agree. These are the tests we hold our own features to.
Is it opt-in and default-off? The capability should not exist until the customer deliberately creates the role in their own account. Read-only should be the state of a fresh connection, and every write path should be a decision the customer makes on purpose, with a clear sense of what they are enabling.
Is it scoped by the customer, not the vendor? The customer should decide the boundary, whether that is the set of tagged resources, a permissions boundary the role cannot exceed, or the specific managed policy attached. A vendor that scopes its own write access is grading its own homework. The account owner draws the line.
Is it bounded in time or blast radius, and fully audited? Either the credential expires quickly, or it can only touch a small, customer-defined set of resources, and ideally both. And every action it takes should land in the customer’s own CloudTrail, attributable to a specific request, so the account owner has a complete record in a log the vendor does not control.
A capability that passes all three is a tool. A capability that fails any of them is a liability wearing the costume of a feature.
What this costs, and what it buys
Being honest about the tradeoff matters. The read-only-by-default posture costs you the movie-magic moment where a problem fixes itself before you finish reading the alert. For a handful of low-risk, high-volume, well-understood changes, that automation would genuinely save time, and the scoped-write patterns above are how we give it back without the standing role.
What it buys is the thing that actually keeps you employed after an incident. Your security tool cannot be turned into a weapon against you. A compromise of the vendor does not become a compromise of your production account, because there is no standing key to steal and no broad role to hijack. Your change management stays intact, because meaningful writes flow through your own review and your own pipeline. And your audit story is clean, because you can show exactly what was changed, by whose authority, for how long, in your own logs.
For a CISO, this is the difference between explaining to the board that your vendor’s breach was contained by design and explaining why a third party had a standing key to your crown jewels. One of those conversations ends your week. The other ends your job.
The shape of the bet
The last few years of security tooling have been a race to do more on your behalf. We think the more important race is to need less from you. The best posture for a cloud security platform is to be enormously useful with almost no authority, and to treat every increment of write access as a deliberate, scoped, revocable exception rather than a default convenience.
Read-only should be the resting state. Remediation should be code you deploy. Managed writes should be tag-scoped to a set you control. Elevated access should be borrowed for minutes and then gone. And a standing broad write role held by your vendor should be the one rung on the ladder you never step onto.
Coverage should scale. Authority should stay scoped, temporary, and yours to grant.
Sources and reporting notes
- This article describes CloudDefender’s own design posture as of publication: read-only auditing by default, remediation delivered as customer-deployed infrastructure as code, and three opt-in, default-off, customer-scoped write paths (tag-scoped managed execution for scheduled EC2 actions, just-in-time brokered access via short-lived credentials, and a tightly-scoped backup and recovery role). The just-in-time model is covered in depth in a companion article.
- The IAM patterns referenced (cross-account roles gated by an external ID, permissions boundaries, tag-based conditions, and short-lived credentials via the AWS Security Token Service) are standard AWS mechanisms, not product-specific inventions.
- No specific third-party vendor is named or characterized. The “autonomous fix” pattern is described as a general industry direction, not an account of any particular product.
CloudDefender audits your AWS accounts read-only by default. Where a fix genuinely needs to make a change, it never takes a standing write role: access is opt-in, scoped by you, and either short-lived or narrowly tagged, and every action lands in your own CloudTrail. The platform contributes the expertise. You keep the authority.