Deciding what is safe to touch is the next mile.

Add context and correlate Orca Alerts to trace them back to their root cause, providing clearer insights for addressing the underlying issues.

No scanner to replace. No contract to end.
Nothing to install in production.

Orca alerts, plus the context that decides them Safe
Risky
Awaiting data

Orca 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.

Orca alone

Orca plus Tamnoon

An alert opens

Scored by severity, exploitability, accessibility and business impact

The finding

Investigated read-only, then rated

An attack path forms

Risk combinations drawn to the crown jewels, choke points marked

The finding

The path is walked read-only, each hop rated

Identical alerts

One control, one answer

The finding

Six buckets, three answers

Safe

Risky

Awaiting data

What cannot be proven safe

Stays open

The finding

Risky

Declined, with the reason attached

The safe ones

Wait for an engineer

The finding

Safe

Closed on your execution plane

After detection, three questions are left standing:

What stays open after that is the residue: the misconfigured bucket that three workloads quietly read, the KMS key nobody admits to owning, the alert where the fix is obvious and its blast radius is not.

That is the mile Tamnoon runs, read-only first, on every finding, with the answer and its evidence filed back where your team already works.

Is this fix safe here?

Who answers for it?

Will it stay closed?

An Orca alert, 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 access on a production storage bucket
Made with Tamnoon
Environment
PROD
Exposure
Public
Encryption
True
Resource
S3
Crown jewel
1
Owner
J. Doe
ScannerSeverityFindingEnvironment factVerdict
OrcaCriticalMisconfigured S3 bucket open to the internetno requests in 90 daysSafe
OrcaHighAttack path: exposed workload reaches crown jewel data store2 services, live trafficRisky
OrcaMediumImproperly configured KMS key on production dataowner unresolvedAwaiting data
Create an initiative from this recommendation? AcceptReject
TMN-63410 · RDS instance misconfiguration, public accessibilitySafe to remediate
RecordEvidenceTicket
PriorityInvestigatedCloud providerAssetStatusLands in
Mediumread-only, 07:40AWSrds-billing-prod-009Safe
ServiceNow

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 Orca alerts. Three different answers.

TMN-63407Orca
Orca alert: S3 bucket misconfigured for public access. No requests in 90 days, no policy attached, nothing on the graph reaches it.
Investigatedread-only, 08:27
ChangePUBLIC → PRIVATE
Rollbackready before execution
Safeclosed 08:28

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

TMN-63407
Orca
Orca alert: S3 bucket misconfigured for public access. No requests in 90 days, no policy attached, nothing on the graph reaches it.
Investigated
read-only, 08:27
Change
PUBLIC → PRIVATE
Rollback
ready before execution
Safe closed 08:28

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

TMN-63408Orca
Identical control, identical severity. This bucket sits on an attack path to a crown jewel data store, and two live services read it.
Investigatedread-only, 08:27
Dependents2 services, live
Changenot executed
Riskydeclined 08:28

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

TMN-63408
Orca
Identical control, identical severity. This bucket sits on an attack path to a crown jewel data store, and two live services read it.
Investigated
read-only, 08:27
Dependents
2 services, live
Change
not executed
Risky declined 08:28

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

TMN-63409Orca
Orca alert: Elasticsearch domain misconfiguration. The owning team cannot be resolved from tags or recent activity.
Investigatedread-only, 08:27
Ownerunresolved
Changenothing touched
Awaiting dataasked 08:28

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

TMN-63409
Orca
Orca alert: Elasticsearch domain misconfiguration. The owning team cannot be resolved from tags or recent activity.
Investigated
read-only, 08:27
Owner
unresolved
Change
nothing touched
Awaiting data asked 08:28

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

Tamnoon reads Orca findings.

Through the Orca API, read access only. No scanner change, no re-scan, no agent added anywhere.

Tamnoon investigates before it touches anything.

Live traffic, usage, dependencies and ownership, all read-only.

Tamnoon executes through your change process.

Under your IAM policies, on your audit trail, with rollback defined first.

Tamnoon carries over when you switch.

Move scanners and every judgment already made comes with you.

Tamnoon executes through your change process, not around it.

Findings from your scanner, context from your cloud, changes on your execution plane.

What teams running Orca 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 Orca’s own remediation?
+

Orca automates hygiene on its own findings. Tamnoon works on what remains after that. It investigates each alert read-only in your live environment, groups things together to increase efficiency of each action instead of going a single alert 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.

Orca is agentless. Does Tamnoon add an agent?
+

No. Tamnoon reads Orca’s alerts and your cloud’s own telemetry through APIs, read-only. Your estate stays exactly as agentless as Orca left it, and execution happens through your own change process when a fix is proven safe.

Does it respect Orca’s prioritization?
+

Tamnoon builds on it. Orca’s scoring already weighs exploitability, accessibility and business impact, and attack paths mark the choke points. Tamnoon adds the question the score cannot answer: whether the fix itself is safe to make here, today, given what is actually reading that resource.

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.

See the engine run against your own Orca account.

Read-only, in the first meeting. Live discrimination, a live refusal, and a live safe heal.