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 Tenable’s one-click and guided remediation?+
Tenable drafts the fix: a least-privilege policy, a configuration change, an IaC snippet, ready for someone to click Proceed. Tamnoon works on the question that button leaves open. It investigates each finding read-only in your live environment, groups findings so one change retires many, closes what it can prove safe through your own change process, declines what it cannot with the evidence why, and answers for the outcome.
Least privilege is Tenable’s strength. Why add Tamnoon?+
Tenable is very good at finding unused privileges and inactive identities. Unused during a learning period is evidence, not proof: quarterly jobs, disaster-recovery roles and break-glass access all look idle until the day they are needed. Tamnoon checks each privilege, and each inactive identity marked for deletion, against schedules, pipelines and dependencies before anything changes, and refuses the ones that would break something, on the record.
Does it keep Tenable’s compliance mapping?+
Yes. Each finding arrives with the compliance sections Tenable maps it to, and Tamnoon carries them onto the decision record. A closed finding shows which control now passes; a refused one shows which control stays failed, and why.
Does it respect Tenable’s severity?+
Tamnoon starts from it. Each finding arrives with the severity and policy Tenable assigned. Tamnoon adds the question severity cannot answer: whether the fix itself is safe to make here, today, given what actually depends on that entity. The most severe finding on the board can still be the most dangerous change on the board.
Do we have to change our Tenable setup?+
No. Tamnoon sits downstream of the Tenable Cloud Security you already run, connecting with an API token you issue. Your cloud accounts, policies and compliance settings stay exactly as they are, and Tenable never needs write access to production for Tamnoon to close findings. No scanner to replace, no contract to end.
Which Tenable findings does Tamnoon read?+
Open configuration and identity findings from Tenable Cloud Security, with the policy, entity and compliance sections attached to each. Vulnerability findings from Tenable Vulnerability Management, Nessus and Tenable One are not read today.
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.
