Skip to main content
Two teams can get the same finding and be right to treat it differently. A public bucket is a breach in one organization and a static site in another. The knowledge base is where Amnify learns which one you are. Severity itself is not up for negotiation: it is rated against established security frameworks. What your context decides is whether a finding applies to you at all, and what gets fixed first. It is built from two things: the documents you upload, and the questions you answer.

​
Knowledge sources

Upload the security documents your organization already has: policies, standards, architecture decisions, exception registers. PDF, Word, plain text and Markdown. An agent reads them for two purposes.

To answer without asking you

Where a document already settles a case, Amnify applies it and stays quiet. You are not asked about something you have already written down.

To pre-fill and cite

Where a question is still needed, the answer Amnify believes is yours is pre-filled, with the passage it came from quoted as the citation.
Each document shows how many decisions cite it. Removing one stops it being used immediately, and existing citations stay readable.

​
Questions

A question is a decision Amnify needs and will not infer for you. Each one is short: pick one option, pick several, or write your own, and every question names the findings it affects. They are grouped into Needs input, Assigned to you, and Answered.

​
When Amnify asks

All three of these have to hold.
1

The same pattern spans more than one finding

A single occurrence is triaged on its own. A pattern repeating across findings is a sign of an organizational preference worth capturing once and reusing.
2

The answer would change the outcome

Whether the finding stands at all, how urgent it is for you, or how its fix should be planned. If the answer changes nothing, there is no question.
3

Nothing already answers it

Neither your documents nor a decision from an earlier answer covers the case. Amnify checks what it already knows before it asks.

​
The one exception

Amnify also asks when a document does answer the question, but what it recommends conflicts with security best practice. It neither follows the document quietly nor overrides it quietly. Instead it:
  • pre-fills the answer the document implies,
  • marks it as conflicting and shows the passage it is based on,
  • warns you before you confirm it.
You can still choose the document’s answer, and sometimes that is the right call for your organization. What Amnify will not do is let a decision against best practice be inherited in silence from a file. A person makes it, and the record says so.

​
When Amnify stays quiet

When a document or an earlier decision already settles it, the answer is applied without asking. Silence is the goal. The first week is the loudest one, and every answer you give removes a class of future question.

​
An answer becomes a decision

Until you answer, the findings a question gates are held back: not listed, not counted in your posture, and not planned for a fix. Answering releases them in the same moment. An answer keeps a finding Open when it is a real gap for you, Suppresses it when your answer waives it, and becomes a decision reused on everything similar.
Answering applies immediately, with no separate re-evaluation step. The findings it affects are re-evaluated on the spot, and for Critical and High findings a remediation is planned right away. If you correct a pre-filled answer, your correction wins over the document permanently.

​
Clusters

The knowledge base also records how findings relate to each other. An agent links them and states which kind of relationship it is, with a confidence and a one line reason. The connected group is a cluster, and one remediation covers the whole cluster. This is what stops a fix closing the symptom while leaving the cause to recreate it.

​
Where a finding originates

Amnify also records where each finding comes from: a repository file and line range today, with documentation and ticket references following the same shape. It turns a finding about a running system into a finding about the code that produced it, so the fix can be made where it lasts. A cloud misconfiguration traced to the infrastructure as code that created the resource, and a penetration test finding traced to the handler that is exploitable, are the same mechanism. It is also what forms clusters: finding out where two issues originate is what reveals they originate in the same place.

​
What this changes

Priority is yours

The severity of an issue is fixed by the frameworks. Whether it is a real gap for you, and where it sits in the queue, is your call.

One issue, one entry

Findings sharing a cause are one cluster with one fix, not several tickets that each half solve it.

Fixes reach the cause

Because a finding knows where it originates, the fix can be made at the origin rather than at the symptom.

Noise falls over time

Every answer removes a class of future question, and every document removes questions before they are asked.