Everyone demos the fix. This is the other half: every change Tamnoon’s engine would not make in our own cloud, what it read first, why it stopped, and what would change its mind. Identifiers removed.
Watch mode: read-only, 30 minutes, nothing written. You keep the decision record, including the findings Tamnoon declines in writing.
PICK A TIME →TRUSTED BY TEAMS THAT CANNOT AFFORD A BLIND FIX
Warner Music Group runs this, on record.
THE RECORD · OUR OWN AWS · SEP 17 TO OCT 2, 2026
17
changes it would not make yet, each with the reason and the missing fact
83
alerts it proved safe in the same period, in two changes
RECEIPT NO. 17
A scanner sees a bucket anyone can read and calls it a finding. It is a finding. It is also where our logo lives, embedded in emails and pages we do not control. The obvious change breaks every one of them.
So the engine did not make it. It wrote down what it read, why it stopped, and the exact fact that would turn this into a yes.
Not yes. Not no. The one fact that decides it.
Bring us your ugliest finding →No. 17
Finding
A bucket policy grants read to everyone.
What we read first
The bucket hosts the company logo, and public access to it is intentional. Whether the logo is referenced directly by bucket URL from websites, emails, documentation or external applications; whether a CDN already fronts the bucket; whether other objects in the bucket are also meant to be public.
Verdict
Reason
Removing the global read permission outright would break the logo everywhere it is embedded. The right change is a scoped delivery mechanism, and its shape depends on how the logo is consumed today.
What would change it
The delivery architecture, and the list of objects that must stay public.
How to do it by hand
Put a CDN distribution with origin access control in front of the bucket; move references to the CDN address; restrict the bucket policy to the CDN principal, or to the specific public prefixes; verify; then remove the global grant.
Before it changes anything, the engine reads who uses the resource, what depends on it, who owns it and what changed. Then it gives one of three verdicts, and every verdict carries the same six fields.
A proven route, the rollback ready before anything moves, run through your own change process.
Declined in writing, with the evidence attached. Nothing runs.
Says exactly what is missing, and asks the person who has it.
WHAT A DECLINE LOOKS LIKE
In our own cloud this period the engine issued no RISKY: every change it would not make, it held as a question. This is the receipt you get when the answer comes back and the change still cannot be proven safe.
Built from receipt No. 04, with the facts filled in: all fifteen services use the secret, and the identity provider cannot rotate it in place. "Rotate the secret" is the most common automated fix there is. Here it would take the platform down.
Illustration. Not from our record.
Illustration
Finding
Automatic rotation is disabled on a secret holding OAuth2 client credentials used by fifteen serverless services.
What we read first
All fifteen roles read the secret in the last 30 days. The identity provider cannot rotate this kind of client in place: a new credential means deleting and recreating the client. No rotation procedure for this client has been tested.
Verdict
Reason
Turning on rotation would invalidate the credential all fifteen services use at the same moment, and the services behind the platform’s API would fail together. The change cannot be proven safe as a single step.
What would change it
A rotation procedure tested once on a non-production client, and consumers moved to the new credential one at a time.
How to do it by hand
Create a second client; store its credential as a new secret version; move consumers to it one at a time and verify each; delete the old client; only then enable scheduled rotation.
RECEIPT NO. 18
A count of refusals means nothing without the yes beside it. Here is a SAFE from the same period, in the same six fields.
Proven safe and ready to run through our own change process, with the rollback prepared before anything moves.
No. 18
Finding
A CI/CD pipeline role’s inline policy grants s3:PutObjectAcl, write access to S3 object ACLs.
What we read first
Ninety days of CloudTrail for the role: zero PutObjectAcl calls. Both target buckets enforce bucket-owner object ownership, which disables ACLs entirely, so any such call would fail with AccessControlListNotSupported. The deploy stage: a CDN and a bucket policy, no object ACLs.
Verdict
Reason
The permission has not been used, cannot work on these buckets, and nothing in the deploy path depends on it. Removing one action leaves every other permission, and the running pipeline, untouched.
What would change it
A PutObjectAcl call in CloudTrail, or either bucket moving off bucket-owner-enforced ownership.
How to do it by hand
Back up the inline policy to JSON. Remove s3:PutObjectAcl from every statement’s Action list and re-apply the policy. Confirm the action is gone. To roll back, re-apply the backup.
Half of everything ever detected in the cloud is still open: 53% across 14.86 million detections, up from 41% a year earlier. A critical finding now stays open 150 days on average.
The findings were never the hard part. The change is. Nobody approves a change in production that a machine cannot explain, so the remediate buttons stay off and the backlog grows.
So the first thing we automated was restraint. Every vendor can show you a fix. This page is the other half, from our own cloud.
Everyone demos the fix. Ask them to demo the decline.
Everyone automates the yes.
We mastered the no.
Bring us your ugliest finding. The one that has been open for most of a year because nobody wants to be the person who touches it.
Watch mode: read-only, 30 minutes, nothing written. You keep the decision record, including the findings Tamnoon declines in writing.
PICK A TIME →Everyone in security sells fear in a black hoodie.We are the ones with the octopus.
TAMNOON 2026 ALL FINDING IDS AND TIMESTAMPS SHOWN ARE FICTIONAL PRIVACY · TERMS