What Sift guarantees

These are the properties a security or operations team can rely on when deciding whether to put Sift in front of an agent. Each is enforced in Sift’s code, not left to configuration or good practice. The second half of the page lists what Sift does not promise.

What Sift guarantees

Nothing is filtered until a person says so

A new filter sends everything. Its threshold starts at 0, which sends every event.
Only an active filter filters. In every other state (draft, authoring, shadow, proposed, paused, retired) a filter filters nothing. Shadow scores every event and records what it would filter, but sends everything. See Shadow and filtering.
What the agent does not see is never called filtered. Two settings, both off unless you switch them on, can keep events from the agent without the filter deciding anything: an agent budget and sampled shadow. What they keep back is recorded as not seen by the agent, apart from what the filter filtered, and never counts toward its recall. A budget holds its overflow in a queue before it lets anything go, and every escalation that leaves unsent is recorded and alerted.
Two approvals by people, in order. Before a filter can enter shadow, a person judges every example in its gold set and an operator or admin approves the set. After training, an operator or admin approves a measured threshold, with a written reason that goes in the audit log. That approval is the only way into active, and a resume only re-affirms an approval that still stands.
A change that could filter more needs a new approval. Saving a change to the threshold, a filtering stage, the source query or the target, or lowering the leak-through rate, moves an active filter back to shadow (or, for a change to a pipeline stage alone, holds it as a waiting version) until it is approved again. A change that keeps more from the agent on an alarm or under a budget needs a new approval or a person’s written re-affirmation of the standing one.
A new model starts in shadow. Retraining never swaps a model in by itself. The new model is measured in shadow and replaces the running one only through another threshold approval.

What filtering misses is always measured

Leak-through never stops. A random share of the events a filter would filter is sent anyway: 3% by default, set between 1% and 5%, and never zero. Their verdicts are how Sift measures the miss rate of a running filter.
The agent cannot tell. A leak-through event reaches the agent exactly as any other escalation does: the same bytes, with no flag. The agent never sees a score, a threshold, a model or Sift’s decision, so its verdict cannot be steered by them. See the Agent contract.
A failed run is never a “benign”. A run that failed, was cancelled, or gave no verdict teaches the filter nothing. An insufficient data verdict counts with actionable: an event the agent could not clear is not one to filter.
Recall, never accuracy. Sift reports recall and miss rate. It does not report accuracy, which would rank highest a filter that filters everything.

Every filtered event is on record

Every event a filter filters is listed on its Filtered events page: which event, its score and the model version, without the event’s content. The log is kept for 400 days by default. The audit log records every state change and approval with who made it and why.

Failures send more to the agent, not less

When something goes wrong, Sift’s answer is to send more events to the agent, not to go quiet. That costs runs; it does not cost missed events.

When	What Sift does
Escalations keep failing to reach the agent	Filters nothing until an escalation lands again. The state does not change.
An active filter’s escalations in one hour reach its trigger ceiling (200 by default)	Moves the filter back to shadow and raises an alert.
A filter’s traffic or scores drift from what was approved	Moves the filter back to shadow and raises an alert.
A filter is running a version with no standing threshold approval	Moves the filter back to shadow.

A move back to shadow withdraws the threshold approval, so the filter filters again only after a person decides. For drift and the trigger ceiling only, an operator can set On alarm to Keep filtering in the filter’s settings: the filter then keeps filtering and Sift raises an alert instead. A stalled delivery path and a missing approval stop filtering whatever On alarm says. See Health, Actions and alerts.

Sift cannot be talked into changing itself

The assistant cannot change anything. Sift’s assistant, which helps you build a filter, reads samples and proposes; it has no tool that writes. A malicious string in a ticket can at worst produce a bad proposal, which a person then rejects at the gold set.
No generated code. A filter uses one of a fixed set of recipes. Sift never writes or runs code.
Scoring is local. Each event is scored inside Sift, with no call out. The model files Sift scores with are pinned: if the files on disk do not match the pin, Sift stops at start-up rather than score with them.

What Sift does not promise

Exactly one run per event. Kindo does not de-duplicate agent runs. When the answer to a send is lost, Sift sends again and marks the event as a possible re-send, so the agent can check before acting twice.
High availability. Sift runs as one Docker Compose stack on one host. There is no clustering or failover.
Single sign-on or multi-factor sign-in. Sift has its own local accounts and passwords only. Run it inside a network perimeter you trust.
Savings in your environment. Sift shows what a filter would filter on your own events before you approve it. It makes no general claim about how much you will save.

What leaves your deployment

Destination	When	What
Your Kindo API	Once an admin connects Kindo	Source reads, agent runs, verdict reads, and Sift’s own model calls, all with the stored key.
Hugging Face, or a mirror you set	On first start only	A one-time download of the pinned model files Sift scores with (about 134 MB). An air-gapped install stages them by hand.
Webhook endpoints	Only if an admin adds them (at most 10)	Signed alert notices. Never an event, a score or a verdict.
The decision model’s provider	Only if it is turned on in the deployment’s configuration	Off by default. See The decision model.

Nothing else is sent anywhere. See Security and data handling for retention and how secrets are stored.