feat(dane): mechanizm rekordów-pułapek (canary) — wykrywanie wycieku baz (DAN-26) #52

Merged

gitea merged 1 commits from feat/dan26-canary into master 2026-08-03 19:36:59 +00:00

Conversation 0 Commits 1 Files Changed 4

+198 -2

gitea commented 2026-08-03 19:16:14 +00:00

Owner

Copy Link

Copy Source

Zabezpieczenie detekcyjne (nie prewencyjne): kilka unikalnych, wiarygodnie
wyglądających rekordów-pułapek w bazach. Nie zmieniają interpretacji, ale jeśli
pojawią się w cudzej kopii — są dowodem pochodzenia, a przy wariancie na kopię
wskazują źródło wycieku.

Mechanizm (services/data/app/canary.py)

Pułapkę rozpoznajemy po markerze (unikalny ciąg z ENV CANARY_MARKERS,
nieobecny w realnych danych). screen(rows, query_value):

• odsiewa rekordy z markerem — i to na wyjściu z warstwy danych (/search),
  więc nie dotrą wyżej ani do promptu LLM (LOG-30), niezależnie od dostawcy
  (Excel/SQL);
• tripwire: gdy zapytanie celuje wprost w marker (enumeracja bazy, nie liczenie
  horoskopu) → warning.

Bez CANARY_MARKERS — przezroczyste, zero kosztu dla normalnego ruchu.

Poza kodem (krok właściciela)

Rejestr wariant → kopia (traitor tracing) i wstrzyknięcie do realnych baz
robi właściciel — nie ruszamy kupionych plików automatycznie. Pełna instrukcja:
docs/canary-registry.md (konfiguracja per wdrożenie,
rejestr, granice — canary nie wykrywa retencji treści u dostawcy LLM, od tego jest
LOG-32 + ZDR).

Weryfikacja

Mechanizm zbudowany i przetestowany na syntetycznych pułapkach. Testy: +7
(przezroczystość bez markerów, odsiewanie, tripwire, marker w dowolnym polu,
endpoint odsiewa przed zwrotem). Pierwsze testy w usłudze data.

Domyka mechanizm DAN-26 (injekcja/rejestr = ops). Dalej „czysto": PRE-17
(konta+audyt), PRE-09/DAN-15 (przegląd baz NFS + toggle).

Zabezpieczenie **detekcyjne** (nie prewencyjne): kilka unikalnych, wiarygodnie wyglądających rekordów-pułapek w bazach. Nie zmieniają interpretacji, ale jeśli pojawią się w cudzej kopii — są **dowodem pochodzenia**, a przy wariancie na kopię wskazują **źródło** wycieku. ## Mechanizm (`services/data/app/canary.py`) Pułapkę rozpoznajemy po **markerze** (unikalny ciąg z ENV `CANARY_MARKERS`, nieobecny w realnych danych). `screen(rows, query_value)`: - **odsiewa** rekordy z markerem — i to na **wyjściu z warstwy danych** (`/search`), więc nie dotrą wyżej ani do promptu LLM (**LOG-30**), niezależnie od dostawcy (Excel/SQL); - **tripwire**: gdy zapytanie celuje wprost w marker (enumeracja bazy, nie liczenie horoskopu) → `warning`. Bez `CANARY_MARKERS` — **przezroczyste**, zero kosztu dla normalnego ruchu. ## Poza kodem (krok właściciela) Rejestr **wariant → kopia** (traitor tracing) i **wstrzyknięcie** do realnych baz robi właściciel — nie ruszamy kupionych plików automatycznie. Pełna instrukcja: [`docs/canary-registry.md`](docs/canary-registry.md) (konfiguracja per wdrożenie, rejestr, granice — canary nie wykrywa retencji treści u dostawcy LLM, od tego jest LOG-32 + ZDR). ## Weryfikacja Mechanizm zbudowany i przetestowany na **syntetycznych** pułapkach. Testy: **+7** (przezroczystość bez markerów, odsiewanie, tripwire, marker w dowolnym polu, endpoint odsiewa przed zwrotem). **Pierwsze testy w usłudze `data`.** Domyka mechanizm **DAN-26** (injekcja/rejestr = ops). Dalej „czysto": PRE-17 (konta+audyt), PRE-09/DAN-15 (przegląd baz NFS + toggle).

gitea added 1 commit 2026-08-03 19:16:15 +00:00

feat(dane): mechanizm rekordów-pułapek (canary) — wykrywanie wycieku baz (DAN-26) ... 78af6d4755

Zabezpieczenie DETEKCYJNE (nie prewencyjne): kilka unikalnych, wiarygodnie
wyglądających rekordów-pułapek w bazach. Nie zmieniają interpretacji (odsiewamy
je z wyników), ale jeśli pojawią się w cudzej kopii — są dowodem pochodzenia, a
przy wariancie na kopię — wskazują ŹRÓDŁO wycieku.

`canary.py`: pułapkę rozpoznajemy po MARKERZE (unikalny ciąg z ENV, nieobecny w
realnych danych). `screen(rows, query_value)`:
- ODSIEWA rekordy z markerem z wyników — i to na WYJŚCIU z warstwy danych
  (`/search`), więc nie dotrą wyżej ani do promptu LLM (LOG-30), niezależnie od
  dostawcy (Excel/SQL);
- TRIPWIRE: gdy zapytanie celuje wprost w marker (enumeracja bazy, nie liczenie
  horoskopu) → log warning.
Bez `CANARY_MARKERS` — przezroczyste, zero kosztu dla normalnego ruchu.

Rejestr wariant→kopia (traitor tracing) i wstrzyknięcie do REALNYCH baz to krok
właściciela (poza kodem — nie ruszamy kupionych plików automatycznie);
instrukcja: docs/canary-registry.md. Mechanizm zbudowany i przetestowany na
syntetycznych pułapkach.

Testy: +7 (przezroczystość bez markerów, odsiewanie, tripwire, marker w dowolnym
polu, endpoint odsiewa przed zwrotem). Pierwsze testy w usłudze `data`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

gitea merged commit 78af6d4755 into master 2026-08-03 19:36:59 +00:00

gitea deleted branch feat/dan26-canary 2026-08-03 19:37:00 +00:00

gitea referenced this issue from a commit 2026-08-03 19:38:50 +00:00

ci: odpalaj testy warstwy bazodanowej (dotąd nie były uruchamiane)

gitea referenced this pull request 2026-08-03 19:39:03 +00:00

ci: odpalaj testy warstwy bazodanowej (dotąd nie były uruchamiane) #53

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

gitea

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/astrololo#52