Self-healing for Sweet Security

Sweet found it in minutes. The finding is still open in month five.

53 percent of everything ever detected is still open. The State of Cloud Remediation 2026, 14.86M detections across hundreds of enterprise environments.

Sweet alone

Sweet plus Tamnoon

An issue opens

Runtime-verified by the sensor, prioritized in the Issues Hub

Investigated read-only, then rated

A vulnerability lands

Judged by what is loaded, executed or exposed

The runtime-real ones get a safe fix, or a reasoned refusal

Identical issues

One rule, one answer

Six buckets, three answers

Safe

Risky

Awaiting data

What cannot be proven safe

Stays in the Hub

Risky

Declined, with the reason attached

The safe ones

Wait for an engineer

Safe

Closed on your execution plane

A Sweet issue, after the engine has read it.

The queue carries the environment facts that decide the answer. The record carries the change, the owner, the rollback and where it lands in your ticketing.

RecommendationClose public exposure on a production S3 bucket

Made with Tamnoon

Environment: PROD
Exposure: Public
Encryption: True
Resource: S3
Crown jewel: 1
Owner: J. Doe

Severity	Finding	Environment fact	Verdict
Critical	Issue: publicly exposed S3 bucket, no runtime reads observed	no flows in 90 days	Safe
High	Issue: runtime-loaded package with exploitable CVE on exposed workload	2 services, live traffic	Risky
Medium	Issue: non-human identity with anomalous permissions	owner unresolved	Awaiting data

Create an initiative from this recommendation? AcceptReject

TMN-61779 · Exposed S3 bucket, no runtime readsSafe to remediate

RecordEvidenceTicket

Priority	Investigated	Cloud provider	Asset	Status	Lands in
Medium	read-only, 07:40	AWS	s3-assets-prod-063	Safe	Jira

Read-only investigation runs before anything is proposed, and it is the evidence attached to whichever answer comes back. Identifiers on this page are fictional.

Three Sweet issues. Three different answers.

TMN-61776Sweet

Sweet issue: S3 bucket publicly exposed. The sensor observed no runtime reads in 90 days and no identity depends on the public path.

Investigatedread-only, 11:22

ChangePUBLIC → PRIVATE

Rollbackready before execution

Safeclosed 11:23

Closed at machine speed on your audit trail. Rescan clean.

TMN-61776

Sweet

Sweet issue: S3 bucket publicly exposed. The sensor observed no runtime reads in 90 days and no identity depends on the public path.

Investigated: read-only, 11:22
Change: PUBLIC → PRIVATE
Rollback: ready before execution

Safe closed 11:23

Closed at machine speed on your audit trail. Rescan clean.

TMN-61777Sweet

Identical rule, identical severity. The sensor shows two live services reading this bucket right now, one through a public path.

Investigatedread-only, 11:22

Dependents2 services, live

Changenot executed

Riskydeclined 11:23

Refused, with the reason. The change that would have caused the 3am page was refused at two.

TMN-61777

Sweet

Identical rule, identical severity. The sensor shows two live services reading this bucket right now, one through a public path.

Investigated: read-only, 11:22
Dependents: 2 services, live
Change: not executed

Risky declined 11:23

Refused, with the reason. The change that would have caused the 3am page was refused at two.

TMN-61778Sweet

Sweet issue: non-human identity with anomalous permissions. The owning team cannot be resolved from tags or recent activity.

Investigatedread-only, 11:22

Ownerunresolved

Changenothing touched

Awaiting dataasked 11:23

A third answer, chosen. Ownership could not be resolved, so nothing was touched and the missing context was requested. It does not guess.

TMN-61778

Sweet

Sweet issue: non-human identity with anomalous permissions. The owning team cannot be resolved from tags or recent activity.

Investigated: read-only, 11:22
Owner: unresolved
Change: nothing touched

Awaiting data asked 11:23

A third answer, chosen. Ownership could not be resolved, so nothing was touched and the missing context was requested. It does not guess.

Identifiers fictional · one healed never travels without the declines beside it

What teams running Sweet ask first.

How is this different from self-healing infrastructure?

Self-healing infrastructure restores desired state: a pod restarts, an instance is replaced, a group scales back up. It is availability automation and it exercises no judgment about safety. Tamnoon heals the security posture instead: it investigates the finding in context, decides whether a change is safe to make at all, refuses what it cannot prove, and leaves the receipt behind. Restarting a pod is not the same as knowing which bucket must stay public.

How is this different from Sweet’s own remediation?

Sweet automates hygiene on its own findings. Tamnoon works on what remains after that. It investigates each issue read-only in your live environment, groups things together to increase efficiency of each action instead of going a single issue at a time, closes what it can prove safe through your own change process, declines what it cannot with the evidence why, and answers for the outcome.

Sweet already verifies with runtime. What does Tamnoon add?

Runtime verification answers whether a risk is real. Tamnoon answers the next question: whether the fix is safe to make here, today. A guardrail can hold the line in the meantime, and the posture change underneath it still has to be made by someone willing to answer for it. That is the part Tamnoon signs.

Do we have to change our Sweet setup?

No. Tamnoon sits downstream of the Sweet you already run, reading issues through the API with read access. Your sensor, your guardrails and your Issues Hub stay exactly as they are. No scanner to replace, no contract to end.

We were burned by auto-remediation. Why is this different?

A tool that fires fixes blind is an autoimmune reaction: it attacks the body it is supposed to protect. Tamnoon starts from the opposite premise. Every fix is investigated read-only first, against live traffic, usage, dependencies and ownership. What it cannot prove safe it refuses, and the refusal ships with the evidence why. You were not wrong to pull the plug on a tool that could not tell you why a change was safe.

What do I tell my change advisory board?

They approve a change class, not a black box. Starting mode is SAFE-only: the engine closes only the class of change your board has approved, through your own change process, under your IAM policies, on your audit trail. Autonomy widens on evidence, class by class, and every decision leaves a record your auditor can read.

Sweet is watching. Tamnoon proves the fix safe, or refuses to move.

Sweet found it in minutes. The finding is still open in month five.

A Sweet issue, after the engine has read it.

Three Sweet issues. Three different answers.

Tamnoon executes through your change process, not around it.

What teams running Sweet ask first.

See the engine run against your own Sweet account.