Tamnoon

The changes our engine did not make.

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.

READ-ONLY WATCH MODE · NO ACCESS CHANGES · NOTHING WRITTEN · 30 MINUTES

See which of your findings are safe to close now.

Watch mode: read-only, 30 minutes, nothing written. You keep the decision record, including the findings Tamnoon declines in writing.

PICK A TIME →
Oops! Something went wrong while submitting the form.

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

Start with the bucket that is supposed to be public.

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

A public bucket that is supposed to be public

Global Get Permissions on AWS S3 Bucket via Bucket Policy · 1 alert · 1 asset · Sep 25 2026

AWAITING DATA

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

AWAITING DATA

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.

Three verdicts. One format.

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.

SAFE

A proven route, the rollback ready before anything moves, run through your own change process.

RISKY

Declined in writing, with the evidence attached. Nothing runs.

AWAITING DATA

Says exactly what is missing, and asks the person who has it.

WHAT A DECLINE LOOKS LIKE

And what a RISKY 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

Rotating a secret fifteen services depend on

Unrotated secret in AWS Secrets Manager · illustration based on receipt No. 04

RISKY

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

RISKY

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

And the one it proved safe.

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

A write permission nobody used, on buckets where it cannot work

IAM role with write access to resource policies · 1 alert · 1 asset · Oct 2 2026

SAFE

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

SAFE

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.

Why we publish our own no.

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.

See which of your findings are safe to close now.

READ-ONLY WATCH MODE · NO ACCESS CHANGES · NOTHING WRITTEN · 30 MINUTES

See which of your findings are safe to close now.

Watch mode: read-only, 30 minutes, nothing written. You keep the decision record, including the findings Tamnoon declines in writing.

PICK A TIME →
Oops! Something went wrong while submitting the form.

Everyone in security sells fear in a black hoodie.We are the ones with the octopus.