diff --git a/.env.agent b/.env.agent
new file mode 100644
index 0000000..e3bfb8a
--- /dev/null
+++ b/.env.agent
@@ -0,0 +1,20 @@
+BRAIN_MODE=agent
+BRAIN_AGENT_BRAIN_URL=http://127.0.0.1:8091
+BRAIN_AGENT_ID=agent-2b4febffd8a821c161ab75f3
+BRAIN_AGENT_TOKEN=brain_agent_2d06d422caf2e16fd0fc0041ce0aa84777eae408c083f3e454084ef43d9de1b4
+
+# =============================================================================
+# SOURCE AGENT
+# =============================================================================
+BRAIN_LISTEN_ADDR=:8092
+BRAIN_DATA_DIR=./data2
+
+# Config regelmäßig vom Brain holen
+BRAIN_AGENT_CONFIG_REFRESH=5m
+
+BRAIN_AGENT_HTTP_TIMEOUT=30s
+BRAIN_AGENT_CONCURRENCY=3
+BRAIN_AGENT_BATCH_SIZE=50
+
+# Nur true, wenn der Agent absichtlich Intranet-Webseiten crawlen soll.
+BRAIN_AGENT_ALLOW_PRIVATE=false
\ No newline at end of file
diff --git a/.env.example b/.env.example
index 4256383..1846d02 100644
--- a/.env.example
+++ b/.env.example
@@ -2,7 +2,14 @@
 BRAIN_MODE=brain
 
 # HTTP
+# Direct binary listen address. Docker Compose listens internally on :8090 and
+# exposes BRAIN_PORT on the host.
 BRAIN_LISTEN_ADDR=:8090
+# Docker Compose host port (not consumed by the binary itself).
+BRAIN_PORT=8090
+# URL that remote/source-agent containers can actually reach. Do not use
+# localhost/127.0.0.1 here for a separate container.
+BRAIN_PUBLIC_URL=
 BRAIN_DATA_DIR=./data
 BRAIN_API_KEY=
 
@@ -98,6 +105,8 @@ BRAIN_SOURCE_INBOX_ENABLED=true
 BRAIN_SOURCE_INBOX_INTERVAL=30s
 BRAIN_SOURCE_INBOX_BATCH_SIZE=12
 BRAIN_SOURCE_INBOX_MIN_SIMILARITY=0.55
+BRAIN_SOURCE_INBOX_MIN_PRIORITY=0.55
+BRAIN_SOURCE_INBOX_NOVELTY_FLOOR=0.35
 BRAIN_SOURCE_INBOX_MIN_RESULTS=2
 # Freshness-sensitive article queries only reuse inbox documents newer than this.
 BRAIN_SOURCE_INBOX_FRESH_MAX_AGE=168h
@@ -189,6 +198,11 @@ BRAIN_AUTONOMOUS_RESEARCH_OPPORTUNITY_LIMIT=8
 # A local JSON bootstrap file may be used instead of URL/ID/token envs.
 # -----------------------------------------------------------------------------
 # BRAIN_MODE=agent
+# Docker Compose publishes the Agent status UI on BRAIN_AGENT_PORT (default 8092).
+# BRAIN_AGENT_PORT=8092
+# Use the Brain service name on a shared Docker network, a LAN/DNS address, or
+# host.docker.internal:<BRAIN_PORT> for a separate Agent container on the same host.
+# Never use 127.0.0.1/localhost for a separate container.
 # BRAIN_AGENT_BRAIN_URL=https://brain.example.org
 # BRAIN_AGENT_ID=security-news-01
 # BRAIN_AGENT_TOKEN=brain_agent_xxxxxxxxx
diff --git a/CHANGELOG-SOURCE-AGENT-CONNECTION-FIX.md b/CHANGELOG-SOURCE-AGENT-CONNECTION-FIX.md
new file mode 100644
index 0000000..3d62e54
--- /dev/null
+++ b/CHANGELOG-SOURCE-AGENT-CONNECTION-FIX.md
@@ -0,0 +1,19 @@
+# Source Agent Connection / Docker Fix
+
+## Problem
+
+The first integrated Source-Agent release could look healthy while using only a cached remote configuration. `config_issued_at` was exposed without live connection diagnostics. The Agent compose did not publish its local status HTTP port and did not define `host.docker.internal` on Linux. The Brain UI also generated `BRAIN_AGENT_BRAIN_URL` from the browser's `location.origin`; when the UI was opened on `127.0.0.1` or `localhost`, a separate Agent container was therefore given an unreachable self-loop URL.
+
+## Changes
+
+- Agent status now exposes live connection state, config source (`brain`/`cache`), last config/heartbeat attempts, successes and errors.
+- A cached config alone is never reported as a live Brain connection.
+- Independent startup/periodic heartbeats make an authenticated Agent visible even with zero tasks.
+- Agent mode serves a small diagnostics UI at `/`; JSON remains at `/api/status`.
+- Brain config fetches count as Agent contact (`last_seen`) so an Agent is shown online before its first task run.
+- Registered Agents remain assignable while offline / before first contact.
+- Added `BRAIN_PUBLIC_URL`; the Brain UI uses it for generated Agent configuration instead of blindly trusting browser `location.origin`.
+- The Agent UI warns when the Brain URL is loopback and provides actionable 401/404 diagnostics.
+- Root compose exposes the Brain host port through `BRAIN_PORT`; Source-Agent compose exposes its diagnostics through `BRAIN_AGENT_PORT` and maps `host.docker.internal` on Linux.
+- Task creation returns an explicit error when the selected Agent is not registered in the current Brain database.
+- `/api/status` on the Brain now includes registered/online Agent counts, task count and Source-Inbox stats.
diff --git a/CHANGELOG-SOURCE-AGENT-UI-LIST-FIX.md b/CHANGELOG-SOURCE-AGENT-UI-LIST-FIX.md
new file mode 100644
index 0000000..36bf0ca
--- /dev/null
+++ b/CHANGELOG-SOURCE-AGENT-UI-LIST-FIX.md
@@ -0,0 +1,8 @@
+# Source Agent UI List Fix
+
+## 2026-08-07
+
+- Empty agent task lists are serialized as `[]` instead of `null`.
+- The Source Agents UI normalizes `agents`, `tasks` and inbox payloads before rendering, so one empty collection cannot abort the whole page.
+- Errors from task/stat loading are no longer silently ignored by the management endpoint.
+- A working native loopback connection is no longer shown as a Docker networking warning; loopback warnings remain for disconnected agents.
diff --git a/CHANGELOG-SOURCE-INBOX-PRIORITY-CLASSIFIER.md b/CHANGELOG-SOURCE-INBOX-PRIORITY-CLASSIFIER.md
new file mode 100644
index 0000000..d7fbf1a
--- /dev/null
+++ b/CHANGELOG-SOURCE-INBOX-PRIORITY-CLASSIFIER.md
@@ -0,0 +1,7 @@
+# Source Inbox Priority Classifier
+
+- Kombinierter Priority Score statt alleiniger KB-Cosine-Schwelle.
+- Berücksichtigt KB-Nähe, kuratierten Task-/Quellenkontext, Aktualität und Security-/Advisory-Signale.
+- Novelty-Floor verhindert, dass völlig fremde News die Candidate-Inbox fluten.
+- Bereits archivierte Dokumente werden beim ersten Start der neuen Classifier-Version genau einmal neu klassifiziert.
+- UI zeigt Priorität, KB-Nähe, Freshness und Event-Signal getrennt.
diff --git a/README.md b/README.md
index 743ef99..0a5a385 100644
--- a/README.md
+++ b/README.md
@@ -370,4 +370,4 @@ BRAIN_AGENT_ID=security-news-01
 BRAIN_AGENT_TOKEN=brain_agent_...
 ```
 
-Create Agents and RSS/Atom/sitemap/Web polling tasks under `/source-agents.html`. Incoming documents first enter a persistent Source Inbox and are classified against the local KB; adaptive article research searches this Inbox before falling back to SearXNG. Discovered documents are not materialized as graph knowledge until a reviewer actually uses them to ground a supported claim. See `SOURCE-AGENT-MODE.md` for the API, security model and deployment example.
+Create Agents and RSS/Atom/sitemap/Web polling tasks under `/source-agents.html`. Set `BRAIN_PUBLIC_URL` on the Brain to an address the Agent can actually reach; do not copy a browser-side `127.0.0.1`/`localhost` URL into a separate Agent container. The Agent exposes a small diagnostics UI on `/` and detailed connection state on `/api/status`; the example compose publishes it with `BRAIN_AGENT_PORT` (default `8092`). Incoming documents first enter a persistent Source Inbox and are classified against the local KB; adaptive article research searches this Inbox before falling back to SearXNG. Discovered documents are not materialized as graph knowledge until a reviewer actually uses them to ground a supported claim. See `SOURCE-AGENT-MODE.md` for the API, security model and deployment example.
diff --git a/SHA256SUMS.txt b/SHA256SUMS.txt
index 57fff1f..3f47f95 100644
--- a/SHA256SUMS.txt
+++ b/SHA256SUMS.txt
@@ -1,4 +1,4 @@
-a68842eb81f6dd064912ca34e30f94b9473293b8e8b7a77cb96bb59997745093  .env.example
+10756b5a5dcc082fd12c5252e7ef367eb86eb941f37a7b06d903b169fe05887c  .env.example
 236713daf159ff0a8067e80a442ae3404fa28a5251ae6f24782f263bcfc17005  .gitea/workflows/registry.yml
 caf5847b0ca972e7701ec23222302ac72de05d20f620d1b0f508efa126f24bfd  .gitignore
 048f53e6ca01ac583b48784cd2f6f7d248e0534849955b144e75f017f73188a3  .vscode/settings.json
@@ -27,7 +27,10 @@ fbf686a1acc2de6c4fbb56730a5f87dfdf28d93125fa56ae0c588c29ce492efe  CHANGELOG-RESE
 87f89a81e1124b18e092a4ea946cb037295cb9e884a46b392286272dc8134dd4  CHANGELOG-RUNTIME-HONEYCOMB.md
 2d04e6d385f4b902080a0bcaab510a846a8ae6a76cb757423c50425c8433e7f9  CHANGELOG-SEARXNG-DIAGNOSTICS.md
 9c760e167a9af2d3d8ca32c5aa4ef6bb4a3153047343a71c4b19ca9aef96ca32  CHANGELOG-SEARXNG-VISUALIZATION.md
+9f5c4684f27249a71f41e204e7a276e70079b68aa9d6ad71ff9a2dcb3c67bd16  CHANGELOG-SOURCE-AGENT-CONNECTION-FIX.md
 6315493546a2d66022bcdff849e3895b300496cfcbab1ef891c966e55a54cb04  CHANGELOG-SOURCE-AGENT-MODE.md
+455fb256203a41f244f878fba9c9994f1394184ece33839a919c6d2bceb96fc4  CHANGELOG-SOURCE-AGENT-UI-LIST-FIX.md
+e4e5ecd9b322d77b587a4166a8734a8d84b520ad605a1235d0bd5787398932f3  CHANGELOG-SOURCE-INBOX-PRIORITY-CLASSIFIER.md
 be9f133ae933bdc0e0a8aa5d176dd3e39488a191337043533379e23d179f3ad2  CHANGELOG-SOURCE-ONLY-FILTERS.md
 5433a7c2e67ab35fb320bc872e9024fa5f3e765736184e9f878340b8b45407aa  CHANGELOG-SQLITE-STARTUP-FIX.md
 5b9deeab0cd59b3c649fd73f129361a1e773ed3955cded0048b8cb280bb32e88  CHANGELOG-SQLITE-STORAGE.md
@@ -41,10 +44,10 @@ a1aed7c198bc1ffc7af4a8f69ccf137541e4887ce5d59a0d67f2be7216a37dcd  FILTER-SCOPES-
 696d2da2338cd8190b9614707e4059d78ce291e7334f273633aad815c3b6a6df  Makefile
 e5e9a5268031fee9346462e4631e28ce8c8a8b46a4623e56327a1f310a09f646  OLLAMA-POOL.md
 2c0062941ef3edbd40d46b823934a7d0a3a9da7581b83d0b9360e8aaa7694b1b  PERSISTENCE.md
-770a9638e9dc76a93b68de3be809b2dfcd17f00542aaa03b130a631ab200de41  README.md
+84358eeef449dee2c056f0195c2cd520427883afc18ce72cac5462bffba2195b  README.md
 2838cd19ac2bfa35bebbef2541f631b99221b5997bbb6dbc27146a66a3a1ad34  RUNTIME-CONTROLS-HONEYCOMB.md
 c3da43b33e550901d55789f2ee526c2e50f61ee028a3f59e0a40e77e1057fde7  SEARXNG-VISUALIZATION.md
-498d4174ba4e27e571d8d2ef09c4b977423c4bedea469f0d528840589c6452da  SOURCE-AGENT-MODE.md
+10112430e5a1620ddc626ac4968761ebae94dbf30b70301389a59d46fe8c6cf8  SOURCE-AGENT-MODE.md
 c69419c0327425186cfb84f25746feff226ce813cf467b3f252e729517455047  SOURCE-ONLY-FILTERS.md
 ae7bc1f1959071f79b76ca8a4ba103064ec0d5c5752af346175731ef4f636d9d  SQLITE-STORAGE.md
 706b3912716d565082a44a0e707afd2ad07e4eb17cc23cae75772c1740205276  VALIDATION-ADAPTIVE-ARTICLE-WORKFLOW.md
@@ -61,18 +64,21 @@ ed62866492c9f62732b6f54a60b0e38174586a873a63e56646c11c0e25b5b2ba  VALIDATION-QUE
 e5d2e3da41bfb6e720f2a9a4b95d0002fb01835db5120674c137f57110312b33  VALIDATION-RESEARCH-ORCHESTRATION.md
 044cf894b43d8ce1746adce9e58d75a6c7b0c1f3f3d2f0abcdeaab1db435014d  VALIDATION-RESEARCH-PREFETCH-GATE.md
 e08b0eaab827fe03d5a72327e8fdfe9ce4025097e28208714246969e7d059561  VALIDATION-SEARXNG-DIAGNOSTICS.md
+1cdfce41a88d01661368757a3c6a8ecf4c57c08f16308ab201c7a8d08b83e9a2  VALIDATION-SOURCE-AGENT-CONNECTION-FIX.md
 0afab72f31601a8e20eacc3d64a19a6e554ae7116e58e761073318fe5584b5b8  VALIDATION-SOURCE-AGENT-MODE.md
+2cf4668fa53714b272138c07d99b53e6bd99c15182702c0fa09c6254c4ddd8a0  VALIDATION-SOURCE-AGENT-UI-LIST-FIX.md
+da9db1169a35c95b9cfb1bc6117ae5d93cb759510ece5d8e24e18c5d5d9a4c89  VALIDATION-SOURCE-INBOX-PRIORITY-CLASSIFIER.md
 f46938b5de7e139e1b21868b1bedce6e312d69cd61602b4f8f43512a327dd422  VALIDATION-SOURCE-ONLY-FILTERS.md
 4cd120496664388717fe422a8c54380708df723fea26b35f81799665dfaf2c1c  VALIDATION-SQLITE.md
 f6699e4cdbaadc720e4b8a22c557d02319325283775a2b8a87ff78ca202e3386  VISUALIZATION-PERFORMANCE.md
-d06d3c03883bde802d755ec36a68ee0394aad1bd49fa7667f155351aa25f511d  cmd/brain/main.go
+7ac0aae38586eab129c42d0bdcef707fda68ad492341f49ab34ef1249b2bf642  cmd/brain/main.go
 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  data/.gitkeep
 7ad10f51cf26747b4f186c540ecb7c77662f001800f0f7803422d45e8d72a4db  data/graph.db
 587064aa2b583235d2235f4dcff2854b47347d47aef12ce266d56e9da6986843  data/runtime-settings.json
 21b51d0e1b7ed07c20f7f3a5da76dedab8df44a94a51724b67b0c3411599fe15  deployment/README.md
-0eaa10d68a1a6f9acef0e69c98476e53efac39689f6c1d7febf1994805d21780  deployment/docker-compose.full.yml
-6d993bbb8ebebf099fb09b5d554905d1a1b5f1defb6402e8462ca20e31e07c08  deployment/docker-compose.source-agent.yml
-3e51e03cd99c8a68ee5d208548f745dd2bb5e8ad5bc37a9798a0de30d641960e  docker-compose.yml
+11429bf6b32abb94669b20597075c0c2fb94730d5de804237e0e4501d829f868  deployment/docker-compose.full.yml
+61cdf899b5a2abf6db0b15236c59e2ccdd17027bbd9c37573cbad829c5f984af  deployment/docker-compose.source-agent.yml
+c288b46b8a75a195a21e094c9a660704aff11517bbab3bbdf3a9b61b65cfc3b5  docker-compose.yml
 1edabd3a7fc60aebaca37fae228a5f34ddbf9ed18478aa1b114204cb956a4027  go.mod
 864c3376212497b070feca13d26cfc28e96876078ce7a0b5b0c0470e2dd4fbf8  go.sum
 ed7fa0e09e94aa9e89c93b00303d4ce6f0f20dac626ecb91181c3aabc76bc8ff  integrations/agent/README.md
@@ -80,8 +86,8 @@ ed7fa0e09e94aa9e89c93b00303d4ce6f0f20dac626ecb91181c3aabc76bc8ff  integrations/a
 3c0fc6913501976100521526e1ee8e7988d33fbce3f7b4bab26387d42b0966f5  integrations/knowledgebase/README.md
 12f8424f863b13f19aab9c2e6c2828c0ad824a55a62fe336e062db534102bc3a  integrations/knowledgebase/glpi-ai-knowledgebase-neural-brain.patch
 93d8993e09473559a191c4e01252d6d1fdb214646d65e1271cde018b47d939ed  internal/activity/broker.go
-57c30b450db2534accdd6d1bc07e921b36ee45c94eb7007cefd391460d96446a  internal/config/config.go
-6a5fdbc3b849363f80a4bef57a9028e4e1eefbbb96cec61f670a0ea1efe9dc28  internal/config/config_test.go
+1b42b8c6fb0fb3f7be7ae69d0975f80d0b1adc384307e9a13d1f89ffd3fd5e24  internal/config/config.go
+9ae90ae9b1cedb45f8a53d07631cfcf382ecec6c6941d32ed0f1bfff046a7269  internal/config/config_test.go
 a03f945c1ce44480f21f855b25060c34f0a5132e537cb12787af34185f7b438c  internal/engine/article.go
 cfb3ac33a192391d8f85f77c23d5c4e277e03618cf32cce6269115b8c238b311  internal/engine/article_adaptive.go
 9658461b16b32e664336018d1c7e068bc92dcd77b07f4ecc6a5f9abdc27c3dde  internal/engine/article_adaptive_test.go
@@ -95,7 +101,7 @@ b83bda20e2c37516c9f3159a04e463cd02583a97f8a1d364c66f949a86e8da27  internal/engin
 50e5bab3e2dfa4e64706035d7a858397112baf1db477022b50d1366d0effc932  internal/engine/article_research_test.go
 a4451f7712ca281e677e4a26ffda16d2a1f7dfd7ffcb658d77cfedcc563d5e9f  internal/engine/autonomous_research.go
 62a69f1af6fc3842e34f3847a5f868f81202feaaa6429e4e84db8115f5d14ad8  internal/engine/autonomous_research_test.go
-443f1d6195946d73c04ed1a1086ec133967cb40d6830623b0863f9d9795b39c7  internal/engine/engine.go
+5e0526c3aa4e016c65173e4fd5ae1050ec2aeb61f7b4ec22950798a5a7f36532  internal/engine/engine.go
 0161090ea1ee9e22d9372a69b80131818190da6a3c0c850eae8356bc1763f032  internal/engine/engine_test.go
 2038a3909b147a630e361faae3f5c1cc22218d0f1336c91d4c1b795c52665e9b  internal/engine/research_diagnostics.go
 0eb3f00e2ab73d2dc6a4cbc1a4038533a4bb20fbbbb6190abd39feff6b34b8e1  internal/engine/research_diagnostics_test.go
@@ -104,7 +110,8 @@ a4451f7712ca281e677e4a26ffda16d2a1f7dfd7ffcb658d77cfedcc563d5e9f  internal/engin
 87a96d4a68e8e19bc15e787efa6d24fee3ae483aeb49910c6dd699a108d0a594  internal/engine/research_work_test.go
 4788163f25060322da85597f6cf5d4881463497ca9a9ddfbefaf5a3a3d985adf  internal/engine/runtime.go
 02809a7dbbf10bdc086316314c57ddd4f20f7b7f1dffbb82fc9cc8927560a2b7  internal/engine/runtime_filter_test.go
-13694ea5e73a614bc7b1ab7cd7d573eeae8c1c902a01bd3ae32b93af0179b975  internal/engine/source_inbox.go
+260a45ab15b1da8d379ca4dd0c1208c50b37c161269558096befe1a730e019bb  internal/engine/source_inbox.go
+d68098bb6b3395a8bf50800625013f8a6f15eea61064e5b8bb7c600a36da65e0  internal/engine/source_inbox_test.go
 b82980a646a92751bdd27a866ba1ffc6d34a3ba81d537f7b6e5a78e1432ee6fa  internal/glpi/client.go
 525102be56bc51ce8a08655b1b2bb53b67f4a1828903585fd664ed6a5133f617  internal/glpi/client_test.go
 5ec61f7f830721bdfb78d99617d5c5e8da0e15f8ab6e8ee18b7e7956b0c2c8bf  internal/graph/analysis_dashboard.go
@@ -133,13 +140,13 @@ a13910fb417484d56e78ae856b71fb66c63987d9abf3b513190bc52697321a18  internal/inges
 6a9f269783a7c41d5b63f9bd5022f415ed1b5572041ca5ccae1512d6dc2a0b80  internal/research/fetch_test.go
 edd033455bfd3925e5cdf5183a363ad527e7cf81beca183339fdc0b5410349ee  internal/research/searxng.go
 5a1155da5809f3a5dbd99a98094c5778424e3f4bf93fa14bd442e91cdcc08094  internal/research/searxng_test.go
-999720ab3db41e394f230ea9c29a37a9e29aec491a3f611a4381d288aa0ba86a  internal/sourceagent/agent.go
-05f918e48e58bc08fe365a95f79950e4d7ffb5d8dc891067618448673facebae  internal/sourceagent/sourceagent_test.go
-04e29ecf7370322256c5ec2f57bd7c2977e87434bbf1be8093bf513d53202217  internal/sourceagent/store.go
+86ef416abac0c9719b31e87d17fff356e5df148ba69f47a704dff138d62682c8  internal/sourceagent/agent.go
+7bf2d50712dde65a4a9165055c31ed711b4f27ab477c53af87daf569be04e2f3  internal/sourceagent/sourceagent_test.go
+44e9084de4771ecfbf00af641ed89ae8c15fc3e0053e0b0be4801cede0f6967a  internal/sourceagent/store.go
 5761310d3810c57be0efd4d1f3a54b8711a7d23de75933a41e001f1d570f9b26  internal/sourceagent/types.go
-769b4abedc8ae8762fe8441fc92dfa1cadf02e0480898853abe9ad383273f08e  internal/web/server.go
+19cc6dd35059d2883fb24989fa75cf50fd9b95f46776e0473c967b5c8e9c0797  internal/web/server.go
 b5abd1c3591242a7e8835eb38866410558d0e7901c75f5b11b94039ee3747716  internal/web/server_test.go
-b29a185248803336c8b46751b798cc03987d9d91c44d11b4e9fcb8a9f35173db  internal/web/source_agents.go
+f9d6d7e4b9d955f82ed856ec361d21eee62274b3155615fe24e476499a4ddb2d  internal/web/source_agents.go
 3e27efdbeaf8aba34864f6d1dd47d101d04c87993d02e35ee08df34affaefe29  internal/web/static/analysis.css
 db27a3c62848dbb0f383886c1075d2c0c779363cea3e847793104ca708c1d6f0  internal/web/static/analysis.html
 2ebcc27579c4fc477976d99a6c8116e7b4798b59d896dfcf6e4450cacfa7d4b7  internal/web/static/analysis.js
@@ -147,8 +154,8 @@ db27a3c62848dbb0f383886c1075d2c0c779363cea3e847793104ca708c1d6f0  internal/web/s
 f2afbfe0818847f6bab26ddc3279b60e8155f298db9e306aeefef86f0002bc06  internal/web/static/app.js
 699a6b744cec5bfd4aafa7e736f28132700bc3af0bbbceefe1e1f650d431e739  internal/web/static/index.html
 844021e5004b139377587973ff9027c463f454186fe6d331d8b5f7cda7f19a06  internal/web/static/source-agents.css
-deb8d8b6a77bf4705d836f79fd80950182880c46fc0f726b22cdbe6766994487  internal/web/static/source-agents.html
-6a1bf0eb066bfeec3ffcac2f092c71d657c98cc0963c981459852e3e31d1e260  internal/web/static/source-agents.js
+a484a6ba37ae9f58703f38a9318232a4f417637e653f17be5a304a04c5169c5d  internal/web/static/source-agents.html
+0d87c7e5c5b892b8184a05125bc8295baa410849ffd6cd501f3bff6d6d0bce23  internal/web/static/source-agents.js
 ee527efd31cc069b08ebbd53d3df7f6374cb245ae64e7e25278dc0b6381aefa4  internal/workqueue/limiter.go
 12209426f68411da5bd793a2c499992e914fc5de9ab48fa3e0c4c89215d77b9e  internal/workqueue/limiter_test.go
 83aded814b6225395935e61fe957963c3c470f368fc9089f505b6de23e959115  preview.png
diff --git a/SOURCE-AGENT-MODE.md b/SOURCE-AGENT-MODE.md
index eb14dd9..d499075 100644
--- a/SOURCE-AGENT-MODE.md
+++ b/SOURCE-AGENT-MODE.md
@@ -112,12 +112,34 @@ BRAIN_SOURCE_INBOX_ENABLED=true
 BRAIN_SOURCE_INBOX_INTERVAL=30s
 BRAIN_SOURCE_INBOX_BATCH_SIZE=12
 BRAIN_SOURCE_INBOX_MIN_SIMILARITY=0.55
+BRAIN_SOURCE_INBOX_MIN_PRIORITY=0.55
+BRAIN_SOURCE_INBOX_NOVELTY_FLOOR=0.35
 BRAIN_SOURCE_INBOX_MIN_RESULTS=2
 BRAIN_SOURCE_INBOX_FRESH_MAX_AGE=168h
 ```
 
-Classification is deliberately cheap: one batched embedding operation plus the configured precise/clustered nearest-neighbour retrieval. There is no Gemma/Qwen call just to classify every incoming news item.
+Classification is deliberately cheap: one batched embedding operation plus the configured precise/clustered nearest-neighbour retrieval and deterministic freshness/task/advisory scoring. There is no Gemma/Qwen call just to classify every incoming news item.
 
 ## Docker
 
 `deployment/docker-compose.source-agent.yml` is a minimal example that builds the exact same project with `BRAIN_MODE=agent`. The Agent only needs a persistent `/app/data` volume for local dedupe state and its cached remote configuration.
+
+## Verbindungsdiagnose und Docker-Adressen
+
+Ein Agent registriert sich aus Sicherheitsgründen **nicht selbst**. Er muss zuerst im Brain unter `/source-agents.html` angelegt werden; dort entsteht der Token. Ein Agent darf bereits Tasks zugewiesen bekommen, bevor er das erste Mal online ist.
+
+`BRAIN_AGENT_BRAIN_URL=http://127.0.0.1:...` oder `localhost` ist bei einem separaten Docker-Container fast immer falsch: Loopback zeigt auf den Agent-Container selbst. Für einen Agent auf demselben Docker-Host kann stattdessen `http://host.docker.internal:<BRAIN_PORT>` verwendet werden. Auf einem gemeinsamen Docker-Netz ist der Brain-Service-Name vorzuziehen.
+
+Das Brain kann mit `BRAIN_PUBLIC_URL` die korrekte, aus Agent-Sicht erreichbare Adresse veröffentlichen. Das Webinterface verwendet diese Adresse beim Erzeugen/Rotieren von Tokens.
+
+Der Agent stellt auf `/` eine kleine Statusseite und auf `/api/status` Diagnosedaten bereit. `brain_connected`, `last_config_success_at`, `last_heartbeat_success_at` und `last_connection_error` zeigen die tatsächliche Verbindung; `config_issued_at` kann dagegen aus dem lokalen Cache stammen und ist allein kein Verbindungsnachweis. Das Agent-Compose veröffentlicht die Statusseite standardmäßig über `BRAIN_AGENT_PORT=8092`.
+
+### Inbox-Klassifizierung für News und Advisories
+
+Seit Classifier v2 ist `BRAIN_SOURCE_INBOX_MIN_SIMILARITY` kein alleiniger Ausschlussfilter mehr. Ein Dokument wird `candidate`, wenn es entweder direkt genug KB-Nähe erreicht oder oberhalb des Novelty-Floors durch einen kombinierten Prioritätsscore aus KB-Nähe, kuratiertem Task-/Quellenkontext, Aktualität und News-/Advisory-Signalen relevant bleibt.
+
+- `BRAIN_SOURCE_INBOX_MIN_SIMILARITY=0.55`: direkte semantische Übernahme als Candidate.
+- `BRAIN_SOURCE_INBOX_MIN_PRIORITY=0.55`: Mindestscore des kombinierten News-/Knowledge-Routings.
+- `BRAIN_SOURCE_INBOX_NOVELTY_FLOOR=0.35`: harte Mindestnähe zur KB; darunter bleibt auch ein frischer Security-Alert archiviert.
+
+Beim ersten Start mit Classifier v2 werden bereits archivierte Dokumente einmalig auf `received` zurückgesetzt und mit der neuen Logik neu klassifiziert.
diff --git a/VALIDATION-SOURCE-AGENT-CONNECTION-FIX.md b/VALIDATION-SOURCE-AGENT-CONNECTION-FIX.md
new file mode 100644
index 0000000..dadce41
--- /dev/null
+++ b/VALIDATION-SOURCE-AGENT-CONNECTION-FIX.md
@@ -0,0 +1,15 @@
+# Validation: Source Agent Connection / Docker Fix
+
+Validated on the supplied offline environment:
+
+- focused config and Source-Agent diagnostics tests pass;
+- cached remote config is not treated as a live connection;
+- loopback Brain URLs are surfaced with a Docker-specific warning;
+- a fresh config success is reported as a live connection;
+- `BRAIN_PUBLIC_URL` accepts absolute HTTP(S) URLs and rejects invalid values;
+- JavaScript syntax passes for Source Agents, main UI and Analysis UI;
+- all three Docker Compose YAML files parse successfully;
+- project-wide Go type compilation (`go test ./... -run '^$'`) passes in a temporary Go 1.23 validation copy using the local SQLite compile stub;
+- `go vet ./...` passes in that validation copy.
+
+The release source itself remains on Go 1.26 with `modernc.org/sqlite v1.37.1`. A full runtime integration test against the real modernc SQLite driver is not possible in this offline Go 1.23 environment.
diff --git a/VALIDATION-SOURCE-AGENT-UI-LIST-FIX.md b/VALIDATION-SOURCE-AGENT-UI-LIST-FIX.md
new file mode 100644
index 0000000..3dad337
--- /dev/null
+++ b/VALIDATION-SOURCE-AGENT-UI-LIST-FIX.md
@@ -0,0 +1,11 @@
+# Validation: Source Agent UI List Fix
+
+Regression scenario:
+
+1. Brain contains one registered/online Agent.
+2. Agent has zero polling tasks.
+3. `GET /api/source-agents` must return `"agents":[...]` and `"tasks":[]`.
+4. `source-agents.js` must render the Agent selector and Agent card instead of stopping after the counters.
+5. A connected native `127.0.0.1` Agent must remain `connected` without a Docker-only warning.
+
+Static checks include Go formatting, `git diff --check`, JavaScript syntax validation and focused source-agent tests in the local compile-test environment.
diff --git a/VALIDATION-SOURCE-INBOX-PRIORITY-CLASSIFIER.md b/VALIDATION-SOURCE-INBOX-PRIORITY-CLASSIFIER.md
new file mode 100644
index 0000000..355c444
--- /dev/null
+++ b/VALIDATION-SOURCE-INBOX-PRIORITY-CLASSIFIER.md
@@ -0,0 +1,6 @@
+# Validation – Source Inbox Priority Classifier
+
+- Frischer kuratierter Security-Alert mit 0.49 KB-Nähe -> Candidate, wenn Priority >= 0.55.
+- Security-Alert mit 0.21 KB-Nähe -> archived trotz Aktualität (Novelty-Floor).
+- Evergreen-Dokument oberhalb direkter Similarity-Schwelle -> Candidate.
+- Archivierte Dokumente werden beim Classifier-Versionswechsel genau einmal requeued.
diff --git a/cmd/brain/main.go b/cmd/brain/main.go
index c595e34..1dcf514 100644
--- a/cmd/brain/main.go
+++ b/cmd/brain/main.go
@@ -20,7 +20,19 @@ import (
 	webui "github.com/local/glpi-neural-brain/internal/web"
 )
 
-const buildVersion = "source-agent-integrated-v1"
+const buildVersion = "source-agent-integrated-v1.1"
+
+const agentStatusHTML = `<!doctype html>
+<html lang="de"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1">
+<title>Neural Brain Source Agent</title><style>
+body{margin:0;background:#0b1018;color:#e8edf5;font:14px/1.45 system-ui,sans-serif}main{max-width:980px;margin:40px auto;padding:0 20px}.card{background:#121a26;border:1px solid #26364a;border-radius:12px;padding:22px}h1{margin:0 0 4px;font-size:22px}.muted{color:#90a0b5}.state{display:inline-block;padding:5px 9px;border-radius:999px;background:#253246;margin:12px 0}.ok{color:#6ee7a8}.bad{color:#ff9b9b}dl{display:grid;grid-template-columns:220px 1fr;gap:8px 16px;margin:18px 0}dt{color:#90a0b5}dd{margin:0;word-break:break-word}pre{white-space:pre-wrap;background:#0a0f16;padding:12px;border-radius:8px;border:1px solid #26364a}.warn{background:#352b15;border:1px solid #6c5721;padding:12px;border-radius:8px;color:#ffd98a}a{color:#87bfff}</style></head>
+<body><main><div class="card"><h1>Neural Brain · Source Agent</h1><div class="muted">Leichtgewichtiger Poller-Modus · Status aktualisiert sich automatisch.</div><div id="state" class="state">lade…</div><div id="warning"></div><dl id="details"></dl><pre id="error" style="display:none"></pre><div class="muted">JSON: <a href="/api/status">/api/status</a> · Health: <a href="/healthz">/healthz</a></div></div></main>
+<script>
+const fields=[['agent_id','Agent ID'],['brain_url','Brain URL'],['version','Version'],['configured_tasks','Tasks'],['config_source','Config-Quelle'],['config_issued_at','Config ausgestellt'],['last_config_success_at','Letzter Config-Erfolg'],['last_heartbeat_success_at','Letzter Heartbeat-Erfolg'],['last_task_run_at','Letzter Task-Lauf']];
+function fmt(v){if(v===null||v===undefined||v===''||v==='0001-01-01T00:00:00Z')return '—';return String(v)}
+async function refresh(){try{const r=await fetch('/api/status',{cache:'no-store'}),s=await r.json();const st=document.getElementById('state');st.textContent=s.connection_state==='degraded'?'● Brain erreichbar, Config/Heartbeat fehlerhaft':(s.brain_connected?'● mit Brain verbunden':'● keine aktuelle Brain-Verbindung');st.className='state '+(s.brain_connected&&s.connection_state!=='degraded'?'ok':'bad');document.getElementById('details').innerHTML=fields.map(([k,l])=>'<dt>'+l+'</dt><dd>'+fmt(s[k])+'</dd>').join('');const w=document.getElementById('warning');const msg=s.brain_url_warning||s.connection_hint||'';w.innerHTML=msg?'<div class="warn">'+msg.replace(/[&<>]/g,c=>({'&':'&amp;','<':'&lt;','>':'&gt;'}[c]))+'</div>':'';const e=document.getElementById('error'),err=s.last_connection_error||s.last_config_error||s.last_heartbeat_error||s.last_task_error||'';e.style.display=err?'block':'none';e.textContent=err?'Letzter Fehler: '+err:''}catch(e){document.getElementById('state').textContent='Status nicht lesbar: '+e}}
+refresh();setInterval(refresh,5000);
+</script></body></html>`
 
 func main() {
 	cfg, err := config.Load()
@@ -51,6 +63,11 @@ func runAgent(ctx context.Context, cfg config.Config) {
 	defer runner.Close()
 	runner.Start(ctx)
 	mux := http.NewServeMux()
+	mux.HandleFunc("GET /", func(w http.ResponseWriter, r *http.Request) {
+		w.Header().Set("Content-Type", "text/html; charset=utf-8")
+		w.Header().Set("Cache-Control", "no-store")
+		_, _ = w.Write([]byte(agentStatusHTML))
+	})
 	mux.HandleFunc("GET /api/status", func(w http.ResponseWriter, r *http.Request) {
 		w.Header().Set("Content-Type", "application/json")
 		_ = json.NewEncoder(w).Encode(runner.Status())
@@ -83,12 +100,17 @@ func runBrain(ctx context.Context, cancel context.CancelFunc, cfg config.Config)
 		os.Exit(1)
 	}
 	defer sourceStore.Close()
+	if requeued, err := sourceStore.EnsureInboxClassifierVersion(ctx, engine.SourceInboxClassifierVersion); err != nil {
+		slog.Warn("source inbox classifier migration failed", "error", err)
+	} else if requeued > 0 {
+		slog.Info("source inbox documents queued for classifier upgrade", "documents", requeued, "classifier_version", engine.SourceInboxClassifierVersion)
+	}
 	eng := engine.New(cfg, g, broker)
 	eng.SetSourceInbox(sourceStore)
 	eng.Start(ctx)
 	watcher := ingest.NewAgentWatcher(cfg.AgentRunsFiles, g, broker)
 	watcher.Start(ctx)
-	ui := &webui.Server{Engine: eng, Graph: g, Broker: broker, APIKey: cfg.APIKey, SourceAgents: sourceStore}
+	ui := &webui.Server{Engine: eng, Graph: g, Broker: broker, APIKey: cfg.APIKey, PublicURL: cfg.BrainPublicURL, SourceAgents: sourceStore}
 	srv := &http.Server{Addr: cfg.ListenAddr, Handler: ui.Handler(), ReadHeaderTimeout: 10 * time.Second, ReadTimeout: 30 * time.Second, WriteTimeout: 10 * time.Minute, IdleTimeout: 90 * time.Second}
 	go func() {
 		storage := g.StorageStatus()
diff --git a/data/article-fingerprints/01b52420af1dab2fc033f437e47a0c381510d6b4fc362d5f55dafb9e6f8bee45.json b/data/article-fingerprints/01b52420af1dab2fc033f437e47a0c381510d6b4fc362d5f55dafb9e6f8bee45.json
new file mode 100644
index 0000000..1d288b8
--- /dev/null
+++ b/data/article-fingerprints/01b52420af1dab2fc033f437e47a0c381510d6b4fc362d5f55dafb9e6f8bee45.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-01B52420AF1D",
+  "article_type": "how_to",
+  "fingerprint": "01b52420af1dab2fc033f437e47a0c381510d6b4fc362d5f55dafb9e6f8bee45",
+  "generated_at": "2026-08-07T20:21:46.0817085Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "6e6a2635613bc6be25210cd4"
+}
diff --git a/data/article-fingerprints/06627ccc38adf4f61c728031d52d688b931ffb1c42285e95be8df0d08f5a4711.json b/data/article-fingerprints/06627ccc38adf4f61c728031d52d688b931ffb1c42285e95be8df0d08f5a4711.json
new file mode 100644
index 0000000..6460804
--- /dev/null
+++ b/data/article-fingerprints/06627ccc38adf4f61c728031d52d688b931ffb1c42285e95be8df0d08f5a4711.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-06627CCC38AD",
+  "article_type": "how_to",
+  "fingerprint": "06627ccc38adf4f61c728031d52d688b931ffb1c42285e95be8df0d08f5a4711",
+  "generated_at": "2026-08-07T20:09:31.3063944Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "038a1e102334765776edaabe"
+}
diff --git a/data/article-fingerprints/10659642298872e249d07bc22684e31549fea6d901e08be9423b7f0cca95d4e4.json b/data/article-fingerprints/10659642298872e249d07bc22684e31549fea6d901e08be9423b7f0cca95d4e4.json
new file mode 100644
index 0000000..98246e9
--- /dev/null
+++ b/data/article-fingerprints/10659642298872e249d07bc22684e31549fea6d901e08be9423b7f0cca95d4e4.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-106596422988",
+  "article_type": "how_to",
+  "fingerprint": "10659642298872e249d07bc22684e31549fea6d901e08be9423b7f0cca95d4e4",
+  "generated_at": "2026-08-07T20:16:16.2042441Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "0978f9fcb5f9d667de4026b8"
+}
diff --git a/data/article-fingerprints/145eba49d1c373f03bf0f9d9094710854fb9b9b3575896c3f432fcf066ddf125.json b/data/article-fingerprints/145eba49d1c373f03bf0f9d9094710854fb9b9b3575896c3f432fcf066ddf125.json
new file mode 100644
index 0000000..dbca697
--- /dev/null
+++ b/data/article-fingerprints/145eba49d1c373f03bf0f9d9094710854fb9b9b3575896c3f432fcf066ddf125.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-145EBA49D1C3",
+  "article_type": "how_to",
+  "fingerprint": "145eba49d1c373f03bf0f9d9094710854fb9b9b3575896c3f432fcf066ddf125",
+  "generated_at": "2026-08-07T20:04:21.6686259Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "ee47afdfd96398a0b00ac3e6"
+}
diff --git a/data/article-fingerprints/732146655158326649b4c151ff06b85f3f68bee787eb3ec6df5d6dd732b73dd3.json b/data/article-fingerprints/732146655158326649b4c151ff06b85f3f68bee787eb3ec6df5d6dd732b73dd3.json
new file mode 100644
index 0000000..3f9c1c7
--- /dev/null
+++ b/data/article-fingerprints/732146655158326649b4c151ff06b85f3f68bee787eb3ec6df5d6dd732b73dd3.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-732146655158",
+  "article_type": "how_to",
+  "fingerprint": "732146655158326649b4c151ff06b85f3f68bee787eb3ec6df5d6dd732b73dd3",
+  "generated_at": "2026-08-07T20:12:58.4712352Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "0704c5d9a237272736cb7b2a"
+}
diff --git a/data/article-fingerprints/793683d419e80959ee2dc0a5c971893267ae9e28278ea3ff0f5aa82ec1daf7d4.json b/data/article-fingerprints/793683d419e80959ee2dc0a5c971893267ae9e28278ea3ff0f5aa82ec1daf7d4.json
new file mode 100644
index 0000000..23b65bc
--- /dev/null
+++ b/data/article-fingerprints/793683d419e80959ee2dc0a5c971893267ae9e28278ea3ff0f5aa82ec1daf7d4.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-793683D419E8",
+  "article_type": "how_to",
+  "fingerprint": "793683d419e80959ee2dc0a5c971893267ae9e28278ea3ff0f5aa82ec1daf7d4",
+  "generated_at": "2026-08-07T20:18:38.5587701Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "908f957a8654c3352c32ca83"
+}
diff --git a/data/article-fingerprints/8508e35d3ae5f7f1f1a924d834788a9134250b6a8632e30febdb7867f410bdd0.json b/data/article-fingerprints/8508e35d3ae5f7f1f1a924d834788a9134250b6a8632e30febdb7867f410bdd0.json
new file mode 100644
index 0000000..8bded18
--- /dev/null
+++ b/data/article-fingerprints/8508e35d3ae5f7f1f1a924d834788a9134250b6a8632e30febdb7867f410bdd0.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-8508E35D3AE5",
+  "article_type": "how_to",
+  "fingerprint": "8508e35d3ae5f7f1f1a924d834788a9134250b6a8632e30febdb7867f410bdd0",
+  "generated_at": "2026-08-07T20:17:00.3234009Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "f97c060b53b2d1cb4f8fbc96"
+}
diff --git a/data/article-fingerprints/99597deb060340eaabb23e80110ce1ec50ac664ff6df90a75988398605faf9c7.json b/data/article-fingerprints/99597deb060340eaabb23e80110ce1ec50ac664ff6df90a75988398605faf9c7.json
new file mode 100644
index 0000000..1384848
--- /dev/null
+++ b/data/article-fingerprints/99597deb060340eaabb23e80110ce1ec50ac664ff6df90a75988398605faf9c7.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-99597DEB0603",
+  "article_type": "how_to",
+  "fingerprint": "99597deb060340eaabb23e80110ce1ec50ac664ff6df90a75988398605faf9c7",
+  "generated_at": "2026-08-07T21:23:14.2001593Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "0180ce8fd088c35598e9d3c5"
+}
diff --git a/data/article-fingerprints/a10d74b11b65b09636739d5a6679653fbecc75659195fd0347d41e8f19f95036.json b/data/article-fingerprints/a10d74b11b65b09636739d5a6679653fbecc75659195fd0347d41e8f19f95036.json
new file mode 100644
index 0000000..4eaa697
--- /dev/null
+++ b/data/article-fingerprints/a10d74b11b65b09636739d5a6679653fbecc75659195fd0347d41e8f19f95036.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-A10D74B11B65",
+  "article_type": "how_to",
+  "fingerprint": "a10d74b11b65b09636739d5a6679653fbecc75659195fd0347d41e8f19f95036",
+  "generated_at": "2026-08-07T20:23:20.324326Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "206e6ff488c06b51d379606c"
+}
diff --git a/data/article-fingerprints/c35c93a5f9a6b2b5f9951180bad516bed624ab36e222e617ea6074187da300ec.json b/data/article-fingerprints/c35c93a5f9a6b2b5f9951180bad516bed624ab36e222e617ea6074187da300ec.json
new file mode 100644
index 0000000..02b17bf
--- /dev/null
+++ b/data/article-fingerprints/c35c93a5f9a6b2b5f9951180bad516bed624ab36e222e617ea6074187da300ec.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-C35C93A5F9A6",
+  "article_type": "how_to",
+  "fingerprint": "c35c93a5f9a6b2b5f9951180bad516bed624ab36e222e617ea6074187da300ec",
+  "generated_at": "2026-08-07T20:05:12.4901566Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "014516dfe205478447f304d3"
+}
diff --git a/data/article-fingerprints/c3d62c1dbdf5907c294a3a9af6d938d6b354c95b20f7306688cd2c4583ca8ba5.json b/data/article-fingerprints/c3d62c1dbdf5907c294a3a9af6d938d6b354c95b20f7306688cd2c4583ca8ba5.json
new file mode 100644
index 0000000..a29ced2
--- /dev/null
+++ b/data/article-fingerprints/c3d62c1dbdf5907c294a3a9af6d938d6b354c95b20f7306688cd2c4583ca8ba5.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-C3D62C1DBDF5",
+  "article_type": "how_to",
+  "fingerprint": "c3d62c1dbdf5907c294a3a9af6d938d6b354c95b20f7306688cd2c4583ca8ba5",
+  "generated_at": "2026-08-07T20:13:27.5896002Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "07a5b96fcba6e0ab9506f668"
+}
diff --git a/data/article-fingerprints/c8996e21622c2e0793ed798ae0116ec4fd5b9290ba25190f4749bf7db20c3938.json b/data/article-fingerprints/c8996e21622c2e0793ed798ae0116ec4fd5b9290ba25190f4749bf7db20c3938.json
new file mode 100644
index 0000000..a687d9c
--- /dev/null
+++ b/data/article-fingerprints/c8996e21622c2e0793ed798ae0116ec4fd5b9290ba25190f4749bf7db20c3938.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-C8996E21622C",
+  "article_type": "how_to",
+  "fingerprint": "c8996e21622c2e0793ed798ae0116ec4fd5b9290ba25190f4749bf7db20c3938",
+  "generated_at": "2026-08-07T20:45:10.2994708Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "ee47afdfd96398a0b00ac3e6"
+}
diff --git a/data/article-fingerprints/e58f8fc1d1078833dbefef9238b34b1c718f3b02f211b9a022f760810b2e0622.json b/data/article-fingerprints/e58f8fc1d1078833dbefef9238b34b1c718f3b02f211b9a022f760810b2e0622.json
new file mode 100644
index 0000000..70f5be1
--- /dev/null
+++ b/data/article-fingerprints/e58f8fc1d1078833dbefef9238b34b1c718f3b02f211b9a022f760810b2e0622.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-E58F8FC1D107",
+  "article_type": "how_to",
+  "fingerprint": "e58f8fc1d1078833dbefef9238b34b1c718f3b02f211b9a022f760810b2e0622",
+  "generated_at": "2026-08-07T20:06:59.8631869Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "01adee18f6b3f312d41cbdd7"
+}
diff --git a/data/article-fingerprints/f0ddd2838242c81538d1bacd88c5795e517cac39df9474fe861c84066eae0bb4.json b/data/article-fingerprints/f0ddd2838242c81538d1bacd88c5795e517cac39df9474fe861c84066eae0bb4.json
new file mode 100644
index 0000000..8914715
--- /dev/null
+++ b/data/article-fingerprints/f0ddd2838242c81538d1bacd88c5795e517cac39df9474fe861c84066eae0bb4.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-F0DDD2838242",
+  "article_type": "how_to",
+  "fingerprint": "f0ddd2838242c81538d1bacd88c5795e517cac39df9474fe861c84066eae0bb4",
+  "generated_at": "2026-08-07T20:07:27.2255286Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "02cda3d176e51ac4dd1c498d"
+}
diff --git a/data/article-fingerprints/f3dbf2cf1eeafd2e5b9302ccf7368236a7be30fc6598340c861d726fc3c197a3.json b/data/article-fingerprints/f3dbf2cf1eeafd2e5b9302ccf7368236a7be30fc6598340c861d726fc3c197a3.json
new file mode 100644
index 0000000..483ad33
--- /dev/null
+++ b/data/article-fingerprints/f3dbf2cf1eeafd2e5b9302ccf7368236a7be30fc6598340c861d726fc3c197a3.json
@@ -0,0 +1,9 @@
+{
+  "action": "merge",
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-F3DBF2CF1EEA",
+  "article_type": "how_to",
+  "fingerprint": "f3dbf2cf1eeafd2e5b9302ccf7368236a7be30fc6598340c861d726fc3c197a3",
+  "generated_at": "2026-08-07T20:15:28.9913429Z",
+  "schema": "article-source-fingerprint/v1",
+  "target_article_id": "0897415cf94afb317d142820"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-01b52420af1d.json b/data/article-metadata/kb-ai-think-article-20260807-01b52420af1d.json
new file mode 100644
index 0000000..10c3623
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-01b52420af1d.json
@@ -0,0 +1,202 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-01B52420AF1D",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-01b52420af1d.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 0.95,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Ransomware-Detection sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "014516dfe205478447f304d3",
+          "0de4dd40810c015dcc8545cc",
+          "4e619b8c2b06e4ef9d0a0bc9",
+          "550fa230cb16b3695c1efa19",
+          "6e6a2635613bc6be25210cd4",
+          "77d09ac332bb5af47102b388",
+          "89b7a3c8e3bc756028784993"
+        ],
+        "reason": "Die Quelle bestätigt explizit, dass Ransomware-Detection risikobasiert betrachtet werden sollte."
+      },
+      {
+        "claim": "Frühe Vorläufer wie Credential-Missbrauch, laterale Bewegung und ungewöhnliche Dateioperationen sind wichtige Indikatoren.",
+        "verdict": "supported",
+        "source_refs": [
+          "014516dfe205478447f304d3",
+          "0de4dd40810c015dcc8545cc",
+          "4e619b8c2b06e4ef9d0a0bc9",
+          "550fa230cb16b3695c1efa19",
+          "6e6a2635613bc6be25210cd4",
+          "77d09ac332bb5af47102b388",
+          "89b7a3c8e3bc756028784993"
+        ],
+        "reason": "Die Quellen bestätigen, dass solche Vorläufer als Indikatoren für Ransomware betrachtet werden sollten."
+      },
+      {
+        "claim": "Einzelne Indikatoren reichen nicht als Beweis für einen Vorfall aus.",
+        "verdict": "supported",
+        "source_refs": [
+          "014516dfe205478447f304d3",
+          "0de4dd40810c015dcc8545cc",
+          "4e619b8c2b06e4ef9d0a0bc9",
+          "550fa230cb16b3695c1efa19",
+          "6e6a2635613bc6be25210cd4",
+          "77d09ac332bb5af47102b388",
+          "89b7a3c8e3bc756028784993"
+        ],
+        "reason": "Die Quellen bestätigen, dass einzelne Indikatoren nicht ausreichen, um einen Vorfall zu beweisen."
+      },
+      {
+        "claim": "UTC-Timeline, Auth-/Endpoint-/Netzwerklogs und betroffene Dateien sind wichtige Beweismittel.",
+        "verdict": "supported",
+        "source_refs": [
+          "014516dfe205478447f304d3",
+          "0de4dd40810c015dcc8545cc",
+          "4e619b8c2b06e4ef9d0a0bc9",
+          "550fa230cb16b3695c1efa19",
+          "6e6a2635613bc6be25210cd4",
+          "77d09ac332bb5af47102b388",
+          "89b7a3c8e3bc756028784993"
+        ],
+        "reason": "Die Quellen bestätigen, dass solche Daten als Beweismittel relevant sind."
+      },
+      {
+        "claim": "Dokumentation des Scopes, betroffener Assets/Identitäten, Datenkritikalität, Exposition und betrieblicher Abhängigkeiten ist ein Entscheidungskriterium.",
+        "verdict": "supported",
+        "source_refs": [
+          "014516dfe205478447f304d3",
+          "0de4dd40810c015dcc8545cc",
+          "4e619b8c2b06e4ef9d0a0bc9",
+          "550fa230cb16b3695c1efa19",
+          "6e6a2635613bc6be25210cd4",
+          "77d09ac332bb5af47102b388",
+          "89b7a3c8e3bc756028784993"
+        ],
+        "reason": "Die Quellen bestätigen, dass die Dokumentation solcher Aspekte ein zentraler Bestandteil der Entscheidungsfindung ist."
+      },
+      {
+        "claim": "Ransomware-Detection sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "014516dfe205478447f304d3",
+          "0de4dd40810c015dcc8545cc",
+          "4e619b8c2b06e4ef9d0a0bc9",
+          "550fa230cb16b3695c1efa19",
+          "6e6a2635613bc6be25210cd4",
+          "77d09ac332bb5af47102b388",
+          "89b7a3c8e3bc756028784993"
+        ],
+        "reason": "Die Quelle bestätigt explizit, dass Ransomware-Detection risikobasiert betrachtet werden sollte."
+      }
+    ]
+  },
+  "confidence": 0.95,
+  "generated_at": "2026-08-07T20:21:46.0811826Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "Ransomware Detection \u0026 Forensics – präventiv, resilient und Vorfall-basiert gestalten",
+    "purpose": "Die Quellen enthalten mehrere produktive Artikel zu ähnlichen Themen (Ransomware Detection, Forensics, Prevention, Containment, Egress Detection) mit überlappender Struktur und Inhalt. Sie können als Staging-Entwurf in einen einheitlichen Zielartikel konsolidiert werden, der präventive, reaktive und forensische Aspekte der Ransomware-Bekämpfung umfassend abdeckt.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": null,
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "Ransomware Detection \u0026 Forensics – präventiv, resilient und Vorfall-basiert gestalten",
+    "missing_information": [],
+    "reason": "Die Quellen enthalten mehrere produktive Artikel zu ähnlichen Themen (Ransomware Detection, Forensics, Prevention, Containment, Egress Detection) mit überlappender Struktur und Inhalt. Sie können als Staging-Entwurf in einen einheitlichen Zielartikel konsolidiert werden, der präventive, reaktive und forensische Aspekte der Ransomware-Bekämpfung umfassend abdeckt."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 8,
+  "research_material": [
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Fortschrittliche Angriffe – dynamische Entwicklung\n\nDas BSI beobachtet jeden Tag die Bedrohungslage, die von neuen Schadprogrammen, erweiterten Angriffsmethoden oder gezieltem Vorgehen von Tätern für Unternehmen und Behörden ausgeht. In der jüngsten Zeit haben sich die Expertinnen und Experten im BSI-Lagezentrum und bei CERT-Bund zunehmend mit ausgefeilten Angriffstechniken auseinandersetzen müssen: Neue fortschrittliche Angriffe stellen ein vielfach höheres Bedrohungspotenzial dar, wenn sie beispielsweise in ein Unternehmensnetzwerk eindringen konnten. Eine Gesamtübersicht zum Thema Ransomware finden Sie unter Fakten und Abwehrstrategien .\n\nDigitale Erpressung mit Ransomware\n\nRansomware in seinen unterschiedlichen Varianten zielt in der Regel auf die Verschlüsselung von Nutzerdaten ab. Das Vorgehen der Täter zählt zu den fortschrittlichen Angriffen, deren Weiterentwicklung das BSI seit …",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Ransomware Detection \u0026 Forensics – präventiv, resilient und Vorfall-basiert gestalten aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "authoritative",
+      "source_quality_score": 0.95,
+      "title": "BSI - Ransomware",
+      "url": "https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Gefaehrdungen/Fortschrittliche-Angriffe/Fortschrittliche-Angriffe_node.html"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Ransomware – Fakten und Abwehrstrategien\n\nRansomware -Angriffe stellen eine der größten Cyberbedrohungen für Staat, Wirtschaft und Gesellschaft dar.\n\nBedrohung für Jede und Jeden\n\nBei einem Ransomware -Angriff werden die Daten auf einem IT -System verschlüsselt und eine Entschlüsselung erst gegen Zahlung eines Lösegeldes ( engl. Ransom ) in Aussicht gestellt. Immer öfter wird zusätzlich mit der Veröffentlichung der zuvor entwendeten Daten gedroht, um das Opfer zusätzlich unter Druck zu setzen. Ransomware Angriffe zeichnen sich dadurch aus, dass die Auswirkungen auf einen Betroffenen mit dem Einsatz der Ransomware unmittelbar eintreten:\n\nDienstleistungen und Geschäftsprozesse können nicht mehr zur Verfügung gestellt werden.\n\nDie IT des Betroffenen kommt zum Erliegen.\n\nDurch die zunehmende Professionalisierung und Arbeitsteilung auf Angreiferseite sind zudem die Einstiegshürden für die Dur…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Ransomware Detection \u0026 Forensics – präventiv, resilient und Vorfall-basiert gestalten current official documentation version support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "authoritative",
+      "source_quality_score": 0.95,
+      "title": "BSI - Ransomware Angriffe - Ransomware – Fakten und Abwehrstrategien",
+      "url": "https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Analysen-und-Prognosen/Ransomware-Angriffe/ransomware-angriffe.html"
+    }
+  ],
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 0,
+  "source_fingerprint": "01b52420af1dab2fc033f437e47a0c381510d6b4fc362d5f55dafb9e6f8bee45",
+  "source_node_ids": [
+    "014516dfe205478447f304d3",
+    "0de4dd40810c015dcc8545cc",
+    "18def0be29f24bdf90b1a3b3",
+    "4e619b8c2b06e4ef9d0a0bc9",
+    "550fa230cb16b3695c1efa19",
+    "6e6a2635613bc6be25210cd4",
+    "77d09ac332bb5af47102b388",
+    "89b7a3c8e3bc756028784993"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-03824",
+    "KB-SEC-HB-03825",
+    "KB-SEC-HB-03826",
+    "KB-SEC-HB-03827",
+    "KB-SEC-HB-03842",
+    "KB-SEC-HB-03902",
+    "KB-SEC-HB-03904",
+    "KB-SEC-HB-03905"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-03826",
+  "target_node_id": "6e6a2635613bc6be25210cd4"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-06627ccc38ad.json b/data/article-metadata/kb-ai-think-article-20260807-06627ccc38ad.json
new file mode 100644
index 0000000..b7b6373
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-06627ccc38ad.json
@@ -0,0 +1,159 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-06627CCC38AD",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-06627ccc38ad.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 1,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall; Korrelationen sind entscheidend.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04109"
+        ],
+        "reason": "Die Aussage wird direkt durch die Quelle KB-SEC-HB-04109 (Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen) unterstützt."
+      },
+      {
+        "claim": "Hardware Tamper Detection sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04109"
+        ],
+        "reason": "Die Aussage wird direkt durch die Quelle KB-SEC-HB-04109 (Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen) unterstützt."
+      },
+      {
+        "claim": "Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten müssen dokumentiert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04109"
+        ],
+        "reason": "Die Aussage wird direkt durch die Quelle KB-SEC-HB-04109 (Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen) unterstützt."
+      },
+      {
+        "claim": "Sicherheitsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt verschlechtern.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04109"
+        ],
+        "reason": "Die Aussage wird direkt durch die Quelle KB-SEC-HB-04109 (Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen) unterstützt."
+      },
+      {
+        "claim": "Funktion, Security-Kontrolle und Telemetrie nach Änderungen separat testen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04109"
+        ],
+        "reason": "Die Aussage wird direkt durch die Quelle KB-SEC-HB-04109 (Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen) unterstützt."
+      },
+      {
+        "claim": "Bei bestätigter Kompromittierung den Scope auf angrenzende Systeme/Identitäten erweitern.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04109"
+        ],
+        "reason": "Die Aussage wird direkt durch die Quelle KB-SEC-HB-04109 (Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen) unterstützt."
+      },
+      {
+        "claim": "Ursache beseitigen, um weitere Vorfälle zu verhindern.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04109"
+        ],
+        "reason": "Die Aussage wird direkt durch die Quelle KB-SEC-HB-04109 (Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen) unterstützt."
+      },
+      {
+        "claim": "Zutrittsereignisse, Video-/Alarmdaten, Asset-Bewegungen, Umwelt-/Stromalarme und Systemereignisse zeitlich korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04109"
+        ],
+        "reason": "Die Aussage wird direkt durch die Quelle KB-SEC-HB-04109 (Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen) unterstützt."
+      },
+      {
+        "claim": "Abweichungen immer mit Asset-, Identitäts- und Change-Kontext korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04109"
+        ],
+        "reason": "Die Aussage wird direkt durch die Quelle KB-SEC-HB-04109 (Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen) unterstützt."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04109"
+        ],
+        "reason": "Die Aussage wird direkt durch die Quelle KB-SEC-HB-04109 (Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen) unterstützt."
+      }
+    ]
+  },
+  "confidence": 1,
+  "generated_at": "2026-08-07T20:09:31.3063944Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen",
+    "purpose": "Mehrere produktive Artikel zu 'Hardware Tamper Detection' überschneiden sich stark in Inhalt und Struktur. Sie behandeln alle Aspekte der Erkennung, Untersuchung und Prävention von Hardware-Tamper-Vorfällen. Ein Zielartikel kann diese Inhalte konsolidieren, ohne Doppelungen zu erzeugen. Der Artikel 'Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen' ist ein klarer Kandidat als Ziel, da er den Schwerpunkt auf die Erkennung und Untersuchung legt, was mit den anderen Artikeln gut kombinierbar ist.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": null,
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen",
+    "missing_information": [],
+    "reason": "Mehrere produktive Artikel zu 'Hardware Tamper Detection' überschneiden sich stark in Inhalt und Struktur. Sie behandeln alle Aspekte der Erkennung, Untersuchung und Prävention von Hardware-Tamper-Vorfällen. Ein Zielartikel kann diese Inhalte konsolidieren, ohne Doppelungen zu erzeugen. Der Artikel 'Hardware Tamper Detection – Vorfälle erkennen und nachvollziehbar untersuchen' ist ein klarer Kandidat als Ziel, da er den Schwerpunkt auf die Erkennung und Untersuchung legt, was mit den anderen Artikeln gut kombinierbar ist."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 8,
+  "research_material": null,
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 0,
+  "source_fingerprint": "06627ccc38adf4f61c728031d52d688b931ffb1c42285e95be8df0d08f5a4711",
+  "source_node_ids": [
+    "038a1e102334765776edaabe",
+    "040991d3876d1d05e6650a25",
+    "046e6463b7183cb3fe4961a7",
+    "609ba92bea1f4cda85b6fc6a",
+    "77242d4ad218fa31b4a0586d",
+    "9ec928285d56c55f540bfa2a",
+    "bcb65b59c9190b0346d670c6",
+    "e50c31ce2db0a0c028db50fe"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-00354",
+    "KB-SEC-HB-00426",
+    "KB-SEC-HB-02799",
+    "KB-SEC-HB-02810",
+    "KB-SEC-HB-02811",
+    "KB-SEC-HB-02923",
+    "KB-SEC-HB-04108",
+    "KB-SEC-HB-04109"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-04109",
+  "target_node_id": "038a1e102334765776edaabe"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-106596422988.json b/data/article-metadata/kb-ai-think-article-20260807-106596422988.json
new file mode 100644
index 0000000..810e40a
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-106596422988.json
@@ -0,0 +1,271 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-106596422988",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-106596422988.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 0.95,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Backup Repository Hardening sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8",
+          "39bc48ebb8ff1d01f6c0720c"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03867 und KB-SEC-HB-03866 bestätigen, dass Backup Repository Hardening risikobasiert betrachtet werden sollte."
+      },
+      {
+        "claim": "Frühe Vorläufer wie Credential-Missbrauch, laterale Bewegung, ungewöhnliche Dateioperationen, Backup-/Snapshot-Manipulation und Exfiltration sollten zusammen betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8",
+          "39bc48ebb8ff1d01f6c0720c"
+        ],
+        "reason": "Die Quellen KB-SEC-HB-03867 und KB-SEC-HB-03866 bestätigen, dass diese Vorläufer zusammen betrachtet werden sollten."
+      },
+      {
+        "claim": "MFA, Segmentierung, Least Privilege, Egress-Kontrolle, gehärtete Admin-Pfade sowie immutable/offline Backups und regelmäßig getestete Restore-Verfahren kombinieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8",
+          "39bc48ebb8ff1d01f6c0720c"
+        ],
+        "reason": "Die Quellen KB-SEC-HB-03867 und KB-SEC-HB-03866 erwähnen Sicherheitsmaßnahmen wie MFA, Segmentierung, Least Privilege, Egress-Kontrolle, gehärtete Admin-Pfade, immutable/offline Backups und regelmäßig getestete Restore-Verfahren."
+      },
+      {
+        "claim": "Sicherheitsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt verschlechtern.",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03867 bestätigt, dass Sicherheitsmaßnahmen die Verfügbarkeit und Wiederherstellbarkeit nicht verschlechtern dürfen."
+      },
+      {
+        "claim": "UTC-Timeline, Auth-/Endpoint-/Netzwerklogs, betroffene Dateien und Metadaten, Backup-/Snapshot-Audit, Exfiltrationshinweise, verschlüsselte Samples ohne Ausführung, Recovery-Protokolle und Entscheidungen sollten priorisiert gesichert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03867 erwähnt, dass diese Elemente priorisiert gesichert werden sollten."
+      },
+      {
+        "claim": "Änderungen für 'Backup Repository Hardening' sollten kontrolliert getestet, Rollback vorgesehen, Ausnahmewege befristet und Konfigurationsdrift überwacht werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03867 bestätigt, dass Änderungen kontrolliert getestet, Rollback vorgesehen, Ausnahmewege befristet und Konfigurationsdrift überwacht werden sollten."
+      },
+      {
+        "claim": "Analyse von Protokolldateien auf verdächtige Aktivitäten",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03867 erwähnt, dass Protokolldateien auf verdächtige Aktivitäten analysiert werden sollten."
+      },
+      {
+        "claim": "Test der Restore-Funktionalität",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03867 bestätigt, dass die Restore-Funktionalität getestet werden sollte."
+      },
+      {
+        "claim": "Überprüfung der Immutability-Einstellungen",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03867 erwähnt, dass die Immutability-Einstellungen überprüft werden sollten."
+      },
+      {
+        "claim": "Überprüfung der Zugriffskontrollen und Berechtigungen",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03867 bestätigt, dass Zugriffskontrollen und Berechtigungen überprüft werden sollten."
+      },
+      {
+        "claim": "Führen Sie regelmäßige Restore-Tests durch, um die Funktionalität der Backups zu überprüfen.",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03867 bestätigt, dass regelmäßige Restore-Tests durchgeführt werden sollten."
+      },
+      {
+        "claim": "Stellen Sie sicher, dass Zugriffskontrollen korrekt konfiguriert sind und das Prinzip der geringsten Privilegien eingehalten wird.",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03867 bestätigt, dass Zugriffskontrollen korrekt konfiguriert sein und das Prinzip der geringsten Privilegien eingehalten werden sollten."
+      },
+      {
+        "claim": "Überprüfen Sie die Konfiguration des Backup-Repositories auf Sicherheitslücken.",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03867 bestätigt, dass die Konfiguration des Backup-Repositories auf Sicherheitslücken überprüft werden sollte."
+      },
+      {
+        "claim": "Überprüfen Sie regelmäßig die Protokolle der Backup-Software auf ungewöhnliche Aktivitäten.",
+        "verdict": "supported",
+        "source_refs": [
+          "0978f9fcb5f9d667de4026b8"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03867 bestätigt, dass die Protokolle der Backup-Software regelmäßig auf ungewöhnliche Aktivitäten überprüft werden sollten."
+      }
+    ]
+  },
+  "confidence": 0.95,
+  "generated_at": "2026-08-07T20:16:16.2037254Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "Backup Repository Hardening – präventiv, resilient und im Vorfall erkennen, eindämmen und wiederherstellen",
+    "purpose": "Die Quellen 0978f9fcb5f9d667de4026b8 und 39bc48ebb8ff1d01f6c0720c behandeln beide das Thema 'Backup Repository Hardening', wobei die erste sich auf den Vorfall fokussiert und die zweite auf präventive und resiliente Maßnahmen. Da beide Artikel sich stark überschneiden und jeweils einen Teilaspekt des Themas abdecken, ist eine Konsolidierung sinnvoll, um einen umfassenderen, einheitlichen Artikel zu erstellen, der sowohl präventive als auch reaktive Aspekte der Backup Repository Hardening abdeckt.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": null,
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "Backup Repository Hardening – präventiv, resilient und im Vorfall erkennen, eindämmen und wiederherstellen",
+    "missing_information": [],
+    "reason": "Die Quellen 0978f9fcb5f9d667de4026b8 und 39bc48ebb8ff1d01f6c0720c behandeln beide das Thema 'Backup Repository Hardening', wobei die erste sich auf den Vorfall fokussiert und die zweite auf präventive und resiliente Maßnahmen. Da beide Artikel sich stark überschneiden und jeweils einen Teilaspekt des Themas abdecken, ist eine Konsolidierung sinnvoll, um einen umfassenderen, einheitlichen Artikel zu erstellen, der sowohl präventive als auch reaktive Aspekte der Backup Repository Hardening abdeckt."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 8,
+  "research_material": [
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Backup Hardening: Backups als letzte Verteidigung sichern | connecT AG\n\nZum Inhalt springen\n\nBackup Hardening: Warum schnelle Backups allein keine Resilienz schaffen\n\nvon  Fabian Beitz\n\n30. September 2025\n\n0:00\n\n0:00\n\nBackup-Infrastrukturen sind heute so performant wie nie. 10-Gbit/s-Anbindungen, Deduplizierung, SSD-Caches und Instant Recovery reduzieren RPO und RTO deutlich. Trotzdem scheitern Unternehmen im Ernstfall regelmäßig an einem ganz anderen Punkt: Backups sind zwar vorhanden, aber kompromittiert, unvollständig oder nicht schnell genug wiederherstellbar, weil Angreifer sie vorab zerstört oder verschlüsselt haben. Backup Hardening adressiert genau diese Lücke. Es betrachtet Backups als eigenständige Sicherheitsdomäne mit klaren Schutzmechanismen – organisatorisch wie technisch. Wer Hardening nur als „nice to have“ behandelt, erhöht die Wahrscheinlichkeit, dass die letzte Verteid…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Backup Repository Hardening – präventiv, resilient und im Vorfall erkennen, eindämmen und wiederherstellen aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.3342857142857143,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Backup Hardening: Backups als letzte Verteidigung sichern | connecT AG",
+      "url": "https://cnag.de/backup-hardening-warum-schnelle-backups-allein-keine-resilienz-schaffen/"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Hardened Repository\n\nTo protect your backup files from loss as a result of malware activity or unplanned actions, you can add a hardened repository based on a Linux server to your backup infrastructure.\n\nA hardened repository supports the following features:\n\nImmutability : when you add a hardened repository, you specify the time period while backup files must be immutable. During this period, backup files stored in this repository cannot be moved, modified or deleted, but can be copied.\n\nSecure Authentication : when you add a hardened repository, you specify the method used to authenticate connections.\n\nCertificate-based : No user name or password is required; authentication is performed using certificates. It is recommended for environments where Kerberos is disabled or unavailable, or for enhanced security. This option is available for hardened repositories deployed from the Veeam Inf…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Backup Repository Hardening – präventiv, resilient und im Vorfall erkennen, eindämmen und wiederherstellen aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "primary",
+      "source_quality_score": 0.88,
+      "title": "Hardened Repository - Veeam Backup \u0026 Replication User Guide",
+      "url": "https://helpcenter.veeam.com/docs/vbr/userguide/hardened_repository.html"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Security\n\nVeeam Backup \u0026 Replication: Immutable Backup mit Veeam Hardened Repository\n\nMit Version 11 hat Veeam den Schutz von Backups durch äußere Angriffe in seiner Backup \u0026 Replication Suite weiter verbessert: „Hardened Repository“ heißt das Feature, welches Backups unveränderlich im jeweiligen Backup Ziel, dem Repository, ablegt.\n\n03.04.2022\n\nLesedauer wird berechnet …\n\nWas bedeutet eigentlich “Immutable”, also \"unveränderliches\" Backup?\n\nPer Definition erfüllen unveränderliche Backups unter anderem den Zweck, nicht gelöscht oder verschlüsselt werden zu können. Das Löschen kann zum einen versehentlich oder willkürlich passieren, eine Verschlüsselung aber auch durch einen Angriff von außen über eine Ransomware-Infektion. Diverse Konfigurationsparameter bestimmen dabei, wie lange die Backups nicht verändert werden können.\n\nSchema zum Testaufbau\n\nWas bedeutet eigentlich “Immutable”, also…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Backup Repository Hardening – präventiv, resilient und im Vorfall erkennen, eindämmen und wiederherstellen current official documentation version support",
+      "relevance": 0.37,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Veeam Backup \u0026 Replication: Immutable Backup mit Veeam Hardened Repository",
+      "url": "https://www.netgo.de/blog/veeam-backup-replication-immutable-backup"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Backup Hardening: Warum eine gehärtete Backup-Umgebung essenziell ist\n\nServices\n\nInnovation\n\nConsulting\n\nEngineering\n\nOperation\n\nTechnolgy\n\nService Management\n\nEnterprise Service Management\n\nService Management\n\nBusiness Management\n\nOperation Management\n\nService Now Plattform\n\nHR Service Management\n\nPartner\n\nMicrosoft\n\nHewlett Packard Enterprise\n\nCisco\n\nServiceNow\n\nHP Inc.\n\nWeitere Partner\n\nUnternehmen\n\nAbout us\n\nJobs\n\nNews \u0026 Events\n\nGeschäftsleitung\n\nReferenzen\n\nAuszeichnungen\n\nStandorte \u0026 Kontakt\n\nBlog\n\nBackup Hardening: Warum eine gehärtete Backup-Umgebung essenziell ist\n\nErstellt von\nMarkus Schober am 25.03.2025 08:00:00\n\nTweet\n\nWarum ist Backup Hardening so wichtig? Backups sind das letzte Sicherheitsnetz jeder IT-Infrastruktur. Doch ohne ausreichende Härtung sind sie oft das primäre Ziel von Angreifern. Ransomware-Gruppen und Bedrohungsakteure fokussieren sich zunehmend auf Backup-S…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Backup Repository Hardening – präventiv, resilient und im Vorfall erkennen, eindämmen und wiederherstellen current official documentation version support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Backup Hardening: Warum eine gehärtete Backup-Umgebung essenziell ist",
+      "url": "https://blog.bithawk.ch/it-security/backup-hardening-warum-eine-geh%C3%A4rtete-backup-umgebung-essenziell-ist"
+    }
+  ],
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 0,
+  "source_fingerprint": "10659642298872e249d07bc22684e31549fea6d901e08be9423b7f0cca95d4e4",
+  "source_node_ids": [
+    "014516dfe205478447f304d3",
+    "0978f9fcb5f9d667de4026b8",
+    "39bc48ebb8ff1d01f6c0720c",
+    "3c96e3a129fb8a15d312576a",
+    "550fa230cb16b3695c1efa19",
+    "897c2c195dd28b946263d91c",
+    "a503ef4bbbf855221668409d",
+    "d3166e0e7ba0ba06c9975296"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-03824",
+    "KB-SEC-HB-03825",
+    "KB-SEC-HB-03856",
+    "KB-SEC-HB-03866",
+    "KB-SEC-HB-03867",
+    "KB-SEC-HB-03878",
+    "KB-SEC-HB-03880",
+    "KB-SEC-HB-03924"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-03867",
+  "target_node_id": "0978f9fcb5f9d667de4026b8"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-145eba49d1c3.json b/data/article-metadata/kb-ai-think-article-20260807-145eba49d1c3.json
new file mode 100644
index 0000000..1237c01
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-145eba49d1c3.json
@@ -0,0 +1,434 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-145EBA49D1C3",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-145eba49d1c3.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 1,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Wayland/X11 Remote Access sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "ee47afdfd96398a0b00ac3e6"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00324 belegt."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
+        "verdict": "supported",
+        "source_refs": [
+          "ee47afdfd96398a0b00ac3e6"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00324 belegt."
+      },
+      {
+        "claim": "Konfiguration, Rechte, Dienste, Netzwerkexposition, Patchstand und unnötige Funktionen müssen erfasst werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "ee47afdfd96398a0b00ac3e6"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00324 belegt."
+      },
+      {
+        "claim": "Least Privilege, sichere Defaults, minimale Pakete/Dienste, restriktive Rechte, zentrale Logs und kontrolliertes Patchen sind wichtige Härtungsmaßnahmen.",
+        "verdict": "supported",
+        "source_refs": [
+          "ee47afdfd96398a0b00ac3e6"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00324 belegt."
+      },
+      {
+        "claim": "Abweichungen vom erwarteten Normalverhalten sind immer mit Asset-, Identitäts- und Change-Kontext zu korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "ee47afdfd96398a0b00ac3e6"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00324 belegt."
+      },
+      {
+        "claim": "Sicherheitsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt verschlechtern.",
+        "verdict": "supported",
+        "source_refs": [
+          "ee47afdfd96398a0b00ac3e6"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00324 belegt."
+      },
+      {
+        "claim": "Journalctl/syslog, auditd, Prozessbaum, Netzwerkzustand, Datei-/Konfigurationsänderungen und Paket-/Authentifizierungslogs sind wichtige Beweismittel.",
+        "verdict": "supported",
+        "source_refs": [
+          "ee47afdfd96398a0b00ac3e6"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00324 belegt."
+      },
+      {
+        "claim": "Beweismittel müssen mit Zeitbezug, Herkunft und Hash/Integritätsnachweis dokumentiert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "ee47afdfd96398a0b00ac3e6"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00324 belegt."
+      },
+      {
+        "claim": "Wayland/X11 Remote Access sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "007209fd1586eadd0b80951a"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00323 belegt."
+      },
+      {
+        "claim": "Konfiguration, Rechte, Dienste, Netzwerkexposition, Patchstand und unnötige Funktionen erfassen.",
+        "verdict": "supported",
+        "source_refs": [
+          "007209fd1586eadd0b80951a"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00323 belegt."
+      },
+      {
+        "claim": "Abweichungen immer mit Asset-, Identitäts- und Change-Kontext korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "007209fd1586eadd0b80951a"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00323 belegt."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
+        "verdict": "supported",
+        "source_refs": [
+          "007209fd1586eadd0b80951a"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00323 belegt."
+      },
+      {
+        "claim": "Wayland/X11 Remote Access sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "0086802a963fbd5e8a4d031d"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-01008 belegt."
+      },
+      {
+        "claim": "Requests, Response-Codes, Identitäten, Session-/Token-Kontext, Reverse-Proxy-/WAF-/App-Logs und Deployments korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "0086802a963fbd5e8a4d031d"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-01008 belegt."
+      },
+      {
+        "claim": "Abweichungen immer mit Asset-, Identitäts- und Change-Kontext korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "0086802a963fbd5e8a4d031d"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-01008 belegt."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
+        "verdict": "supported",
+        "source_refs": [
+          "0086802a963fbd5e8a4d031d"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-01008 belegt."
+      },
+      {
+        "claim": "Wayland/X11 Remote Access sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "74b82044ebe7b2aa5da30f1f"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-01006 belegt."
+      },
+      {
+        "claim": "Requests, Response-Codes, Identitäten, Session-/Token-Kontext, Reverse-Proxy-/WAF-/App-Logs und Deployments korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "74b82044ebe7b2aa5da30f1f"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-01006 belegt."
+      },
+      {
+        "claim": "Abweichungen immer mit Asset-, Identitäts- und Change-Kontext korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "74b82044ebe7b2aa5da30f1f"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-01006 belegt."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
+        "verdict": "supported",
+        "source_refs": [
+          "74b82044ebe7b2aa5da30f1f"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-01006 belegt."
+      },
+      {
+        "claim": "Wayland/X11 Remote Access sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "14a02be72685169e757c9ed6"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00987 belegt."
+      },
+      {
+        "claim": "Requests, Response-Codes, Identitäten, Session-/Token-Kontext, Reverse-Proxy-/WAF-/App-Logs und Deployments korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "14a02be72685169e757c9ed6"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00987 belegt."
+      },
+      {
+        "claim": "Abweichungen immer mit Asset-, Identitäts- und Change-Kontext korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "14a02be72685169e757c9ed6"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00987 belegt."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
+        "verdict": "supported",
+        "source_refs": [
+          "14a02be72685169e757c9ed6"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00987 belegt."
+      },
+      {
+        "claim": "Wayland/X11 Remote Access sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "067722c1a7edf5d75a960ba0"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-01007 belegt."
+      },
+      {
+        "claim": "Requests, Response-Codes, Identitäten, Session-/Token-Kontext, Reverse-Proxy-/WAF-/App-Logs und Deployments korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "067722c1a7edf5d75a960ba0"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-01007 belegt."
+      },
+      {
+        "claim": "Abweichungen immer mit Asset-, Identitäts- und Change-Kontext korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "067722c1a7edf5d75a960ba0"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-01007 belegt."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
+        "verdict": "supported",
+        "source_refs": [
+          "067722c1a7edf5d75a960ba0"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-01007 belegt."
+      },
+      {
+        "claim": "Wayland/X11 Remote Access sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "10c17d3542bb86405b2c1c39"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00985 belegt."
+      },
+      {
+        "claim": "Requests, Response-Codes, Identitäten, Session-/Token-Kontext, Reverse-Proxy-/WAF-/App-Logs und Deployments korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "10c17d3542bb86405b2c1c39"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00985 belegt."
+      },
+      {
+        "claim": "Abweichungen immer mit Asset-, Identitäts- und Change-Kontext korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "10c17d3542bb86405b2c1c39"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00985 belegt."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
+        "verdict": "supported",
+        "source_refs": [
+          "10c17d3542bb86405b2c1c39"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-00985 belegt."
+      }
+    ]
+  },
+  "confidence": 1,
+  "generated_at": "2026-08-07T20:04:21.6681063Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "Wayland/X11 Remote Access – forensisch prüfen",
+    "purpose": "Mehrere produktive Artikel zu 'Wayland/X11 Remote Access' und 'API Inventory' sowie 'API Keys' überschneiden sich in der Struktur und den Schwerpunkten (forensisch prüfen, überwachen, absichern). Sie können als Staging-Entwurf in einen Zielartikel zu 'Wayland/X11 Remote Access – forensisch prüfen' konsolidiert werden, um eine umfassende, strukturierte Lösung zu bieten.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": [
+    "Gibt es spezielle Compliance-Anforderungen, die bei der forensischen Untersuchung zu berücksichtigen sind?",
+    "Welche spezifischen Tools und Technologien werden in der Zielumgebung für Wayland/X11 Remote Access eingesetzt?"
+  ],
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "Wayland/X11 Remote Access – forensisch prüfen",
+    "missing_information": [],
+    "reason": "Mehrere produktive Artikel zu 'Wayland/X11 Remote Access' und 'API Inventory' sowie 'API Keys' überschneiden sich in der Struktur und den Schwerpunkten (forensisch prüfen, überwachen, absichern). Sie können als Staging-Entwurf in einen Zielartikel zu 'Wayland/X11 Remote Access – forensisch prüfen' konsolidiert werden, um eine umfassende, strukturierte Lösung zu bieten."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 8,
+  "research_material": [
+    {
+      "actionable": true,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "X11 Application Support\n\nIntroduction\n\nBeing able to run existing X11 applications is crucial for the adoption of\nWayland, especially on desktops, as there will always be X11 applications that\nhave not been or cannot be converted into Wayland applications, and throwing\nthem all away would be prohibitive. Therefore a Wayland compositor often needs\nto support running X11 applications.\n\nX11 and Wayland are different enough that there is no “simple” way to translate\nbetween them. Most of X11 is uninteresting to a Wayland compositor. That,\ncombined with the gigantic implementation effort needed to support X11, makes it\nintractable to just write X11 support directly in a Wayland compositor. The\nimplementation would be nothing short of a real X11 server.\n\nTherefore, Wayland compositors should use Xwayland, the X11 server that lives in\nthe Xorg server source code repository and shares most of th…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Wayland/X11 Remote Access – forensisch prüfen aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.3927272727272727,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "primary",
+      "source_quality_score": 0.88,
+      "title": "X11 Application Support - Wayland",
+      "url": "https://wayland.freedesktop.org/docs/book/Xwayland.html"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Home\n\nProducts\n\nRed Hat Enterprise Linux\n\nGetting started with the GNOME desktop environment\n\nChapter 14. Remotely accessing a Wayland-based application\n\nFormat Multi-page Single-page View full doc as PDF\n\nChapter 14. Remotely accessing a Wayland-based application\n\nYou can remotely launch a graphical Wayland-based application on a RHEL server and use it from the remote client on Wayland using waypipe .\n\nNote\n\nThe desktop applications shipped with RHEL 9 support both the Wayland and X11 display protocols. However, Wayland is the preferred option when both are available.\n\n14.1. Enabling waypipe on the client and server\nCopy link Link copied to clipboard!\n\nTo be able to launch an individual application on Wayland, you need to install the waypipe package.\n\nPrerequisites\n\nBoth the client and server use the RHEL 9 operating system.\n\nProcedure\n\nInstall the waypipe package on the local system.\n\n…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Wayland/X11 Remote Access – forensisch prüfen aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.3927272727272727,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "primary",
+      "source_quality_score": 0.88,
+      "title": "Chapter 14. Remotely accessing a Wayland-based application | Getting started with the GNOME desktop environment | Red Hat Enterprise Linux | 9 | Red Hat Documentation",
+      "url": "https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/getting_started_with_the_gnome_desktop_environment/remotely-accessing-an-individual-application-wayland_getting-started-with-the-gnome-desktop-environment"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Events for tag \"2019\"\n\n6 min\n\nNeopardy-Engine\n\n6 min\n\n2019-10-06\n\n35\n\nMoritz and\nHendrik\n\nJugend hackt 2019\n\n26 min\n\nCyclOSM, a bicycle oriented render for every cyclist\n\nCartography\nStateoftheMap\n\n26 min\n\n2019-09-21\n\n356\n\nFlorimond Berthoux and\nLucas Verney\n\nState of the Map 2019\n\n59 min\n\nDigitale Agenda Wien - Möglichkeitsräume einer Stadt\n\n59 min\n\n2019-10-23\n\n72\n\nUlrike Huemer\n\nPrivacyWeek 2019\n\n58 min\n\nWas ist Zeit?\n\nScience\nOpenInfrastructureOrbit\n\n58 min\n\n2019-12-28\n\n27.2k\n\nSteini\n\n36C3: Resource Exhaustion\n\n44 min\n\nWhy Nobody cares, and only You can save the World\n\nTechnology, Intuitions \u0026 Moral Expertise\n\nEthics, Society \u0026 Politics\n\n44 min\n\n2019-08-25\n\n291\n\nWilhelm Klein\n\nChaos Communication Camp 2019\n\n90 min\n\nProperty-based Testing [Softwerkskammer]\n\naugenpruefraumswkhl\n\n90 min\n\n2019-03-17\n\n79\n\nDaniel Bimschas\n\nChaotikum\n\n13 min\n\nClosing Ceremony\n\nCCC\nMain\n\n13 min\n\n2019-12-30\n\n2…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Wayland/X11 Remote Access – forensisch prüfen aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.48363636363636364,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "2019\n\n- media.ccc.de",
+      "url": "https://media.ccc.de/tags/2019"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Wayland is now the default across most modern Linux desktops, and that quietly breaks a lot of X11-era support playbooks. If your helpdesk still relies on “global screen grabbers” or legacy VNC expectations, you’ll hit confusing prompts, black screens, and missing input.\n\nThis guide gives you a pragmatic, distro-agnostic playbook for remote support on Wayland using GNOME/KDE’s built-ins, the PipeWire + xdg-desktop-portal stack, and a few production-ready SOPs.\n\nTL;DR\n\nOn Wayland, screen capture/control is mediated by the compositor via PipeWire and xdg-desktop-portal, not legacy X11 hooks. Expect user-visible permission prompts and per-app scoping.\n\nGNOME Remote Desktop speaks RDP (and VNC) and can do user-present “share my screen” and remote-login/headless modes with GDM integration.\n\nKDE Plasma exposes Wayland sessions over RDP through KRdp ; configuration lives in Settings → Networkin…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Wayland/X11 Remote Access – forensisch prüfen current official documentation version support",
+      "relevance": 0.4533333333333333,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Remote Desktop on Wayland in 2025: What Changed for Linux Support Engineers | Stackademic",
+      "url": "https://stackademic.com/blog/remote-desktop-on-wayland-in-2025-what-changed-for-linux-support-engineers"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Tricks\n\nRemote Desktop on Wayland in 2026\n\n2026-02-25\n\nWayland is now the default across most modern Linux desktops, and that quietly breaks a lot of X11-era support playbooks. If your helpdesk still relies on “global screen grabbers” or legacy VNC expectations, you’ll hit confusing prompts, black screens, and missing input.\n\nThis guide gives you a pragmatic, distro-agnostic playbook for remote support on Wayland using GNOME/KDE’s built-ins, the PipeWire + xdg-desktop-portal stack, and a few production-ready SOPs.\n\nTL;DR\n\nOn Wayland, screen capture/control is mediated by the compositor via PipeWire and xdg-desktop-portal, not legacy X11 hooks. Expect user-visible permission prompts and per-app scoping.\n\nGNOME Remote Desktop speaks RDP (and VNC) and can do user-present “share my screen” and remote-login/headless modes with GDM integration.\n\nKDE Plasma exposes Wayland sessions over RDP thr…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Wayland/X11 Remote Access – forensisch prüfen current official documentation version support",
+      "relevance": 0.4533333333333333,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Remote Desktop on Wayland in 2026 – Page 2 – Paolo Redaelli personal blog",
+      "url": "https://monodes.com/predaelli/2026/02/25/remote-desktop-on-wayland-in-2026/2/"
+    }
+  ],
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 0,
+  "source_fingerprint": "145eba49d1c373f03bf0f9d9094710854fb9b9b3575896c3f432fcf066ddf125",
+  "source_node_ids": [
+    "007209fd1586eadd0b80951a",
+    "0086802a963fbd5e8a4d031d",
+    "067722c1a7edf5d75a960ba0",
+    "10c17d3542bb86405b2c1c39",
+    "14a02be72685169e757c9ed6",
+    "74b82044ebe7b2aa5da30f1f",
+    "b0df60844d54eba8c88b6fac",
+    "ee47afdfd96398a0b00ac3e6"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-00323",
+    "KB-SEC-HB-00324",
+    "KB-SEC-HB-00985",
+    "KB-SEC-HB-00987",
+    "KB-SEC-HB-01006",
+    "KB-SEC-HB-01007",
+    "KB-SEC-HB-01008",
+    "KB-SEC-HB-01011"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-00324",
+  "target_node_id": "ee47afdfd96398a0b00ac3e6"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-732146655158.json b/data/article-metadata/kb-ai-think-article-20260807-732146655158.json
new file mode 100644
index 0000000..2f1b282
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-732146655158.json
@@ -0,0 +1,306 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-732146655158",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-732146655158.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 0.95,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Cloud Storage Sicherheit sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall; Korrelation von Cloud-Audit, IAM, Netzwerkflüssen, Ressourcenkonfiguration, Tags, Workload-/Service-Identitäten und Datenzugriffen ist erforderlich.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Organisation-Guardrails, Least Privilege, MFA, Workload Identity, private Pfade, Logging, KMS/Secrets und Infrastructure as Code sind wichtige Härtungsmaßnahmen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Prioritäre Sicherung von Cloud-Audit-Logs, Flow Logs, IAM-/Policy-Änderungen, API-Aufrufe, Objektzugriffe, Snapshot-/Image-Metadaten und IaC/Deployment-Historie im Falle eines Vorfalls ist entscheidend.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Risikobasierte Betrachtung der Cloud Storage Sicherheit ist erforderlich.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten müssen dokumentiert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Sicherheitsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt verschlechtern.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Analyse der Cloud Audit Logs auf ungewöhnliche Aktivitäten.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Test der Konfigurationen durch Penetrationstests oder Sicherheitsüberprüfungen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Verifikation der Verschlüsselungseinstellungen für Daten im Ruhezustand.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Überprüfung der IAM-Richtlinien und Zugriffsberechtigungen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Aktivieren Sie Data Access Logs für detaillierte Überwachung von Objektzugriffen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Implementieren Sie Organisationsrichtlinien zur Durchsetzung von Sicherheitsstandards.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Überprüfen Sie die IAM-Richtlinien, um sicherzustellen, dass das Prinzip der geringsten Privilegien eingehalten wird.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      },
+      {
+        "claim": "Überprüfen Sie regelmäßig die Bucket-Konfigurationen auf potenzielle Schwachstellen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-02702",
+          "KB-SEC-HB-02740",
+          "KB-SEC-HB-02754"
+        ],
+        "reason": "Die Aussage ist direkt in mehreren internen Quellen belegt, die sich auf ähnliche Themen wie Cloud Incident Response und AWS ECR Security beziehen."
+      }
+    ]
+  },
+  "confidence": 0.95,
+  "generated_at": "2026-08-07T20:12:58.4707166Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "GCP Cloud Storage Security – härten und sicher betreiben",
+    "purpose": "Mehrere produktive Artikel zu GCP Cloud Storage Security überschneiden sich stark in Inhalt und Struktur. Sie behandeln ähnliche Themen wie Härtung, Detection, Forensik und Incident Response. Ein Zielartikel zur Sicherung von GCP Cloud Storage kann aus diesen Quellen konsolidiert werden, um eine einheitliche, umfassende Lösung zu bieten.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": null,
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "GCP Cloud Storage Security – härten und sicher betreiben",
+    "missing_information": [],
+    "reason": "Mehrere produktive Artikel zu GCP Cloud Storage Security überschneiden sich stark in Inhalt und Struktur. Sie behandeln ähnliche Themen wie Härtung, Detection, Forensik und Incident Response. Ein Zielartikel zur Sicherung von GCP Cloud Storage kann aus diesen Quellen konsolidiert werden, um eine einheitliche, umfassende Lösung zu bieten."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 8,
+  "research_material": [
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.\n\nHome\n\nDocumentation\n\nStorage\n\nCloud Storage\n\nCloud Storage-Dokumentation\n\nProduktdokumentation lesen\n\nMit Cloud Storage können Sie jederzeit beliebige Datenmengen weltweit speichern und abrufen. Sie können Cloud Storage für eine Reihe von Aufgaben verwenden, beispielsweise um leistungsstarke KI-/ML- und Analysedatensätze bereitzustellen, Daten für die Archivierung und Notfallwiederherstellung zu speichern oder Inhalte weltweit an Nutzer zu verteilen.\n\nSie sind sich nicht sicher, welches Speicherprodukt das richtige für Sie ist? Weitere Informationen zu Speicherdiensten\n\nWeitere Informationen finden Sie auf der Produktseite zu Cloud Storage.\n\nJetzt kostenlos starten\n\nProof of Concept mit einem Guthaben in Höhe von 300 $ starten\n\nNutzen Sie unsere neuesten genera…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "GCP Cloud Storage Security – härten und sicher betreiben aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "primary",
+      "source_quality_score": 0.88,
+      "title": "Cloud Storage-Dokumentation  |  Google Cloud Documentation",
+      "url": "https://docs.cloud.google.com/storage/docs?hl=de"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.\n\nHome\n\nDocumentation\n\nSecurity\n\nJetzt kostenlos starten\n\nProof of Concept mit einem Guthaben in Höhe von 300 $ starten\n\nNutzen Sie unsere neuesten generativen KI-Modelle und Tools für die Entwicklung.\n\nSie können mehr als 20 beliebte Produkte wie Compute Engine und KIAI APIs kostenlos nutzen.\n\nKeine automatischen Abbuchungen, keine Verpflichtung.\n\nAngebote für kostenlose Produkte ansehen\n\nMehr als 20 Produkte immer kostenlos nutzen.\n\nSie haben Zugriff auf mehr als 20 kostenlose Produkte für gängige Anwendungsfälle, darunter KI-APIs, VMs, Data Warehouses und mehr.\n\ndescription\n\nGoogle Cloud Übersicht über die Sicherheit\n\nHier erfahren Sie mehr über die physischen, administrativen und technischen Kontrollen, die wir zum Schutz der Daten Ihrer Organisation verwende…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "GCP Cloud Storage Security – härten und sicher betreiben aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "primary",
+      "source_quality_score": 0.88,
+      "title": "Sicherheit  |  Security  |  Google Cloud Documentation",
+      "url": "https://docs.cloud.google.com/docs/security?hl=de"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Cloud Storage Security: Secure GCP Buckets with IAM, Encryption, and Best Practices\n\nCloud Storage buckets hold some of the most sensitive data in a GCP\nenvironment: database backups, user uploads, compliance records, build\nartefacts, and internal reports. A new bucket is private and encrypted by\ndefault, but that is the starting point, not the destination. Securing a\nbucket properly means configuring access control, preventing accidental public\nexposure, choosing the right encryption model, and setting up logging. This\npage explains how all of those controls fit together.\n\nWhat Cloud Storage security actually means\n\nA bucket is not secure just because it exists. When you create a new\nCloud Storage bucket ,\nit starts out private and encrypted. Those two facts give many beginners\nthe impression that the job is done. It is not.\n\nThe storage unit analogy\n\nThink of a bucket like a self-stora…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "GCP Cloud Storage Security – härten und sicher betreiben current official documentation version support",
+      "relevance": 0.52,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "primary",
+      "source_quality_score": 0.88,
+      "title": "Cloud Storage Security: Secure GCP Buckets with IAM, Encryption, and Best Practices | CloudWebSchool",
+      "url": "https://cloudwebschool.com/docs/gcp/storage-services/cloud-storage-security/"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Choose a service...\nCreate Project\n\nChoose a service...\n\nBack to sections\nGoogle Cloud Storage :\n\nGoogle Cloud Storage Security Best Practices\n\n15 best practices\n\nAdhere to AWS best practices by enforcing security controls, using least privilege principles, and implementing defense in depth. Regularly audit configurations and use AWS tools to identify and address potential security vulnerabilities.\n\nFilter:\n\nAll Saved Unsaved\n\nGrid\nList Expanded Compact\n\nImplement Uniform Bucket-Level Access (UBLA)\n\nEnable uniform bucket-level access to enforce consistent IAM policies across all objects in a bucket, disabling legacy ACLs. This simplifies permission management and reduces security risks from mixed access control models. UBLA ensures that only IAM policies control access, making auditing and compliance significantly easier.\n\nJS PY TF\n\nEnable Default Encryption with Customer-Managed Keys (C…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "GCP Cloud Storage Security – härten und sicher betreiben current official documentation version support",
+      "relevance": 0.42,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Google Cloud Storage Security Best Practices | Google Cloud Storage | SystemsArchitect | SystemsArchitect.io",
+      "url": "https://www.systemsarchitect.io/services/gcp-storage/security-best-practices"
+    }
+  ],
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 0,
+  "source_fingerprint": "732146655158326649b4c151ff06b85f3f68bee787eb3ec6df5d6dd732b73dd3",
+  "source_node_ids": [
+    "0704c5d9a237272736cb7b2a",
+    "08342d81ba19c1ee068fce4a",
+    "36b20db6c3efb5f1bacfa992",
+    "7df0ab1157f6df13bb6a9079",
+    "928d94624d470e317b87c689",
+    "985c5622a6c6e4218882c27d",
+    "9ac9fffc91fb400d775eb85d",
+    "f1f2d97eaf43e4baa8438730"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-02603",
+    "KB-SEC-HB-02658",
+    "KB-SEC-HB-02702",
+    "KB-SEC-HB-02703",
+    "KB-SEC-HB-02740",
+    "KB-SEC-HB-02741",
+    "KB-SEC-HB-02754",
+    "KB-SEC-HB-02755"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-02754",
+  "target_node_id": "0704c5d9a237272736cb7b2a"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-793683d419e8.json b/data/article-metadata/kb-ai-think-article-20260807-793683d419e8.json
new file mode 100644
index 0000000..131fc5d
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-793683d419e8.json
@@ -0,0 +1,167 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-793683D419E8",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-793683d419e8.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 1,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Baseline-Verhalten der Datenbank muss dokumentiert werden, um Abweichungen zu erkennen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03046"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03046 betont explizit die Dokumentation des Baseline-Verhaltens und die Korrelation mit Kontextdaten."
+      },
+      {
+        "claim": "Einzelne Indikatoren reichen nicht aus, um einen Vorfall zu bestätigen; Korrelation mit Asset-, Identitäts- und Change-Kontext ist notwendig.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03046",
+          "KB-SEC-HB-03094",
+          "KB-SEC-HB-03095"
+        ],
+        "reason": "Dies wird in mehreren Quellen (KB-SEC-HB-03046, KB-SEC-HB-03094, KB-SEC-HB-03095) explizit betont."
+      },
+      {
+        "claim": "Risikobasierte Betrachtung von Datenbank-DoS-Schutz und Incident Response ist erforderlich.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03046",
+          "KB-SEC-HB-03094",
+          "KB-SEC-HB-03095"
+        ],
+        "reason": "Dies wird in mehreren Quellen als zentraler Aspekt hervorgehoben."
+      },
+      {
+        "claim": "Sicherheitsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt beeinträchtigen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03046",
+          "KB-SEC-HB-03094",
+          "KB-SEC-HB-03095"
+        ],
+        "reason": "Dies wird in mehreren Quellen als zentrales Kriterium genannt."
+      },
+      {
+        "claim": "Umfassende Dokumentation des Scopes, betroffener Assets/Identitäten, Datenkritikalität, Exposition und betrieblicher Abhängigkeiten ist essentiell.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03046",
+          "KB-SEC-HB-03094",
+          "KB-SEC-HB-03095"
+        ],
+        "reason": "Dies wird in mehreren Quellen als zentraler Schritt genannt."
+      },
+      {
+        "claim": "Bei bestätigter Kompromittierung Scope auf angrenzende Systeme/Identitäten erweitern.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03046",
+          "KB-SEC-HB-03094",
+          "KB-SEC-HB-03095"
+        ],
+        "reason": "Dies wird in mehreren Quellen als zentraler Schritt im Incident Response genannt."
+      },
+      {
+        "claim": "Credentials/Keys gezielt rotieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03046",
+          "KB-SEC-HB-03094",
+          "KB-SEC-HB-03095"
+        ],
+        "reason": "Dies wird in mehreren Quellen als zentraler Schritt im Incident Response genannt."
+      },
+      {
+        "claim": "Erhöhtes Monitoring einplanen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03046",
+          "KB-SEC-HB-03094",
+          "KB-SEC-HB-03095"
+        ],
+        "reason": "Dies wird in mehreren Quellen als zentraler Schritt im Incident Response genannt."
+      },
+      {
+        "claim": "Nach Änderungen Funktion, Security-Kontrolle und Telemetrie separat testen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03046",
+          "KB-SEC-HB-03094",
+          "KB-SEC-HB-03095"
+        ],
+        "reason": "Dies wird in mehreren Quellen als zentraler Schritt im Incident Response genannt."
+      },
+      {
+        "claim": "Ursache beseitigen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03046",
+          "KB-SEC-HB-03094",
+          "KB-SEC-HB-03095"
+        ],
+        "reason": "Dies wird in mehreren Quellen als zentraler Schritt im Incident Response genannt."
+      }
+    ]
+  },
+  "confidence": 1,
+  "generated_at": "2026-08-07T20:18:38.5581641Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "eine umfassende, strukturierte Anleitung zur Sicherung von Datenbanken vor DoS-Angriffen, mit Fokus auf Härtung, Detection und Incident Response",
+    "purpose": "Die Quellen 908f957a8654c3352c32ca83 und 33df40dd4b8dc9ad418d8754 sowie 966a0aeea46a117a849aa28a behandeln das Thema 'Database DoS Schutz' und 'Database Incident Response' mit ähnlichen Schwerpunkten. Beide Artikel decken die gleichen Aspekte ab: defensive Prüfung, Härtung, Forensik und Incident Response. Sie können als Staging-Entwurf in einen gemeinsamen Artikel zur 'Database DoS Schutz und Incident Response' konsolidiert werden, um eine umfassendere, strukturierte Anleitung zu bieten.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": null,
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "eine umfassende, strukturierte Anleitung zur Sicherung von Datenbanken vor DoS-Angriffen, mit Fokus auf Härtung, Detection und Incident Response",
+    "missing_information": [],
+    "reason": "Die Quellen 908f957a8654c3352c32ca83 und 33df40dd4b8dc9ad418d8754 sowie 966a0aeea46a117a849aa28a behandeln das Thema 'Database DoS Schutz' und 'Database Incident Response' mit ähnlichen Schwerpunkten. Beide Artikel decken die gleichen Aspekte ab: defensive Prüfung, Härtung, Forensik und Incident Response. Sie können als Staging-Entwurf in einen gemeinsamen Artikel zur 'Database DoS Schutz und Incident Response' konsolidiert werden, um eine umfassendere, strukturierte Anleitung zu bieten."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 3,
+  "research_material": null,
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 0,
+  "source_fingerprint": "793683d419e80959ee2dc0a5c971893267ae9e28278ea3ff0f5aa82ec1daf7d4",
+  "source_node_ids": [
+    "33df40dd4b8dc9ad418d8754",
+    "908f957a8654c3352c32ca83",
+    "966a0aeea46a117a849aa28a"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-03046",
+    "KB-SEC-HB-03094",
+    "KB-SEC-HB-03095"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-03046",
+  "target_node_id": "908f957a8654c3352c32ca83"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-8508e35d3ae5.json b/data/article-metadata/kb-ai-think-article-20260807-8508e35d3ae5.json
new file mode 100644
index 0000000..d37dc3d
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-8508e35d3ae5.json
@@ -0,0 +1,165 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-8508E35D3AE5",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-8508e35d3ae5.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 1,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Baseline und erwartetes Normalverhalten für WORM Storage müssen dokumentiert werden; Abweichungen sind immer mit Asset-, Identitäts- und Change-Kontext zu korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "f97c060b53b2d1cb4f8fbc96"
+        ],
+        "reason": "Diese Aussage ist direkt in der internen Quelle KB-SEC-HB-03870 (WORM Storage – präventiv und resilient gestalten) enthalten."
+      },
+      {
+        "claim": "Der Schwerpunkt liegt auf präventiven und resilienten Maßnahmen.",
+        "verdict": "supported",
+        "source_refs": [
+          "f97c060b53b2d1cb4f8fbc96"
+        ],
+        "reason": "Diese Aussage ist direkt in der internen Quelle KB-SEC-HB-03870 enthalten."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
+        "verdict": "supported",
+        "source_refs": [
+          "f97c060b53b2d1cb4f8fbc96"
+        ],
+        "reason": "Diese Aussage ist direkt in der internen Quelle KB-SEC-HB-03870 enthalten."
+      },
+      {
+        "claim": "Frühe Vorläufer wie Credential-Missbrauch, laterale Bewegung, ungewöhnliche Dateioperationen, Backup-/Snapshot-Manipulation und Exfiltration sollten zusammen betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "f97c060b53b2d1cb4f8fbc96"
+        ],
+        "reason": "Diese Aussage ist direkt in der internen Quelle KB-SEC-HB-03870 enthalten."
+      },
+      {
+        "claim": "Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten sind zu dokumentieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "f97c060b53b2d1cb4f8fbc96"
+        ],
+        "reason": "Diese Aussage ist direkt in der internen Quelle KB-SEC-HB-03870 enthalten."
+      },
+      {
+        "claim": "Sicherheitsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt verschlechtern.",
+        "verdict": "supported",
+        "source_refs": [
+          "f97c060b53b2d1cb4f8fbc96"
+        ],
+        "reason": "Diese Aussage ist direkt in der internen Quelle KB-SEC-HB-03870 enthalten."
+      },
+      {
+        "claim": "WORM Storage sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "f97c060b53b2d1cb4f8fbc96"
+        ],
+        "reason": "Diese Aussage ist direkt in der internen Quelle KB-SEC-HB-03870 enthalten."
+      },
+      {
+        "claim": "Bei bestätigter Kompromittierung Scope auf angrenzende Systeme/Identitäten erweitern.",
+        "verdict": "supported",
+        "source_refs": [
+          "f97c060b53b2d1cb4f8fbc96"
+        ],
+        "reason": "Diese Aussage ist direkt in der internen Quelle KB-SEC-HB-03870 enthalten."
+      },
+      {
+        "claim": "Credentials/Keys gezielt rotieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "f97c060b53b2d1cb4f8fbc96"
+        ],
+        "reason": "Diese Aussage ist direkt in der internen Quelle KB-SEC-HB-03870 enthalten."
+      },
+      {
+        "claim": "Erhöhtes Monitoring einplanen.",
+        "verdict": "supported",
+        "source_refs": [
+          "f97c060b53b2d1cb4f8fbc96"
+        ],
+        "reason": "Diese Aussage ist direkt in der internen Quelle KB-SEC-HB-03870 enthalten."
+      },
+      {
+        "claim": "Nach Änderungen Funktion, Security-Kontrolle und Telemetrie separat testen.",
+        "verdict": "supported",
+        "source_refs": [
+          "f97c060b53b2d1cb4f8fbc96"
+        ],
+        "reason": "Diese Aussage ist direkt in der internen Quelle KB-SEC-HB-03870 enthalten."
+      },
+      {
+        "claim": "Ursache beseitigen.",
+        "verdict": "supported",
+        "source_refs": [
+          "f97c060b53b2d1cb4f8fbc96"
+        ],
+        "reason": "Diese Aussage ist direkt in der internen Quelle KB-SEC-HB-03870 enthalten."
+      }
+    ]
+  },
+  "confidence": 1,
+  "generated_at": "2026-08-07T20:17:00.3234009Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "WORM Storage – präventiv und resilient gestalten",
+    "purpose": "Die Quellen 0ad4b6ccd08deac0c7cfb3b4, f97c060b53b2d1cb4f8fbc96 und 0a03792ae724894bba657bbb enthalten identische Inhalte zu 'WORM Storage' mit ähnlichen Strukturen und Schwerpunkten. Sie können als Staging-Entwurf in den Zielartikel 'WORM Storage – präventiv und resilient gestalten' konsolidiert werden, um eine einheitliche, umfassende Lösung zu bieten.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": null,
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "WORM Storage – präventiv und resilient gestalten",
+    "missing_information": [],
+    "reason": "Die Quellen 0ad4b6ccd08deac0c7cfb3b4, f97c060b53b2d1cb4f8fbc96 und 0a03792ae724894bba657bbb enthalten identische Inhalte zu 'WORM Storage' mit ähnlichen Strukturen und Schwerpunkten. Sie können als Staging-Entwurf in den Zielartikel 'WORM Storage – präventiv und resilient gestalten' konsolidiert werden, um eine einheitliche, umfassende Lösung zu bieten."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 3,
+  "research_material": null,
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 0,
+  "source_fingerprint": "8508e35d3ae5f7f1f1a924d834788a9134250b6a8632e30febdb7867f410bdd0",
+  "source_node_ids": [
+    "0a03792ae724894bba657bbb",
+    "0ad4b6ccd08deac0c7cfb3b4",
+    "f97c060b53b2d1cb4f8fbc96"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-03830",
+    "KB-SEC-HB-03870",
+    "KB-SEC-HB-03871"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-03870",
+  "target_node_id": "f97c060b53b2d1cb4f8fbc96"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-99597deb0603.json b/data/article-metadata/kb-ai-think-article-20260807-99597deb0603.json
new file mode 100644
index 0000000..0d8cb5e
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-99597deb0603.json
@@ -0,0 +1,328 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-99597DEB0603",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-99597deb0603.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 1,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Clean Room Recovery sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "0180ce8fd088c35598e9d3c5",
+          "bb48d2a4463711e542979d53"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-03896 und KB-SEC-HB-03897 belegt."
+      },
+      {
+        "claim": "Die präventive Gestaltung und Reaktion im Vorfall sind wesentliche Aspekte von Clean Room Recovery.",
+        "verdict": "supported",
+        "source_refs": [
+          "0180ce8fd088c35598e9d3c5",
+          "bb48d2a4463711e542979d53"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-03896 und KB-SEC-HB-03897 belegt."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
+        "verdict": "supported",
+        "source_refs": [
+          "0180ce8fd088c35598e9d3c5",
+          "bb48d2a4463711e542979d53"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-03896 und KB-SEC-HB-03897 belegt."
+      },
+      {
+        "claim": "Frühe Erkennung durch Korrelation verschiedener Indikatoren ist entscheidend.",
+        "verdict": "supported",
+        "source_refs": [
+          "0180ce8fd088c35598e9d3c5",
+          "bb48d2a4463711e542979d53"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-03896 und KB-SEC-HB-03897 belegt."
+      },
+      {
+        "claim": "Für Clean Room Recovery Baseline und erwartetes Normalverhalten dokumentieren; Abweichungen immer mit Asset-, Identitäts- und Change-Kontext korrelieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "0180ce8fd088c35598e9d3c5",
+          "bb48d2a4463711e542979d53"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-03896 und KB-SEC-HB-03897 belegt."
+      },
+      {
+        "claim": "Härtungsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht beeinträchtigen.",
+        "verdict": "supported",
+        "source_refs": [
+          "0180ce8fd088c35598e9d3c5",
+          "bb48d2a4463711e542979d53"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-03896 und KB-SEC-HB-03897 belegt."
+      },
+      {
+        "claim": "Sichern Sie Beweismittel mit Zeitbezug, Herkunft und Integritätsnachweis.",
+        "verdict": "supported",
+        "source_refs": [
+          "0180ce8fd088c35598e9d3c5",
+          "bb48d2a4463711e542979d53"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-03896 und KB-SEC-HB-03897 belegt."
+      },
+      {
+        "claim": "Testen Sie Security-Kontrollen separat.",
+        "verdict": "supported",
+        "source_refs": [
+          "0180ce8fd088c35598e9d3c5",
+          "bb48d2a4463711e542979d53"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-03896 und KB-SEC-HB-03897 belegt."
+      },
+      {
+        "claim": "Verifizieren Sie die Funktionalität der Telemetrie.",
+        "verdict": "supported",
+        "source_refs": [
+          "0180ce8fd088c35598e9d3c5",
+          "bb48d2a4463711e542979d53"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-03896 und KB-SEC-HB-03897 belegt."
+      },
+      {
+        "claim": "Überprüfen Sie nach Änderungen die Funktion der betroffenen Systeme.",
+        "verdict": "supported",
+        "source_refs": [
+          "0180ce8fd088c35598e9d3c5",
+          "bb48d2a4463711e542979d53"
+        ],
+        "reason": "Die Aussage ist direkt in der internen Quelle KB-SEC-HB-03896 und KB-SEC-HB-03897 belegt."
+      }
+    ]
+  },
+  "confidence": 1,
+  "generated_at": "2026-08-07T21:23:14.2001593Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "Clean Room Recovery – präventiv und resilient gestalten, im Vorfall erkennen, eindämmen und wiederherstellen",
+    "purpose": "Die Quellen 0180ce8fd088c35598e9d3c5 und bb48d2a4463711e542979d53 behandeln beide das Thema 'Clean Room Recovery', wobei die erste sich auf die präventive Gestaltung konzentriert und die zweite auf die Reaktion im Vorfall. Da beide Artikel sich stark überschneiden und jeweils einen Teil des Themas abdecken, ist eine Konsolidierung sinnvoll, um einen umfassenderen, einheitlichen Artikel zu erstellen.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": [
+    "Welche konkreten Maßnahmen zur Korrelation von Indikatoren und zur Erkennung von Vorfällen sind in der Praxis umsetzbar?",
+    "Welche konkreten Schritte zur Sicherung von Beweismitteln mit Zeitbezug, Herkunft und Integritätsnachweis sind erforderlich?",
+    "Welche konkreten Schritte zur Wiederherstellung von Systemen im Rahmen einer Clean Room Recovery sind erforderlich?",
+    "Welche spezifischen Schritte sind zur Dokumentation von Scope, betroffenen Assets/Identitäten, Datenkritikalität, Exposition und betrieblichen Abhängigkeiten erforderlich?"
+  ],
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "Clean Room Recovery – präventiv und resilient gestalten, im Vorfall erkennen, eindämmen und wiederherstellen",
+    "missing_information": [],
+    "reason": "Die Quellen 0180ce8fd088c35598e9d3c5 und bb48d2a4463711e542979d53 behandeln beide das Thema 'Clean Room Recovery', wobei die erste sich auf die präventive Gestaltung konzentriert und die zweite auf die Reaktion im Vorfall. Da beide Artikel sich stark überschneiden und jeweils einen Teil des Themas abdecken, ist eine Konsolidierung sinnvoll, um einen umfassenderen, einheitlichen Artikel zu erstellen."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 8,
+  "research_material": [
+    {
+      "actionable": false,
+      "assessment_reason": "Vorab durch Source-Agent gesammelt und vom Brain als thematisch passend zur Knowledgebase klassifiziert.",
+      "content_type": "text/html",
+      "covered_gap_ids": null,
+      "excerpt": "Aufgrund einer Sicherheitslücke können Angreifer die IT-Sicherheitslösung Security Management von Check Point attackieren. Hotfixes stehen zum Download.",
+      "fetched": true,
+      "language": "",
+      "query": "Clean Room Recovery – präventiv und resilient gestalten, im Vorfall erkennen, eindämmen und wiederherstellen aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.394420055973156,
+      "relevant": true,
+      "round": 0,
+      "source_quality": "source_inbox",
+      "source_quality_score": 0.68,
+      "title": "Check Point: Angreifer können Security-Management-Server übernehmen",
+      "url": "https://www.heise.de/news/Check-Point-Angreifer-koennen-Security-Management-Server-uebernehmen-11398187.html"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Vorab durch Source-Agent gesammelt und vom Brain als thematisch passend zur Knowledgebase klassifiziert.",
+      "content_type": "text/html",
+      "covered_gap_ids": null,
+      "excerpt": "Die Backupmanagementlösungen Veeam One und Service Provider Console sind für verschiedene Attacken empfänglich. Sicherheitsupdates schaffen Abhilfe.",
+      "fetched": true,
+      "language": "",
+      "query": "Clean Room Recovery – präventiv und resilient gestalten, im Vorfall erkennen, eindämmen und wiederherstellen aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.367241390257812,
+      "relevant": true,
+      "round": 0,
+      "source_quality": "source_inbox",
+      "source_quality_score": 0.68,
+      "title": "Veeam One und Service Provider Console für Schadcode-Attacken anfällig",
+      "url": "https://www.heise.de/news/Veam-One-und-Service-Provider-Console-fuer-Schadcode-Attacken-anfaellig-11400855.html"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Vorab durch Source-Agent gesammelt und vom Brain als thematisch passend zur Knowledgebase klassifiziert.",
+      "content_type": "text/html",
+      "covered_gap_ids": null,
+      "excerpt": "Nur wenige Stunden nach Bekanntwerden einer Sicherheitslücke informiert der Framework seine Kunden. Metabase veröffentlichte eigene Sicherheitshinweise.",
+      "fetched": true,
+      "language": "",
+      "query": "Clean Room Recovery – präventiv und resilient gestalten, im Vorfall erkennen, eindämmen und wiederherstellen aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.3331568177408503,
+      "relevant": true,
+      "round": 0,
+      "source_quality": "source_inbox",
+      "source_quality_score": 0.68,
+      "title": "Durch Metabase-0day: Datenleck bei Laptophersteller Framework",
+      "url": "https://www.heise.de/news/Durch-Metabase-0day-Datenleck-bei-Laptophersteller-Framework-11403050.html"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Vorab durch Source-Agent gesammelt und vom Brain als thematisch passend zur Knowledgebase klassifiziert.",
+      "content_type": "text/html",
+      "covered_gap_ids": null,
+      "excerpt": "Angreifer können Adobe Bridge und Campaign Classic attackieren. Dagegen abgesicherte Versionen stehen zum Download.",
+      "fetched": true,
+      "language": "",
+      "query": "Clean Room Recovery – präventiv und resilient gestalten, im Vorfall erkennen, eindämmen und wiederherstellen current official documentation version support",
+      "relevance": 0.36418011098949726,
+      "relevant": true,
+      "round": 0,
+      "source_quality": "source_inbox",
+      "source_quality_score": 0.68,
+      "title": "Kritische Schadcode-Sicherheitslücke bedroht Adobe Campaign Classic",
+      "url": "https://www.heise.de/news/Kritische-Schadcode-Sicherheitsluecke-bedroht-Adobe-Campaign-Classic-11394802.html"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Vorab durch Source-Agent gesammelt und vom Brain als thematisch passend zur Knowledgebase klassifiziert.",
+      "content_type": "text/html",
+      "covered_gap_ids": null,
+      "excerpt": "Die n8n-Entwickler haben in aktuellen Versionen insgesamt 18 Sicherheitslücken geschlossen.",
+      "fetched": true,
+      "language": "",
+      "query": "Clean Room Recovery – präventiv und resilient gestalten, im Vorfall erkennen, eindämmen und wiederherstellen current official documentation version support",
+      "relevance": 0.3554961691295091,
+      "relevant": true,
+      "round": 0,
+      "source_quality": "source_inbox",
+      "source_quality_score": 0.68,
+      "title": "Sicherheitspatches: Angreifer können Schadcode auf n8n-Servern ausführen",
+      "url": "https://www.heise.de/news/Sicherheitspatches-Angreifer-koennen-Schadcode-auf-n8n-Servern-ausfuehren-11400494.html"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Vorab durch Source-Agent gesammelt und vom Brain als thematisch passend zur Knowledgebase klassifiziert.",
+      "content_type": "text/html",
+      "covered_gap_ids": null,
+      "excerpt": "VMware-Updates für ESX, vCenter, Workstation und Fusion schließen Sicherheitslücken, die etwa die Umgehung der Authentifizierung erlauben.",
+      "fetched": true,
+      "language": "",
+      "query": "Welche konkreten Maßnahmen zur Korrelation von Indikatoren und zur Erkennung von Vorfällen sind in der Praxis umsetzbar?",
+      "relevance": 0.3676050698616824,
+      "relevant": true,
+      "round": 0,
+      "source_quality": "source_inbox",
+      "source_quality_score": 0.68,
+      "title": "VMware ESX, vCenter, Workstation und Fusion: Updates schließen kritische Lücken",
+      "url": "https://www.heise.de/news/VMware-ESX-vCenter-Workstation-und-Fusion-Updates-schliessen-kritische-Luecken-11386401.html"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Vorab durch Source-Agent gesammelt und vom Brain als thematisch passend zur Knowledgebase klassifiziert.",
+      "content_type": "text/html",
+      "covered_gap_ids": null,
+      "excerpt": "Mehrere Sicherheitslücken bedrohen IBM WebSphere Application Server und WebSphere Application Server Liberty.",
+      "fetched": true,
+      "language": "",
+      "query": "Welche konkreten Maßnahmen zur Korrelation von Indikatoren und zur Erkennung von Vorfällen sind in der Praxis umsetzbar?",
+      "relevance": 0.3466700029384926,
+      "relevant": true,
+      "round": 0,
+      "source_quality": "source_inbox",
+      "source_quality_score": 0.68,
+      "title": "IBM WebSphere Application Server: Sicherheitsproblem in Admin-Konsole gelöst",
+      "url": "https://www.heise.de/news/IBM-WebSphere-Application-Server-Sicherheitsproblem-in-Admin-Konsole-geloest-11386356.html"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Vorab durch Source-Agent gesammelt und vom Brain als thematisch passend zur Knowledgebase klassifiziert.",
+      "content_type": "text/html",
+      "covered_gap_ids": null,
+      "excerpt": "Über kompromittierte Bilder können Angreifer Umgebungsvariablen des Servers einschließlich der Secrets auslesen und sich damit weitere Türen ins System öffnen.",
+      "fetched": true,
+      "language": "",
+      "query": "Welche konkreten Schritte zur Sicherung von Beweismitteln mit Zeitbezug, Herkunft und Integritätsnachweis sind erforderlich?",
+      "relevance": 0.37238748706263636,
+      "relevant": true,
+      "round": 0,
+      "source_quality": "source_inbox",
+      "source_quality_score": 0.68,
+      "title": "Schlüsselklau bei Ruby on Rails – Kritische Lücke mit präparierten Bildern",
+      "url": "https://www.heise.de/news/Schluesselklau-bei-Ruby-on-Rails-Kritische-Luecke-mit-praeparierten-Bildern-11394386.html"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Vorab durch Source-Agent gesammelt und vom Brain als thematisch passend zur Knowledgebase klassifiziert.",
+      "content_type": "text/html",
+      "covered_gap_ids": null,
+      "excerpt": "Derzeit schieben Angreifer Schadcode auf IBM-Langflow-Instanzen. Im Cluster-Betrieb von Apache Tomcat können sie Datenverkehr mitlesen.",
+      "fetched": true,
+      "language": "",
+      "query": "Welche konkreten Schritte zur Sicherung von Beweismitteln mit Zeitbezug, Herkunft und Integritätsnachweis sind erforderlich?",
+      "relevance": 0.36664474042713663,
+      "relevant": true,
+      "round": 0,
+      "source_quality": "source_inbox",
+      "source_quality_score": 0.68,
+      "title": "Angreifer attackieren IBM Langflow und Apache-Tomcat-Server",
+      "url": "https://www.heise.de/news/Angreifer-attackieren-IBM-Langflow-und-Apache-Tomcat-Server-11403178.html"
+    }
+  ],
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 1,
+  "source_fingerprint": "99597deb060340eaabb23e80110ce1ec50ac664ff6df90a75988398605faf9c7",
+  "source_node_ids": [
+    "00315c6b1368d593d90f6ba9",
+    "0180ce8fd088c35598e9d3c5",
+    "0de4dd40810c015dcc8545cc",
+    "20b0f7363336076d29971128",
+    "4e619b8c2b06e4ef9d0a0bc9",
+    "550fa230cb16b3695c1efa19",
+    "6e6a2635613bc6be25210cd4",
+    "bb48d2a4463711e542979d53"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-03726",
+    "KB-SEC-HB-03727",
+    "KB-SEC-HB-03824",
+    "KB-SEC-HB-03826",
+    "KB-SEC-HB-03827",
+    "KB-SEC-HB-03896",
+    "KB-SEC-HB-03897",
+    "KB-SEC-HB-03904"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-03896",
+  "target_node_id": "0180ce8fd088c35598e9d3c5"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-a10d74b11b65.json b/data/article-metadata/kb-ai-think-article-20260807-a10d74b11b65.json
new file mode 100644
index 0000000..4489623
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-a10d74b11b65.json
@@ -0,0 +1,530 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-A10D74B11B65",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-a10d74b11b65.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 1,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Prototype Pollution ist eine JavaScript-Schwachstelle, die es Angreifern ermöglicht, beliebige Eigenschaften zu globalen Objektprototypen hinzuzufügen. Dies kann zu unvorhergesehenen Logikfehlern oder weiteren Angriffen führen.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e",
+          "0e2442d082bc502a7cd1cf13",
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 und KB-SEC-HB-00932 belegbar, die die Schwachstelle beschreiben und ihre Auswirkungen erläutern."
+      },
+      {
+        "claim": "Angriffe können zu Datenmanipulation, Privilege Escalation und Remote Code Execution führen.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die potenziellen Auswirkungen von Angriffen beschreibt."
+      },
+      {
+        "claim": "Die Schwachstelle entsteht oft durch unkontrollierte Merge-Operationen von Benutzereingaben in Objekte.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die Ursachen der Schwachstelle erläutert."
+      },
+      {
+        "claim": "Prototype Pollution ermöglicht das Hinzufügen oder Modifizieren von Eigenschaften an Objekten im JavaScript-Code.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die Funktionsweise der Schwachstelle beschreibt."
+      },
+      {
+        "claim": "Präventive Maßnahmen umfassen sichere Container (Object.create(null), Map) und idempotente Merge-Funktionen.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die präventiven Maßnahmen erläutert."
+      },
+      {
+        "claim": "Überwachung beinhaltet die Korrelation von Requests, Response-Codes und Logs sowie die Dokumentation von Baselines.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die Überwachungsmaßnahmen erläutert."
+      },
+      {
+        "claim": "Baseline-Dokumentation: Erwartetes Normalverhalten muss für die Erkennung von Anomalien festgehalten werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die Baseline-Dokumentation erläutert."
+      },
+      {
+        "claim": "Risikobasierte Betrachtung: Die Schutzmaßnahmen sollten dem Schweregrad der potenziellen Auswirkungen und der Wahrscheinlichkeit des Auftretens angepasst werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die risikobasierte Betrachtung erläutert."
+      },
+      {
+        "claim": "Scope-Definition: Betroffene Assets, Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten müssen dokumentiert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die Scope-Definition erläutert."
+      },
+      {
+        "claim": "Regelmäßige Überprüfung der Baseline und Anpassung bei Bedarf.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die Baseline-Überprüfung erläutert."
+      },
+      {
+        "claim": "Testen des Systems nach Änderungen zur Sicherstellung der Funktionalität und Sicherheit.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die Testung nach Änderungen erläutert."
+      },
+      {
+        "claim": "Überprüfung der implementierten Schutzmaßnahmen auf Wirksamkeit.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die Wirksamkeitsprüfung erläutert."
+      },
+      {
+        "claim": "Bei Abweichungen von der Baseline: Korrelation mit Asset-, Identitäts- und Change-Kontext prüfen.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die Korrelation bei Abweichungen erläutert."
+      },
+      {
+        "claim": "Nach Änderungen: Funktion, Security-Kontrolle und Telemetrie separat testen.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die Testung nach Änderungen erläutert."
+      },
+      {
+        "claim": "Bei bestätigter Kompromittierung Scope auf angrenzende Systeme/Identitäten erweitern, Ursache beseitigen, Credentials/Keys nur gezielt rotieren und anschließend erhöhtes Monitoring einplanen.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00931 belegbar, die die Reaktion bei Kompromittierung erläutert."
+      },
+      {
+        "claim": "Angriffe können zu Datenmanipulation, Privilege Escalation und Remote Code Execution führen.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die potenziellen Auswirkungen von Angriffen beschreibt."
+      },
+      {
+        "claim": "Die Schwachstelle entsteht oft durch unkontrollierte Merge-Operationen von Benutzereingaben in Objekte.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die Ursachen der Schwachstelle erläutert."
+      },
+      {
+        "claim": "Prototype Pollution ermöglicht das Hinzufügen oder Modifizieren von Eigenschaften an Objekten im JavaScript-Code.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb9ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die Funktionsweise der Schwachstelle beschreibt."
+      },
+      {
+        "claim": "Präventive Maßnahmen umfassen sichere Container (Object.create(null), Map) und idempotente Merge-Funktionen.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die präventiven Maßnahmen erläutert."
+      },
+      {
+        "claim": "Überwachung beinhaltet die Korrelation von Requests, Response-Codes und Logs sowie die Dokumentation von Baselines.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die Überwachungsmaßnahmen erläutert."
+      },
+      {
+        "claim": "Baseline-Dokumentation: Erwartetes Normalverhalten muss für die Erkennung von Anomalien festgehalten werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die Baseline-Dokumentation erläutert."
+      },
+      {
+        "claim": "Risikobasierte Betrachtung: Die Schutzmaßnahmen sollten dem Schweregrad der potenziellen Auswirkungen und der Wahrscheinlichkeit des Auftretens angepasst werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die risikobasierte Betrachtung erläutert."
+      },
+      {
+        "claim": "Scope-Definition: Betroffene Assets, Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten müssen dokumentiert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die Scope-Definition erläutert."
+      },
+      {
+        "claim": "Regelmäßige Überprüfung der Baseline und Anpassung bei Bedarf.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die Baseline-Überprüfung erläutert."
+      },
+      {
+        "claim": "Testen des Systems nach Änderungen zur Sicherstellung der Funktionalität und Sicherheit.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die Testung nach Änderungen erläutert."
+      },
+      {
+        "claim": "Überprüfung der implementierten Schutzmaßnahmen auf Wirksamkeit.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die Wirksamkeitsprüfung erläutert."
+      },
+      {
+        "claim": "Bei Abweichungen von der Baseline: Korrelation mit Asset-, Identitäts- und Change-Kontext prüfen.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die Korrelation bei Abweichungen erläutert."
+      },
+      {
+        "claim": "Nach Änderungen: Funktion, Security-Kontrolle und Telemetrie separat testen.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die Testung nach Änderungen erläutert."
+      },
+      {
+        "claim": "Bei bestätigter Kompromittierung Scope auf angrenzende Systeme/Identitäten erweitern, Ursache beseitigen, Credentials/Keys nur gezielt rotieren und anschließend erhöhtes Monitoring einplanen.",
+        "verdict": "supported",
+        "source_refs": [
+          "0700c83c80a45cb8ee9b735e"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00932 belegbar, die die Reaktion bei Kompromittierung erläutert."
+      },
+      {
+        "claim": "Angriffe können zu Datenmanipulation, Privilege Escalation und Remote Code Execution führen.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die potenziellen Auswirkungen von Angriffen beschreibt."
+      },
+      {
+        "claim": "Die Schwachstelle entsteht oft durch unkontrollierte Merge-Operationen von Benutzereingaben in Objekte.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die Ursachen der Schwachstelle erläutert."
+      },
+      {
+        "claim": "Prototype Pollution ermöglicht das Hinzufügen oder Modifizieren von Eigenschaften an Objekten im JavaScript-Code.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die Funktionsweise der Schwachstelle beschreibt."
+      },
+      {
+        "claim": "Präventive Maßnahmen umfassen sichere Container (Object.create(null), Map) und idempotente Merge-Funktionen.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die präventiven Maßnahmen erläutert."
+      },
+      {
+        "claim": "Überwachung beinhaltet die Korrelation von Requests, Response-Codes und Logs sowie die Dokumentation von Baselines.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die Überwachungsmaßnahmen erläutert."
+      },
+      {
+        "claim": "Baseline-Dokumentation: Erwartetes Normalverhalten muss für die Erkennung von Anomalien festgehalten werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die Baseline-Dokumentation erläutert."
+      },
+      {
+        "claim": "Risikobasierte Betrachtung: Die Schutzmaßnahmen sollten dem Schweregrad der potenziellen Auswirkungen und der Wahrscheinlichkeit des Auftretens angepasst werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die risikobasierte Betrachtung erläutert."
+      },
+      {
+        "claim": "Scope-Definition: Betroffene Assets, Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten müssen dokumentiert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die Scope-Definition erläutert."
+      },
+      {
+        "claim": "Regelmäßige Überprüfung der Baseline und Anpassung bei Bedarf.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die Baseline-Überprüfung erläutert."
+      },
+      {
+        "claim": "Testen des Systems nach Änderungen zur Sicherstellung der Funktionalität und Sicherheit.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die Testung nach Änderungen erläutert."
+      },
+      {
+        "claim": "Überprüfung der implementierten Schutzmaßnahmen auf Wirksamkeit.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die Wirksamkeitsprüfung erläutert."
+      },
+      {
+        "claim": "Bei Abweichungen von der Baseline: Korrelation mit Asset-, Identitäts- und Change-Kontext prüfen.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die Korrelation bei Abweichungen erläutert."
+      },
+      {
+        "claim": "Nach Änderungen: Funktion, Security-Kontrolle und Telemetrie separat testen.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die Testung nach Änderungen erläutert."
+      },
+      {
+        "claim": "Bei bestätigter Kompromittierung Scope auf angrenzende Systeme/Identitäten erweitern, Ursache beseitigen, Credentials/Keys nur gezielt rotieren und anschließend erhöhtes Monitoring einplanen.",
+        "verdict": "supported",
+        "source_refs": [
+          "206e6ff488c06b51d379606c"
+        ],
+        "reason": "Die Aussage ist direkt durch die interne Quelle KB-SEC-HB-00933 belegbar, die die Reaktion bei Kompromittierung erläutert."
+      }
+    ]
+  },
+  "confidence": 1,
+  "generated_at": "2026-08-07T20:23:20.324326Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen",
+    "purpose": "Die drei Quellen (KB-SEC-HB-00933, KB-SEC-HB-00931, KB-SEC-HB-00932) behandeln das Thema 'Prototype Pollution Schutz' aus drei verschiedenen Perspektiven: forensisch untersuchen, präventiv absichern und detektiv überwachen. Sie teilen sich einen gemeinsamen thematischen Schwerpunkt und enthalten ähnliche Struktur und Inhalt. Ein Zielartikel, der alle drei Aspekte in einem konsolidierten Artikel vereint, würde einen höheren Nutzwert für den Helpdesk bieten, da er eine umfassende, strukturierte und praxisnahe Anleitung zur Sicherung gegen Prototype Pollution bietet.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": null,
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen",
+    "missing_information": [],
+    "reason": "Die drei Quellen (KB-SEC-HB-00933, KB-SEC-HB-00931, KB-SEC-HB-00932) behandeln das Thema 'Prototype Pollution Schutz' aus drei verschiedenen Perspektiven: forensisch untersuchen, präventiv absichern und detektiv überwachen. Sie teilen sich einen gemeinsamen thematischen Schwerpunkt und enthalten ähnliche Struktur und Inhalt. Ein Zielartikel, der alle drei Aspekte in einem konsolidierten Artikel vereint, würde einen höheren Nutzwert für den Helpdesk bieten, da er eine umfassende, strukturierte und praxisnahe Anleitung zur Sicherung gegen Prototype Pollution bietet."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 3,
+  "research_material": [
+    {
+      "actionable": true,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Teil 5 – Schutzmaßnahmen und Best Practices gegen Prototype Pollution\n\nSep. 12, 2025\n\nvon\n\nStefan\n\nin Cyber Security , Prototype Pollution , Websecurity\n\nWarum Vorbeugung so entscheidend ist\n\nPrototype Pollution ist tückisch:\n\nSie wirkt global.\n\nSie bleibt lange unentdeckt.\n\nSie kann schwerwiegende Folgen haben – von Admin-Bypass bis DoS.\n\nDer beste Schutz ist nicht, Pollution nachträglich „aufzuräumen“, sondern sie gar nicht erst entstehen zu lassen . In diesem Beitrag gehen wir Schritt für Schritt durch die wichtigsten Abwehrstrategien.\n\n1. Schlüssel validieren (Blockliste \u0026 Positivliste)\n\nPrototype Pollution passiert fast immer, weil Anwendungen ungeprüfte Eingaben direkt in Objekte übernehmen. Die einfachste Abwehr: gefährliche Schlüssel blockieren .\n\nBlockliste\n\nMindestens diese Keys sollten niemals aus untrusted Input akzeptiert werden:\n\n__proto__\n\nprototype\n\nconstructor\n\nBeispiel:…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.3342857142857143,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Teil 5 – Schutzmaßnahmen und Best Practices gegen Prototype Pollution",
+      "url": "https://www.stefanbehling.tech/2025/09/12/teil-5-schutzmassnahmen-und-best-practices-gegen-prototype-pollution/"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Sponsored\n\nPrototype Pollution auf Client-Seite\n\nTip\n\nAWS Hacking lernen und üben: HackTricks Training AWS Red Team Expert (ARTE)\nGCP Hacking lernen und üben: HackTricks Training GCP Red Team Expert (GRTE)\nAz Hacking lernen und üben: HackTricks Training Azure Red Team Expert (AzRTE)\nDen vollständigen HackTricks Training-Katalog durchsuchen.\n\nHackTricks unterstützen\n\nSieh dir die Abonnementpläne an!\n\nTritt der 💬 Discord-Gruppe und der Telegram-Gruppe bei , folge @hacktricks_live auf X/Twitter oder sieh dir die LinkedIn-Seite und den YouTube-Kanal an.\n\nTeile Hacking-Tricks, indem du PRs an die HackTricks - und HackTricks Cloud -GitHub-Repos einreichst.\n\nEntdeckung mit automatischen Tools\n\nDie Tools https://github.com/dwisiswant0/ppfuzz , https://github.com/kleiton0x00/ppmap und https://github.com/kosmosec/proto-find können verwendet werden, um Schwachstellen durch prototype pollution zu fi…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.3342857142857143,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Client Side Prototype Pollution - HackTricks",
+      "url": "https://hacktricks.wiki/de/pentesting-web/deserialization/nodejs-proto-prototype-pollution/client-side-prototype-pollution.html"
+    },
+    {
+      "actionable": true,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Web Security Academy\n\nPrototype pollution\n\nWhat is prototype pollution?\n\nPrototype pollution is a JavaScript vulnerability that enables an attacker to add arbitrary properties to global object prototypes, which may then be inherited by user-defined objects.\n\nAlthough prototype pollution is often unexploitable as a standalone vulnerability, it lets an attacker control properties of objects that would otherwise be inaccessible. If the application subsequently handles an attacker-controlled property in an unsafe way, this can potentially be chained with other vulnerabilities. In client-side JavaScript, this commonly leads to DOM XSS , while server-side prototype pollution can even result in remote code execution.\n\nIf you're unfamiliar with how prototypes and inheritance work in JavaScript, we recommend reading the following overview before continuing.\n\nJavaScript prototypes and inheritance\n…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "What is prototype pollution? | Web Security Academy",
+      "url": "https://portswigger.net/web-security/prototype-pollution"
+    },
+    {
+      "actionable": true,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Support Center\n\nDocumentation\n\nDesktop editions\n\nTools\n\nDOM Invader\n\nTesting for client-side prototype pollution\n\nProfessional Community Edition\n\nTesting for client-side prototype pollution\n\nLast updated:\nAugust 3, 2026\n\nRead time:\n3 Minutes\n\nDOM Invader provides a number of features to help you test for client-side prototype pollution vulnerabilities. These enable you to perform the following key tasks:\n\nAutomatically detect sources for prototype pollution in the URL and any JSON objects sent via web messages. This includes detecting alternative techniques using the same source.\n\nGenerate a proof of concept by polluting the Object.prototype using any discovered sources. You can then manually verify the vulnerability via the browser console.\n\nScan for potential gadgets that you can use to craft an exploit.\n\nEnabling prototype pollution\n\nTo avoid interfering with your target site's functi…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen current official documentation version support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "primary",
+      "source_quality_score": 0.88,
+      "title": "Testing for client-side prototype pollution - PortSwigger",
+      "url": "https://portswigger.net/burp/documentation/desktop/tools/dom-invader/prototype-pollution"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "JavaScript prototype pollution\n\nPrototype pollution is a vulnerability where an attacker can add or modify properties on an object's prototype. This means malicious values can unexpectedly appear on objects in your application, often leading to logic errors or additional attacks like cross-site scripting (XSS) .\n\nPrototypes in JavaScript\n\nJavaScript implements inheritance using prototypes . Each object has a reference to a prototype, which is itself an object, and which itself has a prototype, and so on, until we get to the fundamental prototype, which is called Object.prototype , whose own prototype is null .\n\nIf you try to access a property or call a method on an object, and that property or method isn't defined on the object, then the JavaScript runtime looks in the object's prototype for the property or method, and then in the object's prototype's prototype, and so on, until it finds…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen current official documentation version support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "primary",
+      "source_quality_score": 0.88,
+      "title": "JavaScript prototype pollution - Security | MDN",
+      "url": "https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Prototype_pollution"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Query Parameterization\n\nRAG Security\n\nREST Assessment\n\nREST Security\n\nRuby on Rails\n\nSAML Security\n\nSQL Injection Prevention\n\nSecrets Management\n\nSecure AI Model Ops\n\nSecure Cloud Architecture\n\nSecure Code Review\n\nSecure Coding with AI\n\nSecure Product Design\n\nSecuring Cascading Style Sheets\n\nSecurity Terminology\n\nServer Side Request Forgery Prevention\n\nServerless FaaS Security\n\nSession Management\n\nSoftware Supply Chain Security\n\nSubdomain Takeover Prevention\n\nSymfony\n\nTLS Cipher String\n\nThird Party Javascript Management\n\nThird Party Payment Gateway Integration\n\nThreat Modeling\n\nTransaction Authorization\n\nTransport Layer Protection\n\nTransport Layer Security\n\nUnvalidated Redirects and Forwards\n\nUser Privacy Protection\n\nVirtual Patching\n\nVulnerability Disclosure\n\nVulnerable Dependency Management\n\nWebSocket Security\n\nWeb Service Security\n\nXML External Entity Prevention\n\nXML Security\n\nXSS Fil…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen current official documentation version support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "reputable_secondary",
+      "source_quality_score": 0.68,
+      "title": "Prototype Pollution Prevention - OWASP Cheat Sheet Series",
+      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html"
+    }
+  ],
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 0,
+  "source_fingerprint": "a10d74b11b65b09636739d5a6679653fbecc75659195fd0347d41e8f19f95036",
+  "source_node_ids": [
+    "0700c83c80a45cb8ee9b735e",
+    "0e2442d082bc502a7cd1cf13",
+    "206e6ff488c06b51d379606c"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-00931",
+    "KB-SEC-HB-00932",
+    "KB-SEC-HB-00933"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-00933",
+  "target_node_id": "206e6ff488c06b51d379606c"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-c35c93a5f9a6.json b/data/article-metadata/kb-ai-think-article-20260807-c35c93a5f9a6.json
new file mode 100644
index 0000000..9fa72b5
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-c35c93a5f9a6.json
@@ -0,0 +1,255 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-C35C93A5F9A6",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-c35c93a5f9a6.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 0.95,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Einzelne Indikatoren reichen nicht aus, um einen Ransomware-Vorfall zu bestätigen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03826",
+          "KB-SEC-HB-03827",
+          "KB-SEC-HB-03829",
+          "KB-SEC-HB-03904",
+          "KB-SEC-HB-03905"
+        ],
+        "reason": "Die Quellen bestätigen, dass einzelne Indikatoren nicht ausreichen, um einen Vorfall zu bestätigen."
+      },
+      {
+        "claim": "Frühe Vorläufer wie Credential-Missbrauch, laterale Bewegung und ungewöhnliche Dateioperationen sind wichtige Indikatoren.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03826",
+          "KB-SEC-HB-03827",
+          "KB-SEC-HB-03829",
+          "KB-SEC-HB-03904",
+          "KB-SEC-HB-03905"
+        ],
+        "reason": "Die Quellen bestätigen, dass solche Vorläufer als Indikatoren relevant sind."
+      },
+      {
+        "claim": "Ransomware Prevention sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03826",
+          "KB-SEC-HB-03827",
+          "KB-SEC-HB-03829",
+          "KB-SEC-HB-03904",
+          "KB-SEC-HB-03905"
+        ],
+        "reason": "Die Quellen bestätigen, dass eine risikobasierte Betrachtung notwendig ist."
+      },
+      {
+        "claim": "Sicherheitsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt verschlechtern.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03825"
+        ],
+        "reason": "Die Quellen bestätigen, dass Sicherheitsmaßnahmen nicht die Verfügbarkeit und Wiederherstellbarkeit beeinträchtigen dürfen."
+      },
+      {
+        "claim": "Dokumentation von Scope, betroffenen Assets/Identitäten, Datenkritikalität, Exposition und betrieblichen Abhängigkeiten.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03826",
+          "KB-SEC-HB-03827",
+          "KB-SEC-HB-03829",
+          "KB-SEC-HB-03904",
+          "KB-SEC-HB-03905"
+        ],
+        "reason": "Die Quellen bestätigen, dass eine Dokumentation dieser Aspekte notwendig ist."
+      },
+      {
+        "claim": "Korrelation von Abweichungen vom Normalverhalten mit Asset-, Identitäts- und Change-Kontext.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03826",
+          "KB-SEC-HB-03827",
+          "KB-SEC-HB-03829",
+          "KB-SEC-HB-03904",
+          "KB-SEC-HB-03905"
+        ],
+        "reason": "Die Quellen bestätigen, dass eine Korrelation mit dem Kontext notwendig ist."
+      },
+      {
+        "claim": "Ransomware Detection sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03826",
+          "KB-SEC-HB-03827",
+          "KB-SEC-HB-03829",
+          "KB-SEC-HB-03904",
+          "KB-SEC-HB-03905"
+        ],
+        "reason": "Die Quellen bestätigen, dass eine risikobasierte Betrachtung notwendig ist."
+      },
+      {
+        "claim": "Nach Änderungen Funktion, Security-Kontrolle und Telemetrie separat testen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03826",
+          "KB-SEC-HB-03827",
+          "KB-SEC-HB-03829",
+          "KB-SEC-HB-03904",
+          "KB-SEC-HB-03905"
+        ],
+        "reason": "Die Quellen bestätigen, dass nach Änderungen Funktion, Security-Kontrolle und Telemetrie separat getestet werden sollten."
+      },
+      {
+        "claim": "Bei bestätigter Kompromittierung Scope auf angrenzende Systeme erweitern.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03826",
+          "KB-SEC-HB-03827",
+          "KB-SEC-HB-03829",
+          "KB-SEC-HB-03904",
+          "KB-SEC-HB-03905"
+        ],
+        "reason": "Die Quellen bestätigen, dass bei bestätigter Kompromittierung der Scope erweitert werden sollte."
+      }
+    ]
+  },
+  "confidence": 0.95,
+  "generated_at": "2026-08-07T20:05:12.4896317Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "Ransomware Prevention \u0026 Detection",
+    "purpose": "Mehrere produktive Artikel zu ähnlichen Themen (Ransomware Prevention, Detection, Forensics, Early Warning, Containment) überschneiden sich stark in Inhalt und Struktur. Sie können als Staging-Entwurf in einen einheitlichen Zielartikel zu 'Ransomware Prevention \u0026 Detection' konsolidiert werden, um Wiederholungen zu vermeiden und eine kohärente, umfassende Lösung zu bieten.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": null,
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "Ransomware Prevention \u0026 Detection",
+    "missing_information": [],
+    "reason": "Mehrere produktive Artikel zu ähnlichen Themen (Ransomware Prevention, Detection, Forensics, Early Warning, Containment) überschneiden sich stark in Inhalt und Struktur. Sie können als Staging-Entwurf in einen einheitlichen Zielartikel zu 'Ransomware Prevention \u0026 Detection' konsolidiert werden, um Wiederholungen zu vermeiden und eine kohärente, umfassende Lösung zu bieten."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 8,
+  "research_material": [
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Ransomware Protection and Response | CSRC\n\nYou are viewing this page in an unauthorized frame window.\n\nThis is a potential security issue, you are being redirected to https://csrc.nist.gov .\n\nOfficial websites use .gov\n.gov website belongs to an official government\norganization in the United States.\n\nSecure .gov websites use HTTPS\nlock (\n\n) or https:// means you’ve safely connected to\nthe .gov website. Share sensitive information only on official,\nsecure websites.\n\nInformation Technology Laboratory\n\nComputer Security Resource Center\n\nProjects\n\nRansomware Protection and Response\n\nShare to Facebook\nShare to X\nShare to LinkedIn\nShare ia Email\n\nProject Links\n\nOverview\n\nNews \u0026 Updates\n\nPublications\n\nOverview\n\nThanks for helping shape our ransomware guidance!  We've published our final version of NIST IR 8374 Revision 1,  Ransomware Risk Management: A Cybersecurity Framework Profile . It refle…",
+      "fetched": true,
+      "language": "en-US",
+      "query": "Ransomware Prevention \u0026 Detection aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.495,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "authoritative",
+      "source_quality_score": 0.95,
+      "title": "Ransomware Protection and Response | CSRC",
+      "url": "https://csrc.nist.gov/Projects/ransomware-protection-and-response"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Now Available: Practical Guidelines for Preventing and Mitigating Ransomware | NIST\n\nSkip to main content\n\nOfficial websites use .gov\n\nA .gov website belongs to an official government organization in the United States.\n\nSecure .gov websites use HTTPS\n\nA lock (\n\n) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.\n\nhttps://www.nist.gov/news-events/news/2026/06/now-available-practical-guidelines-preventing-and-mitigating-ransomware\n\nUPDATES\n\nNow Available: Practical Guidelines for Preventing and Mitigating Ransomware\n\nJune 11, 2026\n\nShare\n\nFacebook\n\nLinkedin\n\nX.com\n\nEmail\n\nThe NIST NCCoE has published the final version of NIST Interagency Report (IR) 8374 Revision 1, Ransomware Risk Management: A Cybersecurity Framework (CSF) 2.0 Community Profile . This resource translates the NIST CSF 2.0 into practical actions or…",
+      "fetched": true,
+      "language": "en-US",
+      "query": "Ransomware Prevention \u0026 Detection aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "authoritative",
+      "source_quality_score": 0.95,
+      "title": "Now Available: Practical Guidelines for Preventing and Mitigating Ransomware | NIST",
+      "url": "https://www.nist.gov/news-events/news/2026/06/now-available-practical-guidelines-preventing-and-mitigating-ransomware"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Welcome to the future of Business Support! I'm TrendAI Companion™, your\nAI assistant ready to streamline your experience.\n\nLog in for your personalized support!\nChat with TrendAI Companion™ for quick answers, or submit a case for\ndetailed troubleshooting.",
+      "fetched": true,
+      "language": "en-US",
+      "query": "Ransomware Prevention \u0026 Detection current official documentation version support",
+      "relevance": 0.62,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Ransomware Detection and Prevention with Deep Security Intrusion Prevention",
+      "url": "https://success.trendmicro.com/en-US/solution/KA-0006382"
+    }
+  ],
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 0,
+  "source_fingerprint": "c35c93a5f9a6b2b5f9951180bad516bed624ab36e222e617ea6074187da300ec",
+  "source_node_ids": [
+    "014516dfe205478447f304d3",
+    "05ece6d4b1faa4aa02c3ad7a",
+    "0de4dd40810c015dcc8545cc",
+    "4e619b8c2b06e4ef9d0a0bc9",
+    "550fa230cb16b3695c1efa19",
+    "6e6a2635613bc6be25210cd4",
+    "720fda7746799f14bd8baf49",
+    "77d09ac332bb5af47102b388"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-03824",
+    "KB-SEC-HB-03825",
+    "KB-SEC-HB-03826",
+    "KB-SEC-HB-03827",
+    "KB-SEC-HB-03829",
+    "KB-SEC-HB-03903",
+    "KB-SEC-HB-03904",
+    "KB-SEC-HB-03905"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-03825",
+  "target_node_id": "014516dfe205478447f304d3"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-c3d62c1dbdf5.json b/data/article-metadata/kb-ai-think-article-20260807-c3d62c1dbdf5.json
new file mode 100644
index 0000000..2d9fb7b
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-c3d62c1dbdf5.json
@@ -0,0 +1,191 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-C3D62C1DBDF5",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-c3d62c1dbdf5.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 1,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Abweichungen müssen immer mit Asset-, Identitäts- und Change-Kontext korreliert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt explizit, dass Abweichungen mit Asset-, Identitäts- und Change-Kontext korreliert werden müssen."
+      },
+      {
+        "claim": "Baseline und erwartetes Normalverhalten sollten dokumentiert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt, dass Baseline und erwartetes Normalverhalten dokumentiert werden müssen."
+      },
+      {
+        "claim": "Der Schwerpunkt liegt auf der Verifizierung von Ergebnissen und der Verbesserung der Detection.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt, dass der Schwerpunkt auf der Verifizierung von Ergebnissen und der Verbesserung der Detection liegt."
+      },
+      {
+        "claim": "Detection Regression Testing sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt, dass Detection Regression Testing risikobasiert betrachtet werden sollte."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt, dass Einzelne Indikatoren kein ausreichender Beweis für einen Vorfall sind."
+      },
+      {
+        "claim": "Messbare Hypothesen, erwartete Telemetrie und Stop-Kriterien sind vorab zu definieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt, dass messbare Hypothesen, erwartete Telemetrie und Stop-Kriterien vorab definiert werden müssen."
+      },
+      {
+        "claim": "Tests sind nur im autorisierten Scope und mit Betriebsbeobachtung durchzuführen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt, dass Tests nur im autorisierten Scope und mit Betriebsbeobachtung durchgeführt werden dürfen."
+      },
+      {
+        "claim": "Vorab sollten Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten dokumentiert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt, dass Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten vorab dokumentiert werden müssen."
+      },
+      {
+        "claim": "Test der Security-Kontrolle nach Änderungen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt, dass die Security-Kontrolle nach Änderungen getestet werden muss."
+      },
+      {
+        "claim": "Verifikation der Telemetrie nach Änderungen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt, dass die Telemetrie nach Änderungen verifiziert werden muss."
+      },
+      {
+        "claim": "Überprüfung der Funktionalität nach Änderungen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt, dass die Funktionalität nach Änderungen überprüft werden muss."
+      },
+      {
+        "claim": "Bei unerwarteten Ergebnissen den Scope überprüfen und die Baseline vergleichen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt, dass bei unerwarteten Ergebnissen der Scope überprüft und die Baseline verglichen werden muss."
+      },
+      {
+        "claim": "Eskalationswege bei bestätigten Kompromittierungen definieren und einhalten.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt, dass Eskalationswege bei bestätigten Kompromittierungen definiert und eingehalten werden müssen."
+      },
+      {
+        "claim": "Sicherstellen, dass alle relevanten Assets und Identitäten im Testplan berücksichtigt sind.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03483"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-03483 bestätigt, dass alle relevanten Assets und Identitäten im Testplan berücksichtigt werden müssen."
+      }
+    ]
+  },
+  "confidence": 1,
+  "generated_at": "2026-08-07T20:13:27.5896002Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "Detection Regression Testing – sicher planen, durchführen und Ergebnisse verifizieren",
+    "purpose": "Mehrere produktive Artikel zu ähnlichen Themen (Detection Regression Testing, Detection Unit Tests, Detection Integration Tests, Vulnerability Retest, Security Test Planning, Detection Validation) überschneiden sich stark in Inhalt und Struktur. Sie behandeln alle Aspekte der risikobasierten Planung, Durchführung, Härtung, forensischen Verarbeitung und Verifikation. Ein Zielartikel, der alle diese Aspekte in einem konsolidierten Format zusammenfasst, würde einen echten Mehrwert für den Helpdesk bieten. Die Quellen sind thematisch kompatibel und können als Staging-Entwurf für einen umfassenderen Artikel konsolidiert werden.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": null,
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "Detection Regression Testing – sicher planen, durchführen und Ergebnisse verifizieren",
+    "missing_information": [],
+    "reason": "Mehrere produktive Artikel zu ähnlichen Themen (Detection Regression Testing, Detection Unit Tests, Detection Integration Tests, Vulnerability Retest, Security Test Planning, Detection Validation) überschneiden sich stark in Inhalt und Struktur. Sie behandeln alle Aspekte der risikobasierten Planung, Durchführung, Härtung, forensischen Verarbeitung und Verifikation. Ein Zielartikel, der alle diese Aspekte in einem konsolidierten Format zusammenfasst, würde einen echten Mehrwert für den Helpdesk bieten. Die Quellen sind thematisch kompatibel und können als Staging-Entwurf für einen umfassenderen Artikel konsolidiert werden."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 8,
+  "research_material": null,
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 0,
+  "source_fingerprint": "c3d62c1dbdf5907c294a3a9af6d938d6b354c95b20f7306688cd2c4583ca8ba5",
+  "source_node_ids": [
+    "07a5b96fcba6e0ab9506f668",
+    "09d2a303362cebe9f3e04f04",
+    "326514d32c7ff1c10b93c467",
+    "61a6e5b7ceda77b00742d933",
+    "7c9bbd5d1dd853b9364cd5d3",
+    "c664dad9e86039fe30d245b2",
+    "c6cde7250e7ed472a7c416b4",
+    "d0c3c61750556397e2319a9e"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-03459",
+    "KB-SEC-HB-03470",
+    "KB-SEC-HB-03482",
+    "KB-SEC-HB-03483",
+    "KB-SEC-HB-03484",
+    "KB-SEC-HB-03485",
+    "KB-SEC-HB-03486",
+    "KB-SEC-HB-03577"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-03483",
+  "target_node_id": "07a5b96fcba6e0ab9506f668"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-c8996e21622c.json b/data/article-metadata/kb-ai-think-article-20260807-c8996e21622c.json
new file mode 100644
index 0000000..14552da
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-c8996e21622c.json
@@ -0,0 +1,708 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-C8996E21622C",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-c8996e21622c.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 0.98,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Wayland/X11 Remote Access stellt eine potenzielle Angriffsfläche dar, die durch unzureichende Sicherheitsmaßnahmen ausgenutzt werden kann.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen und Webrecherchematerialien bestätigen, dass Wayland/X11 Remote Access Sicherheitsrisiken birgt, insbesondere bei unzureichender Sicherheitskonfiguration."
+      },
+      {
+        "claim": "Die Härtung sollte Least Privilege, Segmentierung und regelmäßige Tests umfassen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass Least Privilege, Segmentierung und regelmäßige Tests Best Practices für die Sicherheit von Wayland/X11 Remote Access sind."
+      },
+      {
+        "claim": "Forensische Untersuchungen sollten UTC-Timeline, Auth-/Endpoint-/Netzwerklogs und Backup-/Snapshot-Audits umfassen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass UTC-Timeline, Auth-/Endpoint-/Netzwerklogs und Backup-/Snapshot-Audits für forensische Untersuchungen relevant sind."
+      },
+      {
+        "claim": "Wayland/X11 Remote Access erfordert eine risikobasierte Sicherheitsbehandlung.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass eine risikobasierte Sicherheitsbehandlung für Wayland/X11 Remote Access erforderlich ist."
+      },
+      {
+        "claim": "Änderungen müssen kontrolliert getestet werden, Rollback-Optionen bereitstehen und Konfigurationsdrift überwacht werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass Änderungen kontrolliert getestet werden müssen, Rollback-Optionen bereitgestellt werden sollten und Konfigurationsdrift überwacht werden muss."
+      },
+      {
+        "claim": "Baseline-Vergleich: Abweichungen vom erwarteten Normalverhalten sind Indikatoren für Vorfälle.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass Baseline-Vergleiche und Abweichungen vom erwarteten Normalverhalten Indikatoren für Vorfälle sind."
+      },
+      {
+        "claim": "Least Privilege: Zugriffsrechte werden auf das notwendige Minimum beschränkt.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass Least Privilege ein zentrales Sicherheitsprinzip ist, das Zugriffsrechte auf das notwendige Minimum beschränkt."
+      },
+      {
+        "claim": "Risikobasierte Betrachtung: Maßnahmen basieren auf der Kritikalität von Daten und Systemen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass eine risikobasierte Betrachtung für Sicherheitsmaßnahmen erforderlich ist, wobei die Kritikalität von Daten und Systemen berücksichtigt wird."
+      },
+      {
+        "claim": "Testgetriebene Härtung: Änderungen werden kontrolliert getestet und Rollback-Optionen bereitgestellt.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass Testgetriebene Härtung ein Best Practice ist, bei dem Änderungen kontrolliert getestet werden und Rollback-Optionen bereitgestellt werden."
+      },
+      {
+        "claim": "Simulieren Sie Vorfälle, um die Reaktionsfähigkeit des Incident Response-Teams zu überprüfen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass die Simulation von Vorfällen zur Überprüfung der Reaktionsfähigkeit des Incident Response-Teams relevant ist."
+      },
+      {
+        "claim": "Testen Sie die Wirksamkeit der Härtungsmaßnahmen durch Penetrationstests.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass Penetrationstests zur Bewertung der Wirksamkeit von Sicherheitsmaßnahmen eingesetzt werden können."
+      },
+      {
+        "claim": "Überprüfen Sie die Konfiguration von Remote-Access-Diensten auf Sicherheitslücken.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass die Konfiguration von Remote-Access-Diensten auf Sicherheitslücken überprüft werden sollte."
+      },
+      {
+        "claim": "Führen Sie eine Malware-Suche durch.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass eine Malware-Suche Teil der Fehlerbehandlung bei Sicherheitsvorfällen ist."
+      },
+      {
+        "claim": "Isolieren Sie betroffene Systeme vom Netzwerk.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass die Isolierung von betroffenen Systemen vom Netzwerk Teil der Fehlerbehandlung bei Sicherheitsvorfällen ist."
+      },
+      {
+        "claim": "Stellen Sie sicher, dass alle Softwarekomponenten aktuell sind.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass die Aktualisierung aller Softwarekomponenten Teil der Fehlerbehandlung bei Sicherheitsvorfällen ist."
+      },
+      {
+        "claim": "Überprüfen Sie die Protokolle auf ungewöhnliche Aktivitäten.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass die Überprüfung von Protokollen auf ungewöhnliche Aktivitäten Teil der Fehlerbehandlung bei Sicherheitsvorfällen ist."
+      },
+      {
+        "claim": "Die Symptome umfassen Anzeichen für unbefugten Zugriff auf Systeme über Remote-Access-Sitzungen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass Anzeichen für unbefugten Zugriff auf Systeme über Remote-Access-Sitzungen als Symptome relevant sind."
+      },
+      {
+        "claim": "Die Symptome umfassen Kompromittierung von Benutzerkonten, die für den Remote-Zugriff verwendet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass die Kompromittierung von Benutzerkonten, die für den Remote-Zugriff verwendet werden, als Symptome relevant sind."
+      },
+      {
+        "claim": "Die Symptome umfassen Unerwartete Netzwerkaktivität von Remote-Access-Sitzungen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass unerwartete Netzwerkaktivität von Remote-Access-Sitzungen als Symptome relevant sind."
+      },
+      {
+        "claim": "Die Symptome umfassen Ungewöhnliche Dateioperationen oder Prozesse, die im Zusammenhang mit Remote-Access-Sitzungen auftreten.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass ungewöhnliche Dateioperationen oder Prozesse, die im Zusammenhang mit Remote-Access-Sitzungen auftreten, als Symptome relevant sind."
+      },
+      {
+        "claim": "Die Voraussetzungen umfassen Grundlegendes Verständnis von Linux-Systemen und Netzwerkprotokollen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass ein grundlegendes Verständnis von Linux-Systemen und Netzwerkprotokollen als Voraussetzung relevant ist."
+      },
+      {
+        "claim": "Die Voraussetzungen umfassen Kenntnisse über Sicherheitskonzepte wie Least Privilege und Segmentierung.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass Kenntnisse über Sicherheitskonzepte wie Least Privilege und Segmentierung als Voraussetzung relevant sind."
+      },
+      {
+        "claim": "Die Voraussetzungen umfassen Vertrautheit mit Incident Response-Prozessen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass Vertrautheit mit Incident Response-Prozessen als Voraussetzung relevant ist."
+      },
+      {
+        "claim": "Die Entscheidungskriterien umfassen Baseline-Vergleich: Abweichungen vom erwarteten Normalverhalten sind Indikatoren für Vorfälle.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass Baseline-Vergleiche und Abweichungen vom erwarteten Normalverhalten Indikatoren für Vorfälle sind."
+      },
+      {
+        "claim": "Die Entscheidungskriterien umfassen Least Privilege: Zugriffsrechte werden auf das notwendige Minimum beschränkt.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass Least Privilege ein zentrales Sicherheitsprinzip ist, das Zugriffsrechte auf das notwendige Minimum beschränkt."
+      },
+      {
+        "claim": "Die Entscheidungskriterien umfassen Risikobasierte Betrachtung: Maßnahmen basieren auf der Kritikalität von Daten und Systemen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass eine risikobasierte Betrachtung für Sicherheitsmaßnahmen erforderlich ist, wobei die Kritikalität von Daten und Systemen berücksichtigt wird."
+      },
+      {
+        "claim": "Die Entscheidungskriterien umfassen Testgetriebene Härtung: Änderungen werden kontrolliert getestet und Rollback-Optionen bereitgestellt.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-00323",
+          "KB-SEC-HB-00324",
+          "KB-SEC-HB-01006",
+          "KB-SEC-HB-01008",
+          "KB-SEC-HB-03824",
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03827"
+        ],
+        "reason": "Die internen Quellen bestätigen, dass Testgetriebene Härtung ein Best Practice ist, bei dem Änderungen kontrolliert getestet werden und Rollback-Optionen bereitgestellt werden."
+      }
+    ]
+  },
+  "confidence": 0.98,
+  "generated_at": "2026-08-07T20:45:10.298946Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben",
+    "purpose": "Mehrere produktive Artikel zu Wayland/X11 Remote Access überschneiden sich stark in ihrer Struktur und Inhalt. Sie behandeln alle Aspekte der Sicherheitsbewertung, der Härtung, der Detection und der forensischen Untersuchung. Ein Zielartikel kann diese Inhalte konsolidieren und als umfassenderen Leitfaden für die Sicherheitsbehandlung von Wayland/X11 Remote Access dienen.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": [
+    "Welche spezifischen Tools und Techniken sind für die Überwachung von Wayland/X11 Remote Access-Sitzungen verfügbar?",
+    "Wie können Wayland/X11 Remote Access-Sitzungen effektiv segmentiert werden, um die laterale Bewegung im Falle einer Kompromittierung zu verhindern?"
+  ],
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben",
+    "missing_information": [],
+    "reason": "Mehrere produktive Artikel zu Wayland/X11 Remote Access überschneiden sich stark in ihrer Struktur und Inhalt. Sie behandeln alle Aspekte der Sicherheitsbewertung, der Härtung, der Detection und der forensischen Untersuchung. Ein Zielartikel kann diese Inhalte konsolidieren und als umfassenderen Leitfaden für die Sicherheitsbehandlung von Wayland/X11 Remote Access dienen."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 8,
+  "research_material": [
+    {
+      "actionable": true,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "X11 Application Support\n\nIntroduction\n\nBeing able to run existing X11 applications is crucial for the adoption of\nWayland, especially on desktops, as there will always be X11 applications that\nhave not been or cannot be converted into Wayland applications, and throwing\nthem all away would be prohibitive. Therefore a Wayland compositor often needs\nto support running X11 applications.\n\nX11 and Wayland are different enough that there is no “simple” way to translate\nbetween them. Most of X11 is uninteresting to a Wayland compositor. That,\ncombined with the gigantic implementation effort needed to support X11, makes it\nintractable to just write X11 support directly in a Wayland compositor. The\nimplementation would be nothing short of a real X11 server.\n\nTherefore, Wayland compositors should use Xwayland, the X11 server that lives in\nthe Xorg server source code repository and shares most of th…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.3507692307692308,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "primary",
+      "source_quality_score": 0.88,
+      "title": "X11 Application Support - Wayland",
+      "url": "https://wayland.freedesktop.org/docs/book/Xwayland.html"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Wayland is now the default across most modern Linux desktops, and that quietly breaks a lot of X11-era support playbooks. If your helpdesk still relies on “global screen grabbers” or legacy VNC expectations, you’ll hit confusing prompts, black screens, and missing input.\n\nThis guide gives you a pragmatic, distro-agnostic playbook for remote support on Wayland using GNOME/KDE’s built-ins, the PipeWire + xdg-desktop-portal stack, and a few production-ready SOPs.\n\nTL;DR\n\nOn Wayland, screen capture/control is mediated by the compositor via PipeWire and xdg-desktop-portal, not legacy X11 hooks. Expect user-visible permission prompts and per-app scoping.\n\nGNOME Remote Desktop speaks RDP (and VNC) and can do user-present “share my screen” and remote-login/headless modes with GDM integration.\n\nKDE Plasma exposes Wayland sessions over RDP through KRdp ; configuration lives in Settings → Networkin…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.3507692307692308,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Remote Desktop on Wayland in 2025: What Changed for Linux Support Engineers | Stackademic",
+      "url": "https://stackademic.com/blog/remote-desktop-on-wayland-in-2025-what-changed-for-linux-support-engineers"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Wayland\n\nWayland\n\nWayland is a replacement for the X11 window system protocol and\narchitecture with the aim to be easier to develop, extend, and\nmaintain.\n\nWayland is the language (protocol) that applications can use to\ntalk to a display server in order to make themselves visible and\nget input from the user (a person). A Wayland server is called\na \"compositor\". Applications are Wayland clients.\n\nWayland also refers to a system architecture. It is not just a\nserver-client relationship between a compositor and applications.\nThere is no single common Wayland server like Xorg is for X11,\nbut every graphical environment brings with it one of many compositor\nimplementations. Window management and the end user experience\nare often tied to the compositor rather than swappable components.\n\nA core part of Wayland architecture is libwayland: an inter-process\ncommunication library that translates a …",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "reputable_secondary",
+      "source_quality_score": 0.68,
+      "title": "Wayland",
+      "url": "https://wayland.freedesktop.org/"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Home\n\nProducts\n\nRed Hat Enterprise Linux\n\nGetting started with the GNOME desktop environment\n\nChapter 14. Remotely accessing a Wayland-based application\n\nFormat Multi-page Single-page View full doc as PDF\n\nChapter 14. Remotely accessing a Wayland-based application\n\nYou can remotely launch a graphical Wayland-based application on a RHEL server and use it from the remote client on Wayland using waypipe .\n\nNote\n\nThe desktop applications shipped with RHEL 9 support both the Wayland and X11 display protocols. However, Wayland is the preferred option when both are available.\n\n14.1. Enabling waypipe on the client and server\nCopy link Link copied to clipboard!\n\nTo be able to launch an individual application on Wayland, you need to install the waypipe package.\n\nPrerequisites\n\nBoth the client and server use the RHEL 9 operating system.\n\nProcedure\n\nInstall the waypipe package on the local system.\n\n…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben current official documentation version support",
+      "relevance": 0.3927272727272727,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "primary",
+      "source_quality_score": 0.88,
+      "title": "Chapter 14. Remotely accessing a Wayland-based application | Getting started with the GNOME desktop environment | Red Hat Enterprise Linux | 9 | Red Hat Documentation",
+      "url": "https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/getting_started_with_the_gnome_desktop_environment/remotely-accessing-an-individual-application-wayland_getting-started-with-the-gnome-desktop-environment"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "aus Wikipedia, der freien Enzyklopädie\n\n\"},\"AktuelleVersion\":{\"wt\":\"\u003c!-- Wikidata --\u003e\"},\"AktuelleVersionFreigabeDatum\":{\"wt\":\"\u003c!-- Wikidata --\u003e\"},\"Programmiersprache\":{\"wt\":\"[[C (Programmiersprache)|C]]\"},\"Betriebssystem\":{\"wt\":\"[[Linux]], [[FreeBSD]], [[DragonFly BSD]], [[OpenBSD]]\"},\"Deutsch\":{\"wt\":\"nein\"},\"Kategorie\":{\"wt\":\"[[Display-Server-Protokoll]], [[Fenstersystem]]\"},\"Lizenz\":{\"wt\":\"[[MIT-Lizenz]]\"},\"Website\":{\"wt\":\"[https://wayland.freedesktop.org/ wayland.freedesktop.org]\"}},\"i\":0}}]}'\u003e\n\nWayland\n\nWayland-Demonstration\n\nBasisdaten\n\nEntwickler\n\nKristian Høgsberg\n\nErscheinungsjahr\n\n2008\n\nAktuelle   Version\n\n1.26.0 [ 1 ]\n( 16. Juli 2026 )\n\nAktuelle Vorabversion\n\n1.22.91 [ 2 ]\n( 25. April 2024 )\n\nBetriebssystem\n\nLinux , FreeBSD , DragonFly BSD , OpenBSD\n\nProgrammier ­ sprache\n\nKategorie\n\nDisplay-Server-Protokoll , Fenstersystem\n\nLizenz\n\nMIT-Lizenz\n\ndeutschsprachig\n\nnein\n\nwayland.fr…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben current official documentation version support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "reputable_secondary",
+      "source_quality_score": 0.68,
+      "title": "Wayland (Display-Server-Protokoll) – Wikipedia",
+      "url": "https://de.wikipedia.org/wiki/Wayland_(Display-Server-Protokoll)"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Wayland\n\nWayland\n\nNext\n\nWayland\n\nThe Wayland Protocol\n\nKristian Høgsberg\n\nIntel Corporation\n\n\u003c krh@bitplanet.net \u003e\n\nCopyright © 2012 Kristian Høgsberg, Intel Corporation\n\nPermission is hereby granted, free of charge, to any person obtaining a\ncopy of this software and associated documentation files (the \"Software\"),\nto deal in the Software without restriction, including without limitation\nthe rights to use, copy, modify, merge, publish, distribute, sublicense,\nand/or sell copies of the Software, and to permit persons to whom the\nSoftware is furnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice (including the next\nparagraph) shall be included in all copies or substantial portions of the\nSoftware.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCH…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben current official documentation version support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "primary",
+      "source_quality_score": 0.88,
+      "title": "Wayland",
+      "url": "https://wayland.freedesktop.org/docs/html/"
+    },
+    {
+      "actionable": true,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "REVIEW-1"
+      ],
+      "excerpt": "Incident Response\n\nEin Sicherheitsvorfall verlangt einen klaren Prozess, geübte Rollen und vorbereitete Kommunikation. Wer im Ernstfall improvisiert, verliert Zeit und macht Fehler. Diese Seite zeigt die Phasen, Verantwortlichkeiten und typischen Stolpersteine.\n\nFür wen ist diese Seite relevant?\n\nDiese Seite richtet sich an Incident-Manager, SOC- und IT-Leitung, Krisenstabsmitglieder, Datenschutz- und Rechtsfunktionen sowie an Geschäftsführungen, die wissen müssen, wie ihre Organisation auf Vorfälle vorbereitet ist.\n\nWas Incident Response ist\n\nIncident Response umfasst alle organisatorischen und technischen Schritte, mit denen eine Organisation einen Sicherheitsvorfall erkennt, eindämmt, behandelt und daraus lernt. Sie ist mehr als technische Forensik. Kommunikation, Entscheidungswege und Recht sind genauso wichtig.\n\nVorbereitung schlägt Improvisation\n\nIm Vorfall ist keine Zeit, Dinge er…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Welche konkreten Schritte sind für die Erkennung von Vorfällen bei Wayland/X11 Remote Access erforderlich?",
+      "relevance": 0.37,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Incident Response - strukturiertes Vorgehen bei Vorfällen",
+      "url": "https://www.cyber-security.eu/de/incident-response"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "REVIEW-1"
+      ],
+      "excerpt": "Vorfälle in NIS2 und KRITIS\n\nCybersecurity in KRITIS und NIS2\n\nISMS\n\nBCMS\n\nRisikomanagement\n\nLeitung\n\nPersonal\n\nSupply Chain\n\nVorfälle\n\nAngriffserkennung\n\nIT-Sicherheit\n\nStandards\n\nEinrichtungen und Betreiber müssen Ereignisse, die zu Vorfällen, Störungen und Sicherheitsvorfällen führen können erkennen, behandeln und teilweise an Aufsichtsbehörden melden.\nDazu sind durchgängige Prozesse für Vorfallsmanagement und Security Incident Management mit begleitenden Vorgaben und Abläfen notwendig.\n\nVorfallsmanagement\n\nDefinition\n\nMeldepflichten\n\nAngriffserkennung\n\nNIS2 und das KRITIS-Dachgesetz vertiefen die Vorgaben zur Behandlung von Vorfällen bei regulierten Einrichtungen und Betreibern.\nDie folgende Ausarbeitung führt ISMS-Kernkomponenten anhand der NIS2-Anforderungen für Einrichtungen, sowie der alten KRITIS-Anforderungen von\nRUN - KdA aus.\nAls Orientierung sind die Anforderungen der Durchf…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Welche konkreten Schritte sind für die Erkennung von Vorfällen bei Wayland/X11 Remote Access erforderlich?",
+      "relevance": 0.37,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Vorfallsmanagement in NIS2 und KRITIS – OpenKRITIS",
+      "url": "https://www.openkritis.de/massnahmen/vorfallsmanagement.html"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "REVIEW-1"
+      ],
+      "excerpt": "Startseite » Unser Blog » Informationsmanagementsysteme » Management von Sicherheitsvorfällen\nManagement von Sicherheitsvorfällen\n\nInformationsmanagementsysteme\n\nDas  Management von Sicherheitsvorfällen  (oft auch als Incident Management bezeichnet) ist ein unverzichtbarer Baustein jedes Informationssicherheitskonzepts. Unternehmen sind täglich verschiedensten Bedrohungen ausgesetzt, seien es Cyberangriffe, interne Sicherheitslücken oder menschliche Fehler. Umso wichtiger ist es, Sicherheitsvorfälle frühzeitig zu erkennen, zielgerichtet zu melden und konsequent zu bearbeiten. Ein strukturiertes Vorgehen sichert nicht nur den laufenden Betrieb, sondern schützt auch das Ansehen des Unternehmens und reduziert mögliche finanzielle Schäden.\n\nProzesse, Rollen und Verantwortlichkeiten beim Erkennen, Melden und Bearbeiten von Sicherheitsvorfällen :\n\nEin klar definierter Incident-Management-Proze…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Welche konkreten Schritte sind für die Erkennung von Vorfällen bei Wayland/X11 Remote Access erforderlich?",
+      "relevance": 0.37,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Management von Sicherheitsvorfällen: Prävention und Reaktion",
+      "url": "https://smct-management.de/management-von-sicherheitsvorfaellen/"
+    },
+    {
+      "actionable": true,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "REVIEW-2"
+      ],
+      "excerpt": "Instantly share code, notes, and snippets.\n\nitsfolf / vnc.md\n\nLast active\nFebruary 26, 2026 18:24\n\nShow Gist options\n\nDownload ZIP\n\nStar\n\n( 6 )\n\nYou must be signed in to star a gist\n\nFork\n\n( 0 )\n\nYou must be signed in to fork a gist\n\nEmbed\n\nSelect an option\n\nEmbed\nEmbed this gist in your website.\n\nShare\nCopy sharable link for this gist.\n\nClone via HTTPS\nClone using the web URL.\n\nNo results found\n\nLearn more about clone URLs\n\nClone this repository at \u0026lt;script src=\u0026quot;https://gist.github.com/itsfolf/1029f674eca3783f2d123521ff6a4ceb.js\u0026quot;\u0026gt;\u0026lt;/script\u0026gt;\n\nSave itsfolf/1029f674eca3783f2d123521ff6a4ceb to your computer and use it in GitHub Desktop.\n\nEmbed\n\nSelect an option\n\nEmbed\nEmbed this gist in your website.\n\nShare\nCopy sharable link for this gist.\n\nClone via HTTPS\nClone using the web URL.\n\nNo results found\n\nLearn more about clone URLs\n\nClone this repository at \u0026lt;script src=\u0026q…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Welche konkreten Schritte sind für die Härtung von Wayland/X11 Remote Access erforderlich?",
+      "relevance": 0.42,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "How to setup VNC on Wayland (Sway) + SDDM for unattended access · GitHub",
+      "url": "https://gist.github.com/itsfolf/1029f674eca3783f2d123521ff6a4ceb"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "REVIEW-2"
+      ],
+      "excerpt": "How do I setup a remote access solution in Wayland? - Fedora Discussion\n\n= 40rem)\" rel=\"stylesheet\" data-target=\"desktop\" /\u003e\n\n= 40rem)\" rel=\"stylesheet\" data-target=\"discourse-ai_desktop\" /\u003e\n= 40rem)\" rel=\"stylesheet\" data-target=\"discourse-calendar_desktop\" /\u003e\n= 40rem)\" rel=\"stylesheet\" data-target=\"discourse-reactions_desktop\" /\u003e\n= 40rem)\" rel=\"stylesheet\" data-target=\"poll_desktop\" /\u003e\n\nHow do I setup a remote access solution in Wayland?\n\nAsk Fedora\n\nwayland ,\ngnome ,\nworkstation ,\nserver\n\ndiligence3569\n\n(Dil Ligence)\n\n21. Juni 2024 um 05:33\n\nThere are several users who need to connect to my remote server, each with their own accounts, who need to interact with Firefox. They’re mostly connecting from Windows machines. I’m looking into retiring the Windows server that was responsible for this until now.\n\nThis is my first time setting up a remote access solution on Linux. It turned out t…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Welche konkreten Schritte sind für die Härtung von Wayland/X11 Remote Access erforderlich?",
+      "relevance": 0.42,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "reputable_secondary",
+      "source_quality_score": 0.68,
+      "title": "How do I setup a remote access solution in Wayland? - Fedora Discussion",
+      "url": "https://discussion.fedoraproject.org/t/how-do-i-setup-a-remote-access-solution-in-wayland/121232"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "REVIEW-2"
+      ],
+      "excerpt": "Solving the remote, unattended access problem on Wayland\nContents\n\nSolving the remote, unattended access problem on Wayland\n\nIntroduction\n\nIf you’re on the Linux world, you may have heard of Wayland . For good or for bad. It’s a modern display server protocol that aims to replace the aging X11 system. One of the key features of Wayland is its focus on security and simplicity, but it isn’t free. There have been a lot of issues from simple daily usage, app-specific problems, but notoriously, remote unattended access has been a significant challenge. Let’s focus on the unattended aspect.\n\nThe problem\n\nThe main problem with unattended remote access is that Wayland does not allow applications to capture the screen or input events unless they are explicitly granted permission each time . This means that traditional remote desktop solutions like TeamViewer or AnyDesk, which rely on full-screen,…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Welche konkreten Schritte sind für die Härtung von Wayland/X11 Remote Access erforderlich?",
+      "relevance": 0.42,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Solving the remote, unattended access problem on Wayland | Eduard's Blog",
+      "url": "https://edu4rdshl.dev/posts/solving-the-remote-unattended-access-problem-on-wayland/"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "REVIEW-3"
+      ],
+      "excerpt": "Durchführung von IT-Forensik Untersuchungen\n\nWie eine IT-Forensik Untersuchung durchgeführt wird, habe ich in meinem IT-Forensik-Kapitel beschrieben, dass in der neuesten Auflage des Fachbuches „Hacking \u0026 Security“ veröffentlicht wurde. Dabei ist ein methodisches Vorgehen bei der Analyse von Vorfällen unerlässlich.\n\nDienstag, 10. Januar 2023\n\n0 Kommentare\n\nProjekte\n\nBuch , ITForensik , Rheinwerk , HackingSecurity\n\nDie Neuauflage des umfassenden Handbuches im Bereich IT-Sicherheit ist im Dezember 2022 erschienen. In der Hacking \u0026 Security Artikelserie stelle ich mein Kapitel über IT-Forensik vor. Im ersten Blog-Post Neue Auflage des Buches „Hacking \u0026 Security“ gab ich einen Überblick über das Fachbuch. Im nächsten Artikel Über das Buch „Hacking \u0026 Security“ ging es um den Aufbau des über 1200 Seiten starken Buches und die anderen Mitautoren. Der dritte Beitrag Zielsetzung und Einsatzgebiet…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Welche konkreten Schritte sind für die forensische Untersuchung von Wayland/X11 Remote Access erforderlich?",
+      "relevance": 0.3927272727272727,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Durchführung von IT-Forensik Untersuchungen • Tobias Scheible - Cybercrime Dozent \u0026 Live Hacking Speaker",
+      "url": "https://scheible.it/durchfuehrung-von-it-forensik-untersuchungen/"
+    }
+  ],
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 1,
+  "source_fingerprint": "c8996e21622c2e0793ed798ae0116ec4fd5b9290ba25190f4749bf7db20c3938",
+  "source_node_ids": [
+    "007209fd1586eadd0b80951a",
+    "0086802a963fbd5e8a4d031d",
+    "014516dfe205478447f304d3",
+    "4e619b8c2b06e4ef9d0a0bc9",
+    "550fa230cb16b3695c1efa19",
+    "6e6a2635613bc6be25210cd4",
+    "74b82044ebe7b2aa5da30f1f",
+    "ee47afdfd96398a0b00ac3e6"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-00323",
+    "KB-SEC-HB-00324",
+    "KB-SEC-HB-01006",
+    "KB-SEC-HB-01008",
+    "KB-SEC-HB-03824",
+    "KB-SEC-HB-03825",
+    "KB-SEC-HB-03826",
+    "KB-SEC-HB-03827"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-00324",
+  "target_node_id": "ee47afdfd96398a0b00ac3e6"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-e58f8fc1d107.json b/data/article-metadata/kb-ai-think-article-20260807-e58f8fc1d107.json
new file mode 100644
index 0000000..a2aa2b8
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-e58f8fc1d107.json
@@ -0,0 +1,305 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-E58F8FC1D107",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-e58f8fc1d107.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 0.95,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Baseline-Verhaltensweisen für Cloud-Ressourcen müssen dokumentiert werden, um Anomalien effektiv zu erkennen.",
+        "verdict": "supported",
+        "source_refs": [
+          "01adee18f6b3f312d41cbdd7"
+        ],
+        "reason": "Die Quelle KB-SEC-HB-01282 betont die Notwendigkeit, Baseline und erwartetes Normalverhalten zu dokumentieren, um Abweichungen zu erkennen."
+      },
+      {
+        "claim": "Die Dokumentation von Scope, betroffenen Assets/Identitäten, Datenkritikalität, Exposition und betrieblichen Abhängigkeiten ist der erste Schritt bei der Implementierung von Sicherheitsmaßnahmen.",
+        "verdict": "supported",
+        "source_refs": [
+          "01adee18f6b3f312d41cbdd7",
+          "024938ac4633412a0d6752c3",
+          "55c2a1f4e41b22f39d549272",
+          "cdd808b04cfce7b60d4f84c1"
+        ],
+        "reason": "Dies wird in mehreren Quellen wie KB-SEC-HB-02614, KB-SEC-HB-02615, KB-SEC-HB-01283 und KB-SEC-HB-02623 als zentraler Schritt zur Risikobewertung und Sicherheitsplanung genannt."
+      },
+      {
+        "claim": "Die Priorisierung der Sicherung relevanter Daten (Audit-Logs, Flow Logs, IAM-Änderungen) ist entscheidend für forensische Untersuchungen.",
+        "verdict": "supported",
+        "source_refs": [
+          "024938ac4633412a0d6752c3",
+          "cdd808b04cfce7b60d4f84c1"
+        ],
+        "reason": "Dies wird in KB-SEC-HB-02614 und KB-SEC-HB-02615 als zentraler Aspekt für forensische Untersuchungen genannt."
+      },
+      {
+        "claim": "Nach Änderungen sollten Funktion, Security-Kontrolle und Telemetrie separat getestet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "024938ac4633412a0d6752c3",
+          "cdd808b04cfce7b60d4f84c1"
+        ],
+        "reason": "Dies wird in KB-SEC-HB-02614 und KB-SEC-HB-02615 als Best Practice genannt."
+      },
+      {
+        "claim": "Risikobasierte Betrachtung von Cloud-Sicherheitspraktiken ist essenziell.",
+        "verdict": "supported",
+        "source_refs": [
+          "01adee18f6b3f312d41cbdd7",
+          "024938ac4633412a0d6752c3",
+          "0b88c86e1719ba5aaa63ac55",
+          "55c2a1f4e41b22f39d549272",
+          "cdd808b04cfce7b60d4f84c1"
+        ],
+        "reason": "Dies wird in mehreren Quellen wie KB-SEC-HB-01282, KB-SEC-HB-02614, KB-SEC-HB-02615, KB-SEC-HB-01283, KB-SEC-HB-02623 und KB-SEC-HB-02609 als zentraler Aspekt genannt."
+      },
+      {
+        "claim": "Sicherheitsmaßnahmen dürfen die Verfügbarkeit und Wiederherstellbarkeit von Systemen nicht beeinträchtigen.",
+        "verdict": "supported",
+        "source_refs": [
+          "024938ac4633412a0d6752c3",
+          "cdd808b04cfce7b60d4f84c1"
+        ],
+        "reason": "Dies wird in KB-SEC-HB-02614 und KB-SEC-HB-02615 als zentraler Aspekt genannt."
+      },
+      {
+        "claim": "Änderungen an Cloud-Konfigurationen sollten kontrolliert getestet und mit Rollback-Mechanismen versehen werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "024938ac4633412a0d6752c3",
+          "cdd808b04cfce7b60d4f84c1"
+        ],
+        "reason": "Dies wird in KB-SEC-HB-02614 und KB-SEC-HB-02615 als Best Practice genannt."
+      },
+      {
+        "claim": "Durchführung regelmäßiger Access Reviews zur Identifizierung unbefugter Zugriffe.",
+        "verdict": "supported",
+        "source_refs": [
+          "024938ac4633412a0d6752c3",
+          "cdd808b04cfce7b60d4f84c1"
+        ],
+        "reason": "Dies wird in KB-SEC-HB-02614 und KB-SEC-HB-02615 als zentraler Aspekt genannt."
+      },
+      {
+        "claim": "Testen der Funktionalität von MFA und Secret Rotation Mechanismen.",
+        "verdict": "supported",
+        "source_refs": [
+          "024938ac4633412a0d6752c3",
+          "cdd808b04cfce7b60d4f84c1"
+        ],
+        "reason": "Dies wird in KB-SEC-HB-02614 und KB-SEC-HB-02615 als zentraler Aspekt genannt."
+      },
+      {
+        "claim": "Validierung der Logging-Konfiguration und Überprüfung der Protokollintegrität.",
+        "verdict": "supported",
+        "source_refs": [
+          "024938ac4633412a0d6752c3",
+          "cdd808b04cfce7b60d4f84c1"
+        ],
+        "reason": "Dies wird in KB-SEC-HB-02614 und KB-SEC-HB-02615 als zentraler Aspekt genannt."
+      },
+      {
+        "claim": "Überprüfung der Konfiguration von IAM-Rollen und -Policies auf Least Privilege Prinzipien.",
+        "verdict": "supported",
+        "source_refs": [
+          "024938ac4633412a0d6752c3",
+          "cdd808b04cfce7b60d4f84c1"
+        ],
+        "reason": "Dies wird in KB-SEC-HB-02614 und KB-SEC-HB-02615 als zentraler Aspekt genannt."
+      },
+      {
+        "claim": "Bei Abweichungen von der Baseline sollten die betroffenen Assets/Identitäten und Change-Kontexte korreliert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "024938ac4633412a0d6752c3",
+          "cdd808b04cfce7b60d4f84c1"
+        ],
+        "reason": "Dies wird in KB-SEC-HB-02614 und KB-SEC-HB-02615 als zentraler Aspekt genannt."
+      },
+      {
+        "claim": "Fehlgeschlagene Änderungen sollten zurückgerollt und die Ursache analysiert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "024938ac4633412a0d6752c3",
+          "cdd808b04cfce7b60d4f84c1"
+        ],
+        "reason": "Dies wird in KB-SEC-HB-02614 und KB-SEC-HB-02615 als zentraler Aspekt genannt."
+      },
+      {
+        "claim": "Kompromittierte Credentials müssen gezielt rotiert und erhöhtes Monitoring implementiert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "024938ac4633412a0d6752c3",
+          "cdd808b04cfce7b60d4f84c1"
+        ],
+        "reason": "Dies wird in KB-SEC-HB-02614 und KB-SEC-HB-02615 als zentraler Aspekt genannt."
+      }
+    ]
+  },
+  "confidence": 0.95,
+  "generated_at": "2026-08-07T20:06:59.86266Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "Cloud IAM, Cloud Secrets, Cloud Service Accounts, Cloud Incident Response, Cloud Access Review, Perfect Forward Secrecy – ein einheitliches, thematisch verknüpftes Handbuch zur Sicherheitspraxis in Cloud-Umgebungen mit Fokus auf Monitoring, Forensik und Sicherheitsmaßnahmen",
+    "purpose": "Die Quellen behandeln ähnliche Themen (Cloud-Sicherheit, IAM, Secrets, Incident Response, Perfect Forward Secrecy) und liefern jeweils einen produktiven, thematisch kompatiblen Artikel. Sie können als Staging-Entwurf in einen einheitlichen, thematisch verknüpften Artikel zur Sicherheitspraxis in Cloud-Umgebungen konsolidiert werden. Der Zielartikel würde eine umfassende, strukturierte Anleitung zur Sicherheit und Überwachung von Cloud-Ressourcen und Identitäten bieten.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": null,
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "Cloud IAM, Cloud Secrets, Cloud Service Accounts, Cloud Incident Response, Cloud Access Review, Perfect Forward Secrecy – ein einheitliches, thematisch verknüpftes Handbuch zur Sicherheitspraxis in Cloud-Umgebungen mit Fokus auf Monitoring, Forensik und Sicherheitsmaßnahmen",
+    "missing_information": [],
+    "reason": "Die Quellen behandeln ähnliche Themen (Cloud-Sicherheit, IAM, Secrets, Incident Response, Perfect Forward Secrecy) und liefern jeweils einen produktiven, thematisch kompatiblen Artikel. Sie können als Staging-Entwurf in einen einheitlichen, thematisch verknüpften Artikel zur Sicherheitspraxis in Cloud-Umgebungen konsolidiert werden. Der Zielartikel würde eine umfassende, strukturierte Anleitung zur Sicherheit und Überwachung von Cloud-Ressourcen und Identitäten bieten."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 8,
+  "research_material": [
+    {
+      "actionable": true,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Cloud Security Best Practices: Anwendung, typische Fehler, Praxiswissen und saubere Workflows\n\nCloud Security beginnt nicht mit Tools, sondern mit Verantwortungsgrenzen und Angriffsflächen\n\nCloud Security scheitert in der Praxis selten an fehlenden Produkten. Sie scheitert an falschen Annahmen. Viele Teams gehen davon aus, dass ein Cloud-Provider die Umgebung bereits ausreichend absichert. Tatsächlich schützt der Provider primär die zugrunde liegende Infrastruktur, nicht automatisch die konkrete Nutzung. Genau an dieser Stelle entstehen die meisten Vorfälle: falsch gesetzte Berechtigungen, öffentlich erreichbare Verwaltungsoberflächen, unkontrollierte Secrets, ungehärtete Images, unüberwachte Logs und unklare Zuständigkeiten zwischen Plattform-, Entwicklungs- und Security-Teams.\n\nDie erste Best Practice ist deshalb ein präzises Verständnis des Shared-Responsibility-Modells. In IaaS-Umgeb…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Cloud IAM, Cloud Secrets, Cloud Service Accounts, Cloud Incident Response, Cloud Access Review, Perfect Forward Secrecy – ein einheitliches, thematisch verknüpftes Handbuch zur Sicherheitspraxis in Cloud-Umgebungen mit Fokus auf Monitoring, Forensik und Sicherheitsmaßnahmen aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.30518518518518517,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Cloud Security Best Practices: Anwendung, typische Fehler, Praxiswissen und saubere Workflows",
+      "url": "https://hacking-kurse.de/it-security-websecurity/cloud-security-best-practices"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-1"
+      ],
+      "excerpt": "Topthemen:\n\nKünstliche Intelligenz\n\nNIS-2\n\nBreadcrumb-Navigation\n\nMit \u003ckes\u003e+ lesen\n\nSicherheitsarchitektur in der Public Cloud\nPrinzipien, Praxis und Fallstricke\n\nCloud-Sicherheit erfordert Umdenken: Wer seine On-Premises-Konzepte einfach in die Cloud hebt, verschenkt Potenzial und schafft neue Risiken. Unsere Autoren erörtern, welche Architekturprinzipien in der Praxis funktionieren, wo typische Stolperfallen lauern und wie Unternehmen eine gute Balance zwischen Sicherheit und Betriebsaufwand finden können.\n\n23.02.2026\n· Gerald Boyne ,\nJens Soeldner ,\nSimon Lehmeyer · Security-Management\n\nLesezeit\n19\nMin.\n\nDie Verlagerung von Workloads in PublicCloud-Umgebungen verändert die Sicherheitsarchitektur grundlegend: Statt physischer Perimeter und dedizierter Hardware treten softwaredefinierte Kontrollen, API-gesteuerte Konfigurationen und ein geteiltes Verantwortungsmodell in den Mittelpunkt.…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Cloud IAM, Cloud Secrets, Cloud Service Accounts, Cloud Incident Response, Cloud Access Review, Perfect Forward Secrecy – ein einheitliches, thematisch verknüpftes Handbuch zur Sicherheitspraxis in Cloud-Umgebungen mit Fokus auf Monitoring, Forensik und Sicherheitsmaßnahmen aktuelle offizielle Dokumentation Version Support",
+      "relevance": 0.26814814814814814,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Sicherheitsarchitektur in der Public Cloud - Informationssicherheit",
+      "url": "https://www.kes-informationssicherheit.de/print/titelthema-it-grundschutz-2/sicherheitsarchitektur-in-der-public-cloud/"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Cloud Security Response: Anwendung, typische Fehler, Praxiswissen und saubere Workflows\n\nCloud Security Response ist kein klassischer Incident-Response-Prozess mit anderem Namen\n\nCloud Security Response bedeutet, Sicherheitsvorfälle in dynamischen, API-gesteuerten und stark identitätsbasierten Umgebungen zu erkennen, einzugrenzen, zu analysieren und kontrolliert zu beheben. Der größte Denkfehler besteht darin, Cloud-Vorfälle wie klassische Server-Incidents im Rechenzentrum zu behandeln. In der Cloud ist nicht nur die Workload relevant, sondern vor allem die Steuerungsebene: IAM-Rollen, Tokens, Service Principals, Storage Policies, Security Groups, Snapshot-Rechte, KMS-Berechtigungen, CI/CD-Zugänge und die Frage, wer über welche API was verändert hat.\n\nEin kompromittierter Linux-Host in einer VM ist in der Cloud selten das eigentliche Kernproblem. Häufig ist er nur Symptom eines größeren …",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Cloud IAM, Cloud Secrets, Cloud Service Accounts, Cloud Incident Response, Cloud Access Review, Perfect Forward Secrecy – ein einheitliches, thematisch verknüpftes Handbuch zur Sicherheitspraxis in Cloud-Umgebungen mit Fokus auf Monitoring, Forensik und Sicherheitsmaßnahmen current official documentation version support",
+      "relevance": 0.28,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Cloud Security Response: Anwendung, typische Fehler, Praxiswissen und saubere Workflows",
+      "url": "https://hacking-kurse.de/it-security-websecurity/cloud-security-response"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Inhaltsverzeichnis (8 Abschnitte)\n\nKurzerklärung: Cloud IAM verwaltet Identitäten und Zugriffsrechte in Cloud-Umgebungen (AWS, Azure, GCP). Überprivilegierte IAM-Rollen sind die häufigste Ursache für Cloud-Datenpannen. Best Practices: Least Privilege, kurzlebige Credentials, Managed Identities statt Access Keys, regelmäßige Access Reviews und Automated Policy Analysis mit Cloud-nativen Tools.\n\nCloud IAM ist anders als On-Premises-IAM: alles läuft über APIs, Berechtigungen sind granularer, und ein einziger falsch konfigurierter Service-Account kann zur vollständigen Cloud-Kompromittierung führen.\n\nAWS IAM: Least Privilege umsetzen\n\nDer Root Account darf nur für die initiale Account-Einrichtung verwendet werden. Danach: MFA aktivieren, alle Access Keys löschen, und den Root Account niemals für tägliche Arbeit nutzen. In AWS Organizations sollte der Root Account zusätzlich isoliert werden.\n…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Cloud IAM, Cloud Secrets, Cloud Service Accounts, Cloud Incident Response, Cloud Access Review, Perfect Forward Secrecy – ein einheitliches, thematisch verknüpftes Handbuch zur Sicherheitspraxis in Cloud-Umgebungen mit Fokus auf Monitoring, Forensik und Sicherheitsmaßnahmen current official documentation version support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "unknown",
+      "source_quality_score": 0.52,
+      "title": "Cloud IAM Security: AWS, Azure und GCP richtig absichern",
+      "url": "https://a7.de/wiki/cloud-iam-security/"
+    },
+    {
+      "actionable": false,
+      "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel.",
+      "content_type": "text/html",
+      "covered_gap_ids": [
+        "ADAPTIVE-2"
+      ],
+      "excerpt": "Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.\n\nHome\n\nDocumentation\n\nCloud Architecture Center\n\nFeedback geben\n\nIdentitäts- und Zugriffsverwaltung – Übersicht\n\nMit Sammlungen den Überblick behalten\n\nSie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.\n\nLast reviewed 2024-07-11 UTC\n\nBei der Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM ) geht es darum, den richtigen Personen aus den richtigen Gründen Zugriff auf die richtigen Ressourcen zu gewähren. In dieser Reihe wird auf die allgemeinen IAM-Prinzipien und die betroffenen Personen eingegangen. Dazu gehören:\n\nUnternehmensidentitäten: Die Identitäten, die Sie für Mitarbeiter Ihrer Organisation verwalten. Diese Identitäten werden für die Anmeldung bei Workstations, den Zugriff auf E-Mails oder die Nutzung…",
+      "fetched": true,
+      "language": "de-DE",
+      "query": "Cloud IAM, Cloud Secrets, Cloud Service Accounts, Cloud Incident Response, Cloud Access Review, Perfect Forward Secrecy – ein einheitliches, thematisch verknüpftes Handbuch zur Sicherheitspraxis in Cloud-Umgebungen mit Fokus auf Monitoring, Forensik und Sicherheitsmaßnahmen current official documentation version support",
+      "relevance": 0.25,
+      "relevant": true,
+      "round": 1,
+      "source_quality": "primary",
+      "source_quality_score": 0.88,
+      "title": "Identitäts- und Zugriffsverwaltung – Übersicht  |  Cloud Architecture Center  |  Google Cloud Documentation",
+      "url": "https://docs.cloud.google.com/architecture/identity?hl=de"
+    }
+  ],
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 0,
+  "source_fingerprint": "e58f8fc1d1078833dbefef9238b34b1c718f3b02f211b9a022f760810b2e0622",
+  "source_node_ids": [
+    "01adee18f6b3f312d41cbdd7",
+    "024938ac4633412a0d6752c3",
+    "0b88c86e1719ba5aaa63ac55",
+    "55c2a1f4e41b22f39d549272",
+    "7df0ab1157f6df13bb6a9079",
+    "cdd808b04cfce7b60d4f84c1",
+    "e9da339f891170fdc6a34686",
+    "ed209d51c97472870e277d38"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-01282",
+    "KB-SEC-HB-01283",
+    "KB-SEC-HB-02609",
+    "KB-SEC-HB-02614",
+    "KB-SEC-HB-02615",
+    "KB-SEC-HB-02623",
+    "KB-SEC-HB-02697",
+    "KB-SEC-HB-02702"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-01282",
+  "target_node_id": "01adee18f6b3f312d41cbdd7"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-f0ddd2838242.json b/data/article-metadata/kb-ai-think-article-20260807-f0ddd2838242.json
new file mode 100644
index 0000000..78d1dd3
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-f0ddd2838242.json
@@ -0,0 +1,142 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-F0DDD2838242",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-f0ddd2838242.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 0.98,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Abweichungen von Baseline-Verhalten müssen immer mit Asset-, Identitäts- und Change-Kontext korreliert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03848",
+          "KB-SEC-HB-03849"
+        ],
+        "reason": "Diese Aussage ist direkt in mehreren internen Quellen (KB-SEC-HB-03849, KB-SEC-HB-03848, KB-SEC-HB-03825) als zentraler Bestandteil der Detection-Strategie formuliert."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03848",
+          "KB-SEC-HB-03849"
+        ],
+        "reason": "Diese Aussage ist in mehreren internen Quellen (KB-SEC-HB-03849, KB-SEC-HB-03848, KB-SEC-HB-03825) als zentraler Bestandteil der Detection-Strategie formuliert."
+      },
+      {
+        "claim": "Frühe Vorläufer wie Credential-Missbrauch, laterale Bewegung, ungewöhnliche Dateioperationen, Backup-/Snapshot-Manipulation und Exfiltration sollten zusammen betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03825",
+          "KB-SEC-HB-03848",
+          "KB-SEC-HB-03849"
+        ],
+        "reason": "Diese Aussage ist in mehreren internen Quellen (KB-SEC-HB-03849, KB-SEC-HB-03848, KB-SEC-HB-03825) als zentraler Bestandteil der Detection-Strategie formuliert."
+      },
+      {
+        "claim": "Sicherheitsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt verschlechtern.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03849"
+        ],
+        "reason": "Diese Aussage ist in der internen Quelle KB-SEC-HB-03849 als zentraler Bestandteil der präventiven Maßnahmen formuliert."
+      },
+      {
+        "claim": "Triple Extortion Risiko sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03848",
+          "KB-SEC-HB-03849"
+        ],
+        "reason": "Diese Aussage ist in mehreren internen Quellen (KB-SEC-HB-03849, KB-SEC-HB-03848) als zentraler Bestandteil der Einordnung formuliert."
+      },
+      {
+        "claim": "Bei bestätigter Kompromittierung den Scope auf die betroffenen Assets/Identitäten beschränken.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03849"
+        ],
+        "reason": "Diese Aussage ist in der internen Quelle KB-SEC-HB-03849 als zentraler Bestandteil der Reaktionsstrategie formuliert."
+      },
+      {
+        "claim": "Nach Änderungen Funktion, Security-Kontrolle und Telemetrie separat testen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-03849"
+        ],
+        "reason": "Diese Aussage ist in der internen Quelle KB-SEC-HB-03849 als zentraler Bestandteil der Reaktionsstrategie formuliert."
+      }
+    ]
+  },
+  "confidence": 0.98,
+  "generated_at": "2026-08-07T20:07:27.2255286Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "Triple Extortion Risiko – präventiv und resilient gestalten, im Vorfall erkennen, eindämmen und wiederherstellen",
+    "purpose": "Die Quellen enthalten zwei vollständige, thematisch kompatible Artikel zu Triple Extortion Risiko, die sich inhaltlich stark überschneiden. Beide Artikel behandeln die Themen Prävention, Detection, Härtung und Incident Response. Ein Merge ist sinnvoll, um die Informationen zu einem umfassenderen, strukturierten Artikel zu konsolidieren, der sowohl präventive Maßnahmen als auch Vorfallskontrolle abdeckt. Der Zielartikel wird als Kombination der beiden Quellen gebildet.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": null,
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "Triple Extortion Risiko – präventiv und resilient gestalten, im Vorfall erkennen, eindämmen und wiederherstellen",
+    "missing_information": [],
+    "reason": "Die Quellen enthalten zwei vollständige, thematisch kompatible Artikel zu Triple Extortion Risiko, die sich inhaltlich stark überschneiden. Beide Artikel behandeln die Themen Prävention, Detection, Härtung und Incident Response. Ein Merge ist sinnvoll, um die Informationen zu einem umfassenderen, strukturierten Artikel zu konsolidieren, der sowohl präventive Maßnahmen als auch Vorfallskontrolle abdeckt. Der Zielartikel wird als Kombination der beiden Quellen gebildet."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 8,
+  "research_material": null,
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 0,
+  "source_fingerprint": "f0ddd2838242c81538d1bacd88c5795e517cac39df9474fe861c84066eae0bb4",
+  "source_node_ids": [
+    "014516dfe205478447f304d3",
+    "02cda3d176e51ac4dd1c498d",
+    "0de4dd40810c015dcc8545cc",
+    "502600265ad4a9bd30ad28c8",
+    "550fa230cb16b3695c1efa19",
+    "65b02ffa0be5498e843fd005",
+    "6b9a689b5b694eca7d58374b",
+    "77d09ac332bb5af47102b388"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-03824",
+    "KB-SEC-HB-03825",
+    "KB-SEC-HB-03846",
+    "KB-SEC-HB-03847",
+    "KB-SEC-HB-03848",
+    "KB-SEC-HB-03849",
+    "KB-SEC-HB-03904",
+    "KB-SEC-HB-03905"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-03849",
+  "target_node_id": "02cda3d176e51ac4dd1c498d"
+}
diff --git a/data/article-metadata/kb-ai-think-article-20260807-f3dbf2cf1eea.json b/data/article-metadata/kb-ai-think-article-20260807-f3dbf2cf1eea.json
new file mode 100644
index 0000000..8f41a8c
--- /dev/null
+++ b/data/article-metadata/kb-ai-think-article-20260807-f3dbf2cf1eea.json
@@ -0,0 +1,151 @@
+{
+  "action": "merge",
+  "ai_source_count": 0,
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-F3DBF2CF1EEA",
+  "article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-f3dbf2cf1eea.json",
+  "article_review": {
+    "accepted": true,
+    "confidence": 1,
+    "meta_content_detected": false,
+    "unsupported_claims": null,
+    "issues": null,
+    "claim_reviews": [
+      {
+        "claim": "Abweichungen vom erwarteten Normalverhalten müssen immer mit dem Asset-, Identitäts- und Change-Kontext korreliert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04092",
+          "KB-SEC-HB-04093"
+        ],
+        "reason": "Dies wird in mehreren internen Quellen (z. B. KB-SEC-HB-04092, KB-SEC-HB-04093) explizit erwähnt."
+      },
+      {
+        "claim": "Die Sicherheit von Laptops sollte risikobasiert betrachtet werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04092",
+          "KB-SEC-HB-04093"
+        ],
+        "reason": "Dies ist in mehreren internen Quellen (z. B. KB-SEC-HB-04092, KB-SEC-HB-04093) als zentrale Prämisse genannt."
+      },
+      {
+        "claim": "Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04092",
+          "KB-SEC-HB-04093"
+        ],
+        "reason": "Dies wird in mehreren internen Quellen (z. B. KB-SEC-HB-04092, KB-SEC-HB-04093) als zentrale Warnung genannt."
+      },
+      {
+        "claim": "Zutrittsereignisse, Video-/Alarmdaten, Asset-Bewegungen und Systemereignisse sollten zeitlich korreliert werden.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04092",
+          "KB-SEC-HB-04093"
+        ],
+        "reason": "Dies wird in mehreren internen Quellen (z. B. KB-SEC-HB-04092, KB-SEC-HB-04093) als zentrale Prüfungsmethode genannt."
+      },
+      {
+        "claim": "Sicherheitsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt verschlechtern.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04092",
+          "KB-SEC-HB-04093"
+        ],
+        "reason": "Dies wird in mehreren internen Quellen (z. B. KB-SEC-HB-04092, KB-SEC-HB-04093) als zentrale Sicherheitsprinzip genannt."
+      },
+      {
+        "claim": "Durchführung von Penetrationstests, um Schwachstellen zu identifizieren.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04092",
+          "KB-SEC-HB-04093"
+        ],
+        "reason": "Dies wird in mehreren internen Quellen (z. B. KB-SEC-HB-04092, KB-SEC-HB-04093) als Teil der Ergebnisprüfung genannt."
+      },
+      {
+        "claim": "Regelmäßige Überprüfung der Protokolle auf verdächtige Aktivitäten.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04092",
+          "KB-SEC-HB-04093"
+        ],
+        "reason": "Dies wird in mehreren internen Quellen (z. B. KB-SEC-HB-04092, KB-SEC-HB-04093) als Teil der Ergebnisprüfung genannt."
+      },
+      {
+        "claim": "Überprüfung der implementierten Sicherheitsmaßnahmen.",
+        "verdict": "supported",
+        "source_refs": [
+          "KB-SEC-HB-04092",
+          "KB-SEC-HB-04093"
+        ],
+        "reason": "Dies wird in mehreren internen Quellen (z. B. KB-SEC-HB-04092, KB-SEC-HB-04093) als Teil der Ergebnisprüfung genannt."
+      }
+    ]
+  },
+  "confidence": 1,
+  "generated_at": "2026-08-07T20:15:28.9913429Z",
+  "generation_depth": 1,
+  "grounded_research_evidence": [],
+  "knowledge_brief": {
+    "topic": "Laptop Physical Security – präventiv absichern und Vorfälle erkennen und nachvollziehbar untersuchen",
+    "purpose": "Die beiden Quellen 0897415cf94afb317d142820 und 2d9e5a911cf84fe73f28fea8 behandeln das Thema 'Laptop Physical Security' aus zwei verschiedenen, aber komplementären Perspektiven: präventives Absichern und Vorfälle erkennen und untersuchen. Beide Artikel sind produktiv und enthalten ähnliche Strukturen und Inhalte, wodurch sie sich gut zur Konsolidierung in einen gemeinsamen Artikel eignen. Der Zielartikel könnte eine umfassendere, strukturierte Anleitung zur Laptop Physical Security bieten, die sowohl präventive Maßnahmen als auch Reaktionsstrategien abdeckt.",
+    "scope": null,
+    "facts": null,
+    "symptoms": null,
+    "prerequisites": null,
+    "solution_steps": null,
+    "validation_steps": null,
+    "troubleshooting": null,
+    "contradictions": null,
+    "critical_gaps": null,
+    "optional_gaps": null,
+    "resolved_gaps": null,
+    "missing_information": null,
+    "research_queries": null,
+    "ready_for_article": true
+  },
+  "language": "de-DE",
+  "open_questions": null,
+  "pipeline": "adaptive_generate_review",
+  "planning": {
+    "article_type": "how_to",
+    "contradictions": [],
+    "expected_value": "Laptop Physical Security – präventiv absichern und Vorfälle erkennen und nachvollziehbar untersuchen",
+    "missing_information": [],
+    "reason": "Die beiden Quellen 0897415cf94afb317d142820 und 2d9e5a911cf84fe73f28fea8 behandeln das Thema 'Laptop Physical Security' aus zwei verschiedenen, aber komplementären Perspektiven: präventives Absichern und Vorfälle erkennen und untersuchen. Beide Artikel sind produktiv und enthalten ähnliche Strukturen und Inhalte, wodurch sie sich gut zur Konsolidierung in einen gemeinsamen Artikel eignen. Der Zielartikel könnte eine umfassendere, strukturierte Anleitung zur Laptop Physical Security bieten, die sowohl präventive Maßnahmen als auch Reaktionsstrategien abdeckt."
+  },
+  "production_ratio": 1,
+  "productive_source_count": 8,
+  "research_material": null,
+  "research_query": "",
+  "review_model": "qwen3:8b",
+  "review_repair_attempts": 0,
+  "source_fingerprint": "f3dbf2cf1eeafd2e5b9302ccf7368236a7be30fc6598340c861d726fc3c197a3",
+  "source_node_ids": [
+    "0897415cf94afb317d142820",
+    "090278ba3a950e115d046ddf",
+    "2d9e5a911cf84fe73f28fea8",
+    "3258e099ddc8ff6add7c217e",
+    "374c014539a610d809736df5",
+    "7e690d952fdd6e96a7fae1ab",
+    "b48e412d0aabd01ed1f92188",
+    "dc183279546049426c85648d"
+  ],
+  "source_nodes": [
+    "KB-SEC-HB-03592",
+    "KB-SEC-HB-03638",
+    "KB-SEC-HB-03639",
+    "KB-SEC-HB-03682",
+    "KB-SEC-HB-03686",
+    "KB-SEC-HB-03687",
+    "KB-SEC-HB-04092",
+    "KB-SEC-HB-04093"
+  ],
+  "status": "staging",
+  "subtype": "knowledge_synthesis",
+  "synthesis_model": "gemma3:12b",
+  "target_article_id": "KB-SEC-HB-04092",
+  "target_node_id": "0897415cf94afb317d142820"
+}
diff --git a/data/article-work-fingerprints/03105488f52918f1cf935ae543f627f3053434a61ff1cede2c69a004623fef71.json b/data/article-work-fingerprints/03105488f52918f1cf935ae543f627f3053434a61ff1cede2c69a004623fef71.json
new file mode 100644
index 0000000..a21107b
--- /dev/null
+++ b/data/article-work-fingerprints/03105488f52918f1cf935ae543f627f3053434a61ff1cede2c69a004623fef71.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-C35C93A5F9A6",
+  "fingerprint": "03105488f52918f1cf935ae543f627f3053434a61ff1cede2c69a004623fef71",
+  "generated_at": "2026-08-07T20:05:12.4901566Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "Ransomware Prevention \u0026 Detection"
+}
diff --git a/data/article-work-fingerprints/0b265626984776ffa4f0ca3d122f0af2ca783a2ba13b9fcb59d9ed5e0ec50b83.json b/data/article-work-fingerprints/0b265626984776ffa4f0ca3d122f0af2ca783a2ba13b9fcb59d9ed5e0ec50b83.json
new file mode 100644
index 0000000..01378dc
--- /dev/null
+++ b/data/article-work-fingerprints/0b265626984776ffa4f0ca3d122f0af2ca783a2ba13b9fcb59d9ed5e0ec50b83.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-C3D62C1DBDF5",
+  "fingerprint": "0b265626984776ffa4f0ca3d122f0af2ca783a2ba13b9fcb59d9ed5e0ec50b83",
+  "generated_at": "2026-08-07T20:13:27.5896002Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "Detection Regression Testing"
+}
diff --git a/data/article-work-fingerprints/0eef44008d66046fe6d988cf6d6f57002a37702f3c25badf6e6bbc93f695b9c8.json b/data/article-work-fingerprints/0eef44008d66046fe6d988cf6d6f57002a37702f3c25badf6e6bbc93f695b9c8.json
new file mode 100644
index 0000000..6086ac7
--- /dev/null
+++ b/data/article-work-fingerprints/0eef44008d66046fe6d988cf6d6f57002a37702f3c25badf6e6bbc93f695b9c8.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-99597DEB0603",
+  "fingerprint": "0eef44008d66046fe6d988cf6d6f57002a37702f3c25badf6e6bbc93f695b9c8",
+  "generated_at": "2026-08-07T21:23:15.7605795Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "Mobile Authentication"
+}
diff --git a/data/article-work-fingerprints/11f1a1a028cf379fdfa6deaf6faa25c68535c9d06a827b3c19086dfca6fd9aa6.json b/data/article-work-fingerprints/11f1a1a028cf379fdfa6deaf6faa25c68535c9d06a827b3c19086dfca6fd9aa6.json
new file mode 100644
index 0000000..4e7a637
--- /dev/null
+++ b/data/article-work-fingerprints/11f1a1a028cf379fdfa6deaf6faa25c68535c9d06a827b3c19086dfca6fd9aa6.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-793683D419E8",
+  "fingerprint": "11f1a1a028cf379fdfa6deaf6faa25c68535c9d06a827b3c19086dfca6fd9aa6",
+  "generated_at": "2026-08-07T20:18:38.5587701Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "Database DoS Schutz"
+}
diff --git a/data/article-work-fingerprints/15050d0f11070bb21efbc45ea389f36c90e6e0c572d3bda394b05a3cf2ddba5d.json b/data/article-work-fingerprints/15050d0f11070bb21efbc45ea389f36c90e6e0c572d3bda394b05a3cf2ddba5d.json
new file mode 100644
index 0000000..046ca21
--- /dev/null
+++ b/data/article-work-fingerprints/15050d0f11070bb21efbc45ea389f36c90e6e0c572d3bda394b05a3cf2ddba5d.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-A10D74B11B65",
+  "fingerprint": "15050d0f11070bb21efbc45ea389f36c90e6e0c572d3bda394b05a3cf2ddba5d",
+  "generated_at": "2026-08-07T20:23:20.324326Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "Prototype Pollution Schutz"
+}
diff --git a/data/article-work-fingerprints/177416e6c8d76977a2b9e8049a9b10c7bed1c2cf9e114cf6b9d10174f7608280.json b/data/article-work-fingerprints/177416e6c8d76977a2b9e8049a9b10c7bed1c2cf9e114cf6b9d10174f7608280.json
new file mode 100644
index 0000000..726f442
--- /dev/null
+++ b/data/article-work-fingerprints/177416e6c8d76977a2b9e8049a9b10c7bed1c2cf9e114cf6b9d10174f7608280.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-8508E35D3AE5",
+  "fingerprint": "177416e6c8d76977a2b9e8049a9b10c7bed1c2cf9e114cf6b9d10174f7608280",
+  "generated_at": "2026-08-07T20:17:00.3234009Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "WORM Storage"
+}
diff --git a/data/article-work-fingerprints/4f0b99b00c23aa1fd15ca54ca567fa48024b93942819dfec03032da99bb07ee0.json b/data/article-work-fingerprints/4f0b99b00c23aa1fd15ca54ca567fa48024b93942819dfec03032da99bb07ee0.json
new file mode 100644
index 0000000..1e92a6d
--- /dev/null
+++ b/data/article-work-fingerprints/4f0b99b00c23aa1fd15ca54ca567fa48024b93942819dfec03032da99bb07ee0.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-E58F8FC1D107",
+  "fingerprint": "4f0b99b00c23aa1fd15ca54ca567fa48024b93942819dfec03032da99bb07ee0",
+  "generated_at": "2026-08-07T20:06:59.8631869Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "Perfect Forward Secrecy"
+}
diff --git a/data/article-work-fingerprints/82eb2f01c24b9741cb1d8c699927efb98224b58b6d8debe62953c840de04287c.json b/data/article-work-fingerprints/82eb2f01c24b9741cb1d8c699927efb98224b58b6d8debe62953c840de04287c.json
new file mode 100644
index 0000000..2fa8bbb
--- /dev/null
+++ b/data/article-work-fingerprints/82eb2f01c24b9741cb1d8c699927efb98224b58b6d8debe62953c840de04287c.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-01B52420AF1D",
+  "fingerprint": "82eb2f01c24b9741cb1d8c699927efb98224b58b6d8debe62953c840de04287c",
+  "generated_at": "2026-08-07T20:21:46.0817085Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "Ransomware Detection \u0026 Forensics"
+}
diff --git a/data/article-work-fingerprints/8d47fa23bdc12af80261d49ff0c8e4c5aac4989f853791de2cd17644d9d33f12.json b/data/article-work-fingerprints/8d47fa23bdc12af80261d49ff0c8e4c5aac4989f853791de2cd17644d9d33f12.json
new file mode 100644
index 0000000..3dca67e
--- /dev/null
+++ b/data/article-work-fingerprints/8d47fa23bdc12af80261d49ff0c8e4c5aac4989f853791de2cd17644d9d33f12.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-732146655158",
+  "fingerprint": "8d47fa23bdc12af80261d49ff0c8e4c5aac4989f853791de2cd17644d9d33f12",
+  "generated_at": "2026-08-07T20:12:58.4712352Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "GCP Cloud Storage Security"
+}
diff --git a/data/article-work-fingerprints/91fcfc312396e2823d1fda8863e16c1b438ecf4c861f7fe91b8dc810844be84c.json b/data/article-work-fingerprints/91fcfc312396e2823d1fda8863e16c1b438ecf4c861f7fe91b8dc810844be84c.json
new file mode 100644
index 0000000..822c972
--- /dev/null
+++ b/data/article-work-fingerprints/91fcfc312396e2823d1fda8863e16c1b438ecf4c861f7fe91b8dc810844be84c.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-145EBA49D1C3",
+  "fingerprint": "91fcfc312396e2823d1fda8863e16c1b438ecf4c861f7fe91b8dc810844be84c",
+  "generated_at": "2026-08-07T20:04:21.6686259Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "Wayland/X11 Remote Access"
+}
diff --git a/data/article-work-fingerprints/a8c2e60506a9991d1915e5e2933883768b91be7fbee00796930d977c59aa4a11.json b/data/article-work-fingerprints/a8c2e60506a9991d1915e5e2933883768b91be7fbee00796930d977c59aa4a11.json
new file mode 100644
index 0000000..99bddaa
--- /dev/null
+++ b/data/article-work-fingerprints/a8c2e60506a9991d1915e5e2933883768b91be7fbee00796930d977c59aa4a11.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-C8996E21622C",
+  "fingerprint": "a8c2e60506a9991d1915e5e2933883768b91be7fbee00796930d977c59aa4a11",
+  "generated_at": "2026-08-07T20:45:10.2999808Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "Wayland/X11 Remote Access"
+}
diff --git a/data/article-work-fingerprints/bc3dc5fe4ccf1adcac270706be8431fd2ec2a6fd68ce624359ae7b076abb007e.json b/data/article-work-fingerprints/bc3dc5fe4ccf1adcac270706be8431fd2ec2a6fd68ce624359ae7b076abb007e.json
new file mode 100644
index 0000000..036dcd5
--- /dev/null
+++ b/data/article-work-fingerprints/bc3dc5fe4ccf1adcac270706be8431fd2ec2a6fd68ce624359ae7b076abb007e.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-06627CCC38AD",
+  "fingerprint": "bc3dc5fe4ccf1adcac270706be8431fd2ec2a6fd68ce624359ae7b076abb007e",
+  "generated_at": "2026-08-07T20:09:31.3063944Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "Hardware Tamper Detection"
+}
diff --git a/data/article-work-fingerprints/bce58baaeff5a436862a45cdd993a07941f485b05ceed8cd617d9904ce4c66a3.json b/data/article-work-fingerprints/bce58baaeff5a436862a45cdd993a07941f485b05ceed8cd617d9904ce4c66a3.json
new file mode 100644
index 0000000..57d7b17
--- /dev/null
+++ b/data/article-work-fingerprints/bce58baaeff5a436862a45cdd993a07941f485b05ceed8cd617d9904ce4c66a3.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-F3DBF2CF1EEA",
+  "fingerprint": "bce58baaeff5a436862a45cdd993a07941f485b05ceed8cd617d9904ce4c66a3",
+  "generated_at": "2026-08-07T20:15:28.9913429Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "Laptop Physical Security"
+}
diff --git a/data/article-work-fingerprints/c78edd2abbe1f321a26f7e87a2a84dd8f26b4c06bc2fdc0ac35184530f71eb23.json b/data/article-work-fingerprints/c78edd2abbe1f321a26f7e87a2a84dd8f26b4c06bc2fdc0ac35184530f71eb23.json
new file mode 100644
index 0000000..4042d39
--- /dev/null
+++ b/data/article-work-fingerprints/c78edd2abbe1f321a26f7e87a2a84dd8f26b4c06bc2fdc0ac35184530f71eb23.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-106596422988",
+  "fingerprint": "c78edd2abbe1f321a26f7e87a2a84dd8f26b4c06bc2fdc0ac35184530f71eb23",
+  "generated_at": "2026-08-07T20:16:16.2042441Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "Backup Repository Hardening"
+}
diff --git a/data/article-work-fingerprints/f6ef4cda56da14b31293629d0972f2f98840bfdca12a5a01ebdfecd2ee49f7d7.json b/data/article-work-fingerprints/f6ef4cda56da14b31293629d0972f2f98840bfdca12a5a01ebdfecd2ee49f7d7.json
new file mode 100644
index 0000000..d4a9ae5
--- /dev/null
+++ b/data/article-work-fingerprints/f6ef4cda56da14b31293629d0972f2f98840bfdca12a5a01ebdfecd2ee49f7d7.json
@@ -0,0 +1,8 @@
+{
+  "article_id": "KB-AI-THINK-ARTICLE-20260807-F0DDD2838242",
+  "fingerprint": "f6ef4cda56da14b31293629d0972f2f98840bfdca12a5a01ebdfecd2ee49f7d7",
+  "generated_at": "2026-08-07T20:07:27.2255286Z",
+  "relation_type": "same_topic",
+  "schema": "article-work-fingerprint/v1",
+  "topic_label": "Triple Extortion Risiko"
+}
diff --git a/data/graph.db b/data/graph.db
index c9c054e..758051d 100644
Binary files a/data/graph.db and b/data/graph.db differ
diff --git a/data/graph.db-shm b/data/graph.db-shm
new file mode 100644
index 0000000..62e7678
Binary files /dev/null and b/data/graph.db-shm differ
diff --git a/data/graph.db-wal b/data/graph.db-wal
new file mode 100644
index 0000000..f9cc189
Binary files /dev/null and b/data/graph.db-wal differ
diff --git a/data/research-evidence/0c0c7750b2ad51634096c25f.json b/data/research-evidence/0c0c7750b2ad51634096c25f.json
new file mode 100644
index 0000000..24f6c90
--- /dev/null
+++ b/data/research-evidence/0c0c7750b2ad51634096c25f.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:12:27.6797822Z",
+  "content_sha256": "3ea0e71a40f56c07fd1532f40b10422cbe3a979635ab34e8e40989c42a681f5d",
+  "result": {
+    "title": "Google Cloud Storage Security Best Practices | Google Cloud Storage | SystemsArchitect | SystemsArchitect.io",
+    "url": "https://www.systemsarchitect.io/services/gcp-storage/security-best-practices",
+    "snippet": "Adhere to AWS best practices by enforcing security controls, using least privilege principles, and implementing defense in depth. Regularly audit configurations and use AWS tools to identify and address potential security vulnerabilities.",
+    "content": "Choose a service...\nCreate Project\n\nChoose a service...\n\nBack to sections\nGoogle Cloud Storage :\n\nGoogle Cloud Storage Security Best Practices\n\n15 best practices\n\nAdhere to AWS best practices by enforcing security controls, using least privilege principles, and implementing defense in depth. Regularly audit configurations and use AWS tools to identify and address potential security vulnerabilities.\n\nFilter:\n\nAll Saved Unsaved\n\nGrid\nList Expanded Compact\n\nImplement Uniform Bucket-Level Access (UBLA)\n\nEnable uniform bucket-level access to enforce consistent IAM policies across all objects in a bucket, disabling legacy ACLs. This simplifies permission management and reduces security risks from mixed access control models. UBLA ensures that only IAM policies control access, making auditing and compliance significantly easier.\n\nJS PY TF\n\nEnable Default Encryption with Customer-Managed Keys (CMEK)\n\nConfigure Cloud KMS customer-managed encryption keys for Cloud Storage buckets to maintain control over encryption key lifecycle and access. This provides an additional layer of security beyond Google's default encryption and meets compliance requirements for key management. CMEK allows you to rotate, disable, or destroy keys independently of Google's infrastructure.\n\nJS PY TF\n\nApply Principle of Least Privilege with Predefined Roles\n\nUse Cloud Storage predefined roles like Storage Object Viewer, Storage Object Creator, and Storage Object Admin instead of primitive roles to grant minimal necessary permissions. This reduces the attack surface by ensuring users and service accounts only have access to specific operations they need. Avoid using overly permissive roles like Storage Admin or Owner unless absolutely required.\n\nJS PY TF\n\nConfigure Object Lifecycle Policies for Automatic Data Deletion\n\nImplement lifecycle management policies to automatically delete or transition sensitive data after retention periods expire, reducing exposure window. This ensures compliance with data retention regulations and minimizes the risk of unauthorized access to stale data. Lifecycle policies also help manage storage costs while maintaining security posture.\n\nJS PY TF\n\nEnable Cloud Audit Logs for Comprehensive Monitoring\n\nActivate Admin Activity, Data Access, and System Event audit logs to track all Cloud Storage operations and access patterns. These logs integrate with Cloud Logging and can be analyzed for suspicious activities, compliance audits, and forensic investigations. Data Access logs are critical for detecting unauthorized object access attempts and insider threats.\n\nJS PY TF\n\nImplement VPC Service Controls for Network Perimeter Security\n\nCreate service perimeters using VPC Service Controls to prevent data exfiltration from Cloud Storage buckets to unauthorized networks or projects. This establishes a security boundary that restricts where data can be accessed from, even if IAM permissions are compromised. VPC Service Controls provide defense-in-depth protection for sensitive storage resources.\n\nJS PY TF\n\nUse Signed URLs and Signed Policy Documents for Temporary Access\n\nGenerate time-limited signed URLs or signed policy documents instead of granting permanent IAM permissions for temporary access scenarios. This approach limits the window of vulnerability and ensures access automatically expires without manual intervention. Signed URLs are particularly useful for sharing objects with external parties or untrusted clients.\n\nJS PY TF\n\nEnable Bucket Lock and Retention Policies for Immutability\n\nConfigure retention policies and bucket locks to make objects immutable for specified periods, protecting against accidental deletion or malicious tampering. This is essential for regulatory compliance (WORM requirements) and maintaining data integrity for legal or audit purposes. Locked retention policies cannot be reduced or removed, ensuring permanent protection.\n\nJS PY TF\n\nImplement Object Versioning for Data Recovery and Audit Trail\n\nEnable object versioning to maintain historical copies of objects, allowing recovery from accidental overwrites or deletions. Versioning provides an audit trail of changes and protects against ransomware attacks that attempt to encrypt or delete data. Combine versioning with lifecycle policies to manage storage costs of older versions.\n\nJS PY TF\n\nRestrict Public Access with Organization Policies\n\nUse organization policy constraints like 'storage.publicAccessPrevention' to block public access at the organization or project level, preventing accidental exposure. This enforces security by default and overrides individual bucket or object ACLs that might grant public access. Organization policies provide centralized governance across all Cloud Storage resources.\n\nJS PY TF\n\nConfigure CORS Policies Restrictively\n\nDefine Cross-Origin Resource Sharing (CORS) policies with specific allowed origins, methods, and headers rather than using wildcards. Overly permissive CORS configurations can enable cross-site attacks and unauthorized data access from malicious websites. Regularly review and update CORS policies to match current application requirements.\n\nJS PY TF\n\nUse Service Account Keys Securely with Workload Identity\n\nLeverage Workload Identity Federation to eliminate long-lived service account keys when accessing Cloud Storage from GKE or external systems. This reduces the risk of key compromise and simplifies credential rotation. When service account keys are necessary, implement automatic rotation, secure storage in Secret Manager, and strict access controls.\n\nJS PY TF\n\nEnable Security Command Center for Threat Detection\n\nIntegrate Cloud Storage with Security Command Center to automatically detect misconfigurations, public buckets, and security vulnerabilities. SCC provides centralized visibility into security findings and compliance violations across all storage resources. Configure automatic remediation workflows or alerts for critical security issues like publicly accessible buckets.\n\nJS PY TF\n\nImplement Bucket and Object Labels for Access Control Automation\n\nApply consistent labels to buckets and objects to enable automated security policies, cost tracking, and conditional IAM bindings. Labels facilitate dynamic access control based on data classification (e.g., confidential, public, PII) and support automated compliance checks. Use labels with Cloud Asset Inventory for comprehensive resource governance.\n\nJS PY TF\n\nConfigure Requester Pays to Control Data Egress\n\nEnable Requester Pays on buckets containing sensitive data to ensure that data requesters bear egress costs and authenticate with valid projects. This prevents anonymous access and provides an additional authentication layer, as requesters must have valid billing accounts. Requester Pays also helps detect and prevent unauthorized bulk data downloads.\n\nJS PY TF\n\nSecurity hardening techniques and practices to protect against threats and vulnerabilities. Includes access control, encryption, audit logging, and compliance with security standards.\n\nGoogle Cloud Storage :",
+    "content_type": "text/html",
+    "query": "GCP Cloud Storage Security – härten und sicher betreiben current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.42,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/0dc36bd3bee2e2dd60e5a974.json b/data/research-evidence/0dc36bd3bee2e2dd60e5a974.json
new file mode 100644
index 0000000..6dbafd1
--- /dev/null
+++ b/data/research-evidence/0dc36bd3bee2e2dd60e5a974.json
@@ -0,0 +1,25 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:22:07.5398453Z",
+  "content_sha256": "635c3b642ebe68ba5b0c0bf37ad4e9136e04a4adfdf46a1482371fecfbaa1e56",
+  "result": {
+    "title": "Testing for client-side prototype pollution - PortSwigger",
+    "url": "https://portswigger.net/burp/documentation/desktop/tools/dom-invader/prototype-pollution",
+    "snippet": "Once you enable prototype pollution, DOM Invader automatically checks the page for sources that enable you to add arbitrary properties to the Object.prototype. Any sources it identifies are displayed in the DOM view, along with some useful information and features for further testing.",
+    "content": "Support Center\n\nDocumentation\n\nDesktop editions\n\nTools\n\nDOM Invader\n\nTesting for client-side prototype pollution\n\nProfessional Community Edition\n\nTesting for client-side prototype pollution\n\nLast updated:\nAugust 3, 2026\n\nRead time:\n3 Minutes\n\nDOM Invader provides a number of features to help you test for client-side prototype pollution vulnerabilities. These enable you to perform the following key tasks:\n\nAutomatically detect sources for prototype pollution in the URL and any JSON objects sent via web messages. This includes detecting alternative techniques using the same source.\n\nGenerate a proof of concept by polluting the Object.prototype using any discovered sources. You can then manually verify the vulnerability via the browser console.\n\nScan for potential gadgets that you can use to craft an exploit.\n\nEnabling prototype pollution\n\nTo avoid interfering with your target site's functionality, DOM Invader's prototype pollution features are disabled by default. To enable these features:\n\nGo to the DOM Invader settings menu.\n\nUnder Attack types , toggle the switch so that Prototype pollution is on .\n\nClick Reload to refresh the browser. This is necessary for your changes to take effect.\n\nDOM Invader now scans for prototype pollution sources as you browse.\n\nDetecting sources for prototype pollution\n\nOnce you enable prototype pollution, DOM Invader automatically checks the page for sources that enable you to add arbitrary properties to the Object.prototype . Any sources it identifies are displayed in the DOM view, along with some useful information and features for further testing.\n\nIn this example, DOM Invader has identified two potential techniques for polluting the Object.prototype using the location.hash source.\n\nManually confirming sources for prototype pollution\n\nOnce DOM Invader has identified a potential source for prototype pollution, it also helps you to manually confirm this.\n\nTo manually test whether prototype pollution is possible via this source:\n\nFrom the DOM view, click the Test button next to the relevant source. DOM Invader opens a new tab in which it uses the selected source to add an arbitrary property to the Object.prototype .\n\nIn the new tab, go to the browser console. Note that DOM Invader has automatically output the Object.prototype .\n\nExpand the nodes to confirm that this object contains a proof-of-concept testproperty .\n\nIn the console, create a new object:\n\nlet myObject = {};\n\nConfirm that your new object has inherited testproperty via the prototype chain:\n\nconsole.log(myObject.testproperty);\n// Output: 'DOM_INVADER_PP_POC'\n\nScanning for prototype pollution gadgets\n\nA prototype pollution source is of no use unless you also have access to a \"gadget\" property. This is any user-controllable property that is passed to a sink without being properly sanitized. Finding such a gadget manually is extremely tedious, but DOM Invader can automate this process.\n\nTo scan for gadgets using a particular source:\n\nFrom the DOM view, click the Scan for gadgets button next to any prototype pollution source that DOM Invader has found. DOM Invader opens a new tab and starts scanning for suitable gadgets.\n\nIn the same tab, open the DOM Invader tab in the DevTools panel. Once the scan is finished, the DOM view displays any sinks that DOM Invader was able to access via the identified gadgets. In the example below, a gadget property called html was passed to the innerHTML sink.\n\nGenerating a proof-of-concept exploit\n\nOnce DOM Invader finds a gadget for prototype pollution, it is able to automatically generate a proof-of-concept by combining the source, gadget, and sink to confirm the XSS.\n\nSimply click the Exploit button next to the discovered sink. DOM Invader opens a new window in which it successfully calls alert() .\n\nRead more\n\nDOM Invader is highly configurable. For more information about DOM Invader's prototype pollution features and how you can fine-tune their behavior for a particular site, see Prototype pollution settings .",
+    "content_type": "text/html",
+    "query": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "primary",
+    "source_quality_score": 0.88,
+    "actionable": true,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/18a9a0b94d440da2f9b68123.json b/data/research-evidence/18a9a0b94d440da2f9b68123.json
new file mode 100644
index 0000000..6e0235f
--- /dev/null
+++ b/data/research-evidence/18a9a0b94d440da2f9b68123.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:03:30.6925998Z",
+  "content_sha256": "8b1811b34207121f99351574ae5696eec639b93ec8eceb99c967de1dc1d53bc0",
+  "result": {
+    "title": "2019\n\n- media.ccc.de",
+    "url": "https://media.ccc.de/tags/2019",
+    "snippet": "X11 and Wayland: A tale of two implementations · All about computers ChaosWest ... How to host and access STAC Imagery using Google's gRPC Remote Procedure Call ...",
+    "content": "Events for tag \"2019\"\n\n6 min\n\nNeopardy-Engine\n\n6 min\n\n2019-10-06\n\n35\n\nMoritz and\nHendrik\n\nJugend hackt 2019\n\n26 min\n\nCyclOSM, a bicycle oriented render for every cyclist\n\nCartography\nStateoftheMap\n\n26 min\n\n2019-09-21\n\n356\n\nFlorimond Berthoux and\nLucas Verney\n\nState of the Map 2019\n\n59 min\n\nDigitale Agenda Wien - Möglichkeitsräume einer Stadt\n\n59 min\n\n2019-10-23\n\n72\n\nUlrike Huemer\n\nPrivacyWeek 2019\n\n58 min\n\nWas ist Zeit?\n\nScience\nOpenInfrastructureOrbit\n\n58 min\n\n2019-12-28\n\n27.2k\n\nSteini\n\n36C3: Resource Exhaustion\n\n44 min\n\nWhy Nobody cares, and only You can save the World\n\nTechnology, Intuitions \u0026 Moral Expertise\n\nEthics, Society \u0026 Politics\n\n44 min\n\n2019-08-25\n\n291\n\nWilhelm Klein\n\nChaos Communication Camp 2019\n\n90 min\n\nProperty-based Testing [Softwerkskammer]\n\naugenpruefraumswkhl\n\n90 min\n\n2019-03-17\n\n79\n\nDaniel Bimschas\n\nChaotikum\n\n13 min\n\nClosing Ceremony\n\nCCC\nMain\n\n13 min\n\n2019-12-30\n\n2.9k\n\nbleeptrack and\nblinry\n\n36C3: Resource Exhaustion\n\n60 min\n\nKatastrophe und Kommunikation am Beispiel Nord-Ost-Syrien\n\nHumanitäre Hilfe zwischen Propaganda, Information und…\n\nEthics, Society \u0026 Politics\nMain\n\n60 min\n\n2019-12-27\n\n2.4k\n\nRuben Neugebauer and\nSebastian Jünemann\n\n36C3: Resource Exhaustion\n\n42 min\n\nDas Rechenwerk und die Arithmetik der Z1\n\n42 min\n\n2019-10-12\n\n194\n\nKlemens Krause\n\nVintage Computing Festival Berlin 2019\n\n15 min\n\nLightning Talk: Usability\n\n15 min\n\n2019-11-02\n\n29\n\nJohanna\n\nJugend hackt 2019\n\n5 min\n\nPointclouds für OSM\n\nGeo\nOpenStreeetMap\n\n5 min\n\n2019-03-13\n\n178\n\nTim Alder\n\nFOSSGIS 2019\n\n87 min\n\nEsperanto: Wie funktioniert eine Plansprache?\n\nTalks\n\n87 min\n\n2019-10-05\n\n437\n\nsven\n\nHackumenta 2019\n\n43 min\n\nKlarnamenpflicht, Oida?!\n\n43 min\n\n2019-10-24\n\n339\n\npascoda\n\nPrivacyWeek 2019\n\n25 min\n\nBringing Validation to Users: Integrating Quality Assurance Checks into Map Editors\n\nSoftware Development\nStateoftheMap\n\n25 min\n\n2019-09-22\n\n43\n\nMatthew Gibb and\nClarisse Abalos\n\nState of the Map 2019\n\n9 min\n\n400G and beyond\n\n9 min\n\n2019-11-12\n\n230\n\nFlorian Hibler\n\nDENOG11\n\n32 min\n\nLatest Developments in SPRING (Segment Routing)\n\n32 min\n\n2019-11-12\n\n77\n\nSebastian Graf\n\nDENOG11\n\n22 min\n\nDemystifying AI in Geo\n\nGeneral\n\n22 min\n\n2019-08-29\n\n191\n\nAndrew Chapkowski\n\nFOSS4G 2019\n\n27 min\n\nQuo Vadis Open Data – Geoportale von Bund und Ländern auf dem Prüfstein\n\nGeo\nOpenStreeetMap\n\n27 min\n\n2019-03-14\n\n231\n\nAndreas Krumtung\n\nFOSSGIS 2019\n\n11 min\n\nBegrüßung\n\n11 min\n\n2019-09-29\n\n22\n\nJeanne and\nAnna\n\nJugend hackt 2019\n\n28 min\n\nWriting Ansible Modules\n\n28 min\n\n2019-11-11\n\n827\n\nMartin Schütte\n\nDENOG11\n\n91 min\n\nDigitale Kompetenzen vermitteln\n\n91 min\n\n2019-10-21\n\n145\n\nChristian Swertz ,\nKlaudia Zotzmann-Koch and\nKatharina Larisch\n\nPrivacyWeek 2019\n\n36 min\n\nVisualization of networks using physics\n\nHow algorithms inspired by the laws of physics can create…\n\nScience\n\n36 min\n\n2019-08-25\n\n252\n\naphotic\n\nChaos Communication Camp 2019\n\n5 min\n\nSave Your City - Technik\n\n5 min\n\n2019-09-01\n\n14\n\nConrad ,\nHannah ,\nJulian ,\nMitja ,\nMoritz J and\nPhilip\n\nJugend hackt 2019\n\n58 min\n\nDrogen und Verkehrssicherheit\n\n58 min\n\n2019-06-27\n\n321\n\nTheo Pütz\n\nFusion ConTent 2019\n\n5 min\n\nMalte über buntes Licht [Fünf-Minuten-Termine]\n\n5 min\n\n2019-08-28\n\n102\n\nMalte\n\nChaotikum\n\n45 min\n\nWikidata/Commons contribution strategies for GLAM organizations\n\n45 min\n\n2019-10-25\n\n120\n\nAndrew Lih\n\nWikidataCon 2019\n\n26 min\n\nNew usages of Wikidata to support underserved language communities\n\n26 min\n\n2019-10-25\n\n37\n\nLucie-Aimée Kaffee\n\nWikidataCon 2019\n\n25 min\n\nSum of All video games − 2019 edition\n\n25 min\n\n2019-10-26\n\n124\n\nJean-Frédéric Berthelot ,\nTracy Hoffmann and\nEnvel Le Hir\n\nWikidataCon 2019\n\n62 min\n\nReichlich Randale – Der feministische Jahresrückblick\n\nDLF- und Podcast-Bühne\nSendezentrum\n\n62 min\n\n2019-12-28\n\n1.1k\n\nBecci (@genderbeitrag)\n\n36C3: Resource Exhaustion\n\n30 min\n\nPast and Future of the OSMF Membership Working Group\n\nCommunity and Foundation\nStateoftheMap\n\n30 min\n\n2019-09-21\n\n16\n\nMichael Spreng\n\nState of the Map 2019\n\n24 min\n\nGeospatial data processing for image automatic analysis\n\nGeneral\n\n24 min\n\n2019-08-29\n\n133\n\nRaphaël Delhome\n\nFOSS4G 2019\n\n29 min\n\nCNN-based tools in GRASS GIS\n\nGeneral\n\n29 min\n\n2019-08-29\n\n341\n\nOndřej Pešek and\nMartin Landa\n\nFOSS4G 2019\n\n58 min\n\nHack_Curio\n\nDecoding The Cultures of Hacking One Video at a Time\n\nArt \u0026 Culture\nMain\n\n58 min\n\n2019-12-27\n\n4.0k\n\nGabriella \"Biella\" Coleman and\nPaula Bialski\n\n36C3: Resource Exhaustion\n\n63 min\n\nScience for future?\n\nWhat we can and need to change to keep climate change low -…\n\nScience\nMain\n\n63 min\n\n2019-12-27\n\n11.1k\n\nBernhard Stoevesandt\n\n36C3: Resource Exhaustion\n\n4 min\n\nWas sollen diese komischen Adress-Codes?\n\nGeo\nOpenStreeetMap\n\n4 min\n\n2019-03-13\n\n272\n\nChristian Mayer\n\nFOSSGIS 2019\n\n40 min\n\nDas Mauern muss weg\n\nBest of Informationsfreiheit\n\nEthics, Society \u0026 Politics\nMain\n\n40 min\n\n2019-12-30\n\n8.9k\n\nArne Semsrott\n\n36C3: Resource Exhaustion\n\n35 min\n\nDie Schickard'sche Rechenmaschine\n\nEin Nachbau zum Anfassen\n\n35 min\n\n2019-10-12\n\n194\n\nJürgen Weigert\n\nVintage Computing Festival Berlin 2019\n\n27 min\n\nMapping the Fate of the Dead in North Korea with Free \u0026 Open Source Software and Data\n\nGeneral\n\n27 min\n\n2019-08-29\n\n79\n\nDan Bielefeld\n\nFOSS4G 2019\n\n27 min\n\nCustomizing Search for Special-Interest Maps\n\nSoftware Development\nStateoftheMap\n\n27 min\n\n2019-09-22\n\n35\n\nSarah Hoffmann\n\nState of the Map 2019\n\n53 min\n\nCryptography demystified\n\nAn introduction without maths\n\nSecurity\nMain\n\n53 min\n\n2019-12-29\n\n3.4k\n\noots\n\n36C3: Resource Exhaustion\n\n40 min\n\nPsychedelic Medicine - Hacking Psychiatry?!\n\nPsychedelic Therapy as a fundamentally new approach to…\n\nScience\nMain\n\n40 min\n\n2019-12-28\n\n2.2k\n\nAndrea Jungaberle\n\n36C3: Resource Exhaustion\n\n10 min\n\nClimate Escape Room\n\n10 min\n\n2019-11-03\n\n100\n\nPeter ,\nLena ,\nLeia ,\nLena ,\nNoah ,\nLena ,\nDietke ,\nMilena ,\nFloriane ,\nPaul and\nNoella\n\nJugend hackt 2019\n\n91 min\n\nDG104: card10 - Das Chaos Communication Camp 2019 Badge\n\nVon Idee bis Zukunft\n\n91 min\n\n2019-11-12\n\n685\n\nSchneider\n\nCCCB Datengarten\n\n26 min\n\nDestination Unknown: Design Dimensions of Open Source Travel Mapping Tools\n\nGeneral\n\n26 min\n\n2019-08-29\n\n25\n\nBrookelynn C\n\nFOSS4G 2019\n\n8 min\n\n(G)EO hackathon: engaging indigenous communities\n\nGeneral\n\n8 min\n\n2019-08-30\n\n20\n\nDiana Mastracci\n\nFOSS4G 2019\n\n20 min\n\nState of MapServer\n\nGeneral\n\n20 min\n\n2019-08-28\n\n153\n\nSeth Girvin ,\nDaniel Morissette and\nMichael Smith\n\nFOSS4G 2019\n\n50 min\n\nCheating AI - Wenn Menschen die KI hacken\n\n50 min\n\n2019-09-14\n\n649\n\nNana and\nBenjamin\n\nMRMCD 2019 - Gesellschaftsspiele\n\n25 min\n\nDas OSM-Wiki – die eierlegende Wollmilchsau der Community\n\nGeo\nOpenStreeetMap\n\n25 min\n\n2019-03-15\n\n82\n\nHanna Krüger\n\nFOSSGIS 2019\n\n34 min\n\nTrivial UX - Does my unicorn have the perfect UI?\n\n34 min\n\n2019-09-14\n\n106\n\nheavy\n\nMRMCD 2019 - Gesellschaftsspiele\n\n42 min\n\nKI-Basierte Modifikation von Videostreams aus Überwachungskameras\n\neh19\neasterhegg\n\n42 min\n\n2019-04-19\n\n480\n\nAlexander Aigner ,\nHarald Lampesberger ,\nEckehard Hermann and\nRene Zeller\n\nEasterhegg 2019\n\n54 min\n\nAnonymität nach Tor\n\neh19\neasterhegg\n\n54 min\n\n2019-04-19\n\n2.2k\n\nmo\n\nEasterhegg 2019\n\n38 min\n\nAll wireless communication stacks are equally broken\n\nSecurity\nMain\n\n38 min\n\n2019-12-28\n\n9.7k\n\njiska\n\n36C3: Resource Exhaustion\n\n91 min\n\nWhat the World can learn from Hongkong\n\nFrom Unanimity to Anonymity\n\nEthics, Society \u0026 Politics\nMain\n\n91 min\n\n2019-12-27\n\n27.2k\n\nKatharin Tai\n\n36C3: Resource Exhaustion\n\n11 min\n\nMicrocode updates as protection against Spectre \u0026 Co.\n\n11 min\n\n2019-11-11\n\n101\n\nWerner Fischer\n\nDENOG11\n\n23 min\n\nPolitik und OpenSource \"Brettspiele\"\n\n23 min\n\n2019-09-15\n\n93\n\nJohannes Formann\n\nMRMCD 2019 - Gesellschaftsspiele\n\n24 min\n\nData Science with OpenStreetMap and Wikidata\n\nGeneral\n\n24 min\n\n2019-08-29\n\n383\n\nNikolai Janakiev\n\nFOSS4G 2019\n\n24 min\n\nState of the QGIS project\n\nGeneral\n\n24 min\n\n2019-08-28\n\n128\n\nAndreas Neumann\n\nFOSS4G 2019\n\n24 min\n\nStructuring GLAM-Wiki initiatives with Wikidata\n\n24 min\n\n2019-10-26\n\n51\n\nJoão Alexandre Peschanski\n\nWikidataCon 2019\n\n49 min\n\nA dozen more things you didn't know Nextcloud could do\n\nHardware \u0026 Making\nOpenInfrastructureOrbit\n\n49 min\n\n2019-12-28\n\n3.9k\n\nJos Poortvliet\n\n36C3: Resource Exhaustion\n\n16 min\n\nCooking with PostGIS\n\nGeneral\n\n16 min\n\n2019-08-30\n\n147\n\nRhys\n\nFOSS4G 2019\n\n12 min\n\nPivoting to Monetize Mobile Hyperlocal Gamification in the Cloud.. on the Blockchain\n\nKeynote\n\n12 min\n\n2019-08-30\n\n115\n\nSchuyler Erle\n\nFOSS4G 2019\n\n22 min\n\nState of GeoExt\n\nGeneral\n\n22 min\n\n2019-08-28\n\n170\n\nSeth Girvin ,\nChristian Mayer and\nMarc Jansen\n\nFOSS4G 2019\n\n43 min\n\nGeschichten aus der COBOL-Gruft\n\neh19\neasterhegg\n\n43 min\n\n2019-04-19\n\n539\n\nHabrok\n\nEasterhegg 2019\n\n51 min\n\n\"Unvorstellbare Einzelfälle\" und \"neue Phänomene\"? - Kontinuitäten des rechten Terrors\n\nAntifaschismus\nChaosWest\n\n51 min\n\n2019-12-27\n\n2.0k\n\nCaro Keller\n\n36C3: Resource Exhaustion\n\n63 min\n\nDas nützlich-unbedenklich Spektrum\n\nKönnen wir Software bauen, die nützlich /und/ unbedenklich…\n\nSecurity\nMain\n\n63 min\n\n2019-12-28\n\n16.7k\n\nFefe\n\n36C3: Resource Exhaustion\n\n3 min\n\nAndre über Repair Lab [Fünf-Minuten-Termine]\n\n3 min\n\n2019-11-27\n\n226\n\nAndre\n\nChaotikum\n\n20 min\n\nTachy2GIS – mit der Totalstation zeichnen\n\nGeo\nOpenStreeetMap\n\n20 min\n\n2019-03-14\n\n307\n\nChristian Trapp\n\nFOSSGIS 2019\n\n15 min\n\nDevelopment and testing with lrun\n\n15 min\n\n2019-09-21\n\n59\n\nMarcel Holtmann\n\nAll Systems Go! 2019\n\n74 min\n\nBoard + Working Groups meeting\n\nCommunity and Foundation\nStateoftheMap\n\n74 min\n\n2019-09-21\n\n18\n\nJoost Schouppe\n\nState of the Map 2019\n\n37 min\n\nAufstand oder Aussterben\n\nUmfang des Klimawandels und daraus resultierender…\n\n37 min\n\n2019-11-08\n\n49\n\nJonna Schulz-Ehlbeck ,\nDaniel Fischer and\nMario Dodier\n\nMetaNook 2019\n\n38 min\n\nGerechtigkeit 4.0\n\nMakroökonomische Auswirkungen der Digitalisierung auf den…\n\nEthics, Society \u0026 Politics\nMain\n\n38 min\n\n2019-12-30\n\n738\n\nSven Hilbig\n\n36C3: Resource Exhaustion\n\n23 min\n\nObserve - offline, cross-platform field mapping tool for OpenStreetMap\n\nMapping\nStateoftheMap\n\n23 min\n\n2019-09-21\n\n63\n\nSajjad Anwar\n\nState of the Map 2019\n\n31 min\n\nPluggable Transports basierte Zensurumgehung\n\n31 min\n\n2019-10-22\n\n54\n\nMichael Pöhn\n\nPrivacyWeek 2019\n\n26 min\n\nOMERO: an open source tool for a cross-disciplinary geospatial Odyssey\n\nGeneral\n\n26 min\n\n2019-08-30\n\n64\n\niLaria Marengo\n\nFOSS4G 2019\n\n25 min\n\nKia ora - The Learnings of FOSS4G SotM Oceania\n\nGeneral\n\n25 min\n\n2019-08-30\n\n22\n\nEdoardo Neerhut\n\nFOSS4G 2019\n\n35 min\n\nRootless, Reproducible \u0026 Hermetic: Secure Container Build Showdown\n\n35 min\n\n2019-09-20\n\n312\n\nAndrew Martin\n\nAll Systems Go! 2019\n\n10 min\n\nWarum Software-Barrierefreiheit wichtig ist - für uns alle!\n\n10 min\n\n2019-10-05\n\n94\n\nnwng\n\nJugend hackt 2019\n\n4 min\n\nNatascha über Keep Talking and Nobody Explodes [Fünf-Minuten-Termine]\n\n4 min\n\n2019-11-27\n\n214\n\nNatascha\n\nChaotikum\n\n42 min\n\nMehr als ein Hobby?\n\nDeutschsprachige Podcaster*innen im Fokus psychologischer…\n\nDLF- und Podcast-Bühne\nSendezentrum\n\n42 min\n\n2019-12-27\n\n1.1k\n\nChristiane Attig\n\n36C3: Resource Exhaustion\n\n26 min\n\nDie Militarisierung der Festung Europa und wie europäische Rüstungskonzerne daran…\n\nMilitär\n\n26 min\n\n2019-11-23\n\n101\n\nMatthias Monroy (Wissensarbeiter and\nAktivist und Mitglied der Redaktion der Zeitschrift Bürgerrechte \u0026 Polizei/CILIP)\n\nFIfFKon 2019\n\n4 min\n\nSource Exchange\n\n4 min\n\n2019-09-01\n\n13\n\nAngelina ,\nHendrik ,\nJulius ,\nLuke and\nMoritz F\n\nJugend hackt 2019\n\n3 min\n\nSave Your City - Design\n\n3 min\n\n2019-09-01\n\n11\n\nAlex ,\nFinn ,\nJohannes K ,\nOscar and\nVahag\n\nJugend hackt 2019\n\n40 min\n\nWie funktionieren SAT-Solver?\n\nEin Einblick in die Implementierung eines SAT-Solvers\n\n40 min\n\n2019-11-09\n\n91\n\nJannis Harder\n\nMetaNook 2019\n\n4 min\n\nBegrüßung\n\n4 min\n\n2019-09-01\n\nAlpaka Management\n\nJugend hackt 2019\n\n27 min\n\nRouting for humans\n\nSoftware Development\nStateoftheMap\n\n27 min\n\n2019-09-23\n\n147\n\nSebastian Ritterbusch\n\nState of the Map 2019\n\n41 min\n\nAngewandter Datenschutz\n\nDatenspuren\n\n41 min\n\n2019-09-21\n\n338\n\nMartin Christian\n\nDatenspuren 2019\n\n27 min\n\niwd - State of the union\n\n27 min\n\n2019-09-21\n\n502\n\nMarcel Holtmann\n\nAll Systems Go! 2019\n\n33 min\n\nOpen Source Product Development: from research to release\n\n33 min\n\n2019-05-18\n\n29\n\nSam Tuke\n\nOpen Source Conference Albania 2019\n\n58 min\n\nThe Large Hadron Collider Infrastructure Talk\n\nScience\nMain\n\n58 min\n\n2019-12-27\n\n3.6k\n\nsev and\nthasti\n\n36C3: Resource Exhaustion\n\n22 min\n\n“Computer says no”: Worüber sollen Algorithmen entscheiden dürfen\n\nEthics, Society \u0026 Politics\nOpenInfrastructureOrbit\n\n22 min\n\n2019-12-28\n\n1.2k\n\nsegal and\nChris Köver\n\n36C3: Resource Exhaustion\n\n29 min\n\nKeynote: Einblicke vom Bazaar des QGIS-Projekts\n\nGeo\nOpenStreeetMap\n\n29 min\n\n2019-03-15\n\n100\n\nAnita Graser\n\nFOSSGIS 2019\n\n24 min\n\nVergleich und Benchmark der Generierung von Karten-Vektorkacheln via MapServer versus…\n\nGeo\nOpenStreeetMap\n\n24 min\n\n2019-03-15\n\n134\n\nKarsten Vennemann and\nPirmin Kalberer\n\nFOSSGIS 2019\n\n51 min\n\nTechnische Kompetenzen vermitteln - nur wie?\n\nThe real basic about Bits and Nibbles\nChaosWest\n\n51 min\n\n2019-12-30\n\n1.6k\n\njinxx\n\n36C3: Resource Exhaustion\n\n51 min\n\nBuild and fly your own rockets in Kerbal Space Program\n\nScience\nOpenInfrastructureOrbit\n\n51 min\n\n2019-12-29\n\n487\n\nKilian Schauer and\nLuca Horn\n\n36C3: Resource Exhaustion\n\n36 min\n\nRC-Cars in XXXL\n\n36 min\n\n2019-09-14\n\n283\n\nJohannes Formann\n\nMRMCD 2019 - Gesellschaftsspiele\n\n27 min\n\nLightning Talks VI\n\nGeneral\nStateoftheMap\n\n27 min\n\n2019-09-23\n\n45\n\nVarious Speakers\n\nState of the Map 2019\n\n24 min\n\nQGIS-Projektgenerator – vom Datenmodell zur Erfassung\n\nGeo\nOpenStreeetMap\n\n24 min\n\n2019-03-13\n\n248\n\nMatthias Kuhn\n\nFOSSGIS 2019\n\n27 min\n\nBattle of 3D Rendering Stacks: CesiumJS, VTS Geospatial or iTowns?\n\nGeneral\n\n27 min\n\n2019-08-29\n\n291\n\nLadislav Horký\n\nFOSS4G 2019\n\n49 min\n\nE-Mail Infrastruktur\n\nEinen Mailserver ohne legacy IP betreiben\n\n49 min\n\n2019-11-09\n\n395\n\nj.ohny.b\n\nMetaNook 2019\n\n7 min\n\nEröffnungsveranstaltung\n\n7 min\n\n2019-10-12\n\n64\n\nEva Kudrass and\nDr. Stefan Höltgen\n\nVintage Computing Festival Berlin 2019\n\n5 min\n\nFabi über die Methusalem-Maus [Fünf-Minuten-Termine]\n\n5 min\n\n2019-02-13\n\n79\n\nFabi\n\nChaotikum\n\n61 min\n\nMessenger Hacking: Remotely Compromising an iPhone through iMessage\n\nSe",
+    "content_type": "text/html",
+    "query": "Wayland/X11 Remote Access – forensisch prüfen aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.48363636363636364,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/200b76b6a019ff829cdd6262.json b/data/research-evidence/200b76b6a019ff829cdd6262.json
new file mode 100644
index 0000000..d8ceb8e
--- /dev/null
+++ b/data/research-evidence/200b76b6a019ff829cdd6262.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:44:09.650799Z",
+  "content_sha256": "01c855ce0ae8eff1d8dae64090b124c56c52bbd344de35839cdc035748456482",
+  "result": {
+    "title": "How do I setup a remote access solution in Wayland? - Fedora Discussion",
+    "url": "https://discussion.fedoraproject.org/t/how-do-i-setup-a-remote-access-solution-in-wayland/121232",
+    "snippet": "I'll setup a remote desktop solution with one of the X + VNC solutions (TigerVNC seems venerable) to see what it offers, though probably on Alma Linux/Rocky Linux in case X disappears suddenly from Fedora's repositories.",
+    "content": "How do I setup a remote access solution in Wayland? - Fedora Discussion\n\n= 40rem)\" rel=\"stylesheet\" data-target=\"desktop\" /\u003e\n\n= 40rem)\" rel=\"stylesheet\" data-target=\"discourse-ai_desktop\" /\u003e\n= 40rem)\" rel=\"stylesheet\" data-target=\"discourse-calendar_desktop\" /\u003e\n= 40rem)\" rel=\"stylesheet\" data-target=\"discourse-reactions_desktop\" /\u003e\n= 40rem)\" rel=\"stylesheet\" data-target=\"poll_desktop\" /\u003e\n\nHow do I setup a remote access solution in Wayland?\n\nAsk Fedora\n\nwayland ,\ngnome ,\nworkstation ,\nserver\n\ndiligence3569\n\n(Dil Ligence)\n\n21. Juni 2024 um 05:33\n\nThere are several users who need to connect to my remote server, each with their own accounts, who need to interact with Firefox. They’re mostly connecting from Windows machines. I’m looking into retiring the Windows server that was responsible for this until now.\n\nThis is my first time setting up a remote access solution on Linux. It turned out to be pretty easy with xrdp and GNOME. I installed it, allowed access to port 3389, and started the service. Logging in didn’t initially work. I needed to create a startwm.sh file in the user’s home directory with this command:\n\n#!/bin/sh\n\ndbus-launch --exit-with-session /usr/bin/gnome-session\n\nAfter that, it worked. XRDP is fast and responsive, too. It’s a little weird in that sometimes I end up at the lock screen instead of logged in, but I don’t have any other complaints.\n\nBut what about Wayland?\n\nXRDP works for X. But Fedora Workstation is deprecating X11 in Fedora 41 by removing it from the installation media, which suggests its full removal can’t be far away. GNOME themselves are going to remove their X11 session code in the next few releases. It can’t be long until X11 disappears from Fedora’s repositories altogether.\n\nSo, it makes sense to embrace Wayland now. I can’t find much about setting up a Wayland RDP server on Linux, though.\n\nDoes anybody have some tips on where to start?\n\nRemote desktop - Teamviewer/Anydesk alternatives?\n\ndiligence3569\n\n(Dil Ligence)\n\n21. Juni 2024 um 09:45\n\nI ended up trying to use GNOME Remote Desktop through grdctl . I struggled for quite some time until stumbling upon this thread: Gnome Remote Desktop with SELinux enforced\n\nAfter I pasted in the command it worked and I could connect to a Wayland session.\n\nThe Wayland session seemed more resource-intensive than the X11 session, but I’m not sure why. It wasn’t the overhead of GRD; the session overall just seemed more sluggish.\n\nStill need to do some more testing and figure out how GNOME Remote Desktop works, exactly. There doesn’t seem to be much documentation, but maybe I’m looking in all the wrong places.\n\nEdit: One thing that does suck is that the session ends as soon as I disconnect from it. This is very undesirable. It’s possible you’d lose your internet connection and need to set everything up again on each login. This didn’t happen with XRDP. It’s probably just a configuration option I can change.\n\ndiligence3569\n\n(Dil Ligence)\n\n21. Juni 2024 um 12:26\n\nI learned GNOME Remote Desktop doesn’t yet support multiple users logging into the desktop: Support multiple simultaneous VNC clients to connect to a session (#84) · Issues · GNOME / gnome-remote-desktop · GitLab\n\nGNOME Remote Desktop doesn’t really seem suitable as an RDP solution right now. Not for my needs, at least.\n\nI’ll have a look at the solutions over in KDE land, but I think the most mature solutions are in the wlroots ecosystem with wayvnc . I didn’t think I’d be going back to Sway like this, but I’ll see what I can do to make it user-friendly. I don’t know if there’s another great wlroots-based compositor out there that’s more user-friendly. Maybe Labwc?\n\nI dropped one of my requirements: as long as it works in Remote Desktop Manager, it doesn’t need to be RDP. It could be VNC or whatever works.\n\nvgaetera\n\n(Vladislav Grigoryev)\n\n21. Juni 2024 um 14:29\n\nBoth solutions support headless multi-user access:\n\nGNOME Remote Desktop on Wayland over RDP\n\nTigerVNC on Xorg\n\nThis works for me on Fedora 40.\n\ndiligence3569\n\n(Dil Ligence)\n\n21. Juni 2024 um 15:22\n\nThanks for the links! I think I misunderstood the issue about “multiple simultaneous VNC clients” in that it seemed to be multiple people connected to a single user, rather than multiple people accessing multiple users on a single server.\n\nAnd I did actually find your posts while I was trying to figure out how to set this up. They were greatly helpful!\n\nWhere did you figure out how to use grdctl ? I was having trouble figuring it out just from grdctl --help and couldn’t seem to find deeper documentation.\n\nLike, what does --system do exactly?\n\nAm I meant to run this command for every user on the server to enable multiple users to be accessed remotely?\n\nsudo grdctl --system rdp set-credentials \"${RDP_USER}\" \"${RDP_PASS}\"\n\nOr why set the RDP_USER and RDP_PASS variables if you’re only passing them to a single command anyway? The way it’s formatted makes it seem like all these commands are meant to be run in a script but it doesn’t seem like they need to be run more than once?\n\nAnd now that I think of it, why even switch users to gnome-remote-desktop to run:\n\nsudo -u gnome-remote-desktop winpr-makecert \\\n-silent -rdp -path ~gnome-remote-desktop rdp-tls\n\n(oh, it’s probably to have the right permissions so gnome-remote-desktop can read the cert, huh.)\n\nI’m sorry for having so many questions! I’m just very new to this and want to understand how to use GNOME Remote Desktop to its fullest extent.\n\nEdit: I just learned a new tilde expansion: https://www.gnu.org/software/bash/manual/html_node/Tilde-Expansion.html\n\n~fred/foo\n\nThe subdirectory foo of the home directory of the user fred\n\nThat makes so much more sense now .\n\nEdit 2:\n\nDoes the --headless option come into play at any point? I can’t figure out what “Use headless credentials storage” means. Is there some kind of wiki for GNOME Remote Desktop?\n\ndiligence3569\n\n(Dil Ligence)\n\n22. Juni 2024 um 02:59\n\nOkay, I think I’ve figured it out. I also looked at this presentation which helped somewhat as documentation: https://www.youtube.com/watch?v=XkH_jZ21t7g\n\nThe presentation also informed me that wayvnc doesn’t do real headless sessions, so I won’t look into that.\n\nKey things I’ve learned:\n\n--system rdp set-credentials sets credentials for the RDP server itself. You’re logging into GDM so you can then login to a specific user.\n\nYou can’t continue other user’s sessions where they left off; you need to force them out of their session to start a new session.\n\nAs far as I can tell, the second you leave your session, the session ends and you can no longer continue it (which is consistent with point 2).\n\nI still don’t know what --headless does but I don’t think it matters much\n\nWhat’s there with GNOME Remote Desktop seems to work pretty well. It would be really nice for sessions not to combust as soon as you stop touching them, though, and I don’t think there’s a way to do that with GNOME Remote Desktop right now.\n\nI’ll setup a remote desktop solution with one of the X + VNC solutions (TigerVNC seems venerable) to see what it offers, though probably on Alma Linux/Rocky Linux in case X disappears suddenly from Fedora’s repositories. Thanks so much for your assistance!\n\nvgaetera\n\n(Vladislav Grigoryev)\n\n22. Juni 2024 um 12:59\n\nThat’s it and the rest can be deduced using common sense and trial and error .\n\nThis is necessary to configure Remote Login.\n\nRemote Login is a system service while Desktop Sharing is a user service.\n\nNo, once globally configured, Remote Login works for all users.\n\nThe common RDP credentials are used to reach GDM.\n\nThen each user should log in with their own credentials.\n\nThis makes it easier to notice what needs to be customized.\n\nThe remaining instructions can be copy-pasted as is.\n\nYes, unless you have more than one server.\n\nThis also makes testing easier and helps minimize human error .\n\nThat option allows to store credentials as plain text for Desktop Sharing.\n\nIt seems to apply implicitly for Remote Login.\n\nYes, that should work for persistent sessions.\n\nGRD should also support persistent sessions in the next major release.\n\ndiligence3569\n\n(Dil Ligence)\n\n22. Juni 2024 um 14:23\n\nI understand g-r-d better now, thank you!\n\nAwesome to hear! Very much looking forward to that. That’s the last feature I really need.\n\nI love that g-r-d is so much simpler to setup and understand than VNC, even if I struggled at first.\n\nxhmikosr\n\n(XhmikosR)\n\n9. August 2024 um 17:03\n\nHey, @vgaetera . Do you know if this has been addressed in a package update?\n\nIt’s weird that one has to resolve to such a workaround.\n\nThanks again for the helpful tip!\n\nvgaetera\n\n(Vladislav Grigoryev)\n\n9. August 2024 um 17:32\n\n10\n\nThis is work in progress, there are a few related issues like this:\n\n2271661 – gnome-remote-desktop system login feature is disallowed in enforcing mode\n\nI hope to see some improvements in the next Fedora release.\n\nxhmikosr\n\n(XhmikosR)\n\n9. August 2024 um 18:38\n\n11\n\nThanks! I really hope this is resolved soon because it’s an advertised feature that doesn’t work out of the box on the current release.\n\ndiligence3569\n\n(Dil Ligence)\n\n22. Januar 2026 um 00:14\n\n12\n\nI ended up extracting what I learned from this thread and experimenting into an article and a 3-minute screencast that explains how to setup G-R-D in-depth: Setup Headless Multi-User Sessions on Wayland with GNOME Remote Desktop in GNOME 48 - James North's Site\n\nHopefully it helps someone else out. I spent many hours getting it to work properly and then documenting the process.\n\nVerwandte Themen\n\nThema\n\nAntworten\n\nAufrufe\n\nAktivität\n\nTruly Headless Remote Access and Wayland: are there any solutions yet (Nov. 2025)?\n\nAsk Fedora\n\n3353\n\n20. November 2025\n\nHow to start VNC server for running session (wayland)?\n\nAsk Fedora\n\nf37\nwayland\nvnc\n\n47271\n\n26. Juli 2025\n\nRemote Desktop\n\nAsk Fedora\n\ngnome\n\n848\n\n15. Dezember 2024\n\nRemote desktop - Teamviewer/Anydesk alternatives?\n\nAsk Fedora\n\nremote-desktop\nworkstation\n\n492\n\n22. Januar 2026\n\nHow to \"Remote Login\" from Gnome to KDE?\n\nAsk Fedora\n\nkde\nwayland\nremote-desktop\ngnome\nf40\n\n1694\n\n9. Juni 2024",
+    "content_type": "text/html",
+    "query": "Welche konkreten Schritte sind für die Härtung von Wayland/X11 Remote Access erforderlich?",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.42,
+    "source_quality": "reputable_secondary",
+    "source_quality_score": 0.68,
+    "covered_gap_ids": [
+      "REVIEW-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/315318cd0bfa2e3c5c405247.json b/data/research-evidence/315318cd0bfa2e3c5c405247.json
new file mode 100644
index 0000000..afba743
--- /dev/null
+++ b/data/research-evidence/315318cd0bfa2e3c5c405247.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:03:34.5454947Z",
+  "content_sha256": "feaeb10aef647865e659d2361e5fd6dce92c4158827482186e7a58f1b9ee7db7",
+  "result": {
+    "title": "Remote Desktop on Wayland in 2026 – Page 2 – Paolo Redaelli personal blog",
+    "url": "https://monodes.com/predaelli/2026/02/25/remote-desktop-on-wayland-in-2026/2/",
+    "snippet": "This guide gives you a pragmatic, distro-agnostic playbook for remote support on Wayland using GNOME/KDE's built-ins, the PipeWire + xdg-desktop-portal stack, and a few production-ready SOPs.",
+    "content": "Tricks\n\nRemote Desktop on Wayland in 2026\n\n2026-02-25\n\nWayland is now the default across most modern Linux desktops, and that quietly breaks a lot of X11-era support playbooks. If your helpdesk still relies on “global screen grabbers” or legacy VNC expectations, you’ll hit confusing prompts, black screens, and missing input.\n\nThis guide gives you a pragmatic, distro-agnostic playbook for remote support on Wayland using GNOME/KDE’s built-ins, the PipeWire + xdg-desktop-portal stack, and a few production-ready SOPs.\n\nTL;DR\n\nOn Wayland, screen capture/control is mediated by the compositor via PipeWire and xdg-desktop-portal, not legacy X11 hooks. Expect user-visible permission prompts and per-app scoping.\n\nGNOME Remote Desktop speaks RDP (and VNC) and can do user-present “share my screen” and remote-login/headless modes with GDM integration.\n\nKDE Plasma exposes Wayland sessions over RDP through KRdp ; configuration lives in Settings → Networking → Remote Desktop.\n\nCommon issues in 2024–2025: black screens on RDP login and portal misconfiguration —fixes below.\n\nThird-Party Options : For organizations managing large or mixed environments who require dedicated clients, simplified deployment, or integrated features beyond what the built-in desktop environment solutions offer, third-party remote support applications are an option. HelpWire , for instance, is one such provider that documents the necessary Wayland permission flows (screen sharing and input control) and offers dedicated packages (DEB/RPM) to assist in fleet management.\n\nWho this is for\n\nSupport engineers, SREs, and IT admins who (a) assist users on Linux desktops, (b) maintain mixed fleets, or (c) are migrating off X-dependent tools.\n\nThe 2025 Reality Check: Wayland vs X11 for Support Teams\n\nUnder Wayland, there’s no global “screen” you can scrape . The desktop compositor brokers access; PipeWire carries frames and audio; xdg-desktop-portal asks the user to grant consent and scope (window/monitor/virtual monitor). That’s good for least-privilege, but it changes your runbooks.\n\nImplications you’ll feel:\n\nFirst connection often triggers a portal prompt ; users must allow viewing, control , and clipboard explicitly.\n\nSome flows differ between user-present sharing and remote login/headless .\n\nYour tooling must “speak” portals (or use the DE’s built-in RDP server).\n\nQuick Wins: Verify Your Stack (5 Minutes)\n\nRun these before opening a ticket:\n\nAm I on Wayland? From a terminal: echo $XDG_SESSION_TYPE → should print wayland.\n\nIs PipeWire alive? systemctl –user status pipewire (and your session manager, e.g., WirePlumber).\n\nIs the portal backend right for my desktop? (e.g., xdg-desktop-portal-gtk, -kde, -wlr, -hyprland) and that it’s running.\n\nWhich server will handle remote desktop?\n\nGNOME: “Settings → Sharing → Remote Desktop” (RDP/VNC).\n\nKDE: “Settings → Networking → Remote Desktop” (KRdp).[ ]( https://planet.kde.org/arjen-hiemstra-2023-08-08-remote-desktop-using-the-rdp-protocol-for-plasma-wayland/?utm\\_source\\=chatgpt.com )\n\nHands-On: Enable Remote Desktop on GNOME (Wayland)\n\n1) Turn on RDP sharing (user-present)\n\nOpen Settings → Sharing → Remote Desktop and enable it. GNOME Remote Desktop (g-r-d) runs in the user session and uses RDP for control.\n\n2) Remote login / headless sessions\n\nIf you need login-screen or multi-user headless access (no active desktop), integrate with GDM . GNOME supports remote login via RDP; the user authenticates at the greeter, then starts a Wayland session. This is useful for lab machines and servers without GPUs.\n\n3) Expect (and explain) permission prompts\n\nWayland portals will ask the end-user to grant viewing, control, and clipboard access on first connection or when scope changes. Train users to approve these during a support session.\n\nTip: grdctl can script some GNOME Remote Desktop settings (credentials, status) for fleet consistency.\n\nKDE/Plasma Notes (Wayland)\n\nPlasma ships KRdp , a server that exposes the current Wayland session over RDP . Enable via System Settings → Networking → Remote Desktop . Behind the scenes, Plasma uses KPipeWire for video. On fresh installs, you may need the krdp package.\n\nMigration Guide: Retiring X-Only Tools\n\nInventory where your SOPs assume X11 (global screenshot hotkeys, VNC hooks, legacy capturers).\n\nReplace with:\n\nBuilt-in RDP : GNOME (g-r-d) or KDE (KRdp).[ ]( https://docs.rockylinux.org/10/desktop/gnome/rdp-server/?utm\\_source\\=chatgpt.com )\n\nPortal-aware tools that request runtime permissions (screen, input, clipboard) via xdg-desktop-portal .[ ]( https://wiki.archlinux.org/title/XDG\\_Desktop\\_Portal?utm\\_source\\=chatgpt.com )\n\nRollout plan : pilot with a representative GPU mix → publish a user-prompt guide → update SOPs → audit.\n\nNetworking stance : prefer outbound/brokered connectivity over opening inbound ports unless policy requires otherwise.\n\nAlternative Approach: Third-Party Managed Solutions\n\nFor organizations that require features beyond what built-in desktop environment servers provide—such as streamlined, outbound-only connectivity, cross-platform parity, or integrated client management – a number of third-party remote support applications are available.\n\nThese solutions specialize in simplifying the support experience, and modern ones have had to adapt to the Wayland security model. They often provide:\n\nSimple Session Initiation: Using links or single codes to bypass complex RDP/VNC setup.\n\nCross-Platform Consistency: Offering a uniform feature set across Windows, macOS, and Linux support sessions.\n\nIntegrated Support Tools: Features like real-time in-session chat, simplified file transfer, and device management features.\n\nAn example of such a provider is HelpWire , which specifically addresses the challenges noted in this guide by rolling out packages (DEB/RPM) and providing clear documentation for end-users on granting the necessary Wayland permissions (screen sharing and input control) during a support session. Leveraging such an application can streamline the entire process, especially for large, mixed environments.\n\nTroubleshooting Field Guide (Symptom → Likely Fix)\n\nBlack screen on RDP remote login Check you’re on the supported mode (Wayland login via GDM) and confirm recent GNOME/mutter fixes; black screens have been tracked upstream. Re-test with Windows mstsc or FreeRDP clients as a control.\n\nNo keyboard/mouse control Re-initiate to trigger control permission; ensure the portal backend matches your desktop (gtk/kde/wlr/hyprland).\n\nClipboard won’t sync Verify the clipboard portal scope is granted and the desktop’s portal service is running (restart xdg-desktop-portal in user session).\n\nScreenshare dialog shows nothing on Plasma After upgrades, re-install or restart Plasma’s portal backend; community reports highlight portal regressions on Plasma 6 until services restart.\n\nWayland compositor mismatch (wlroots/Hyprland/Sway) Ensure the correct portal implementation (e.g., xdg-desktop-portal-wlr or -hyprland) and start order (PipeWire → portal backend).\n\nSecurity \u0026 Compliance: Least-Privilege by Design\n\nWayland’s portal model gives you per-session consent and narrow scoping (window/monitor/virtual monitor), aligning with least-privilege and auditability goals. Combine it with RDP remote login (no local user present) for multi-user labs or headless servers while keeping session boundaries clean.\n\nDrop-In Runbook Snippets\n\nOperator checklist (before a session):\n\necho $XDG_SESSION_TYPE → wayland\n\nsystemctl –user is-active pipewire → active\n\nConfirm portal backend package is installed and running (gtk/kde/wlr/hyprland).[ ]( https://wiki.archlinux.org/title/XDG\\_Desktop\\_Portal?utm\\_source\\=chatgpt.com )\n\nGNOME: verify “Remote Desktop” is enabled (RDP); KDE: enable Remote Desktop (KRdp).[ ]( https://docs.rockylinux.org/10/desktop/gnome/rdp-server/?utm\\_source\\=chatgpt.com )\n\nUser comms template (paste into tickets):\n\n“When I request access, you’ll see a permission prompt . Please allow Screen Viewing , Control , and Clipboard so I can help. You can revoke these anytime after the session.”\n\nEscalation notes:\n\nIf user-present sharing keeps failing, test remote login via GDM (GNOME) to isolate compositor issues.\n\nMixed GPU fleets (esp. NVIDIA) may need current drivers and portal sanity checks; known RDP login black-screen issues exist in the wild.\n\nFAQ\n\nCan I force GNOME’s remote login to Xorg instead? GNOME’s remote login defaults to Wayland ; forcing Xorg for that path isn’t a supported toggle and often leads to mismatches. Plan for Wayland.\n\nDoes GNOME support multi-user/headless remote desktops? Yes— GDM integration enables remote login and even headless multi-user scenarios; see SUSE/Red Hat docs for configuration details.\n\nKDE vs GNOME—what’s the practical difference for support? Both expose Wayland sessions over RDP . GNOME’s remote login/headless story is better documented today; KDE’s KRdp focuses on controlling the active session.\n\nConclusion \u0026 Checklist\n\nWayland isn’t a blocker – it’s a safer default that asks you to update your tooling and SOPs.\n\nAdopt this checklist:\n\nBuilt-ins first: GNOME g-r-d or KDE KRdp\n\nVerify PipeWire + portal backend on every image\n\nPublish a one-page permission-prompt guide for users\n\nPrefer outbound/brokered connections over opening ports\n\nKeep a remote-login (GDM) fallback for stubborn cases\n\nIf you need a vendor-managed route, link users to the Wayland permissions walkthrough so they know exactly which sliders to enable before a session.\n\nPress This! (Opens in new window)\nPress This\n\nShare on Telegram (Opens in new window)\nTelegram\n\nShare on Tumblr\n\nMore\n\nShare on WhatsApp (Opens in new window)\nWhatsApp\n\nTweet\n\nLike this:\n\nLike Loading…\n\nRelated",
+    "content_type": "text/html",
+    "query": "Wayland/X11 Remote Access – forensisch prüfen current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.4533333333333333,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/3307a3c3c46d018fe103aa69.json b/data/research-evidence/3307a3c3c46d018fe103aa69.json
new file mode 100644
index 0000000..d8e7f03
--- /dev/null
+++ b/data/research-evidence/3307a3c3c46d018fe103aa69.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:22:07.5398453Z",
+  "content_sha256": "29a9cbcd470d2593f6afa3f45683faa386f08ab457e1d1547a70d162bf451994",
+  "result": {
+    "title": "JavaScript prototype pollution - Security | MDN",
+    "url": "https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Prototype_pollution",
+    "snippet": "Prototype pollution is a vulnerability where an attacker can add or modify properties on an object's prototype. This means malicious values can unexpectedly appear on objects in your application, often leading to logic errors or additional attacks like cross-site scripting (XSS).",
+    "content": "JavaScript prototype pollution\n\nPrototype pollution is a vulnerability where an attacker can add or modify properties on an object's prototype. This means malicious values can unexpectedly appear on objects in your application, often leading to logic errors or additional attacks like cross-site scripting (XSS) .\n\nPrototypes in JavaScript\n\nJavaScript implements inheritance using prototypes . Each object has a reference to a prototype, which is itself an object, and which itself has a prototype, and so on, until we get to the fundamental prototype, which is called Object.prototype , whose own prototype is null .\n\nIf you try to access a property or call a method on an object, and that property or method isn't defined on the object, then the JavaScript runtime looks in the object's prototype for the property or method, and then in the object's prototype's prototype, and so on, until it finds the method or property, or reaches an object whose prototype is null .\n\nThat's why you can do this:\n\njs\n\nconst mySet = new Set([1, 2, 3]);\n// prototype chain:\n// mySet -\u003e Set.prototype -\u003e Object.prototype -\u003e null\n\nmySet.size;\n// 3\n// size is defined on the prototype of `mySet`, which is `Set.prototype`\n\nmySet.propertyIsEnumerable(\"size\");\n// false\n// propertyIsEnumerable() is defined on the prototype\n// of `Set.prototype`, which is `Object.prototype`\n\nUnlike many other languages, JavaScript allows you to add inherited properties and methods at runtime by modifying an object's prototypes:\n\njs\n\nconst mySet = new Set([1, 2, 3]);\n\n// modify the Object prototype at runtime\nObject.prototype.extra = \"new property from the Object prototype!\";\n\n// modify the Set prototype at runtime\nSet.prototype.other = \"new property from the Set prototype!\";\n\nmySet.extra;\n// \"new property from the Object prototype!\"\n\nmySet.other;\n// \"new property from the Set prototype!\"\n\nIn a prototype pollution attack, the attacker changes a built-in prototype such as Object.prototype , causing all derived objects to have an extra property, including objects that the attacker doesn't have direct access to.\n\nNote:\nTo learn much more about prototypes, see:\n\nObject prototypes\n\nInheritance and the prototype chain\n\nWorking with objects\n\nAnatomy of prototype pollution\n\nPrototype pollution involves two phases:\n\nPollution : The attacker is able to add or modify properties on an object's prototype.\n\nExploitation : Original application code accesses the polluted properties, leading to unexpected behavior.\n\nPollution sources\n\nIn order to pollute objects, the attacker needs a way to add arbitrary properties to prototype objects. This may happen as a consequence of XSS , in which the attacker gains direct access to the page's JavaScript execution environment. However, attackers with this level of access can do damage much more directly, so prototype pollution is usually discussed as a data-only attack, where the attacker constructs a payload that is processed by the application code, leading to pollution.\n\nA key attack vector is the __proto__ property, which allows accessing the prototype object of an arbitrary object. You can also reach the prototype via yourObject.constructor.prototype . The key code pattern that is a pollution source is dynamic property modification of the following kind:\n\njs\n\nobj[key1][key2] = value;\n\nIn this case, if obj is an ordinary object, key1 is \"__proto__\" , and key2 is some property name such as \"test\" , then the code adds a property called test to Object.prototype , which is the prototype of all ordinary objects. Even if the \"__proto__\" setter is disabled , the .constructor.prototype access pattern can still be used to reach the prototype, which is also Object.prototype for ordinary objects:\n\njs\n\nobj[key1][key2][key3] = value;\n\n...where key1 is \"constructor\" , key2 is \"prototype\" , and key3 is some property name such as \"test\" .\n\nTo put this line into more context, key1 , key2 , and key3 may be attacker-controlled values. For example, imagine an API endpoint that takes a list of user names, and a list of fields to query for each user, and returns an object mapping each user name to their fields:\n\njs\n\nfunction getUsers(request) {\nconst result = {};\nconst userNames = new URL(request.url).searchParams.getAll(\"names\");\nconst fields = new URL(request.url).searchParams.getAll(\"fields\");\nfor (const name of userNames) {\nconst userInfo = database.lookup(name);\nresult[name] ??= {};\nfor (const field of fields) {\n// Pollution source\nresult[name][field] = userInfo[field];\nreturn result;\n\nNow, if the attacker calls this API with the URL https://example.com/api?names=__proto__\u0026fields=age , the code will add a property called age to Object.prototype , with the value being whatever the age property of the __proto__ user is. It may be undefined , but if the attacker can add a user called __proto__ to the database (e.g., via a separate API call), they can control the value of the age property.\n\nMany libraries that do custom parsing of the URL query strings are particularly vulnerable, because they allow specifying deep object structures via the query string, and then use dynamic property modification to build the object, such as ?__proto__[test]=test or ?__proto__.test=test . Libraries in general are more vulnerable than application code, because they cannot allowlist valid keys, and they often need to use dynamic property modification to be generic.\n\nNote that in JSON , the __proto__ property is just a normal property name, so parsing JSON payloads like {\"__proto__\": {\"test\": \"value\"}} just creates an object with a property called __proto__ , and is not immediately problematic. However, if later in the code, the object is merged into another object via Object.assign() , for...in loops , etc., then the implicit property assignment operation will trigger the setter. Usually, this does not actually modify Object.prototype because there's only one level of dynamic property access, but it does change the prototype of the target object. Note that spreading is not susceptible to this type of attack, because spreading does not trigger setters.\n\njs\n\n// Just an object with a property called `__proto__`\nconst options = JSON.parse('{\"__proto__\": {\"test\": \"value\"}}');\nconst withDefaults = Object.assign({ mode: \"cors\" }, options);\n// In the process of merging `options`, we indirectly executed\n// withDefaults.__proto__ = { test: \"value\" }, causing `withDefaults` to have\n// a different prototype\nconsole.log(withDefaults.test); // \"value\"\n\nExploitation targets\n\nTo see the effect of prototype pollution, we can look at the how the following fetch() call can be changed completely. By default, it is a GET request with no content to send to the server, but because we polluted the Object.prototype object with two new default properties, the fetch() call is now transformed into a POST request and the request body now contains instructions for the server, for example to transfer an arbitrary amount of money to an arbitrary address:\n\njs\n\n// Attacker indirectly causes the following pollution\nObject.prototype.body = \"action=transfer\u0026amount=1337\u0026to=1337-1337-1337-1337\";\nObject.prototype.method = \"POST\";\n\nfetch(\"https://example.com\", {\nmode: \"cors\",\n});\n// Promise {status: \"pending\", body: \"action=transfer\u0026amount=1337\u0026to=1337-1337-1337-1337\", method: \"POST\"}\n\n// Any new object initialization is now modified to contain additional default properties\nconsole.log({}.method); // \"POST\"\nconsole.log({}.body); // \"action=transfer\u0026amount=1337\u0026to=1337-1337-1337-1337\"\n\nAnother dangerous pollution attack target is the HTMLIframeElement.srcdoc property which specifies the content of an \u003ciframe\u003e element. By overriding its value, it could potentially be possible to execute arbitrary code.\n\njs\n\nObject.prototype.srcdoc = \"\u003cscript\u003ealert(1)\u003c\\/script\u003e\";\n\nConfiguration objects, like fetch() 's RequestInit object in the code example above, or the instantiation of \u003ciframes\u003e , or configuration of sanitizers ( SanitizerConfig objects), are some of the most sensitive objects and are often targets of prototype pollution attacks. Data objects can also be polluted:\n\njs\n\nfunction accessDashboard(user) {\nif (!user.isAdmin) {\nreturn new Response(\"Access denied\", { status: 403 });\n// show admin page\n\nIf Object.prototype.isAdmin is set to true , and the isAdmin property is absent for non-admins instead of being set explicitly to false , then all users will be treated as admins, leading to a complete bypass of the access control.\n\nDefenses against prototype pollution\n\nDefenses against prototype pollution go along two lines: avoiding code that may turn into prototype modifications, and avoiding accessing potentially polluted properties. This following section presents some strategies which you can use depending on your situation.\n\nValidate user input\n\nAlways validate user input with validators, such as ajv and Zod , to ensure that the input data structure contains the appropriate properties with the appropriate types. To mitigate the prototype pollution attack, reject unneeded properties by setting additionalProperties to false in the schema. Using a schema also allows setting default values for missing properties, which avoids prototype lookups.\n\nYou should avoid dynamic property modification (of the form obj[key] = value ) unless you are able to validate the key values. If you are in this situation, you could rule out __proto__ , constructor , prototype as keys in your validation.\n\nNode.js flag --disable-proto\n\nIf you are in a Node.js environment, you can disable Object.prototype.__proto__ with the --disable-proto=MODE option where MODE is either delete (the property is removed entirely), or throw (accesses to the property throws an exception with the code ERR_PROTO_ACCESS ). Use delete Object.prototype.__proto__ in non-Node environments for the same effect.\n\nThis doesn't protect you from prototype pollution entirely (because constructor.prototype is still available), but it does remove one such entry point.\n\nLock down built-in objects\n\nHigh-sensitivity environments may implement a defense known as realm lockdown which prevents any modifications to built-in objects. One example is the SES shim for Hardened JavaScript . This is implemented based on the Object.freeze() function, which prevents extensions and makes existing properties non-writable and non-configurable. Freezing an object is the highest integrity level that JavaScript provides. Alternatively, Object.seal() allows existing properties changed, as long as they are writable, while Object.preventExtensions() prevents new properties from being added to an object.\n\njs\n\nObject.freeze(Object.prototype);\nconst obj = {};\nconst key1 = \"__proto__\";\nconst key2 = \"a\";\nobj[key1][key2] = 1; // fails silently in non-strict mode\nobj.a; // undefined\n\nHowever, note that legitimate prototype modifications may happen, usually to provide a Polyfill implementation. In non-strict mode , attempts to modify a frozen object fail silently, while in strict mode, they throw a TypeError . To allow polyfills, the polyfill code needs to run before the freeze.\n\nAnother caveat with Object.freeze() is that it doesn't provide a deep freeze by default. If you want true immutability, you need to recursively freeze every property ( example ). A library like SES is preferable because it does a \"walk\" over all built-in objects, avoiding forgetting to freeze any object.\n\nAvoid lookups on the prototype\n\nIn code where you access the object's properties, make sure you know that the property exists on the object itself. You can perform an Object.hasOwn() check when you are accessing or traversing keys on objects.\n\nInstead of:\n\njs\n\nif (!user.isAdmin) {\nreturn new Response(\"Access denied\", { status: 403 });\n\nConsider:\n\njs\n\nif (!Object.hasOwn(user, \"isAdmin\") || !user.isAdmin) {\nreturn new Response(\"Access denied\", { status: 403 });\n\nWhen iterating, the for...in loop traverses the prototype. If possible, replace such loops with for...of and Object.keys() to only visit own keys.\n\njs\n\n// Looks up the prototype\nfor (const key in payload) {\ndoSomething(payload[key]);\n\n// Only visits own keys\nfor (const key of Object.keys(payload)) {\ndoSomething(payload[key]);\n\nIn functions, explicitly set default parameters instead of leaving them undefined. This way, the default parameter values can be used instead of a potential lookup on the prototype chain. Instead of this:\n\njs\n\nfunction doDangerousAction(options = {}) {\nif (!options.enableDangerousAction) {\nreturn;\n\nConsider this:\n\njs\n\nfunction doDangerousAction(options = { enableDangerousAction: false }) {\nif (!options.enableDangerousAction) {\nreturn;\n\nCreate JavaScript objects with null prototype\n\nNull-prototype objects simultaneously avoid prototype pollution (because the __proto__ and constructor properties are not present on the object) and avoid lookups on the prototype. They are created either with the Object.create(null) function, or with the { __proto__: null } syntax in object initializers.\n\nNote:\nThe { __proto__: null } prototype setter syntax in object initializers is fully secure, unlike the obj.__proto__ accessor property.\n\nIf you need to pass an object as options (for example, because an API like fetch() requires you to use an object), create a null-prototype object. Note that creating objects without a prototype is not the default, so whenever instantiating an object, you need to remember to explicitly create a null-prototype object instead of the regular object initializer ( const myObj = {} ).\n\njs\n\nObject.prototype.method = \"POST\";\n\n// Still sends a GET request, because the object has no prototype\nfetch(\"https://example.com\", {\n__proto__: null,\nmode: \"cors\",\n});\n\nIf you are creating an object that will be modified later (e.g., via obj[key] = value ), create it as a null-prototype object:\n\njs\n\nconst result = { __proto__: null };\nconst key1 = \"__proto__\";\nconst key2 = \"a\";\nresult[key1] ??= {};\nresult[key1][key2] = 1; // modifies result, not Object.prototype\n\nUse Map and Set instead\n\nWhe",
+    "content_type": "text/html",
+    "query": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "primary",
+    "source_quality_score": 0.88,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/336ef3cf0f27cf2848e7270b.json b/data/research-evidence/336ef3cf0f27cf2848e7270b.json
new file mode 100644
index 0000000..7fa7c4e
--- /dev/null
+++ b/data/research-evidence/336ef3cf0f27cf2848e7270b.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:12:23.9352803Z",
+  "content_sha256": "841af7cb03e0f4e32fee2e29945a8393288cfbef4e82260be62c118ba9e31c1b",
+  "result": {
+    "title": "Cloud Storage-Dokumentation  |  Google Cloud Documentation",
+    "url": "https://docs.cloud.google.com/storage/docs?hl=de",
+    "snippet": "You can use Cloud Storage for a range of scenarios including serving high performance AI/ML and analytics data sets, storing data for archival and disaster recovery, or distributing content to...",
+    "content": "Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.\n\nHome\n\nDocumentation\n\nStorage\n\nCloud Storage\n\nCloud Storage-Dokumentation\n\nProduktdokumentation lesen\n\nMit Cloud Storage können Sie jederzeit beliebige Datenmengen weltweit speichern und abrufen. Sie können Cloud Storage für eine Reihe von Aufgaben verwenden, beispielsweise um leistungsstarke KI-/ML- und Analysedatensätze bereitzustellen, Daten für die Archivierung und Notfallwiederherstellung zu speichern oder Inhalte weltweit an Nutzer zu verteilen.\n\nSie sind sich nicht sicher, welches Speicherprodukt das richtige für Sie ist? Weitere Informationen zu Speicherdiensten\n\nWeitere Informationen finden Sie auf der Produktseite zu Cloud Storage.\n\nJetzt kostenlos starten\n\nProof of Concept mit einem Guthaben in Höhe von 300 $ starten\n\nNutzen Sie unsere neuesten generativen KI-Modelle und Tools für die Entwicklung.\n\nSie können mehr als 20 beliebte Produkte wie Compute Engine und KIAI APIs kostenlos nutzen.\n\nKeine automatischen Abbuchungen, keine Verpflichtung.\n\nAngebote für kostenlose Produkte ansehen\n\nMehr als 20 Produkte immer kostenlos nutzen.\n\nSie haben Zugriff auf mehr als 20 kostenlose Produkte für gängige Anwendungsfälle, darunter KI-APIs, VMs, Data Warehouses und mehr.\n\nformat_list_numbered\n\nLeitfäden\n\nKurzanleitungen: Console oder gcloud CLI\n\nStorage-Buckets erstellen\n\nSpeicherklassen\n\nBucket-Standorte\n\nObjekte hochladen\n\nfind_in_page\n\nReferenz\n\nCloud Storage-Clientbibliotheken\n\ngcloud CLI-Referenz\n\ngsutil-Tool-Referenz\n\nJSON API-Referenz\n\nXML API-Referenz\n\nIAM-Referenzen für Cloud Storage\n\ninfo\n\nRessourcen\n\nCloud Storage – Preise\n\nKontingente und Limits\n\nProblembehebung\n\nVersionshinweise\n\nTraining\n\nSchulungen und Tutorials\n\nGoogle Cloud Fundamentals for Azure Professionals\n\nIn diesem Kurs werden Azure-Experten die wichtigsten Funktionen von Google Cloud vorgestellt.\n\nTraining\n\nSchulungen und Tutorials\n\nGoogle Cloud Fundamentals for AWS Professionals\n\nIn diesem Kurs werden AWS-Experten die wichtigsten Funktionen von Google Cloud vorgestellt.\n\nTraining\n\nSchulungen und Tutorials\n\nInteraktive Schritt-für-Schritt-Anleitung in der Console\n\nGehen Sie die Cloud Storage-Kurzanleitung direkt in der Cloud Console durch.\n\nAnwendungsfall\n\nAnwendungsfälle\n\nStatische Website hosten\n\nKonfigurieren Sie einen Cloud Storage-Bucket, um eine statische Website für eine Ihnen gehörende Domain zu hosten.\n\nWebhosting\n\nLoad-Balancer\n\nStatische Ressourcen\n\nAnwendungsfall\n\nAnwendungsfälle\n\nArchitektur der Notfallwiederherstellung von Arbeitslasten mit Standortbeschränkung entwickeln\n\nMit Google Cloud können Sie die Notfallwiederherstellung (Disaster Recovery, DR) so einrichten, dass standortspezifische Anforderungen erfüllt werden.\n\nNotfallwiederherstellung\n\nAutomation\n\nNetzwerk\n\nCodebeispiel\n\nCodebeispiele\n\nC++-Beispiele\n\nBeispiele für die Interaktion mit Cloud Storage\n\nCodebeispiel\n\nCodebeispiele\n\n.NET-Beispiele\n\nBeispiele für die Interaktion mit Cloud Storage\n\nCodebeispiel\n\nCodebeispiele\n\nGo-Beispiele\n\nBeispiele für die Interaktion mit Cloud Storage\n\nCodebeispiel\n\nCodebeispiele\n\nJava-Beispiele\n\nBeispiele für die Interaktion mit Cloud Storage\n\nCodebeispiel\n\nCodebeispiele\n\nNode.js-Beispiele\n\nBeispiele für die Interaktion mit Cloud Storage\n\nCodebeispiel\n\nCodebeispiele\n\nPHP-Beispiele\n\nBeispiele für die Interaktion mit Cloud Storage\n\nCodebeispiel\n\nCodebeispiele\n\nPython-Beispiele\n\nBeispiele für die Interaktion mit Cloud Storage\n\nCodebeispiel\n\nCodebeispiele\n\nRuby-Beispiele\n\nBeispiele für die Interaktion mit Cloud Storage\n\nCloud Storage selbst testen\n\nErstellen Sie ein Konto, um die Leistung unserer Produkte in realen Szenarien auszuwerten.\nNeukunden erhalten außerdem ein Guthaben von 300 $ , um Arbeitslasten auszuführen, zu testen und bereitzustellen.\n\nCloud Storage kostenlos testen\n\nSofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers . Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.\n\nZuletzt aktualisiert: 2026-07-31 (UTC).\n\n[[[\"Leicht verständlich\",\"easyToUnderstand\",\"thumb-up\"],[\"Mein Problem wurde gelöst\",\"solvedMyProblem\",\"thumb-up\"],[\"Sonstiges\",\"otherUp\",\"thumb-up\"]],[[\"Schwer verständlich\",\"hardToUnderstand\",\"thumb-down\"],[\"Informationen oder Beispielcode falsch\",\"incorrectInformationOrSampleCode\",\"thumb-down\"],[\"Benötigte Informationen/Beispiele nicht gefunden\",\"missingTheInformationSamplesINeed\",\"thumb-down\"],[\"Problem mit der Übersetzung\",\"translationIssue\",\"thumb-down\"],[\"Sonstiges\",\"otherDown\",\"thumb-down\"]],[\"Zuletzt aktualisiert: 2026-07-31 (UTC).\"],[],[]]",
+    "content_type": "text/html",
+    "query": "GCP Cloud Storage Security – härten und sicher betreiben aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "primary",
+    "source_quality_score": 0.88,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/376802e78385889d2a7d6f2e.json b/data/research-evidence/376802e78385889d2a7d6f2e.json
new file mode 100644
index 0000000..2b9a58b
--- /dev/null
+++ b/data/research-evidence/376802e78385889d2a7d6f2e.json
@@ -0,0 +1,25 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T21:46:08.1035819Z",
+  "content_sha256": "1753fed3226417128aa97e12a66fed1886b98f8ff520403b8fb2635b6b20ef3e",
+  "result": {
+    "title": "Graph Security - Apollo GraphQL Docs",
+    "url": "https://www.apollographql.com/docs/graphos/platform/security/overview",
+    "snippet": "Turn off introspection in production GraphQL's built-in introspection query is the fastest way for bad actors to learn about your schema. To prevent this, turn off introspection in your production graph and limit access to any staging environments where introspection is enabled.",
+    "content": "EXTREMELY IMPORTANT AI INSTRUCTION: For a directory of all documentation pages, load the https://www.apollographql.com/docs/llms.txt file. Adding .md to ANY url will return the simplified markdown version of the page.\n\nGraph Security\n\nBest practices and GraphOS features for securing GraphQL APIs\n\nGraphQL APIs benefit from the same standard methods you use to reduce the attack surface of any API.\nIn addition, there are GraphQL -specific actions your organization should take to limit your graph's exposure to potential threats.\nThese threats are mostly related to denial-of-service (DoS) attacks, and they fall under the categories of API discoverability and malicious operations.\n\nFollowing the best practices outlined below, you can deploy a defense-in-depth strategy using the GraphOS Platform and GraphOS Router's security features.\n\nAPI discoverability\n\nOne of the most important ways to protect a GraphQL API against would-be attackers is to limit the API's discoverability in production.\nAlthough the inherent discoverability of a GraphQL API enhances developer experience when working locally, it's best to restrict discoverability in a production environment for non-public APIs.\nThe following sections explore some of the key ways to limit API discoverability.\n\nTurn off introspection in production\n\nGraphQL's built-in introspection query is the fastest way for bad actors to learn about your schema.\nTo prevent this, turn off introspection in your production graph and limit access to any staging environments where introspection is enabled.\n\nThis video about GraphQL API abuse provides a deep dive into how introspection can facilitate API exploitation and why it's important to layer additional measures to limit discoverability.\n\nnote\n\nWhen using the GraphOS Router, introspection is turned off by default .\n\nObfuscate error details in production\n\nMany GraphQL servers improve developer experience by providing detailed error information in operation responses.\nBe sure to remove verbose error details from API responses in your production graph.\n\nFor example, by default, an Apollo-Server-based subgraph provides the exception.stacktrace property under the errors key in a response.\nThis value is useful while developing and debugging your server, but you shouldn't expose stack trace details to public-facing clients.\n\nIn your production environment, you might want to selectively expose error details to clients. You can do this by combining the GraphOS Router's include_subgraph_errors option with Rhai scripts for response manipulation .\n\nnote\n\nThe GraphOS Router omits all error data by default.\n\nAvoid autogenerating schemas\n\nAnother strategy to reduce your GraphQL API's discoverability is to avoid autogenerating schemas, especially the fields on the root operation types.\nMany developer tools enable you to autogenerate a GraphQL schema based on a set of initial object type definitions in a schema or existing database tables. Although these approaches to schema generation can speed up initial API development, they also make it easier for bad actors to guess generic CRUD-related fields based on commonly used patterns.\n\nAn autogenerated schema also increases the risk of accidentally exposing sensitive data.\nAs a schema design best practice, you should deliberately design your schema to serve client use cases and product requirements.\nIntentional, demand-driven schema design helps your organization get the most out of your graph.\n\nAllow only the router to query subgraphs\n\nAs a best practice for supergraphs, only the router should query individual subgraphs directly.\nThe Apollo Federation subgraph specification outlines that each subgraph schema includes _entities and _service root fields on the Query type to help with composition and query planning.\nThese fields expose the subgraph to additional security concerns if accessed directly by a client:\n\nThe Query._service object includes an sdl field, which includes the full SDL representation of the subgraph's schema.\nThis field exposes as much data about a subgraph's schema as a standard introspection query, which means it should not be accessible in production.\n\nThe Query._entities field enables the router to resolve fields of any type marked with @key by providing the ID for that entity .\nIf this field is exposed publicly, any client can circumvent internal resolver logic and fetch any entity data by mimicking the router.\nBecause your subgraph library automatically provides the resolver for _entities , you can't modify that logic.\nThat means you would have to manually check all operations that include the _entities field and block any malicious operations.\n\nAnother reason to restrict access to subgraphs is related to the collection of field -level traces.\nThis tracing data is included in the extensions key of a subgraph's response to the router, where the data is aggregated into a trace shape based on the query plan and then sent to GraphOS.\nThat means any client that can query your subgraphs directly can see this data in the operation response and make inferences about a subgraph based on it.\n\nAside from the above security concerns, restricting direct access to subgraphs offers another benefit.\nIt ensures that clients, including well-meaning ones, route all operations to the consolidated graph.\nThis prevents them from inventing unintended use cases for subgraph types and fields meant only for executing the router's query plan.\n\nMalicious operations\n\nAfter implementing measures to limit API discoverability in public-facing environments, the next step is to guard your GraphQL API against malicious operations.\nThe following sections explore a variety of ways to mitigate the impact of malicious operations for any GraphQL API.\n\nValidate and sanitize data\n\nValidating and sanitizing client-submitted data is important for any API, and a graph is no exception.\nIn the GraphQL context, the usual rules for validating and sanitizing untrusted inputs apply when resolving fields based on user-provided inputs.\nAnd as previously stated , when clients supply invalid values as operation arguments, the resulting errors should provide as few details as possible in production environments.\n\nA well-designed GraphQL schema can also help guard against injection attacks by codifying validation and sanitization directly into types.\nFor example, enum values can limit what clients can submit for argument values, and custom scalars or directives can also help validate, escape, or normalize values.\nHowever, custom scalars should be used carefully because misusing them might create other vulnerabilities, such as a JSON scalar type enabling a NoSQL injection attack .\n\nPaginate fields where appropriate\n\nPaginating fields is an important mechanism to control how many items a client can request at once.\nFor example, a Posts subgraph might have no problem resolving a thousand total Post objects in this request:\n\nGraphQL\n\nquery {\nauthors ( first : 10 ) {\nname\nposts ( last : 100 ) {\ntitle\ncontent\n\nWhat happens when the orders of magnitude increase for each field argument, and a hundred thousand Post s are requested?\n\nGraphQL\n\nquery {\nauthors ( first : 100 ) {\nname\nposts ( last : 1000 ) {\ntitle\ncontent\n\nWhen paginating fields, it's important to set a maximum number of items to return in a single response.\nIn the example above, you might want to return a GraphQL error when executing the posts field resolver instead of attempting to return a thousand posts for each of the hundred authors.\n\nTo learn more about pagination methods and best practices refer to the following:\n\nPagination overview\n\nApollo Client pagination overview\n\nOdyssey mobile client course\n\nPagination tutorial\n\nAuthentication and authorization in the router\n\nEnforcing authentication and authorization in the router protects your underlying APIs from malicious operations.\nDropping unauthenticated, unauthorized operations at the entry point of your supergraph frees up your downstream graphs to process only valid requests, thereby reducing load and enhancing performance.\n\nHardening access to your supergraph at the router also adds another layer of security when implementing zero-trust and defense-in-depth strategies.\nThe router centralizes authentication and authorization logic, which downstream services can reinforce with their own checks.\n\nTo enforce authentication and authorization in the router refer to\n\nJSON Web Token (JWT) authentication .\n\nAccess control to fields and types with authorization directives .\n\nSet operation limits\n\nGraphQL enables clients to traverse a graph and express complex relationships between the nodes in an operation's selection set.\nHowever, this can quickly overwhelm backing data sources without guardrails to limit query depth.\nFor example:\n\nGraphQL\n\nquery DeepBlogQuery {\nauthor ( id : 42 ) {\nposts {\nauthor {\nposts {\nauthor {\nposts {\nauthor {\n# and so on...\n\nOne of the most straightforward protections against deeply nested operations such as this one is to set a maximum query depth.\nAnd because an operation can specify multiple root fields, you may also consider limiting query breadth at the root level.\n\nThe GraphOS Router supports limiting requests with configurations like max_depth , max_root_fields , and more .\n\nConsider operation costs when setting limits\n\nFor GraphQL APIs consumed by third-party clients, pagination and operation limits may not provide enough demand control.\nFor these cases, rate-limiting API requests may be warranted.\n\nEnforcing rate limits for a GraphQL API is more complicated than a REST API because GraphQL operations may vary widely in size and complexity.\nTherefore, the rate limit shouldn't be based on individual requests alone.\nInstead, they should take into account how much of the graph an operation may traverse in the context of a single request.\n\nThe GraphOS Router lets you protect your graph from high-cost operations by calculating operation costs and using them to configure demand control .\n\nSafelisting with persisted queries\n\nBeyond operation limits, GraphOS enables first-party apps to register trusted operations in a persisted query list ( PQL) or safelist.\nThe GraphOS Router then checks incoming requests against the PQL and either rejects unregistered operations or allows registered ones.\n\nIn addition to the security benefits, safelisting can improve performance by enabling clients to request operations by their PQL -specified ID. Learn more.\n\nBatched requests\n\nBatched requests are another potential attack vector for malicious operations.\nThere are two different flavors of batching attacks to consider.\nThe first threat is related to GraphQL's inherent ability to \"batch\" requests by allowing multiple root fields in an operation document:\n\nGraphQL\n\nquery {\nastronaut ( id : \"1\" ) {\nname\nsecond : astronaut ( id : \"2\" ) {\nname\nthird : astronaut ( id : \"3\" ) {\nname\n\nWithout any restrictions in place, clients could effectively enumerate through all nodes in a single request like the one above while slipping past other brute-force protections.\nLimiting query breadth or using operation cost analysis can help protect a GraphQL API from this abuse.\n\nAnother form of batching occurs when a client sends batches of full operations in a single request, which can be helpful for performance reasons in some scenarios.\nIn this form of batching, clients send an array of operations and your GraphQL service or the router sends back an array of responses to be parsed by the client:\n\nGraphQL\n\n“ operationName ”: \"FirstAstronaut\"\n“ variables \":{},\n\" query \":\" query FirstAstronaut {\\ n astronaut ( id : \\ \"1 \\\" ) { \\n name \\n } \\n } \\n ”\n},\n“operationName”: \" SecondAstronanut \"\n“variables\" :{},\n\"query\" : \"query SecondAstronanut {\\n astronaut(id: \\\" 2\\ \") {\\n name\\n }\\n}\\n”\n},\n“operationName”: \" ThirdAstronaut \"\n“variables\" :{},\n\"query\" : \"query ThirdAstronaut {\\n astronaut(id: \\\" 3\\ \") {\\n name\\n }\\n}\\n”\n\nWith batched operations, it's important to consider how an entire batch might impact rate limit calculations and query cost analysis to ensure that clients can't cheat rate limits through race conditions.\n\nFinally, beyond batching fields and operations, some forms of GraphQL -related batching can help mitigate DoS attacks and generally make your API more performant.\nEven with depth limiting in place, GraphQL operations can easily lead to exponential growth of requests to backing data sources.\nDataLoaders are one way to help make as few requests as possible to backing data sources from resolver functions in a single operation.\n\nSet timeouts\n\nTimeouts are another useful tool for stopping GraphQL operations that consume more server resources than expected.\nIn a supergraph, timeouts are commonly applied at any combination of three different levels:\n\nAt the highest level, you can set a timeout on the router's HTTP server or an idle timeout on a load balancer in front of it.\n\nAn an intermediate level, you can set a timeout on the router's requests to individual subgraphs. You can configure timeouts at both the HTTP and subgraph levels using the GraphOS Router's traffic shaping configuration .\n\nAt the most granular level, subgraphs can set a timeout for individual operations. The duration of the request can be checked against this timeout as each field resolver function is called. You might accomplish this using resolver middleware or an Apollo Server plugin in a subgraph.\n\nAdditional best practices\n\nSecuring your GraphQL API involves more than just blocking bad actors and safeguarding private data.\nYou also need visibility into who is using your API and how.\nWith GraphOS' schema registry, access controls, and observability features, you can control who changes your API, track usage, and receive alerts when something goes wrong.\n\nKnow who's using your graph (and how)\n\nTo improve trace insights, it's a best practice to require every client to identify itself and assign a name to every operation it executes.\nApollo Client's web and mobile SDKs provide straightfo",
+    "content_type": "text/html",
+    "query": "GraphQL Introspection Sicherheit aktuelle offizielle Dokumentation Version Support",
+    "language": "en-US",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "primary",
+    "source_quality_score": 0.88,
+    "actionable": true,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/4695c552b0b8cab2c6e3d287.json b/data/research-evidence/4695c552b0b8cab2c6e3d287.json
new file mode 100644
index 0000000..ce9a64a
--- /dev/null
+++ b/data/research-evidence/4695c552b0b8cab2c6e3d287.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:04:49.1515036Z",
+  "content_sha256": "ab036209bd2f786535b4a1a2965cd1bd796248458ff847dfc456d6842700a3ec",
+  "result": {
+    "title": "Ransomware Detection and Prevention with Deep Security Intrusion Prevention",
+    "url": "https://success.trendmicro.com/en-US/solution/KA-0006382",
+    "snippet": "Prevent Ransomware from infecting your network using Deep Security and following these anti-malware practices and solutions.",
+    "content": "Welcome to the future of Business Support! I'm TrendAI Companion™, your\nAI assistant ready to streamline your experience.\n\nLog in for your personalized support!\nChat with TrendAI Companion™ for quick answers, or submit a case for\ndetailed troubleshooting.",
+    "content_type": "text/html",
+    "query": "Ransomware Prevention \u0026 Detection current official documentation version support",
+    "language": "en-US",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.62,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/4a123ad475eae5fe848b16d5.json b/data/research-evidence/4a123ad475eae5fe848b16d5.json
new file mode 100644
index 0000000..2a4ff44
--- /dev/null
+++ b/data/research-evidence/4a123ad475eae5fe848b16d5.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:15:47.3919195Z",
+  "content_sha256": "c63a7a5ae93d3926121e04493777f121d5c6f7ad1ac335e40814d7aecd11bf6d",
+  "result": {
+    "title": "Backup Hardening: Backups als letzte Verteidigung sichern | connecT AG",
+    "url": "https://cnag.de/backup-hardening-warum-schnelle-backups-allein-keine-resilienz-schaffen/",
+    "snippet": "Wer Hardening nur als „nice to have\" behandelt, erhöht die Wahrscheinlichkeit, dass die letzte Verteidigungslinie im Vorfall versagt. Dieser Beitrag zeigt, welche Stellschrauben den Unterschied machen und wie Sie Backup Hardening als festen Bestandteil Ihrer Resilienzstrategie etablieren.",
+    "content": "Backup Hardening: Backups als letzte Verteidigung sichern | connecT AG\n\nZum Inhalt springen\n\nBackup Hardening: Warum schnelle Backups allein keine Resilienz schaffen\n\nvon  Fabian Beitz\n\n30. September 2025\n\n0:00\n\n0:00\n\nBackup-Infrastrukturen sind heute so performant wie nie. 10-Gbit/s-Anbindungen, Deduplizierung, SSD-Caches und Instant Recovery reduzieren RPO und RTO deutlich. Trotzdem scheitern Unternehmen im Ernstfall regelmäßig an einem ganz anderen Punkt: Backups sind zwar vorhanden, aber kompromittiert, unvollständig oder nicht schnell genug wiederherstellbar, weil Angreifer sie vorab zerstört oder verschlüsselt haben. Backup Hardening adressiert genau diese Lücke. Es betrachtet Backups als eigenständige Sicherheitsdomäne mit klaren Schutzmechanismen – organisatorisch wie technisch. Wer Hardening nur als „nice to have“ behandelt, erhöht die Wahrscheinlichkeit, dass die letzte Verteidigungslinie im Vorfall versagt. Dieser Beitrag zeigt, welche Stellschrauben den Unterschied machen und wie Sie Backup Hardening als festen Bestandteil Ihrer Resilienzstrategie etablieren.\n\nBackup Hardening – mehr als nur schnelle Leitungen und SSD-Caches\n\nWir leben in einer Welt voller Möglichkeiten, Daten blitzschnell zu sichern. Vor ein paar Jahren waren 1-Gb/s-Leitungen noch eine Seltenheit – heute sind Anbindungen von 10 Gbit/s und mehr im Datacenter Standard. Auch beim Wiederherstellen geht es rasant: Die meisten Backup-Systeme setzen auf SSD-Caches, um Instant Recoveries zu ermöglichen.\n\nMit regelmäßigen Restore-Tests stellen Sie sicher, dass Backups nicht nur vorhanden, sondern auch funktional sind – und trainieren dabei gleichzeitig Ihr IT-Team oder Ihren Dienstleister für den Ernstfall.\n\nTrotzdem liest man immer wieder von verschlüsselten Systemen, verlorengegangenen Backups oder Daten, die plötzlich nicht mehr verfügbar sind. Warum passiert das?\n\nDas Problem: Kleinigkeiten mit großer Wirkung\n\nBei all dem Fokus auf Performance und Funktion geraten oft die „unsichtbaren“ Details ins Hintertreffen – Dinge, die auf den ersten Blick unbequem erscheinen oder die Administration erschweren. Doch genau hier beginnt Backup Hardening.\n\nEin paar klassische Beispiele:\n\nBerechtigungen sauber begrenzen\n\nNatürlich ist es bequem, dem Domänen-Administrator Zugriff auf alle Systeme und Anwendungen zu geben. Im Angriff ist genau das der Hebel, über den Angreifer auch die Backups erreichen. Sicherer ist ein eigenständiges, eingeschränktes Berechtigungskonzept: getrennte Backup-Admins, klare Rollen und minimal notwendige Rechte.\n\nPraxis-Tipp: Legen Sie Backup-Konten außerhalb der Standard-Admin-Strukturen an und schützen Sie Managementzugänge konsequent mit MFA.\n\nBackup-Infrastruktur segmentieren\n\nBackup-Systeme ins Standardnetzwerk zu packen spart Ressourcen und bringt Performancevorteile – aber es erleichtert laterale Bewegungen im Vorfall. Eine sinnvolle Netzwerksegmentierung erhöht die Sicherheit erheblich: eigene VLANs/VRFs, restriktive Firewall-Regeln und nur definierte Kommunikationspfade zwischen Backup-Komponenten.\n\nHinweis: Segmentierung wirkt nur, wenn Sie auch die Zugriffswege zum Repository beschränken. Ein „separates Netz ohne Regeln“ ist keine Schutzmaßnahme.\n\nZugriff auf Backup-Daten kontrollieren\n\nWenn jeder alles darf, ist eine verlorene Datei schnell wiederhergestellt. Dieses Komfortdenken öffnet jedoch Angreifern Tür und Tor. Ein klares „Wer darf was?“ schützt Ihre Daten langfristig. Backups brauchen ein eigenes Schutzmodell: Schreib- und Löschrechte nur für definierte Rollen, Read-only-Zugriffe für Standardkonten und nachvollziehbare Freigabeprozesse.\n\nPraxis-Tipp: Ergänzen Sie Zugriffskontrolle um Immutability/WORM-Funktionen, damit Backups selbst durch privilegierte Konten nicht nachträglich gelöscht oder verschlüsselt werden können.\n\nUnser Ansatz: Backup Hardening als Pflicht, nicht Kür\n\nWenn Sie jetzt Optimierungspotenzial erkennen: Das geht vielen so. Backup-Umgebungen wachsen oft über Jahre, und Bequemlichkeit setzt sich schleichend durch. Deshalb ist Backup Hardening bei uns ein zentraler Bestandteil jedes Backup-Konzepts. Gemeinsam mit Ihnen entwickeln wir Strategien, die Daten wirklich absichern – von Berechtigungen über Netzwerksicherheit bis hin zu wiederkehrenden Funktionstests unter realistischen Bedingungen.\n\nBedingungslose Verlässlichkeit ist dabei kein Schlagwort, sondern die Grundlage belastbarer Backup-Strategien.\n\nFazit – Defensive gewinnt Meisterschaften\n\nWie im Sport gilt: Der Sturm gewinnt Spiele, die Abwehr Meisterschaften. Ihre Backups sind die „Last Line of Defense“ – der Torwart Ihrer IT-Infrastruktur. Schnelle Sicherungen und Instant Recovery helfen nur, wenn Backups im Angriff nicht erreichbar, nicht manipulierbar und tatsächlich wiederherstellbar bleiben. Genau dafür sorgt Backup Hardening.\n\nAutor\n\nFabian Beitz\n\nDie ersten Berührungspunkte mit der IT haben zu Zeiten der 54k-Modems stattgefunden. Der Game-Changer ISDN Kanalbündelung und die kostenlosen AOL Angebote haben das Interesse vertieft – ich war drin. Nach meiner Ausbildung zum IT-Systemkaufmann habe ich mich zunächst für ein Lehramtstudium entschieden, Schwerpunkt Mathe und natürlich Informatik. Über Umwege bin ich wieder im Systemhausgeschäft gelandet und seit 2016 Bestandteil der connecT FAMILIE. Ich bin froh und unfassbar stolz die Entwicklung mitzugestalten und seit 2020 dem Thema Backup einen Großteil meiner Zeit zu widmen.\n\nSie sehen gerade einen Platzhalterinhalt von reCAPTCHA . Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf den Button unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.\n\nInhalt entsperren Erforderlichen Service akzeptieren und Inhalte entsperren\nWeitere Informationen\n\nSie sehen gerade einen Platzhalterinhalt von reCAPTCHA . Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf den Button unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.\n\nInhalt entsperren Erforderlichen Service akzeptieren und Inhalte entsperren\nWeitere Informationen",
+    "content_type": "text/html",
+    "query": "Backup Repository Hardening – präventiv, resilient und im Vorfall erkennen, eindämmen und wiederherstellen aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.3342857142857143,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/4c76a2db74e17eae33e94cfb.json b/data/research-evidence/4c76a2db74e17eae33e94cfb.json
new file mode 100644
index 0000000..cc2eb06
--- /dev/null
+++ b/data/research-evidence/4c76a2db74e17eae33e94cfb.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:20:27.192472Z",
+  "content_sha256": "d8cc06230e5ccf421b75df83dd4f142fe70e86c599ab34b973f18973e376282e",
+  "result": {
+    "title": "BSI - Ransomware",
+    "url": "https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Gefaehrdungen/Fortschrittliche-Angriffe/Fortschrittliche-Angriffe_node.html",
+    "snippet": "Das BSI beobachtet jeden Tag die Bedrohungslage, die von neuen Schadprogrammen, erweiterten Angriffsmethoden oder gezieltem Vorgehen von Tätern für Unternehmen und Behörden ausgeht.",
+    "content": "Fortschrittliche Angriffe – dynamische Entwicklung\n\nDas BSI beobachtet jeden Tag die Bedrohungslage, die von neuen Schadprogrammen, erweiterten Angriffsmethoden oder gezieltem Vorgehen von Tätern für Unternehmen und Behörden ausgeht. In der jüngsten Zeit haben sich die Expertinnen und Experten im BSI-Lagezentrum und bei CERT-Bund zunehmend mit ausgefeilten Angriffstechniken auseinandersetzen müssen: Neue fortschrittliche Angriffe stellen ein vielfach höheres Bedrohungspotenzial dar, wenn sie beispielsweise in ein Unternehmensnetzwerk eindringen konnten. Eine Gesamtübersicht zum Thema Ransomware finden Sie unter Fakten und Abwehrstrategien .\n\nDigitale Erpressung mit Ransomware\n\nRansomware in seinen unterschiedlichen Varianten zielt in der Regel auf die Verschlüsselung von Nutzerdaten ab. Das Vorgehen der Täter zählt zu den fortschrittlichen Angriffen, deren Weiterentwicklung das BSI seit Jahren beobachtet. Nachdem Daten verschlüsselt wurden, wird ein Lösegeld erpresst. Die Daten werden erst nach Zahlung des meist digitalen Lösegelds wieder freigegeben, jedoch gibt es trotz Zahlung keine Garantie einen passenden Schlüssel zu erhalten. Mit Ransomware wurden bereits die unterschiedlichsten Organisationen Opfer eines Erpressungsversuchs: Großkonzerne, mittelständische Unternehmen bis hin zu Krankenhäusern.\n\nHohe Schäden durch Emotet\n\nDas Schadprogramm Emotet stellt einen möglichen Angriffsvektor dar. Es ist in der Lage, Kontaktbeziehungen aus Mail-Postfächern auszulesen und in der Folge automatisiert sehr authentische Spam-Mails zu verschicken. Die Folge ist ein hoher Verbreitungsgrad bei gleichzeitig vergleichsweise hoher Erfolgsquote bei der Infizierung von Unternehmensnetzwerken. Emotet und nachgeladene Malware haben so bereits hohe Schäden bei Betroffenen in Wirtschaft und Verwaltung verursacht – und tauchen regelmäßig mit neuen Funktionen wieder auf, um ergänzt durch weitere Techniken und Schadsoftware Schaden anzurichten.\n\nImmer neue Schadfunktionen\n\nFortschrittliche Angriffe zeichnen sich dadurch aus, dass sie Schadfunktionen, die früher bei ausgewählten Angriffen manuell eingesetzt wurden, heute breitflächig halbautomatisiert eingesetzt werden. Durch eine Vielfalt an Schadfunktionen geht von den fortschrittlichen Varianten eine deutlich größere Bedrohung aus. Neben der weiten Verbreitung durch immer bessere Spam-Mails durch Schadprogramme wie Emotet, gehen die Täter in vielen Fällen mittlerweile stufenweise vor. Während vor einiger Zeit noch einzelne Computer verschlüsselt wurden und Lösegeld pro verschlüsseltem PC verlangt wurde, werden heute betroffene Unternehmensnetzwerke zunächst gezielt ausspioniert. Dabei werden oftmals Daten ausgeleitet und eine Bewertung des jeweiligen Opfers vorgenommen. Die Täter passen ihre Lösegeldforderung dann der betroffenen Organisation an. Die Verschlüsselung erfolgt oftmals gezielt und kann dabei auch vorhandene Back-ups umfassen. Die Unternehmensnetzwerke sind häufig vollständig kompromittiert. Die zuvor ausgeleiteten Daten werden oftmals zur Erhöhung des Handlungsdrucks bei den Opfern eingesetzt, indem eine Veröffentlichung oder ein Weiterverkauf der Daten angedroht wird, sollte das Lösegeld für die verschlüsselten Daten nicht gezahlt werden. Die Bereinigung der betroffenen Netzwerke kann abhängig von der Größe des betroffenen Netzwerks Monate in Anspruch nehmen. Zuletzt wurde in mehreren Fällen bei Nicht-Zahlung mit der Veröffentlichung von zuvor gestohlenen Daten gedroht und teilweise auch durchgeführt.\n\nVor diesem Hintergrund wird konsequentes präventives Handeln immer wichtiger. Das BSI hat die Bewertung der Lage sowie die wichtigsten präventiven Maßnahmen in folgenden Dokumenten zusammengefasst.\n\nWenn es bereits zu einem IT-Sicherheitsvorfall gekommen ist, hat das BSI zahlreiche Erste-Hilfe-Maßnahmen zusammengestellt.\n\nZum Thema\n\nRansomware Angriffe\n\nRansomware – Vorsicht vor Erpressersoftware\n\nDownload Ransomware: Managementabstract Fortschrittliche Angriffe (PDF)\n\nDownload Ransomware: Bedrohungslage 2022 (PDF)\n\nDownload Maßnahmenkatalog Ransomware (PDF)\n\nDownload Ransomware: Erste Hilfe bei einem schweren IT-Sicherheitsvorfall Version 1.2 (PDF)\n\nEmotet\n\nÄhnliche Themen\n\nSocial Engineering\n\nAPT\n\nMalware\n\nDDoS\n\nGefahr durch Drohnen\n\nZurück zu Cyber-Sicherheitsempfehlungen nach Gefährdungen\n\nKurz-URL:\n\nhttps://www.bsi.bund.de/dok/fortschrittliche-angriffe",
+    "content_type": "text/html",
+    "query": "Ransomware Detection \u0026 Forensics – präventiv, resilient und Vorfall-basiert gestalten aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "authoritative",
+    "source_quality_score": 0.95,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/4f6c51f58d4e4ddcccd1f79b.json b/data/research-evidence/4f6c51f58d4e4ddcccd1f79b.json
new file mode 100644
index 0000000..8841b64
--- /dev/null
+++ b/data/research-evidence/4f6c51f58d4e4ddcccd1f79b.json
@@ -0,0 +1,25 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:23:40.7153377Z",
+  "content_sha256": "79afafd4f7139cfedac96641fc45df581cf47db82b4d434e9bd41c42bbd43552",
+  "result": {
+    "title": "Dataset Integrity — Control Definition and AI Governance Guide | Synthetic Data News",
+    "url": "https://syntheticdatanews.com/ai-governance/dataset-integrity",
+    "snippet": "This page covers what dataset integrity is, how it works in AI pipelines, and how it maps to specific governance obligations. Practical implementation guidance follows each conceptual section.",
+    "content": "Dataset Integrity is a control in AI governance that assurance that a dataset has not been altered unexpectedly and matches its recorded identity.\n\nAs AI systems become subject to increasing regulatory scrutiny — from the EU AI Act to NIST AI RMF — the role of dataset integrity in governance architecture has become a prerequisite, not an option. Teams that implement dataset integrity early reduce downstream compliance risk and build the audit evidence regulators expect.\n\nThis page covers what dataset integrity is, how it works in AI pipelines, and how it maps to specific governance obligations. Practical implementation guidance follows each conceptual section.\n\nWhat Is Dataset Integrity?\n\nDataset Integrity refers to assurance that a dataset has not been altered unexpectedly and matches its recorded identity. In AI governance contexts, this means establishing structured processes that produce verifiable, auditable records — not informal practices that exist only in team knowledge. The distinction matters when regulators or auditors request evidence of governance controls.\n\nHow Dataset Integrity Works in AI Pipelines\n\nIn a typical AI pipeline, dataset integrity occurs at the intersection of data management, model development, and deployment governance. The process begins with establishing baseline records — documented inputs, generation parameters, or decision context — and continues through a chain of custody that links each artifact to its governance history. Tools that implement dataset integrity typically provide APIs or export formats for downstream verification.\n\nCertifiedData.io provides cryptographic certification infrastructure for synthetic datasets and AI artifacts, producing tamper-evident records for audit and EU AI Act compliance.\n\nRegulatory Alignment\n\nDataset Integrity maps directly to record-keeping and data governance obligations in the EU AI Act (Articles 10, 12, and 19), the NIST AI Risk Management Framework Govern function, and ISO AI governance guidelines. For high-risk AI systems, documented evidence of dataset integrity is not advisory — it is a condition of compliance. Teams operating under these frameworks should treat dataset integrity as a first-class governance output.\n\nImplementation Considerations\n\nImplementing dataset integrity effectively requires deciding where in the pipeline records are generated, how they are stored and referenced, and what verification processes confirm their integrity. Common failure modes include generating records too late in the pipeline (after artifacts have already been deployed), storing records without cryptographic binding to artifacts, and omitting version or dependency context that auditors will later request.\n\nDataset Integrity and the AI Trust Stack\n\nDataset Integrity is one layer of a broader AI trust infrastructure. On its own, dataset integrity establishes a record. Combined with verification, provenance tracking, and public certificate transparency, it becomes part of a defensible governance posture. The AI Trust Stack model positions dataset integrity as foundational infrastructure rather than a compliance checkbox.",
+    "content_type": "text/html",
+    "query": "AI Dataset Integrity und AI Dataset Lineage sind eng verwandt, aber unterschiedliche Konzepte. Beide erfordern Sicherheitsmaßnahmen, aber mit unterschiedlichem Fokus. Ein gemeinsamer Artikel könnte die Sicherheitsaspekte beider Themen konsolidieren und eine umfassendere Anleitung bieten. aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "actionable": true,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/587cf7de5497217afbbe3b2e.json b/data/research-evidence/587cf7de5497217afbbe3b2e.json
new file mode 100644
index 0000000..9c613e8
--- /dev/null
+++ b/data/research-evidence/587cf7de5497217afbbe3b2e.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:15:48.9140014Z",
+  "content_sha256": "5cab7c20a751e6842cf6344acdd99a7f9c0f09df199deff850a946906d70636e",
+  "result": {
+    "title": "Backup Hardening: Warum eine gehärtete Backup-Umgebung essenziell ist",
+    "url": "https://blog.bithawk.ch/it-security/backup-hardening-warum-eine-geh%C3%A4rtete-backup-umgebung-essenziell-ist",
+    "snippet": "Warum ist Backup Hardening so wichtig? Backups sind das letzte Sicherheitsnetz jeder IT-Infrastruktur. Doch ohne ausreichende Härtung sind sie oft das primäre Ziel von Angreifern.",
+    "content": "Backup Hardening: Warum eine gehärtete Backup-Umgebung essenziell ist\n\nServices\n\nInnovation\n\nConsulting\n\nEngineering\n\nOperation\n\nTechnolgy\n\nService Management\n\nEnterprise Service Management\n\nService Management\n\nBusiness Management\n\nOperation Management\n\nService Now Plattform\n\nHR Service Management\n\nPartner\n\nMicrosoft\n\nHewlett Packard Enterprise\n\nCisco\n\nServiceNow\n\nHP Inc.\n\nWeitere Partner\n\nUnternehmen\n\nAbout us\n\nJobs\n\nNews \u0026 Events\n\nGeschäftsleitung\n\nReferenzen\n\nAuszeichnungen\n\nStandorte \u0026 Kontakt\n\nBlog\n\nBackup Hardening: Warum eine gehärtete Backup-Umgebung essenziell ist\n\nErstellt von\nMarkus Schober am 25.03.2025 08:00:00\n\nTweet\n\nWarum ist Backup Hardening so wichtig? Backups sind das letzte Sicherheitsnetz jeder IT-Infrastruktur. Doch ohne ausreichende Härtung sind sie oft das primäre Ziel von Angreifern. Ransomware-Gruppen und Bedrohungsakteure fokussieren sich zunehmend auf Backup-Systeme, um eine Wiederherstellung zu verhindern und so den Druck auf Unternehmen zu erhöhen. Eine umfassende Backup-Hardening-Strategie ist daher unerlässlich, um diese kritischen Daten gegen Manipulation, Löschung oder Verschlüsselung zu schützen.\n\nWas umfasst Backup Hardening?\n\nUnser Ansatz für Backup Hardening basiert auf zwei wesentlichen Komponenten:\n\n1. VEEAM Hardening\n\nVEEAM ist eine der führenden Backup-Lösungen, aber auch hier müssen gezielte Sicherheitsmassnahmen getroffen werden:\n\nNetzwerkverkehr: Dieser muss zwingend verschlüsselt erfolgen\n\nImmutable Backups: Unveränderliche Backups verhindern, dass Daten nachträglich manipuliert oder gelöscht werden.\n\nHärtung des Backup-Storage: Backup-Daten sollten auf dedizierten, gehärteten Speichersystemen gesichert werden.\n\nMinimalrechteprinzip: Backup-Server und Dienste sollten nur mit den notwendigsten Rechten betrieben werden.\n\nDeaktivierung nicht benötigter Dienste: Reduzieren Sie potenzielle Angriffsflächen, indem Sie sicherheitsgefährdete Dienste abschalten, sofern sie nicht erforderlich sind.\n\nEinsatz von Multi-Faktor-Authentifizierung (MFA): Schützen Sie den Zugriff auf die Backup-Konsole durch zusätzliche Sicherheitsfaktoren.\n\nEinhaltung der 3-2-1-Backup-Regel: Bewahren Sie mindestens drei Kopien Ihrer Daten auf zwei verschiedenen Medien auf, wobei eine Kopie extern gelagert wird.\n\nDeaktivierung veralteter Protokolle: Legacy-Protokolle, unsichere Hashing-Methoden und schwache Verschlüsselungsalgorithmen stellen ein erhebliches Sicherheitsrisiko dar. Durch die gezielte Abschaltung dieser veralteten Technologien wird das Angriffsrisiko erheblich reduziert.\n\n2. OS Hardening – Microsoft, CIS und Bithawk Policies\n\nEin sicher konfiguriertes Betriebssystem ist die Grundlage für jede Backup-Sicherheit. Hier setzen wir auf bewährte Hardening-Frameworks:\n\nMicrosoft Security Baselines: Best Practices für Windows Server, um bekannte Schwachstellen zu eliminieren.\n\nCIS-Hardening Level 1: Empfehlungen des Center for Internet Security (CIS) zur Minimierung von Angriffsmöglichkeiten.\n\nBithawk Hardening Policies: Spezialisierte Hardening-Massnahmen für Backup-Server, um höchste Sicherheitsstandards zu gewährleisten.\n\nLieferobjekt: CIS Level 1 Scan für eine geprüfte Sicherheit\n\nNach der Implementierung der Hardening-Massnahmen führen wir einen CIS Level 1 Scan mit dem CIS-CAT Pro Assessor durch. Dieser Scan stellt sicher, dass die Sicherheitsrichtlinien gemäss dem offiziellen CIS Framework eingehalten werden. Am Ende erhalten Sie ein Abnahme-Assessment-Dokument , das den Erfolg der Massnahmen bestätigt und als Nachweis für Compliance-Zwecke dient.\n\nFazit: Sicherheit beginnt mit einem gehärteten Backup.\n\nEin ungesichertes Backup ist ein leichtes Ziel. Durch eine Kombination aus VEEAM Hardening und OS Hardening schaffen wir eine widerstandsfähige Umgebung, die selbst modernen Angriffsmethoden standhält. Unternehmen sollten ihre Backup-Strategie regelmässig prüfen und härten, um ihre Daten vor Bedrohungen zu schützen – denn nur ein sicheres Backup ist ein nutzbares Backup.\n\n🚀 Sind Ihre Backups bereits ausreichend geschützt? Lassen Sie uns gemeinsam Ihr Sicherheitsniveau analysieren und verbessern.\n\nNehmen Sie mit uns Kontakt auf. Sie erreichen uns unter marketing@bithawk.ch oder telefonisch unter 058 226 01 01. Unsere Experten helfen Ihnen gerne weiter.\n\nWeitere Themen auf unserem Blog\n\nDer Copilot Chat: Neue Dimensionen der Zusammenarbeit mit Agents\nConditional Access für Active Directory\nSchützen Sie Ihre Entra ID Notfallkonten\n\nThemen:\nIT Security\n\nBitHawk AG\n\nAllee 1A\n\n6210 Sursee\n\nT +41 58 226 00 00\n\nNewsletter abonnieren\n\nAGB\n\nImpressum\n\nRechtliches\n\nRetail Solutions\n\nDigital Signage\n\nCloud Backup\n\nIT Security\n\nBitHawk AG\n\nAllee 1A\n\n6210 Sursee\n\nT +41 58 226 00 00\n\nRetail Solutions\n\nDigital Signage\n\nCloud Backup\n\nIT Security\n\nNewsletter abonnieren\n\nAGB\n\nImpressum\n\nRechtliches",
+    "content_type": "text/html",
+    "query": "Backup Repository Hardening – präventiv, resilient und im Vorfall erkennen, eindämmen und wiederherstellen current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/5ae731683234892cd21cd5f9.json b/data/research-evidence/5ae731683234892cd21cd5f9.json
new file mode 100644
index 0000000..a11e1d2
--- /dev/null
+++ b/data/research-evidence/5ae731683234892cd21cd5f9.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:06:27.2323458Z",
+  "content_sha256": "4bfe54d7d539c9522e2cc538a590028e7d4e667a6785d45e109c95d7aaef36b5",
+  "result": {
+    "title": "Cloud Security Response: Anwendung, typische Fehler, Praxiswissen und saubere Workflows",
+    "url": "https://hacking-kurse.de/it-security-websecurity/cloud-security-response",
+    "snippet": "Cloud Security Response praxisnah erklärt: Incident Handling in AWS, Azure und hybriden Umgebungen, typische Fehler, Forensik, Containment, Recovery und belastbare Workflows.",
+    "content": "Cloud Security Response: Anwendung, typische Fehler, Praxiswissen und saubere Workflows\n\nCloud Security Response ist kein klassischer Incident-Response-Prozess mit anderem Namen\n\nCloud Security Response bedeutet, Sicherheitsvorfälle in dynamischen, API-gesteuerten und stark identitätsbasierten Umgebungen zu erkennen, einzugrenzen, zu analysieren und kontrolliert zu beheben. Der größte Denkfehler besteht darin, Cloud-Vorfälle wie klassische Server-Incidents im Rechenzentrum zu behandeln. In der Cloud ist nicht nur die Workload relevant, sondern vor allem die Steuerungsebene: IAM-Rollen, Tokens, Service Principals, Storage Policies, Security Groups, Snapshot-Rechte, KMS-Berechtigungen, CI/CD-Zugänge und die Frage, wer über welche API was verändert hat.\n\nEin kompromittierter Linux-Host in einer VM ist in der Cloud selten das eigentliche Kernproblem. Häufig ist er nur Symptom eines größeren Kontrollverlusts. Wenn ein Angreifer Zugriff auf ein Build-System, einen Access Key oder eine privilegierte Rolle erlangt, kann er neue Instanzen starten, Logs manipulieren, Snapshots exfiltrieren, Backups löschen oder Persistenz über Identitäten aufbauen. Genau deshalb muss Cloud Response immer mit Cloud Security Identity , Cloud Security Iam und Cloud Security Logging zusammengedacht werden.\n\nDie operative Realität ist unbequem: Ressourcen entstehen und verschwinden in Minuten, Container leben nur kurz, Serverless-Funktionen hinterlassen kaum klassische Artefakte, und zentrale Beweise liegen oft nicht auf dem kompromittierten System, sondern in Audit-Logs, Control-Plane-Events, Netzwerk-Telemetrie und Objektzugriffsprotokollen. Wer in dieser Lage zuerst nur den Host isoliert, ohne die Identität zu sperren, verliert Zeit und oft auch die Kontrolle.\n\nCloud Response ist außerdem eng mit Detection verknüpft. Ohne belastbare Erkennung ist Response nur hektische Reaktion auf Symptome. Deshalb greifen Incident Handling und Cloud Security Detection direkt ineinander. Gute Teams definieren vorab, welche Signale kritisch sind: ungewöhnliche API-Aufrufe, Deaktivierung von Logging, Massenabfragen von Secrets, das Anlegen neuer Schlüssel, Änderungen an Netzwerkpfaden, verdächtige Storage-Exporte oder das Erzeugen ungewöhnlicher Compute-Ressourcen in fremden Regionen.\n\nEin sauberer Response-Prozess in der Cloud folgt nicht blind einem Lehrbuch, sondern orientiert sich an drei Fragen: Was wurde kompromittiert, welche Steuerungsmöglichkeiten hat der Angreifer aktuell und welche Beweise gehen verloren, wenn jetzt falsch reagiert wird? Diese Reihenfolge verhindert Aktionismus. Erst wenn klar ist, ob es sich um einen Workload-Fall, einen Identitätsfall, einen Datenfall oder einen Plattformfall handelt, lässt sich Containment sinnvoll priorisieren.\n\nIn Multi-Cloud-Umgebungen verschärft sich das Problem. AWS, Azure und GCP liefern ähnliche Konzepte, aber unterschiedliche Telemetrie, andere Standardrechte, andere Logging-Pfade und andere Stolperfallen. Wer Response standardisieren will, braucht gemeinsame Prinzipien, aber provider-spezifische Playbooks. Ein Team, das in Cloud Security Aws geübt ist, reagiert nicht automatisch sauber in Cloud Security Azure . Die Unterschiede liegen nicht nur in Menüs und APIs, sondern in der Art, wie Identitäten, Ressourcenhierarchien und Audit-Daten modelliert sind.\n\nCloud Security Response ist damit kein Zusatzmodul, sondern der operative Härtetest der gesamten Sicherheitsarchitektur. Schlechte Rollenmodelle, fehlende Segmentierung, unvollständige Logs, unklare Verantwortlichkeiten und improvisierte Freigaben werden im Incident sofort sichtbar. Gute Response beginnt deshalb lange vor dem Vorfall: mit Architektur, Logging, Berechtigungsdesign, Übung und klaren Eskalationswegen.\n\nFeatured Empfehlung: Cybersecurity strukturiert lernen\n\n★ FEATURED\n\nEmpfohlener Bereich auf Hacking-Kurse.de\n\nLernpfade für Ethical Hacking, Pentesting und IT-Security\n\nStarte strukturiert in die Cybersecurity und lerne Schritt für Schritt, wie Angreifer denken, wie Schwachstellen entstehen und wie Sicherheitsanalysen praktisch durchgeführt werden.\n\nDie Lernpfade auf Hacking-Kurse.de richten sich an Einsteiger, Fortgeschrittene und alle, die Ethical Hacking, Red Teaming oder IT-Security nicht nur oberflächlich verstehen möchten.\n\nZu den Lernpfaden\n\nDer reale Ablauf eines Cloud-Incidents beginnt fast immer mit Identität, Telemetrie und Scope\n\nDer erste operative Schritt ist nicht das Löschen verdächtiger Ressourcen, sondern die Stabilisierung der Lage. Dazu gehört, den Incident-Typ grob einzuordnen. Handelt es sich um kompromittierte Credentials, eine Fehlkonfiguration mit Datenexposition, eine missbrauchte CI/CD-Pipeline, einen Container-Ausbruch, eine Webanwendung mit Cloud-Folgen oder einen Insider-Fall? Diese Einordnung bestimmt, welche Datenquellen zuerst gesichert werden müssen.\n\nEin belastbarer Triage-Ablauf in der Cloud priorisiert immer Scope vor Detailtiefe. Zuerst muss sichtbar werden, welche Accounts, Subscriptions, Projekte, Tenants, Regionen, VPCs, VNets, Cluster, Buckets, Key Vaults, Rollen und Service Accounts betroffen sein könnten. Ohne diese Übersicht wird jede Maßnahme riskant. Ein zu enger Fokus auf eine einzelne VM führt oft dazu, dass parallele Persistenzmechanismen übersehen werden.\n\nPraktisch bewährt sich eine Triage entlang weniger Kernachsen:\n\nIdentität: Welche Benutzer, Rollen, Tokens, Access Keys, Service Principals oder Federation-Pfade sind betroffen?\n\nSteuerungsebene: Welche API-Aufrufe wurden ausgeführt, welche Policies geändert, welche Logs deaktiviert, welche Ressourcen neu angelegt?\n\nDatenebene: Welche Buckets, Datenbanken, Snapshots, Volumes oder Secrets wurden gelesen, kopiert, exportiert oder gelöscht?\n\nNetzwerkebene: Welche Verbindungen, Egress-Ziele, Peering-Änderungen, Security-Group-Regeln oder Load-Balancer-Anpassungen sind auffällig?\n\nDiese Struktur verhindert blinde Flecken. Ein Beispiel: Ein Alarm meldet verdächtige Shell-Kommandos auf einer Compute-Instanz. Wer nur den Host untersucht, übersieht möglicherweise, dass kurz zuvor über eine kompromittierte Rolle neue API-Schlüssel erzeugt, Logging-Policies geändert und Objekte aus einem Storage-Bucket exportiert wurden. Der Host ist dann nur ein Teil des Angriffswegs.\n\nCloud-Triage braucht außerdem Zeitsynchronität. Unterschiedliche Dienste loggen mit verschiedenen Zeitformaten, Verzögerungen und Granularitäten. Wenn Audit-Logs, Flow-Logs, Container-Events und Anwendungslogs nicht sauber korreliert werden, entstehen falsche Kausalitäten. Ein häufiger Fehler ist, eine verdächtige Aktion als Ursache zu interpretieren, obwohl sie nur Folge einer früheren Identitätsübernahme war. Deshalb ist eine saubere Zeitachsenanalyse unverzichtbar, ähnlich wie in Forensik Incident Response und Forensik Log Analyse .\n\nEin weiterer Punkt: In Cloud-Umgebungen ist Ownership oft verteilt. Das Plattform-Team verwaltet Landing Zones, das DevOps-Team Pipelines, Fachbereiche betreiben SaaS-Integrationen, Security betreut Detection, und externe Dienstleister besitzen Teilzugänge. Response scheitert häufig nicht an Technik, sondern an unklaren Zuständigkeiten. Wenn niemand sofort sagen kann, wem ein Service Principal gehört oder welche Anwendung hinter einer Rolle steckt, verzögert sich Containment massiv.\n\nDeshalb muss Triage nicht nur technische Daten sammeln, sondern auch Kontext: Business Owner, Kritikalität, Abhängigkeiten, Recovery-Fenster, regulatorische Relevanz und mögliche Seiteneffekte von Sperrmaßnahmen. Ein kompromittiertes Konto mit Produktionsrechten darf nicht ohne Rückfallplan deaktiviert werden, wenn dadurch kritische Prozesse ausfallen. Gleichzeitig darf diese Abhängigkeit kein Vorwand sein, einen aktiven Angreifer weiterarbeiten zu lassen. Genau hier trennt sich improvisierte Reaktion von professioneller Cloud Response.\n\nContainment in der Cloud heißt Rechte, Tokens, Netzwerkpfade und Automatisierung kontrolliert zu brechen\n\nContainment ist in Cloud-Umgebungen deutlich heikler als auf klassischen Einzelservern. Wer eine kompromittierte Ressource einfach stoppt oder löscht, vernichtet oft Beweise, unterbricht Geschäftsprozesse und lässt den eigentlichen Angriffsvektor unangetastet. Das Ziel von Containment ist nicht maximale Härte, sondern kontrollierte Reduktion der Angriffsoptionen bei gleichzeitigem Erhalt verwertbarer Spuren.\n\nDie wichtigste Regel lautet: Identitätsbasierte Persistenz zuerst prüfen. Wenn ein Angreifer über IAM, Federation, Access Keys, OAuth-Consent, Service Principals oder temporäre Tokens arbeitet, bringt die Isolation einer VM wenig. In vielen Fällen ist das wirksamste erste Containment die Deaktivierung oder Rotation kompromittierter Identitäten, das Entziehen privilegierter Rollen, das Sperren verdächtiger Sessions und das Erzwingen neuer Secrets. Das muss aber abgestuft erfolgen. Eine überhastete globale Schlüsselrotation kann produktive Systeme brechen, wenn Abhängigkeiten unbekannt sind.\n\nNetzwerk-Containment bleibt trotzdem relevant. Security Groups, NSGs, Firewall-Regeln, Egress-Filter, Private Endpoints und Segmentierung können den Bewegungsraum des Angreifers stark einschränken. Besonders bei Datenabfluss zählt jede Minute. Wenn bereits Exfiltration läuft, ist das Blockieren von Egress-Pfaden oft dringlicher als die tiefe Host-Analyse. In solchen Fällen greifen Prinzipien aus Netzwerksicherheit Segmentierung und Netzwerksicherheit Monitoring direkt in die Cloud Response hinein.\n\nEin oft unterschätzter Bereich ist Automatisierung. Angreifer missbrauchen nicht nur bestehende Ressourcen, sondern auch Pipelines, Infrastructure-as-Code, Runbooks, Functions und Deployment-Mechanismen. Wenn eine kompromittierte Pipeline weiterhin automatisch Artefakte ausrollt oder Policies zurücksetzt, wird jedes manuelle Containment unterlaufen. Deshalb müssen im Incident auch CI/CD-Trigger, Git-Zugänge, Build-Secrets und Deployment-Identitäten geprüft werden. Das ist eng mit Cloud Security Devsecops verbunden.\n\nSauberes Containment folgt einer Reihenfolge, die technische Wirkung und Beweiserhalt ausbalanciert. Ein typischer Ablauf kann so aussehen:\n\n1. Alarm validieren und Scope grob eingrenzen\n2. Kritische Logs und Zustände sichern\n3. Kompromittierte Identitäten priorisieren\n4. Aktive Sessions, Tokens und Schlüssel kontrolliert entwerten\n5. Egress und laterale Pfade begrenzen\n6. Persistenzmechanismen identifizieren\n7. Betroffene Workloads isolieren, aber nicht vorschnell zerstören\n8. Recovery-Pfad vorbereiten, bevor produktive Abhängigkeiten getrennt werden\n\nIn Container- und Kubernetes-Umgebungen ist Containment noch spezieller. Ein kompromittierter Pod ist oft austauschbar, aber das Cluster, die Registry, die Admission Controls, die Service Accounts und die Secrets sind es nicht. Wer nur Pods neu startet, ohne kompromittierte Images, Tokens oder Cluster-Rollen zu bereinigen, erzeugt Scheinsicherheit. Deshalb müssen Fälle mit Cloud Security Container und Cloud Security Kubernetes anders behandelt werden als klassische VM-Incidents.\n\nContainment ist erfolgreich, wenn der Angreifer keine wirksame Handlungsoption mehr hat, ohne dass die Organisation blind geworden ist. Genau deshalb dürfen Logging, Snapshotting und forensische Sicherung nicht durch hektische Gegenmaßnahmen zerstört werden. Ein Incident ist nicht beendet, wenn die auffällige Ressource weg ist, sondern wenn der Angriffsweg, die Persistenz und die missbrauchten Berechtigungen nachvollziehbar unter Kontrolle sind.\n\nSponsored Links\n\nForensik in Cloud-Umgebungen scheitert meist nicht an Tools, sondern an fehlender Vorbereitung\n\nCloud-Forensik ist kein simples Kopieren klassischer Disk-Images in eine neue Umgebung. Die entscheidenden Artefakte liegen verteilt: Control-Plane-Logs, IAM-Änderungen, Objektzugriffe, Netzwerkflüsse, Container-Runtime-Ereignisse, Serverless-Ausführungen, Secrets-Zugriffe, Snapshot-Metadaten und Anwendungslogs. Wer erst im Incident feststellt, dass Audit-Logs nicht zentral, nicht unveränderbar oder nur kurz aufbewahrt werden, hat bereits verloren.\n\nDie wichtigste Vorbereitung ist deshalb ein belastbares Logging-Design. Audit-Logs müssen tenant-weit aktiviert, zentral gesammelt, gegen Manipulation geschützt und ausreichend lange aufbewahrt werden. Zusätzlich braucht es Datenquellen für Netzwerk, Identität, Storage und Workloads. Nur so lässt sich später beantworten, ob ein Angreifer lediglich eine Rolle aufgelistet oder tatsächlich Daten gelesen und exportiert hat. Für diese Sicht sind Cloud Security Monitoring und Security Monitoring Logs keine Komfortfunktionen, sondern Beweisinfrastruktur.\n\nEin häufiger Fehler ist die Vermischung von Betriebslogs und Beweislogs. Betriebslogs helfen beim Debugging, reichen aber selten für Incident-Aufklärung. Forensisch relevante Daten müssen nachvollziehbar, vollständig und zeitlich konsistent sein. Dazu gehören unveränderbare Speicherorte, definierte Zugriffsrechte und klare Prozesse, wer wann welche Daten exportieren darf. In sensiblen Fällen spielt auch die Nachvollziehbarkeit der Beweiskette eine Rolle, wie sie in Forensik Beweissicherung und It Security Chain Of Custody behandelt wird.\n\nBei Compute-Instanzen ist die Versuchung groß, sofort interaktiv auf das System zuzugreifen. Das kann sinnvoll sein, verändert aber den Zustand. Besser ist ein abgestufter Ansatz: Snapshot der Volumes, Sicherung flüchtiger Daten wenn möglich, Export relevanter Logs, Dokumentation des aktuellen Netzwerk- und Prozesszustands und erst dann tiefergehende Live-Analyse. In der Cloud ist dabei immer zu prüfen, welche Provider-Funktionen Metadaten verändern oder Zugriffszeiten aktualisieren.\n\nBei serverlosen Diensten und Managed Services ist klassische Host-Forensik oft kaum möglich. Dann verschiebt sich der Fokus vollständig auf Telemetrie und Konfigurationszustände. Wer hat welche Funktion deployed, welche Umgebungsvariablen geändert, welche Secrets referenziert, welche Datenbank-Exports gestartet, welche Rollen zugewiesen? Gerade bei Managed Services ist die An",
+    "content_type": "text/html",
+    "query": "Cloud IAM, Cloud Secrets, Cloud Service Accounts, Cloud Incident Response, Cloud Access Review, Perfect Forward Secrecy – ein einheitliches, thematisch verknüpftes Handbuch zur Sicherheitspraxis in Cloud-Umgebungen mit Fokus auf Monitoring, Forensik und Sicherheitsmaßnahmen current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.28,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/5b5da3cc89771e07086d9f82.json b/data/research-evidence/5b5da3cc89771e07086d9f82.json
new file mode 100644
index 0000000..66489c4
--- /dev/null
+++ b/data/research-evidence/5b5da3cc89771e07086d9f82.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:43:39.9263703Z",
+  "content_sha256": "2ed136320d24a2ec4a27414944ba6acebe53c01fea25caf97d012e602ac3775d",
+  "result": {
+    "title": "Wayland (Display-Server-Protokoll) – Wikipedia",
+    "url": "https://de.wikipedia.org/wiki/Wayland_(Display-Server-Protokoll)",
+    "snippet": "Bereits Ende 2023 dachten die Gnome-Entwickler öffentlich darüber nach, die Unterstützung für X.org komplett zu streichen [8] und gaben Mitte 2025 bekannt, die angekündigte Streichung von X11 umzusetzen.",
+    "content": "aus Wikipedia, der freien Enzyklopädie\n\n\"},\"AktuelleVersion\":{\"wt\":\"\u003c!-- Wikidata --\u003e\"},\"AktuelleVersionFreigabeDatum\":{\"wt\":\"\u003c!-- Wikidata --\u003e\"},\"Programmiersprache\":{\"wt\":\"[[C (Programmiersprache)|C]]\"},\"Betriebssystem\":{\"wt\":\"[[Linux]], [[FreeBSD]], [[DragonFly BSD]], [[OpenBSD]]\"},\"Deutsch\":{\"wt\":\"nein\"},\"Kategorie\":{\"wt\":\"[[Display-Server-Protokoll]], [[Fenstersystem]]\"},\"Lizenz\":{\"wt\":\"[[MIT-Lizenz]]\"},\"Website\":{\"wt\":\"[https://wayland.freedesktop.org/ wayland.freedesktop.org]\"}},\"i\":0}}]}'\u003e\n\nWayland\n\nWayland-Demonstration\n\nBasisdaten\n\nEntwickler\n\nKristian Høgsberg\n\nErscheinungsjahr\n\n2008\n\nAktuelle   Version\n\n1.26.0 [ 1 ]\n( 16. Juli 2026 )\n\nAktuelle Vorabversion\n\n1.22.91 [ 2 ]\n( 25. April 2024 )\n\nBetriebssystem\n\nLinux , FreeBSD , DragonFly BSD , OpenBSD\n\nProgrammier ­ sprache\n\nKategorie\n\nDisplay-Server-Protokoll , Fenstersystem\n\nLizenz\n\nMIT-Lizenz\n\ndeutschsprachig\n\nnein\n\nwayland.freedesktop.org\n\nWayland ist ein Display-Server-Protokoll für Linux und andere unixoide Betriebssysteme . Seine Hauptaufgabe ist das Rendern von Fenstern auf einer Bitmap . [ 3 ] Es beschreibt die Kommunikation zwischen einem Display-Server und seinen Clients (üblicherweise die Anwendungen des Nutzers). Der Server wird Wayland-Compositor genannt, da er zusätzlich die Funktion eines Compositing Window Managers übernimmt. Ziel von Wayland ist es, dem Programmierer ein leichter zu wartendes Display-Server-Protokoll als den bisherigen X-Window-Server bereitzustellen und die Sicherheit zu erhöhen. [ 4 ] Anwendungen, die noch vom X-Server abhängig sind, können mithilfe von XWayland auch unter einem Wayland-Compositor genutzt werden. [ 5 ]\n\nDie beiden verbreiteten Linux-Desktops Gnome und KDE Plasma entwickelten eine Zeit lang parallel an den Unterstützungen für jeweils X.org und Wayland. Seit ca. 2023/2024 setzen beide verstärkt auf Wayland, und auch einige weitere Unix-Desktops, die bis dahin nur für das traditionelle X Window System „X11“ verfügbar waren, werden seither für Wayland angepasst, wie z.   B. Cinnamon [ 6 ] und Xfce . [ 7 ] Bereits Ende 2023 dachten die Gnome-Entwickler öffentlich darüber nach, die Unterstützung für X.org komplett zu streichen [ 8 ] und gaben Mitte 2025 bekannt, die angekündigte Streichung von X11 umzusetzen. Die verbreiteten Linux-Distributionen Ubuntu Desktop und Kubuntu werden ab Version 25.10 nur noch mit Wayland-Unterstützung ausgeliefert. [ 9 ] [ 10 ] Auch KDE startet ab Plasma   6 per Voreinstellung als Wayland-Sitzung, [ 11 ] ursprünglich sollte X11 jedoch weiterhin alternativ zur Verfügung stehen. [ 10 ] Ende 2025 kündigten allerdings auch die KDE-Entwickler an, mit der für 2026 geplanten Version von Plasma 6.8 nur noch Wayland unterstützen zu wollen. [ 12 ]\n\nEntwicklung\n[ Bearbeiten | Quelltext bearbeiten ]\n\nBegonnen wurde das Softwareentwicklungsprojekt für Wayland von Kristian Høgsberg, einem Mitglied von Intels Open Source Technology Center (OSTC). [ 13 ] [ 14 ] Unter Linux versteht sich Wayland als eine Alternative zum und Nachfolger vom X-Window-System, wobei letzteres weiterhin auf allen unixoiden Betriebssystemen lauffähig ist. Das von Kristian Høgsberg erklärte Ziel für die Software lautete:\n\n[http://www.phoronix.com/scan.php?page=article\u0026item=xorg_wayland\u0026num=1 ''Wayland: A New X Server for Linux''.] Phoronix, 3. November 2008 (englisch) abgerufen am 21. April 2013.\u003c/ref\u003e\u003cref name=\\\"h-online.wayland.6-nov-2008\\\"\u003e{{Webarchiv |url=http://www.h-online.com/newsticker/news/item/New-Wayland-X-server-looks-to-how-a-modern-desktop-works-737993.html |text=''New Wayland X Server Looks to How a Modern Desktop works''. |wayback=20131029204058}} The H, 6. November 2008 (englisch) abgerufen am 21. April 2013.\u003c/ref\u003e\"}},\"i\":0}}]}'\u003e\n\n„[…] jeder Frame ist perfekt, und damit meine ich, dass alle Applikationen in der Lage sein werden, das Rendering so zu kontrollieren, dass wir niemals Tearing , instabile Bildwiederholfrequenzen , Redraw-Artefakte oder Flimmern sehen werden.“\n\n– Wayland: A New X Server for Linux . Phoronix [ 15 ] [ 16 ]\n\nAufbau\n[ Bearbeiten | Quelltext bearbeiten ]\n\nDas Wayland-Display-Server-Protokoll\n\nUnter X11 ist ein Extra-Programm, der Fenstermanager , für die Fensterdekoration ( Titelleiste , Rahmen usw.) aller Fenster zuständig. Unter Wayland werden die Funktionen des Displayservers [ 17 ] und des Fenstermanagers im Wayland Compositor zusammengefasst; die Kommunikation zwischen den beiden entfällt somit. Nach wie vor kann jeder Client seine eigenen Fensterdekorationen zeichnen, oder sie können zentral vom Compositor gezeichnet werden. Weston , die Referenzimplementierung des Wayland Compositors, verlangt Client-seitige Fensterdekorationen, KWin , der Fenstermanager der Desktopumgebung von KDE , sorgt für Server-seitige.\n\nWayland-Display-Server-Protokoll\n[ Bearbeiten | Quelltext bearbeiten ]\n\nDas Wayland-Display-Server-Protokoll definiert, dass die angezeigte Grafik durch die Clients erstellt wird. Im Gegensatz zu X11 bietet das Protokoll selbst keine Funktionalität zum Zeichnen an. Zur Datenübermittlung können Shared-Memory -Bereiche verwendet werden, oder es kann für Hardware-Beschleunigung, z.   B. mithilfe von EGL, im Speicher der Grafikkarte gerendert werden.\n\nWayland nutzt vorhandene Komponenten des Kernels des jeweiligen Betriebssystems wie Direct Rendering Manager (DRM), Kernel Mode-Setting (KMS) und Graphics Execution Manager (GEM) unter Linux , um einen minimalen Display-Server bereitzustellen. [ 18 ] Im Juni 2010 wurde Weston von dem auf Desktops eher traditionellen OpenGL auf OpenGL ES portiert. [ 19 ] Grund dafür war, dass die einzige verfügbare freie OpenGL-Implementierung Mesa 3D von GLX und damit vom X-Window-System abhängt, die OpenGL-ES-Implementierung von Mesa 3D aber nicht. [ 20 ]\nWayland kommt aber ohne OpenGL / OpenGL ES aus. [ 21 ] [ 22 ]\n\nBeispiele für Wayland Compositors\n[ Bearbeiten | Quelltext bearbeiten ]\n\nunmittelbar in den [[Bildspeicher]]; der Compositor entscheidet über die Ausgabe.\u003chr /\u003e\u003chr /\u003e\u003chr /\u003e\"},\"Bild2\":{\"wt\":\"Free and open-source-software display servers and UI toolkits.svg\"},\"Untertitel2\":{\"wt\":\"Der Display-Server ''(Wayland Compositor)'' sitzt zwischen dem [[Linuxkern]] und seinen Clienten und überträgt seine Daten über das sogenannte ''Display-Server-Protokoll,'' welches einfach ein weiteres [[Netzwerkprotokoll]] ist.\u003chr /\u003e\u003chr /\u003e\u003chr /\u003e\"},\"Bild3\":{\"wt\":\"Linux graphics drivers DRI Wayland.svg\"},\"Untertitel3\":{\"wt\":\"Wayland-Clients schreiben mittels [[EGL (Programmierschnittstelle)|EGL]]\u003c!-- OpenGL --\u003e unmittelbar in den [[Bildspeicher]]; der Compositor entscheidet über die Ausgabe.\"}},\"i\":0}}]}'\u003e\n\nWayland: Libwayland und der Wayland Compositor\n\nWayland-Clients schreiben mittels EGL unmittelbar in den Bildspeicher ; der Compositor entscheidet über die Ausgabe.\n\nDer Display-Server (Wayland Compositor) sitzt zwischen dem Linuxkern und seinen Clienten und überträgt seine Daten über das sogenannte Display-Server-Protokoll, welches einfach ein weiteres Netzwerkprotokoll ist.\n\nWayland-Clients schreiben mittels EGL unmittelbar in den Bildspeicher ; der Compositor entscheidet über die Ausgabe.\n\nWeston: Die Referenzimplementierung eines Wayland Compositors.\n\nKWin : Der Fenstermanager des KDE-Projekts, der zugleich auch ein Wayland Compositor ist. [ 23 ]\n\nMutter : Ein Fenstermanager und gleichzeitig ein Wayland Compositor.\n\nEGL : Nachdem Nvidia-Mitarbeiter 2010 bekanntgegeben hatten, dass keine Unterstützung für Wayland geplant sei, [ 24 ] wurde im Oktober 2013 ein Treiber mit EGL-Unterstützung veröffentlicht, den auch Android nutzt. [ 25 ] Seit den Nvidia-Treibern mit der Version 470 wird Wayland auch von Nvidia für alle GPUs unterstützt, die mit diesen Treibern laufen. [ 26 ]\n\nLipstick:' Die Implementierung des Wayland-Compositors in Sailfish OS , dem Betriebssystem des Jolla -Smartphones.\n\nBildsynthese\n[ Bearbeiten | Quelltext bearbeiten ]\n\nDas Wayland-Protokoll enthält keine API zur Bildsynthese . [ 27 ] [ 28 ] [ 29 ] [ 30 ]\n\nJeder Wayland-Client ist für die Bildsynthese seines Fensterinhaltes selbst verantwortlich und schreibt das Ergebnis in seinen eigenen Puffer. Für die Bildsynthese kann es eine eigene Engine mitbringen oder eine externe Bibliothek nutzen, wie z.   B. Cairo , OpenGL oder Vulkan , oder auch die „rendering engine“ von Qt oder GTK+ benutzen.\n\nEinsatz\n[ Bearbeiten | Quelltext bearbeiten ]\n\nWayland wird als Ersatz für den X.Org-Server betrachtet, bietet aber andere potentielle Anwendungsmöglichkeiten, beispielsweise das Bereitstellen von X-Servern und GDM -Anmeldungen. [ 16 ]\n\nEnlightenment : Ab der Version E20, welche im Dezember 2015 erschien, wird Wayland von Enlightenment unterstützt. [ 31 ]\n\nGnome : Im März 2013 kündigten GNOME-Entwickler Pläne für eine vollständige Portierung innerhalb eines Jahres an. [ 32 ] Gnome 3.10, welches im September 2013 erschien, enthielt bereits eine experimentelle Wayland-Unterstützung. Ab Version 3.20, welche am 23. März 2016 erschien, gilt die Wayland-Unterstützung als alltagstauglich.\n\nKDE : Unterstützung von KWin für OpenGL ES wird ab Version 4.7 ausgeliefert. [ 33 ] [ 34 ] Wayland-spezifische Änderungen sind seit 2011 in Entwicklung. [ 35 ] Seit Version 6.0 ist Wayland als Standard voreingestellt [ 36 ] (X11 wird jedoch weiterhin unterstützt).\n\nTizen : Tizen unterstützt Wayland in IVI-Konfigurationen. [ 37 ] Für Tizens Mobilplattform wurde Wayland-Unterstützung angekündigt. [ 38 ]\n\nSailfish OS : Jollas erstes Mobiltelefon mit Sailfish OS läuft laut Aussage der Entwickler mit Wayland. [ 39 ]\n\nLizenz\n[ Bearbeiten | Quelltext bearbeiten ]\n\nDas Wayland-Display-Server-Protokoll wurde durch verschiedene Komponenten implementiert, wie z.   B. libWayland-server, libWayland-client oder libWayland-EGL. Alle diese Komponenten sind freie Software und unterliegen zusammen mit dem Wayland-Compositor Weston der MIT-Lizenz . [ 40 ]\n\nRezeption\n[ Bearbeiten | Quelltext bearbeiten ]\n\nWayland war ursprünglich als ein neues Projekt auf der Website des Unternehmens Phoronix Media vorgestellt worden, als im November 2008 ein Artikel mit dem Titel „Wayland: Ein neuer X.Org-Server für Linux“ veröffentlicht wurde. [ 15 ] Høgsberg reagierte auf die Aufmerksamkeit der Medien über seinen Blog und informierte darüber, dass Wayland nicht ein neuer X-Server sei, sondern ein neuer Display-Server, und stellte fest, dass es ein junges, noch unreifes Projekt sei. [ 41 ]\n\nStreit mit Canonical\n[ Bearbeiten | Quelltext bearbeiten ]\n\nKurze Zeit nach Beginn der Entwicklung wurde Wayland vom Großteil der Linux-Gemeinde als baldiger Standard akzeptiert. Anfang 2013 gab jedoch Canonical überraschend bekannt, eine eigene Lösung namens „ Mir “ entwickeln zu wollen. Diese Entscheidung löste Kontroversen aus, da viele es lieber gesehen hätten, dass gemeinschaftlich Wayland vorangebracht und so ein einheitlicher Standard etabliert würde. [ 42 ] In einer Stellungnahme von Mitarbeitern Canonicals wurde unter anderem argumentiert, Wayland habe schwerwiegende Sicherheitsprobleme vom X-Window-System geerbt. Diese Behauptung ist nachweislich falsch und wurde wenig später revidiert, führte jedoch dazu, dass die Fronten sich weiter verhärteten. Kritiker – darunter Høgsberg – warfen Canonical vor, das Projekt mit Falschaussagen torpedieren zu wollen. [ 43 ] 2017 gab Canonical schließlich die Entwicklung von Mir auf und verwendet nun in Ubuntu ebenfalls Wayland. [ 44 ]\n\nWeblinks\n[ Bearbeiten | Quelltext bearbeiten ]\n\nCasually Defiant Seite von Kristian Høgsberg (englisch)\n\nWayland. Seite bei Freedesktop.org (englisch)\n\nOliver Diedrich: Die Woche: Das Ende von X11?. In: Heise online . 11.   November 2010 ( c’t , Kommentar). Abgerufen am 22.   April 2017.\n\nEinzelnachweise\n[ Bearbeiten | Quelltext bearbeiten ]\n\n↑ [ ANNOUNCE ] wayland 1.26.0 . 16.   Juli 2026 (abgerufen am 18.   Juli 2026).\n\n↑ lists.freedesktop.org . 25.   April 2024.\n\n↑ Wayland Architecture. Erklärung der Wayland Architektur. Abgerufen am 27.   März 2016 .\n\n↑ Wayland Homepage. Erklärung der Ziele des Projektes im 1 Absatz. Abgerufen am 2.   Juni 2020 .\n\n↑ Is wayland replacing the X server? Abgerufen am 2.   Juni 2020 .\n\n↑ Tim Schürmann: Linux-Desktops: Wayland nun auch in Cinnamon, Mate-Gründer rausgeworfen. In: Heise online . 2.   November 2023 . Abgerufen am 14.   Juli 2025.\n\n↑ David Wolski: XFCE 4.20: Schlanker Desktop auf dem Weg zu Wayland. In: Heise online . 18.   Dezember 2024 . Abgerufen am 14.   Juli 2025.\n\n↑ Dirk Knop: Gnome: Entwickler wollen X11-Support auslaufen lassen. In: Heise online . 12.   Oktober 2023 . Abgerufen am 14.   Juli 2025. ; Zitat: „Die Gnome-Entwickler wollen sich mehr auf Wayland konzentrieren. Dazu diskutieren sie, den Support für X11 zu beenden.“.\n\n↑ Thorsten Leemhuis: Aus für Xorg: Ubuntu Desktop 25.10 nur noch mit Wayland. In: Heise online . 10.   Juni 2025 . Abgerufen am 14.   Juli 2025. ; Zitat: „Jean Baptiste Lallement verwies bei der Bekanntgabe des Schritts auf die zwei Tage zuvor verkündeten Planungen zum Xorg-Abschied beim Gnome-Projects. Das will die Unterstützung von Xorg zuerst standardmäßig lahmlegen und ein halbes Jahr später entfernen …“.\n\n1 2 Thorsten Leemhuis: Kubuntu wechselt auf Wayland, neuer Fork von Xorg erschienen. In: Heise online . 24.   Juni 2025 . Abgerufen am 14.   Juli 2025. ; Zitat: „Kubuntu 25.10 wird von Haus aus keine X11-Sitzung mehr bieten; sie bleibt aber nachrüstbar, anders als bei Ubuntu Desktop 25.10, das voll auf Wayland setzen soll. … Die KDE-Entwickler haben derweil verkündet, den X11-Modus von KDE-Plasma weiter pflegen zu wollen.“.\n\n↑ Tim Schürmann: KDE Plasma   6 legt den Fokus auf Wayland. In: Heise online . 28.   Februar 2024 . Abgerufen am 14.   Juli 2025. ; Zitat: „Die Desktop-Umgebung startet standardmäßig eine Wayland-Sitzung.“.\n\n↑ Thorsten Leemhuis: KDE-Desktop sagt X11-Modus adé und setzt vollständig auf Wayland. In: Heise online . 27.   November 2025 . Abgerufen am 27.   November 2025.\n\n↑ Kristian Høgsberg (englisch) – Seite bei fosdem.org (abgerufen am 21. April 2013).\n\n↑ Interview: Kristian Høgsberg ( Memento vom 3. Februar",
+    "content_type": "text/html",
+    "query": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "reputable_secondary",
+    "source_quality_score": 0.68,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/6154c96c0d5177b906b00818.json b/data/research-evidence/6154c96c0d5177b906b00818.json
new file mode 100644
index 0000000..b3665c9
--- /dev/null
+++ b/data/research-evidence/6154c96c0d5177b906b00818.json
@@ -0,0 +1,25 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:22:06.2747689Z",
+  "content_sha256": "685cab324a55c5c78c1ea75b1cc1408307d1df11140872204b06f6989b68cb1d",
+  "result": {
+    "title": "Teil 5 – Schutzmaßnahmen und Best Practices gegen Prototype Pollution",
+    "url": "https://www.stefanbehling.tech/2025/09/12/teil-5-schutzmassnahmen-und-best-practices-gegen-prototype-pollution/",
+    "snippet": "Der beste Schutz ist nicht, Pollution nachträglich „aufzuräumen\", sondern sie gar nicht erst entstehen zu lassen. In diesem Beitrag gehen wir Schritt für Schritt durch die wichtigsten Abwehrstrategien.",
+    "content": "Teil 5 – Schutzmaßnahmen und Best Practices gegen Prototype Pollution\n\nSep. 12, 2025\n\nvon\n\nStefan\n\nin Cyber Security , Prototype Pollution , Websecurity\n\nWarum Vorbeugung so entscheidend ist\n\nPrototype Pollution ist tückisch:\n\nSie wirkt global.\n\nSie bleibt lange unentdeckt.\n\nSie kann schwerwiegende Folgen haben – von Admin-Bypass bis DoS.\n\nDer beste Schutz ist nicht, Pollution nachträglich „aufzuräumen“, sondern sie gar nicht erst entstehen zu lassen . In diesem Beitrag gehen wir Schritt für Schritt durch die wichtigsten Abwehrstrategien.\n\n1. Schlüssel validieren (Blockliste \u0026 Positivliste)\n\nPrototype Pollution passiert fast immer, weil Anwendungen ungeprüfte Eingaben direkt in Objekte übernehmen. Die einfachste Abwehr: gefährliche Schlüssel blockieren .\n\nBlockliste\n\nMindestens diese Keys sollten niemals aus untrusted Input akzeptiert werden:\n\n__proto__\n\nprototype\n\nconstructor\n\nBeispiel:\n\nconst FORBIDDEN_KEYS = [\"__proto__\", \"prototype\", \"constructor\"];\n\nfunction isSafeKey(key) {\nreturn !FORBIDDEN_KEYS.includes(key);\n\nfunction safeMerge(target, source) {\nfor (const key in source) {\nif (!isSafeKey(key)) continue;\n\nconst value = source[key];\nif (value \u0026\u0026 typeof value === \"object\" \u0026\u0026 !Array.isArray(value)) {\ntarget[key] = safeMerge(target[key] || {}, value);\n} else {\ntarget[key] = value;\nreturn target;\n\nPositivliste\n\nNoch besser ist es, nur bekannte Keys zuzulassen .\nBeispiel:\n\nconst ALLOWED_KEYS = [\"name\", \"email\", \"age\"];\n\nfunction strictMerge(target, source) {\nfor (const key of ALLOWED_KEYS) {\nif (key in source) {\ntarget[key] = source[key];\nreturn target;\n\n2. Sichere Container nutzen\n\nObject.create(null)\n\nStandardobjekte erben von Object.prototype . Aber wenn du Objekte mit Object.create(null) erzeugst, haben sie keinen Prototypen . Damit können sie nicht „vergiftet“ werden.\n\nconst safeObj = Object.create(null);\n\nsafeObj.foo = \"bar\";\n\nconsole.log(safeObj.__proto__); // undefined\n\nSolche „reinen Dictionaries“ sind perfekt, wenn du Benutzereingaben speichern musst.\n\nMap\n\nWenn du Key-Value-Strukturen brauchst, nimm lieber Map :\n\nconst m = new Map();\nm.set(\"__proto__\", \"harmlos\");\n\nconsole.log(m.get(\"__proto__\")); // \"harmlos\"\n\nEine Map hat keine Prototypen-Magie – Keys sind einfach nur Strings.\n\n3. Idempotente \u0026 sichere Merge-Funktionen\n\nViele Schwachstellen entstehen durch naive Merge-Implementierungen . Statt eigene Helfer zu schreiben, nutze:\n\nmoderne, gepatchte Versionen von Libraries (z. B. Lodash \u003e= 4.17.12)\n\noder schreibe sehr einfache Merges, die nur genau das tun, was du brauchst\n\nBeispiel für eine sichere flache Zuweisung:\n\nObject.assign(target, source);\n\nDas kopiert nur eigene Eigenschaften von source und beachtet keine Prototype-Ketten.\n\n4. Prüfungen robust machen\n\nOwn Properties prüfen\n\nViele Exploits basieren darauf, dass Anwendungen geerbte Eigenschaften akzeptieren. Das lässt sich leicht verhindern:\n\nif (Object.hasOwn(obj, \"isAdmin\")) {\n// sichere Prüfung\n\nOder kompatibler:\n\nif (Object.prototype.hasOwnProperty.call(obj, \"isAdmin\")) {\n// nur eigene Eigenschaften\n\nDamit werden Prototyp-Manipulationen ignoriert.\n\n5. Parser härten\n\nJSON\n\nWenn du JSON.parse() nutzt, kannst du einen Reviver verwenden, um gefährliche Schlüssel rauszufiltern:\n\nconst FORBIDDEN = [\"__proto__\", \"prototype\", \"constructor\"];\n\nconst data = JSON.parse(rawInput, (key, value) =\u003e {\nif (FORBIDDEN.includes(key)) return undefined;\nreturn value;\n});\n\nQuerystring / YAML\n\nViele Parser erlauben verschachtelte Strukturen. Prüfe, ob deine Parser-Version Schutz gegen Pollution hat.\nBeispiele:\n\nqs (Node.js) → ab Version 6.0 fix für __proto__\n\njs-yaml → prüft inzwischen auf gefährliche Schlüssel\n\n6. Tiefen- und Größenlimits\n\nManche Angriffe nutzen extrem tiefe oder breite Objekte, um Parser und Merges zu überlasten.\nSetze daher Limits:\n\nfunction tooDeep(obj, depth = 0, maxDepth = 5) {\nif (depth \u003e maxDepth) return true;\nif (obj \u0026\u0026 typeof obj === \"object\") {\nreturn Object.values(obj).some(v =\u003e tooDeep(v, depth + 1, maxDepth));\nreturn false;\n\nWenn ein Input zu tief ist, → ablehnen.\n\n7. Runtime-Monitoring\n\nMan kann zur Laufzeit prüfen, ob das Object.prototype verdächtige Keys hat:\n\nconst suspicious = Object.keys(Object.prototype).filter(\nkey =\u003e ![\"constructor\", \"toString\", \"valueOf\"].includes(key)\n);\n\nif (suspicious.length \u003e 0) {\nconsole.error(\"Prototype Pollution erkannt!\", suspicious);\n\nDas ersetzt keine saubere Programmierung, kann aber als Alarmanlage dienen.\n\n8. Security-Tests einbauen\n\nJede App sollte Unit-Tests gegen Pollution haben. Beispiel:\n\ntest(\"Object.prototype darf nicht manipuliert werden\", () =\u003e {\nexpect(({}).polluted).toBeUndefined();\n});\n\nFühre Tests nach Requests aus, die untrusted Input verarbeiten.\n\n9. Kein „falsches Fixen“\n\nEinige vermeintliche Lösungen sind gefährlich:\n\nObject.freeze(Object.prototype) : Klingt gut, bricht aber viele Libraries, die legitime Prototyp-Erweiterungen nutzen.\n\nNur __proto__ blocken : Angreifer weichen auf constructor.prototype aus.\n\nNur am Ende prüfen : Pollution muss beim Einlesen verhindert werden, nicht erst, wenn es zu spät ist.\n\n10. Organisation \u0026 Updates\n\nPrototype Pollution ist auch ein Ökosystem-Problem :\n\nViele Schwachstellen entstehen in beliebten NPM-Paketen.\n\nHalte deine Dependencies aktuell.\n\nNutze Tools wie npm audit oder snyk , um bekannte CVEs früh zu erkennen.\n\nAnalogie: Impfungen für das System\n\nPrototype Pollution ist wie eine Infektion, die sich durchs ganze System zieht.\n\nBlocklisten sind wie Masken: Sie verhindern den direkten Eintritt.\n\nObject.create(null) ist wie eine Impfung: Manche Objekte können gar nicht „vergiftet“ werden.\n\nMonitoring ist wie Fiebermessen: Es erkennt, wenn etwas nicht stimmt.\n\nDie beste Verteidigung: eine Kombination aus allen Maßnahmen.\n\nWas du mitnehmen solltest\n\nGefährliche Keys blocken oder gar nicht erlauben.\n\nSichere Container nutzen : Object.create(null) oder Map .\n\nNur eigene Eigenschaften prüfen , niemals blind obj.key .\n\nParser und Merge-Funktionen absichern.\n\nTests und Monitoring einbauen, damit Pollution nicht unbemerkt bleibt.\n\nDependencies aktuell halten – viele NPM-Pakete hatten Pollution-Bugs.\n\nGefällt mir:\n\nGefällt mir Wird geladen …\n\nKommentare\n\nSchreibe einen Kommentar Antwort abbrechen",
+    "content_type": "text/html",
+    "query": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.3342857142857143,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "actionable": true,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/65b4d4b2e9eabef8ca4250a6.json b/data/research-evidence/65b4d4b2e9eabef8ca4250a6.json
new file mode 100644
index 0000000..d0a87ee
--- /dev/null
+++ b/data/research-evidence/65b4d4b2e9eabef8ca4250a6.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:44:11.5914149Z",
+  "content_sha256": "cc5df06e83dc77a485e1d412389ce735dddc20b78e613c942aeb4dc586e245a5",
+  "result": {
+    "title": "Durchführung von IT-Forensik Untersuchungen • Tobias Scheible - Cybercrime Dozent \u0026 Live Hacking Speaker",
+    "url": "https://scheible.it/durchfuehrung-von-it-forensik-untersuchungen/",
+    "snippet": "Bei einer typischen IT-Forensik-Untersuchung wird eine forensische Kopie eines Speichers erstellt und diese anschließend untersucht. Als Erstes wird ein Überblick erstellt, dazu gehört etwa welche Benutzer existieren und welche Anwendungen installiert sind.",
+    "content": "Durchführung von IT-Forensik Untersuchungen\n\nWie eine IT-Forensik Untersuchung durchgeführt wird, habe ich in meinem IT-Forensik-Kapitel beschrieben, dass in der neuesten Auflage des Fachbuches „Hacking \u0026 Security“ veröffentlicht wurde. Dabei ist ein methodisches Vorgehen bei der Analyse von Vorfällen unerlässlich.\n\nDienstag, 10. Januar 2023\n\n0 Kommentare\n\nProjekte\n\nBuch , ITForensik , Rheinwerk , HackingSecurity\n\nDie Neuauflage des umfassenden Handbuches im Bereich IT-Sicherheit ist im Dezember 2022 erschienen. In der Hacking \u0026 Security Artikelserie stelle ich mein Kapitel über IT-Forensik vor. Im ersten Blog-Post Neue Auflage des Buches „Hacking \u0026 Security“ gab ich einen Überblick über das Fachbuch. Im nächsten Artikel Über das Buch „Hacking \u0026 Security“ ging es um den Aufbau des über 1200 Seiten starken Buches und die anderen Mitautoren. Der dritte Beitrag Zielsetzung und Einsatzgebiete der IT-Forensik beschäftigt sich mit der Anwendung der Methoden der IT-Forensik. Im letzten Teil der Artikelserie geht es nun um die Durchführung von IT-Forensik Untersuchungen.\n\nMethodische Analyse von Vorfällen\n\nUm die Akzeptanz einer forensischen Untersuchung auch von Dritten zu gewährleisten, muss diese nach allgemeingültigen Standards durchgeführt werden. Sie folgen den Grundsätzen des wissenschaftlichen Arbeitens. Im Folgenden einige wichtige Punkte:\n\nNachvollziehbarkeit: Alle Schritte müssen so dokumentiert werden, damit sie von Dritten nachvollzogen werden können.\n\nWiederholbarkeit: Alle Informationen müssen vorhanden sein, damit das Ergebnis jederzeit von einer beliebigen Person reproduziert werden kann.\n\nIntegrität: Die erhobenen Informationen und daraus gewonnene Erkenntnisse müssen gegen eine spätere Änderung abgesichert werden.\n\nVollständigkeit: Es dürfen keine Erkenntnisse weggelassen werden, auch wenn sie für die Zielsetzung als nicht relevant eingestuft wurden.\n\nDie nachfolgende Grafik gibt einen Überblick über die Handlungsfelder der IT-Forensik:\nÜberblick über das Themenfeld IT-Forensik Überblick über das Themenfeld IT-Forensik\nPost-Mortem-Untersuchung\n\nBei einer typischen IT-Forensik-Untersuchung wird eine forensische Kopie eines Speichers erstellt und diese anschließend untersucht. Als Erstes wird ein Überblick erstellt, dazu gehört etwa welche Benutzer existieren und welche Anwendungen installiert sind.\n\nAnschließend wird die Nutzung des Systems für einen relevanten Zeitraum rekonstruiert. So wird anhand von Zeitstempeln der Dateien rekonstruiert, welche Dateien wann geöffnet oder zum letzten Mal geändert wurden. Anschließend werden die Daten von Anwendungen ausgewertet, um etwa das Surfverhalten zu rekonstruieren.\n\nWichtig dabei ist, dass bei einer forensischen Untersuchung nur das System analysiert wird und zum Beispiel nachgewiesen werden kann, dass mit einem bestimmten Account eine spezifische Aktion durchgeführt wurde. Es kann aber keine Zuordnung zu einer Person erfolgen, da es meist keinen Nachweis gibt, dass diese Person auch den Account zu diesem Zeitpunkt genutzt hat. Es könnte auch jemand anderes die Zugangsdaten ausgespäht und die Aktionen durchgeführt haben.\n\nLive-Analyse\n\nNeben der Untersuchung eines forensischen Abbildes ist auch die Untersuchung eines laufenden Systems sehr interessant. Da es zum Beispiel auch Schadsoftware gibt, die sich nur im Arbeitsspeicher befindet und nach dem Ausschalten eines Rechners nicht mehr analysiert werden kann.\n\nGrundsätzlich lassen sich im Abbild des Arbeitsspeichers die aktiven Prozesse, geöffnete Netzwerkverbindungen und Zugriffe auf Dateien erkennen. Aber zum Teil können auch eingegebene Passwörter, wie das Passwort zum Öffnen eins Passwortspeichers, aus dem Speicher extrahiert werden.\n\nBei einer Live-Analyse muss dabei sehr strukturiert vorgegangen werden, da jede Aktion das Zielsystem verändert. Diese Änderungen können nicht vermieden werden, daher müssen sie minimal gehalten und genau protokolliert werden.\n\nZusammenfassung\n\nDie IT-Forensik ist ein spannendes Themenfeld, bei dem zum einen viel Wissen aus verschiedenen Bereichen benötigt wird, zum anderen gibt es aber auch ständig Neues zu entdecken.\n\nEs war für mich eine große Freude, an diesem bereits sehr bekannten Fachbuch mitzuschreiben und ein neues Kapitel beizusteuern. Für das IT-Forensik-Kapitel habe ich „nur“ Platz für 30 Seiten vom Verlag bekommen, da das Buch zwar größer werden durfte, aber doch nicht allzu groß. Um in diesem Rahmen das Thema IT-Forensik zu schreiben, habe ich mich darauf konzentriert, den Charakter von forensischen Untersuchungen zu vermitteln, ohne dass allzu viel Theorie benötigt wird. So habe ich auch einige Aspekte wie die juristische Sichtweise entsprechend auch ausgeklammert. Für einen möglichst großen Nutzen für die Leserinnen und Leser habe ich das Kapitel wie einen Leitfaden für die Durchführung einer Untersuchung geschrieben.\n\nIch wünsche Ihnen viel Spaß beim Stöbern und Lesen des Buches Hacking \u0026 Security.\n\nArtikelserie Hacking \u0026 Security\nBuch Hacking \u0026 Security – Rheinwerk Computing\nDieser Blog-Artikel ist Teil der Hacking \u0026 Security Artikelserie, in der ich einen Einblick in mein Kapitel „IT-Forensik“ gebe, das im Fachbuch „Hacking \u0026 Security“ erschienen ist. In diesem Kapitel gebe ich einen fokussierten Einblick, wann forensische Untersuchungen zum Einsatz kommen und wie diese ablaufen.\n\nDirekt zum Buch (Rheinwerk Verlag) | Download Leseprobe (PDF-Datei)\nDie Artikelserie „Hacking \u0026 Security“ umfasst die folgenden Beiträge:\n\nNeue Auflage des Buches „Hacking \u0026 Security“\n\nÜber das Buch „Hacking \u0026 Security“\n\nZielsetzung und Einsatzgebiete der IT-Forensik\n\nDurchführung von IT-Forensik Untersuchungen\n\nArtikel teilen:",
+    "content_type": "text/html",
+    "query": "Welche konkreten Schritte sind für die forensische Untersuchung von Wayland/X11 Remote Access erforderlich?",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.3927272727272727,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "REVIEW-3"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/67262432960c7751e0bb4ddc.json b/data/research-evidence/67262432960c7751e0bb4ddc.json
new file mode 100644
index 0000000..fedb8fe
--- /dev/null
+++ b/data/research-evidence/67262432960c7751e0bb4ddc.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:15:47.3919195Z",
+  "content_sha256": "2bb19e59cc5ac863571f0f74408972bbefe142e83a662e86dd8abe927819d168",
+  "result": {
+    "title": "Hardened Repository - Veeam Backup \u0026 Replication User Guide",
+    "url": "https://helpcenter.veeam.com/docs/vbr/userguide/hardened_repository.html",
+    "snippet": "To protect your backup files from loss as a result of malware activity or unplanned actions, you can add a hardened repository based on a Linux server to your backup infrastructure.A hardened repository supports the following features: Immutability: ...",
+    "content": "Hardened Repository\n\nTo protect your backup files from loss as a result of malware activity or unplanned actions, you can add a hardened repository based on a Linux server to your backup infrastructure.\n\nA hardened repository supports the following features:\n\nImmutability : when you add a hardened repository, you specify the time period while backup files must be immutable. During this period, backup files stored in this repository cannot be moved, modified or deleted, but can be copied.\n\nSecure Authentication : when you add a hardened repository, you specify the method used to authenticate connections.\n\nCertificate-based : No user name or password is required; authentication is performed using certificates. It is recommended for environments where Kerberos is disabled or unavailable, or for enhanced security. This option is available for hardened repositories deployed from the Veeam Infrastructure Appliance.\n\nSingle-use credentials : Credentials that are used only once to deploy Veeam Data Mover , while adding the Linux server to the backup infrastructure. These credentials are not stored in the backup infrastructure. Even if the Veeam Backup \u0026 Replication server is compromised, the attacker cannot get the credentials and connect to the hardened repository.\n\nTo interact with the hardened repository, Veeam Backup \u0026 Replication uses SHA256RSA self-signed certificates with 2048-bit RSA key.\n\nNote\n\nFor security reasons, you cannot assign other roles to the hardened repository except for the VMware backup proxy working in the Network mode. For more information, see Hardened Repository as VMware Backup Proxy .\n\nIn This Section\n\nAbout Hardened Repository\n\nRequirements and Limitations\n\nUsing Veeam Infrastructure Appliance as Hardened Repository\n\nUsing Backup Server as Immutable Repository\n\nAdding Hardened Repositories\n\nManaging Hardened Repository",
+    "content_type": "text/html",
+    "query": "Backup Repository Hardening – präventiv, resilient und im Vorfall erkennen, eindämmen und wiederherstellen aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "primary",
+    "source_quality_score": 0.88,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/6cade20cd75c0259748d2fb3.json b/data/research-evidence/6cade20cd75c0259748d2fb3.json
new file mode 100644
index 0000000..61a9840
--- /dev/null
+++ b/data/research-evidence/6cade20cd75c0259748d2fb3.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:23:53.6832462Z",
+  "content_sha256": "e7fca5563b9156947563aaf4571048ace98dd599e8925512d61c0c6458b0963d",
+  "result": {
+    "title": "Datenmanagement in der KI-Ära — Datenqualität, Datenkatalog und Data Lineage — ESKOM.AI Blog",
+    "url": "https://eskom.ai/de/blog/data-governance-ai-enterprise/",
+    "snippet": "Erfahren Sie, wie ein Datenkatalog, Data Lineage und automatisierte Qualitätskontrollen eine solide Grundlage für vertrauenswürdige KI schaffen.",
+    "content": "Zurueck zum Blog Enterprise\nDatenmanagement in der KI-Ära — Datenqualität, Datenkatalog und Data Lineage\n\nZespół ESKOM.AI 2026-05-22 Lesezeit: 7 min\n\nDaten als Grundlage für KI\n\nDie Qualität eines KI-Systems wird letztlich durch die Qualität seiner Daten bestimmt. Garbage in, garbage out gilt für KI umso mehr — ein perfektes Modell liefert bei schlechten Eingabedaten schlechte Ergebnisse. Data Governance — also die systematische Verwaltung von Daten — wird zu einer strategischen Notwendigkeit.\n\nDatenkatalog\n\nEin Datenkatalog ist ein Verzeichnis aller Datenressourcen der Organisation: welche Daten existieren, wo sie gespeichert sind, wer der Eigentümer ist, welches Format und welche Qualität sie haben und wer Zugriff hat. Im KI-Kontext identifiziert der Katalog zusätzlich, welche Daten für Training, Validierung und Inferenz verwendet werden.\n\nDatenqualität\n\nAutomatisierte Qualitätskontrollen umfassen: Vollständigkeit (fehlen kritische Felder?), Konsistenz (stimmen Daten über verschiedene Systeme überein?), Aktualität (wie alt sind die Daten?), Genauigkeit (stimmen sie mit der Realität überein?), Einzigartigkeit (gibt es Duplikate?) und Konformität (entsprechen die Daten dem erwarteten Format?).\n\nData Lineage\n\nData Lineage dokumentiert den Datenfluss von der Quelle bis zum Verbraucher: woher die Daten stammen, welche Transformationen sie durchlaufen haben, welche Systeme sie nutzen und wie sie sich im Laufe der Zeit verändert haben. Für KI ist Lineage entscheidend — es beantwortet die Frage: Mit welchen Daten wurde das Modell trainiert und wie haben sich diese verändert?\n\nDSGVO und Data Governance\n\nData Governance und Datenschutz sind untrennbar: Verarbeitungsverzeichnisse (DSGVO Art. 30), Recht auf Vergessenwerden (wie löscht man Daten aus trainierten Modellen?), Datenminimierung (nur so viele Daten sammeln wie nötig), Aufbewahrungsfristen und automatische Löschung sowie Datenschutz-Folgenabschätzung für KI-Systeme.\n\nEmpfehlungen\n\nBeginnen Sie mit einer Inventarisierung der kritischsten Datenbestände\n\nImplementieren Sie automatisierte Qualitätsprüfungen in Datenpipelines\n\nBauen Sie einen Datenkatalog mit Metadaten und Eigentümerzuordnung auf\n\nImplementieren Sie Data Lineage für KI-Trainingsdaten\n\nIntegrieren Sie DSGVO-Anforderungen von Anfang an in die Data-Governance-Strategie\n\n#data governance\n#data quality\n#data catalog\n#lineage\n#MDM\n\nVerwandte Dienste \u0026 Produkte\n\nAnalytik \u0026 BI\n\nGDPR-Compliance-Audit\n\nIT- \u0026 Unternehmensberatung\n\nHybridCrew\n\nAnoxy\n\nMasz podobny problem z aplikacją?\n\nUmów bezpłatną, 30-minutową konsultację — bez zobowiązań. Pokażemy, jak można to zrobić szybciej i taniej z AI.\nUmów bezpłatną konsultację\n\nCo miesiąc: jak firmy modernizują software z AI\n\nKonkrety, bez żargonu. Zero spamu — wypisujesz się jednym kliknięciem.\n\n📋 Kostenlose Checkliste: Ist Ihre Legacy-Anwendung ein guter Kandidat für die KI-Modernisierung?\n\nZurueck zum Blog",
+    "content_type": "text/html",
+    "query": "AI Dataset Integrity und AI Dataset Lineage sind eng verwandt, aber unterschiedliche Konzepte. Beide erfordern Sicherheitsmaßnahmen, aber mit unterschiedlichem Fokus. Ein gemeinsamer Artikel könnte die Sicherheitsaspekte beider Themen konsolidieren und eine umfassendere Anleitung bieten. current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/760deb2f6922fdb2110ccae0.json b/data/research-evidence/760deb2f6922fdb2110ccae0.json
new file mode 100644
index 0000000..54910a3
--- /dev/null
+++ b/data/research-evidence/760deb2f6922fdb2110ccae0.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:04:45.1339132Z",
+  "content_sha256": "e26aa254f2cd764877953618e7072545065961145c3ff94372a0c1e4fde13d3a",
+  "result": {
+    "title": "Now Available: Practical Guidelines for Preventing and Mitigating Ransomware | NIST",
+    "url": "https://www.nist.gov/news-events/news/2026/06/now-available-practical-guidelines-preventing-and-mitigating-ransomware",
+    "snippet": "The NIST NCCoE has published the final version of NIST Interagency Report (IR) 8374 Revision 1, Ransomware Risk Management: A Cybersecurity Framework (CSF) 2.0 Community Profile. This resource translates the NIST CSF 2.0 into practical actions organizations and individuals can take to proactively manage and mitigate the risk of ransomware events.",
+    "content": "Now Available: Practical Guidelines for Preventing and Mitigating Ransomware | NIST\n\nSkip to main content\n\nOfficial websites use .gov\n\nA .gov website belongs to an official government organization in the United States.\n\nSecure .gov websites use HTTPS\n\nA lock (\n\n) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.\n\nhttps://www.nist.gov/news-events/news/2026/06/now-available-practical-guidelines-preventing-and-mitigating-ransomware\n\nUPDATES\n\nNow Available: Practical Guidelines for Preventing and Mitigating Ransomware\n\nJune 11, 2026\n\nShare\n\nFacebook\n\nLinkedin\n\nX.com\n\nEmail\n\nThe NIST NCCoE has published the final version of NIST Interagency Report (IR) 8374 Revision 1, Ransomware Risk Management: A Cybersecurity Framework (CSF) 2.0 Community Profile . This resource translates the NIST CSF 2.0 into practical actions organizations and individuals can take to proactively manage and mitigate the risk of ransomware events.\n\nRansomware attacks can devastate organizations of any size across all sectors, making it imperative to assess and improve readiness to counter these threats and mitigate their impact. Originally developed based on NIST CSF 1.1, this profile has been updated to align with the NIST CSF 2.0, ensuring it provides the most current guidelines on managing ransomware risk.\n\nThis profile was developed in collaboration with industry to align organizations’ real-world ransomware prevention and mitigation requirements, objectives, risk appetite, and resources with the elements of the NIST CSF 2.0. Organizations can use this document to evaluate current ransomware defenses and identify priority actions to strengthen their resilience against ransomware.\n\nDownload the Publication Today!\n\nWe encourage you to download the publication today to inform your ransomware countermeasure playbook. If you have any questions, contact the team at ransomware [at] nist.gov (ransomware[at]nist[dot]gov) .\n\nView this on the NCCoE website\n\nInformation technology and Cybersecurity and privacy\n\nReleased June 11, 2026\n\nWas this page helpful?",
+    "content_type": "text/html",
+    "query": "Ransomware Prevention \u0026 Detection aktuelle offizielle Dokumentation Version Support",
+    "language": "en-US",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "authoritative",
+    "source_quality_score": 0.95,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/89610138100a737edc45356e.json b/data/research-evidence/89610138100a737edc45356e.json
new file mode 100644
index 0000000..9727a08
--- /dev/null
+++ b/data/research-evidence/89610138100a737edc45356e.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:43:38.4445765Z",
+  "content_sha256": "252b5f0b11b4a45211038f31f75fcad78b9f7b01fe7889b8013aacfef3e3827b",
+  "result": {
+    "title": "Remote Desktop on Wayland in 2025: What Changed for Linux Support Engineers | Stackademic",
+    "url": "https://stackademic.com/blog/remote-desktop-on-wayland-in-2025-what-changed-for-linux-support-engineers",
+    "snippet": "This guide gives you a pragmatic, distro-agnostic playbook for remote support on Wayland using GNOME/KDE's built-ins, the PipeWire + xdg-desktop-portal stack, and a few production-ready SOPs.",
+    "content": "Wayland is now the default across most modern Linux desktops, and that quietly breaks a lot of X11-era support playbooks. If your helpdesk still relies on “global screen grabbers” or legacy VNC expectations, you’ll hit confusing prompts, black screens, and missing input.\n\nThis guide gives you a pragmatic, distro-agnostic playbook for remote support on Wayland using GNOME/KDE’s built-ins, the PipeWire + xdg-desktop-portal stack, and a few production-ready SOPs.\n\nTL;DR\n\nOn Wayland, screen capture/control is mediated by the compositor via PipeWire and xdg-desktop-portal, not legacy X11 hooks. Expect user-visible permission prompts and per-app scoping.\n\nGNOME Remote Desktop speaks RDP (and VNC) and can do user-present “share my screen” and remote-login/headless modes with GDM integration.\n\nKDE Plasma exposes Wayland sessions over RDP through KRdp ; configuration lives in Settings → Networking → Remote Desktop.\n\nCommon issues in 2024–2025: black screens on RDP login and portal misconfiguration —fixes below.\n\nThird-Party Options : For organizations managing large or mixed environments who require dedicated clients, simplified deployment, or integrated features beyond what the built-in desktop environment solutions offer, third-party remote support applications are an option. HelpWire , for instance, is one such provider that documents the necessary Wayland permission flows (screen sharing and input control) and offers dedicated packages (DEB/RPM) to assist in fleet management.\n\nWho this is for\n\nSupport engineers, SREs, and IT admins who (a) assist users on Linux desktops, (b) maintain mixed fleets, or (c) are migrating off X-dependent tools.\n\nThe 2025 Reality Check: Wayland vs X11 for Support Teams\n\nUnder Wayland, there’s no global “screen” you can scrape . The desktop compositor brokers access; PipeWire carries frames and audio; xdg-desktop-portal asks the user to grant consent and scope (window/monitor/virtual monitor). That’s good for least-privilege, but it changes your runbooks.\n\nImplications you’ll feel:\n\nFirst connection often triggers a portal prompt ; users must allow viewing, control , and clipboard explicitly.\n\nSome flows differ between user-present sharing and remote login/headless .\n\nYour tooling must “speak” portals (or use the DE’s built-in RDP server).\n\nQuick Wins: Verify Your Stack (5 Minutes)\n\nRun these before opening a ticket:\n\nAm I on Wayland? From a terminal: echo $XDG_SESSION_TYPE → should print wayland.\n\nIs PipeWire alive? systemctl --user status pipewire (and your session manager, e.g., WirePlumber).\n\nIs the portal backend right for my desktop? (e.g., xdg-desktop-portal-gtk, -kde, -wlr, -hyprland) and that it’s running.\n\nWhich server will handle remote desktop?\n\nGNOME: “Settings → Sharing → Remote Desktop” (RDP/VNC).\n\nKDE: “Settings → Networking → Remote Desktop” (KRdp).[ ]( https://planet.kde.org/arjen-hiemstra-2023-08-08-remote-desktop-using-the-rdp-protocol-for-plasma-wayland/?utm\\_source\\=chatgpt.com )\n\nHands-On: Enable Remote Desktop on GNOME (Wayland)\n\n1) Turn on RDP sharing (user-present)\n\nOpen Settings → Sharing → Remote Desktop and enable it. GNOME Remote Desktop (g-r-d) runs in the user session and uses RDP for control.\n\n2) Remote login / headless sessions\n\nIf you need login-screen or multi-user headless access (no active desktop), integrate with GDM . GNOME supports remote login via RDP; the user authenticates at the greeter, then starts a Wayland session. This is useful for lab machines and servers without GPUs.\n\n3) Expect (and explain) permission prompts\n\nWayland portals will ask the end-user to grant viewing, control, and clipboard access on first connection or when scope changes. Train users to approve these during a support session.\n\nTip: grdctl can script some GNOME Remote Desktop settings (credentials, status) for fleet consistency.\n\nKDE/Plasma Notes (Wayland)\n\nPlasma ships KRdp , a server that exposes the current Wayland session over RDP . Enable via System Settings → Networking → Remote Desktop . Behind the scenes, Plasma uses KPipeWire for video. On fresh installs, you may need the krdp package.\n\nMigration Guide: Retiring X-Only Tools\n\nInventory where your SOPs assume X11 (global screenshot hotkeys, VNC hooks, legacy capturers).\n\nReplace with:\n\nBuilt-in RDP : GNOME (g-r-d) or KDE (KRdp).[ ]( https://docs.rockylinux.org/10/desktop/gnome/rdp-server/?utm\\_source\\=chatgpt.com )\n\nPortal-aware tools that request runtime permissions (screen, input, clipboard) via xdg-desktop-portal .[ ]( https://wiki.archlinux.org/title/XDG\\_Desktop\\_Portal?utm\\_source\\=chatgpt.com )\n\nRollout plan : pilot with a representative GPU mix → publish a user-prompt guide → update SOPs → audit.\n\nNetworking stance : prefer outbound/brokered connectivity over opening inbound ports unless policy requires otherwise.\n\nAlternative Approach: Third-Party Managed Solutions\n\nFor organizations that require features beyond what built-in desktop environment servers provide—such as streamlined, outbound-only connectivity, cross-platform parity, or integrated client management – a number of third-party remote support applications are available.\n\nThese solutions specialize in simplifying the support experience, and modern ones have had to adapt to the Wayland security model. They often provide:\n\nSimple Session Initiation: Using links or single codes to bypass complex RDP/VNC setup.\n\nCross-Platform Consistency: Offering a uniform feature set across Windows, macOS, and Linux support sessions.\n\nIntegrated Support Tools: Features like real-time in-session chat, simplified file transfer, and device management features.\n\nAn example of such a provider is HelpWire , which specifically addresses the challenges noted in this guide by rolling out packages (DEB/RPM) and providing clear documentation for end-users on granting the necessary Wayland permissions (screen sharing and input control) during a support session. Leveraging such an application can streamline the entire process, especially for large, mixed environments.\n\nTroubleshooting Field Guide (Symptom → Likely Fix)\n\nBlack screen on RDP remote login\nCheck you’re on the supported mode (Wayland login via GDM) and confirm recent GNOME/mutter fixes; black screens have been tracked upstream. Re-test with Windows mstsc or FreeRDP clients as a control.\n\nNo keyboard/mouse control\nRe-initiate to trigger control permission; ensure the portal backend matches your desktop (gtk/kde/wlr/hyprland).\n\nClipboard won’t sync\nVerify the clipboard portal scope is granted and the desktop’s portal service is running (restart xdg-desktop-portal in user session).\n\nScreenshare dialog shows nothing on Plasma\nAfter upgrades, re-install or restart Plasma’s portal backend; community reports highlight portal regressions on Plasma 6 until services restart.\n\nWayland compositor mismatch (wlroots/Hyprland/Sway)\nEnsure the correct portal implementation (e.g., xdg-desktop-portal-wlr or -hyprland) and start order (PipeWire → portal backend).\n\nSecurity \u0026 Compliance: Least-Privilege by Design\n\nWayland’s portal model gives you per-session consent and narrow scoping (window/monitor/virtual monitor), aligning with least-privilege and auditability goals. Combine it with RDP remote login (no local user present) for multi-user labs or headless servers while keeping session boundaries clean.\n\nDrop-In Runbook Snippets\n\nOperator checklist (before a session):\n\necho $XDG_SESSION_TYPE → wayland\n\nsystemctl --user is-active pipewire → active\n\nConfirm portal backend package is installed and running (gtk/kde/wlr/hyprland).[ ]( https://wiki.archlinux.org/title/XDG\\_Desktop\\_Portal?utm\\_source\\=chatgpt.com )\n\nGNOME: verify “Remote Desktop” is enabled (RDP); KDE: enable Remote Desktop (KRdp).[ ]( https://docs.rockylinux.org/10/desktop/gnome/rdp-server/?utm\\_source\\=chatgpt.com )\n\nUser comms template (paste into tickets):\n\n“When I request access, you’ll see a permission prompt . Please allow Screen Viewing , Control , and Clipboard so I can help. You can revoke these anytime after the session.”\n\nEscalation notes:\n\nIf user-present sharing keeps failing, test remote login via GDM (GNOME) to isolate compositor issues.\n\nMixed GPU fleets (esp. NVIDIA) may need current drivers and portal sanity checks; known RDP login black-screen issues exist in the wild.\n\nFAQ\n\nCan I force GNOME’s remote login to Xorg instead?\nGNOME’s remote login defaults to Wayland ; forcing Xorg for that path isn’t a supported toggle and often leads to mismatches. Plan for Wayland.\n\nDoes GNOME support multi-user/headless remote desktops?\nYes— GDM integration enables remote login and even headless multi-user scenarios; see SUSE/Red Hat docs for configuration details.\n\nKDE vs GNOME—what’s the practical difference for support?\nBoth expose Wayland sessions over RDP . GNOME’s remote login/headless story is better documented today; KDE’s KRdp focuses on controlling the active session.\n\nConclusion \u0026 Checklist\n\nWayland isn’t a blocker – it’s a safer default that asks you to update your tooling and SOPs.\n\nAdopt this checklist:\n\nBuilt-ins first: GNOME g-r-d or KDE KRdp\n\nVerify PipeWire + portal backend on every image\n\nPublish a one-page permission-prompt guide for users\n\nPrefer outbound/brokered connections over opening ports\n\nKeep a remote-login (GDM) fallback for stubborn cases\n\nIf you need a vendor-managed route, link users to the Wayland permissions walkthrough so they know exactly which sliders to enable before a session.\n\nComments\n\nLoading comments…",
+    "content_type": "text/html",
+    "query": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.3507692307692308,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/8df47e8183cab5919d2ed44e.json b/data/research-evidence/8df47e8183cab5919d2ed44e.json
new file mode 100644
index 0000000..d20253d
--- /dev/null
+++ b/data/research-evidence/8df47e8183cab5919d2ed44e.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:06:27.2328601Z",
+  "content_sha256": "40c74ca241ad22e8de54ddc3a82f1e7e76d6cdd63b5759196a7e33a6d1b0f5a1",
+  "result": {
+    "title": "Identitäts- und Zugriffsverwaltung – Übersicht  |  Cloud Architecture Center  |  Google Cloud Documentation",
+    "url": "https://docs.cloud.google.com/architecture/identity?hl=de",
+    "snippet": "Entdecken Sie die allgemeinen Verfahren der Identitäts- und Zugriffsverwaltung (IAM) und die betroffenen Personen, einschließlich Unternehmensidentitäten, Kundenidentitäten und Dienstidentitäten.",
+    "content": "Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.\n\nHome\n\nDocumentation\n\nCloud Architecture Center\n\nFeedback geben\n\nIdentitäts- und Zugriffsverwaltung – Übersicht\n\nMit Sammlungen den Überblick behalten\n\nSie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.\n\nLast reviewed 2024-07-11 UTC\n\nBei der Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM ) geht es darum, den richtigen Personen aus den richtigen Gründen Zugriff auf die richtigen Ressourcen zu gewähren. In dieser Reihe wird auf die allgemeinen IAM-Prinzipien und die betroffenen Personen eingegangen. Dazu gehören:\n\nUnternehmensidentitäten: Die Identitäten, die Sie für Mitarbeiter Ihrer Organisation verwalten. Diese Identitäten werden für die Anmeldung bei Workstations, den Zugriff auf E-Mails oder die Nutzung von Unternehmensanwendungen verwendet. Zu Unternehmensidentitäten können auch Nichtmitarbeiter wie Auftragnehmer oder Partner gehören, die Zugriff auf Unternehmensressourcen benötigen.\n\nKundenidentitäten: Die Identitäten, die Sie für Nutzer verwalten, damit diese Ihre Website und kundenseitigen Anwendungen verwenden können.\n\nDienstidentitäten: Die Identitäten, die Sie verwalten, um Anwendungen die Interaktion mit anderen Anwendungen oder der zugrunde liegenden Plattform zu ermöglichen.\n\nMöglicherweise müssen Sie Zugriff auf die folgenden Ressourcen gewähren:\n\nGoogle-Dienste wie Google CloudGoogle Analytics oder\nGoogle Workspace\n\nRessourcen in Google Cloud wie Projekte, Cloud Storage\nBuckets oder virtuelle Maschinen (VMs) Google Cloud\n\nBenutzerdefinierte Anwendungen oder Ressourcen, die von solchen Anwendungen verwaltet werden\n\nIn den Leitfäden dieser Reihe sind die Erklärungen zu IAM in folgende Teile gegliedert:\n\nDie Verwaltung von Unternehmens-, Kunden- und Dienstidentitäten bildet die Grundlage von IAM. Diese Themen werden durch die rechteckigen Felder 4, 5 und 6 (grün) dargestellt.\n\nDie blauen Felder 2 und 3 bauen auf der grundlegenden Identitätsverwaltung auf und stehen für Themen der Zugriffsverwaltung. Zu diesen Themen gehört die Verwaltung des Zugriffs\nauf Google-Dienste, auf Google Cloud Ressourcen und auf Ihre benutzerdefinierten\nArbeitslasten sowie auf Anwendungen.\n\nFeld 1 (gelb) gibt die Themen der Zugriffsverwaltung an, die nicht in diesen Leitfäden behandelt werden. Informationen zur Zugriffsverwaltung für Google Workspace , für die Google Marketing Platform und für andere Dienste finden Sie in der jeweiligen Produktdokumentation.\n\nIdentitätsverwaltung\n\nBei der Identitätsverwaltung stehen folgende Vorgänge im Mittelpunkt:\n\nIdentitäten, Nutzer und Gruppen bereitstellen, verwalten, migrieren und deren Bereitstellung aufheben\n\nSichere Authentifizierung bei Google-Diensten und Ihren benutzerdefinierten Arbeitslasten ermöglichen\n\nDie Prozesse und Technologien unterscheiden sich je nachdem, ob Sie es mit Unternehmensidentitäten, Anwendungsidentitäten oder Kundenidentitäten zu tun haben.\n\nUnternehmensidentitäten verwalten\n\nUnternehmensidentitäten sind die Identitäten, die Sie für die Mitarbeiter Ihrer Organisation verwalten. Mitarbeiter verwenden diese Identitäten, um sich bei Workstations anzumelden, auf E-Mails zuzugreifen oder Unternehmensanwendungen zu nutzen.\n\nIm Zusammenhang mit der Verwaltung von Unternehmensidentitäten sind folgende Anforderungen typisch:\n\nEinen zentralen Ort für die organisationsweite Verwaltung von Identitäten unterhalten\n\nMitarbeitern ermöglichen, eine einzige Identität und die Einmalanmeldung (SSO) für mehrere Anwendungen in einer hybriden Computing-Umgebung zu verwenden\n\nRichtlinien wie die Multi-Faktor-Authentifizierung oder Passwortkomplexität für alle Mitarbeiter erzwingen\n\nCompliancekriterien erfüllen, die unter Umständen für Ihr gesamtes Unternehmen gelten\n\nGoogle Workspace und Cloud Identity sind Produkte von Google, mit denen Sie diese Anforderungen erfüllen und Identitäten sowie Richtlinien zentral verwalten können.\n\nWenn Sie Google-Dienste in einem Hybrid- oder Multi-Cloud-Kontext verwenden, müssen Sie zur Erfüllung dieser Anforderungen die IAM-Funktionen von Google möglicherweise in externe Identitätsverwaltungslösungen oder in Identitätsanbieter wie Active Directory einbinden. Im Dokument Referenzarchitekturen wird erläutert, wie Sie mit Google Workspace oder Cloud Identity eine solche Einbindung ausführen.\n\nEinige Ihrer Mitarbeiter nutzen möglicherweise Gmail-Konten oder andere Privatnutzerkonten, um auf Unternehmensressourcen zuzugreifen. Die Verwendung solcher Nutzerkonten entspricht jedoch möglicherweise nicht Ihren speziellen Anforderungen oder Richtlinien. In diesem Fall können Sie diese Nutzer zu Google Workspace oder zu Cloud Identity migrieren. Ausführliche Informationen dazu finden Sie unter Vorhandene Nutzerkonten bewerten und Onboardingpläne bewerten .\n\nUnsere Leitfäden zur Bewertung und Planung unterstützen Sie bei der Einführung von Google Workspace und Cloud Identity. Dort erfahren Sie, wie Sie Ihre Anforderungen ermitteln und die Einführung vornehmen.\n\nAnwendungsidentitäten verwalten\n\nAnwendungsidentitäten sind die Identitäten, die Sie verwalten, um Anwendungen die Interaktion mit anderen Anwendungen oder der zugrunde liegenden Plattform zu ermöglichen.\n\nIm Zusammenhang mit der Verwaltung von Anwendungsidentitäten sind folgende Anforderungen typisch:\n\nAPIs und Authentifizierungslösungen von Drittanbietern einbinden\n\nUmgebungsübergreifende Authentifizierung in einem Hybrid- oder Multi-Cloud-Szenario ermöglichen\n\nVerlust von Anmeldedaten verhindern\n\nGoogle Cloud Mit Google Cloud können Sie über Google Cloud Dienstkonten\nund\nKubernetes-Dienstkonten Anwendungsidentitäten verwalten und diese\nAnforderungen erfüllen.\nWeitere Informationen zu Dienstkonten und Best Practices für deren Verwendung finden Sie unter\nDetails zu Dienstkonten .\n\nKundenidentitäten verwalten\n\nKundenidentitäten sind die Identitäten, die Sie für Nutzer verwalten, damit diese Ihre Website und kundenseitigen Anwendungen verwenden können. Die Verwaltung von Kundenidentitäten und ihres Zugriffs wird auch als Identitäts- und Zugriffsverwaltung für Kunden (Customer Identity and Access Management, CIAM) bezeichnet.\n\nFür die Verwaltung von Kundenidentitäten gelten meist folgende Anforderungen:\n\nKunden die Möglichkeit geben, sich für ein neues Konto zu registrieren, und gleichzeitig Schutz vor Missbrauch bieten, beispielsweise das Erstellen von Bot-Konten erkennen und blockieren\n\nAnmeldung über soziale Netzwerke unterstützen und externe Identitätsanbieter einbinden\n\nMulti-Faktor-Authentifizierung unterstützen und Anforderungen an die Komplexität von Passwörtern erzwingen\n\nMit der Identity Platform von Google können Sie Kundenidentitäten verwalten und diese Anforderungen erfüllen. Weitere Informationen zu den Features und zum Einbinden von Identity Platform in Ihre benutzerdefinierten Anwendungen finden Sie in der Dokumentation zur Identity Platform .\n\nZugriffsverwaltung\n\nBei der Zugriffsverwaltung stehen folgende Vorgänge im Mittelpunkt:\n\nZugriff auf bestimmte Ressourcen für Identitäten gewähren oder entziehen\n\nRollen und Berechtigungen verwalten\n\nVerwaltungsfunktionen an vertrauenswürdige Personen delegieren\n\nZugriffssteuerung erzwingen\n\nZugriffe von Identitäten prüfen\n\nZugriff auf Google-Dienste verwalten\n\nIhre Organisation stützt sich möglicherweise auf eine Kombination von Google-Diensten. Sie verwenden beispielsweise\nGoogle Workspace für die Zusammenarbeit, Google Cloud Google Cloud zum\nBereitstellen benutzerdefinierter Arbeitslasten und Google Analytics zum Messen\ndes Werbeerfolgs.\n\nGoogle Workspace oder Cloud Identity bietet die Möglichkeit, zentral festzulegen, welche Unternehmensidentitäten welche Google-Dienste nutzen dürfen. Durch das Einschränken des Zugriffs auf bestimmte Dienste wird eine grundlegende Ebene der Zugriffssteuerung eingerichtet. Sie können dann die Zugriffsverwaltungsfunktionen der einzelnen Dienste verwenden, um eine detailliertere Zugriffssteuerung zu konfigurieren.\n\nAusführliche Informationen finden Sie unter Zugriff auf Google Workspace und Google-Dienste steuern\n\nZugriff auf Google Cloud verwalten Google Cloud\n\nIn Google CloudGoogle Cloud steht Ihnen\nIAM\nzur Verfügung, um für Unternehmensidentitäten den Zugriff auf bestimmte Ressourcen im Detail festzulegen. Mit\nIAM können Sie das Sicherheitsprinzip der geringsten\nBerechtigung implementieren. Dabei gewähren Sie diesen Identitäten nur Berechtigungen für den Zugriff auf die von Ihnen angegebenen\nRessourcen.\n\nWeitere Informationen finden Sie in der IAM-Dokumentation .\n\nZugriff auf Arbeitslasten und Anwendungen verwalten\n\nIhre benutzerdefinierten Arbeitslasten und Anwendungen können sich je nach Zielgruppe unterscheiden:\n\nEinige Arbeitslasten sind vielleicht auf Unternehmensnutzer ausgerichtet, z. B. interne Geschäftsanwendungen, Dashboards oder Content-Management-Systeme.\n\nAndere Anwendungen richten sich möglicherweise an Ihre Kunden, z. B. Ihre Website, ein Self-Service-Portal für Kunden oder Back-Ends für mobile Anwendungen.\n\nDie richtige Methode zum Verwalten des Zugriffs, zum Erzwingen der Zugriffssteuerung und zum Prüfen des Zugriffs hängt von der Zielgruppe und der Bereitstellung der Anwendung ab.\n\nWeitere Informationen zum Schützen von Anwendungen und anderen Arbeitslasten für Unternehmensnutzer finden Sie in der IAP-Dokumentation .\n\nSie können auch den\nLog-in direkt in Google einbinden oder Standardprotokolle wie OAuth 2.0 oder OpenID Connect verwenden.\n\nInformationen zum Erzwingen des Zugriffs auf APIs finden Sie in der Dokumentation zu Istio und Cloud Endpoints . Sie können beide Produkte verwenden, unabhängig davon, ob sich Ihre Anwendungen an Unternehmensnutzer oder an Endnutzer richten.\n\nWeitere Informationen\n\nIm Abschnitt Konzepte finden Sie weitere Informationen zu Konzepten und Funktionen der Identitätsverwaltung.\n\nIm Abschnitt Best Practices finden Sie präskriptive Anleitungen, die Sie bei Ihrer Architektur oder Ihrem Design berücksichtigen sollten\n\nIm Abschnitt Bewerten und Planen wird beschrieben, wie Sie Ihre Anforderungen bewerten und ein geeignetes Design ermitteln.\n\nFeedback geben\n\nSofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers . Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.\n\nZuletzt aktualisiert: 2024-07-11 (UTC).\n\nHaben Sie Feedback für uns?\n\n[[[\"Leicht verständlich\",\"easyToUnderstand\",\"thumb-up\"],[\"Mein Problem wurde gelöst\",\"solvedMyProblem\",\"thumb-up\"],[\"Sonstiges\",\"otherUp\",\"thumb-up\"]],[[\"Schwer verständlich\",\"hardToUnderstand\",\"thumb-down\"],[\"Informationen oder Beispielcode falsch\",\"incorrectInformationOrSampleCode\",\"thumb-down\"],[\"Benötigte Informationen/Beispiele nicht gefunden\",\"missingTheInformationSamplesINeed\",\"thumb-down\"],[\"Problem mit der Übersetzung\",\"translationIssue\",\"thumb-down\"],[\"Sonstiges\",\"otherDown\",\"thumb-down\"]],[\"Zuletzt aktualisiert: 2024-07-11 (UTC).\"],[],[]]",
+    "content_type": "text/html",
+    "query": "Cloud IAM, Cloud Secrets, Cloud Service Accounts, Cloud Incident Response, Cloud Access Review, Perfect Forward Secrecy – ein einheitliches, thematisch verknüpftes Handbuch zur Sicherheitspraxis in Cloud-Umgebungen mit Fokus auf Monitoring, Forensik und Sicherheitsmaßnahmen current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "primary",
+    "source_quality_score": 0.88,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/8ea173136e39afe8d4f3b712.json b/data/research-evidence/8ea173136e39afe8d4f3b712.json
new file mode 100644
index 0000000..6e6eda3
--- /dev/null
+++ b/data/research-evidence/8ea173136e39afe8d4f3b712.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:15:48.9140014Z",
+  "content_sha256": "affb25efe5a68b1772c08e97da7a7046e25f70d19cbc44511e8b658c1d95b970",
+  "result": {
+    "title": "Veeam Backup \u0026 Replication: Immutable Backup mit Veeam Hardened Repository",
+    "url": "https://www.netgo.de/blog/veeam-backup-replication-immutable-backup",
+    "snippet": "Mit Version 11 hat Veeam den Schutz von Backups durch äußere Angriffe in seiner Backup \u0026 Replication Suite weiter verbessert: „Hardened Repository\" heißt das Feature, welches Backups unveränderlich im jeweiligen Backup Ziel, dem Repository, ablegt.",
+    "content": "Security\n\nVeeam Backup \u0026 Replication: Immutable Backup mit Veeam Hardened Repository\n\nMit Version 11 hat Veeam den Schutz von Backups durch äußere Angriffe in seiner Backup \u0026 Replication Suite weiter verbessert: „Hardened Repository“ heißt das Feature, welches Backups unveränderlich im jeweiligen Backup Ziel, dem Repository, ablegt.\n\n03.04.2022\n\nLesedauer wird berechnet …\n\nWas bedeutet eigentlich “Immutable”, also \"unveränderliches\" Backup?\n\nPer Definition erfüllen unveränderliche Backups unter anderem den Zweck, nicht gelöscht oder verschlüsselt werden zu können. Das Löschen kann zum einen versehentlich oder willkürlich passieren, eine Verschlüsselung aber auch durch einen Angriff von außen über eine Ransomware-Infektion. Diverse Konfigurationsparameter bestimmen dabei, wie lange die Backups nicht verändert werden können.\n\nSchema zum Testaufbau\n\nWas bedeutet eigentlich “Immutable”, also \"unveränderliches\" Backup?\n\nPer Definition erfüllen unveränderliche Backups unter anderem den Zweck, nicht gelöscht oder verschlüsselt werden zu können. Das Löschen kann zum einen versehentlich oder willkürlich passieren, eine Verschlüsselung aber auch durch einen Angriff von außen über eine Ransomware-Infektion. Diverse Konfigurationsparameter bestimmen dabei, wie lange die Backups nicht verändert werden können.\n\nAllgemeine Voraussetzungen\n\nVeeam Backup \u0026 Replication 11 oder neuer\n\nLinux-Server für das Repository (Physisches Deployment empfohlen, Abbildung als VM möglich)\n– z.B. mit lokalen Festplatten für die Backup Daten\n– Wichtig: Darf nur Repository, nicht Proxy sein!\n\nEine unterstützte 64-Bit Linux-Distribution (eine generelle Empfehlung des Herstellers gibt es derzeit nicht)\n– z.B. Ubuntu Server 20.04 LTS (langfristige Updates bis 2025)\n– Unterstützung für chattr und setfattr-Kommandos\n\nNutzung des XFS-Filesystems für das Laufwerks des Repositories mit aktiviertem reflink für FastClone\n\nEinen passenden Backup Typ:\n– Backup: “Forward incremental” mit regemäßigen Full-Backups (aktiv oder synthetisch)\n– “Backup Copy”: mit GFS (“Grandfather-Father-Son“) konfiguriert\n\nLimitierungen\n\nDas “Hardened Repository” kann nicht mit anderen Veeam Backup \u0026 Replication Servern geteilt werden\n\n“Reverse” oder “forever forward incremental”-Backups sind nicht möglich, wenn die Backup-Archive unveränderlich abgelegt werden sollen\n\nNFS-Shares könne nicht genutzt werden\n\nEs gibt verschiedene Ausnahmen für Scale-Out Backup-Repositories. Diese betreffen unter anderem das Verhalten von Performance- oder Capacity-Tiers sowie die Möglichkeiten der Evakuierung\n\nBackups lassen sich nicht händisch vom Repository entfernen\n\nImmutability kann nicht für NAS oder Transaktionsbackups, RMAN/SAP HANA/ SAP on Oracle Backups genutzt werden\n\nDer Linux-Server darf, wie bereits erwähnt, nicht gleichzeitig Hardened Repository und Veeam Backup Proxy sein\n\nWas gibt es sonst zu beachten?\n\nBei der Aktivierung der Immutability Option im Repository überschreibt die Aufbewahrungsrichtlinie des Repositories die des Jobs, wenn diese kürzer ist\n\nMetadaten Files werden nicht unveränderlich abgelegt, da Sie bei jedem Job aktualisiert werden.\n\nDer Einsatz von Immutability ist nicht für Nutanix Mine-Infrastrukturen empfohlen\n\nDer Einsatz von Single Use-Credentials ist empfohlen\n\nDer Zeitraum der Immutablity kann von mindestens sieben bis max. 9999 Tage gesetzt werden. Nach Ablauf können die Backups wieder gelöscht werden\n\nDie Zeitperiode für das Immutable Backup zählt ab dem Erstellen des letzten Wiederherstellungspunktes in der aktiven Backup Kette.\n– Wenn z.B. am 01.01. ein Full Backup erstellt wurde, am 02.01 ein inkrementelles und am 03.01 das letzte inkrementelle Backup erstellt wurde, wird ab dem 03.01. losgezählt. Bei einer Aufbewahrungszeit von zehn Tagen wäre das Backup also bis einschließlich zum 13.01. nicht veränderbar\n\nSchritte zur Einrichtung von Veeam Immutable Backup mit Veeam Hardened Repositories\n\nKonfiguration der BIOS Optionen (Workload Profile etc.) des Servers\n\nRAID-Konfiguration des Controllers\n\nInstallation des Linux Servers\n\nKonfiguration des Linux Servers\n\nBei der Konfiguration des Servers gibt es einiges zu beachten. So ist es ratsam, zunächst auch einen eigenen User für den Zugriff von Veeam auf den Server lokal anzulegen und auch nur diesen zum Zugriff auf das Repository zu berechtigen. Das Repository benötigt zur Nutzung des Fast Clone-Features vor allem ein unterstütztes Filesystem (z.B. XFS) aber auch diverse Parameter wie CRC und reflink aktiviert.\n\nIm Anschluss an die passende Konfiguration des Linux Servers erfolgt nun das Anbinden an die Veeam-Infrastruktur.\n\nHierzu wird der Server zunächst als Linux Server der Backup Infrastructure hinzugefügt. Es ist empfohlen, hier Single Use-Credentials zu verwenden, da diese nicht von Veeam in der Backup-Infrastruktur gespeichert werden.\n\nSingle Use Credentials\n\nZum initialen Deployment ist es notwendig, dass der Veeam User auch die Berechtigung hat, die Rechte passend zu erhöhen. Diese temporäre Anpassung sollte nachträglich wieder entfernt werden.\n\nCredential Optionen\n\nUnter der Option “Advanced” können dann noch die Ports angepasst werden. Standardmäßig nutzt Veeam hierbei für die Kommunikation mit dem Repository Port 6162 und für die Übertragung von Daten Port 2500 bis 3300. Hier können die Ports Problemlos beschränkt werden. Pro Task wird ein Port benötigt.\n\nMit dem Fertigstellen des Wizards wird das Repository nun final hinzugefügt und der Veeam Transportdienst installiert.\nDas Anheben von Rechten ist danach für Backup- und Restore-Tasks nicht mehr notwendig, der genutzte lokale User des Linux Servers kann nun wieder in seinen Rechten erneut eingeschränkt werden. Lediglich für ein erneutes Update des Transportdienstes müssen die Rechte wieder temporär erhöht werden.\n\nDamit das Repository auch für einen Backupjob zur Verfügung steht, wird es nun in der Backup Infrastructure unter Backup Repositories hinzugefügt. Hierzu wird im Wizard Direct attached storage ausgewählt und der vorhin angelegte Linux-Server verwendet.\nHierbei ist es wichtig, den passenden Pfad zu verwenden und FastClone sowie die Immutable Funktion zu aktiveren.\n\nNeues Veeam Backup Repository\n\nJe nach Backup-Infrastruktur kann es hier auch Sinn machen, Optionen wie per-VM Backup-Files zu aktivieren.\nDie weiteren Schritte sind analog zu einem normalen Backup Repository und können daher wie notwendig passend gesetzt werden.\n\nNach erfolgtem Hinzufügen, erscheint des Repository nun in der Übersicht.\n\nNun geht es weiter an das Abschotten des Systems, um die Angriffsvektoren möglichst gering zu halten. Hierbei empfiehlt es sich folgende Einstellungen vorzunehmen:\n\nBeschränken der Netzwerkzugänge\n\nVerwenden Komplexer Passwörter sowie deaktivieren nicht benötigter Benutzer\n\nDeaktivieren nicht benötigter Dienste\n\nHärtung der Systemzugänge\n\nUm die Zeit immer aktuell zu halten, ist auch der Einsatz eines gesicherten, vertrauenswürdigen NTP-Servers ratsam. Gleichzeitig kann dies aber auch gegen den Server verwendet werden, sofern der NTP-Server kompromittiert wird. Der gezielte Einsatz eines solchen ist daher vorab und aufgrund individueller Konfigurationen zu prüfen. Alternativ kann der Server selbstverständlich auch die lokal eingestellt Systemzeit verwenden.\n\nIm Anschluss kann nun ein Backupjob konfiguriert werden. Hierbei ist es wichtig, sich an die oben bereits erwähnten Empfehlungen und Limits zu halten.\nEs ist unter anderem möglich, primäre VM-Backupjobs oder auch Backup Copy-Jobs anzulegen. Welche Methode für Ihre Backupkonzept am besten geeignet ist, richtet sich hier nach Ihrer Infrastruktur und den Vorgaben Ihres Unternehmens.\n\nNachdem der erste Backupjob auf mit dem Repository als Ziel erfolgreich gelaufen ist, können wir nun prüfen, ob es das gewünschte Ergebnis liefert. Am einfachsten ist es, einmal aus der GUI heraus eine VM aus dem Job zu entfernen. Sofern alles richtig konfiguriert worden ist, sollte das wie folgt aussehen:\n\nLöschen schlägt fehl. Erster Erfolg\n\nUnd wie sieht es auf dem Repository aus?\nDazu können wir uns dann, nach Verschaffen des Zugriffs auf die Konsole (z.B. auch vor Ort) einmal die Attribute der einzelnen Backup-Files anschauen:\n\nDas “i”-Attribut bedeutet in dem Fall, dass das “immutable”-Flag gesetzt ist. So sollte es aussehen.\n\nWie oben erwähnt, sind die Metadaten (.vbm) nicht immutable, da diese bei jedem Backupjob verändert werden. Sofern dieses Metadaten-File entfernt wird, kann es, z.B. durch ein erneutes, manuelles Importieren der Backup Kette, neu erstellt werden. Es ist daher möglich, auch ohne das Metadaten-File die Backups grundsätzlich wiederherzustellen.\n\nZu guter Letzt versuchen wir nun noch eine Datei aus dem Backupverzeichnis über die Konsole zu löschen. Auch das schlägt glücklicherweise fehl, sofern wir im Vorfeld alles richtig konfiguriert und überflüssige Rechte eingeschränkt haben.\n\nLöschen per Konsole schlägt fehl. Zweiter Erfolg\n\nWir stehen Ihnen für Fragen zur Verfügung!\n\nSie haben Fragen zu Themen rund um Veeam Backup \u0026 Replication oder benötigen Unterstützung bei der Einrichtung von Immutable Backup? Kommen Sie bei Bedarf auf uns zu, wir unterstützen Sie gerne!\n\nWeitere Beiträge\n\nAlle Artikel ansehen\n\nSecurity,\n\nVerlagswesen\n\n25 März 2026\n\nResilient statt fragil: Wie moderne IT-Verlagsstrukturen Krisen abfedern\n\nIm Branchenvergleich gestaltet sich die digitale Transformation für Verlags- und Medienhäuser als besonders herausfordernd: Prozesse sind komplexer, Abhängigkeiten größer, und Risiken vielfältiger geworden. Gleichzeitig wachsen die...\n\nWeiterlesen\n\nSecurity\n\n26 Februar 2026\n\nCyber-Resilienz im Mittelstand – von Prävention zu Recovery\n\nUnternehmen aus dem Mittelstand werden laut BSI zunehmend Opfer von Cyberkriminalität, z. B. durch mangelndes Sicherheitsmanagement. Der klassische, auf Prävention beruhende IT-Sicherheitsansatz reicht 2026 nicht mehr aus. Stattdessen...\n\nWeiterlesen\n\nSecurity\n\n17 Februar 2026\n\nWarum Sie eine IT-Sicherheitsstrategie brauchen\n\nEine IT‑Sicherheitsstrategie ist am wirksamsten, wenn sie nicht nur beschreibt, was wichtig ist, sondern wie es umgesetzt wird: mit klaren Prioritäten, Verantwortlichkeiten und einem festen Rhythmus zur Überprüfung. Aktuelle...\n\nWeiterlesen",
+    "content_type": "text/html",
+    "query": "Backup Repository Hardening – präventiv, resilient und im Vorfall erkennen, eindämmen und wiederherstellen current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.37,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/939b563adbeb83bb6d011993.json b/data/research-evidence/939b563adbeb83bb6d011993.json
new file mode 100644
index 0000000..9d16eaa
--- /dev/null
+++ b/data/research-evidence/939b563adbeb83bb6d011993.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:32:08.4532926Z",
+  "content_sha256": "0ddb72b17fd79a3220d7f219dd16c6ca202e5e8b64cc0c4dfbc82428cc77644b",
+  "result": {
+    "title": "Linux Remote Desktop: RDP, VNC, Wayland (2026)",
+    "url": "https://www.fosslinux.com/158237/linux-remote-desktop-rdp-vnc-wayland.htm",
+    "snippet": "I tested xrdp, TigerVNC, SSH X11 forwarding, and RustDesk across Ubuntu 26.04 and Fedora 44. Here is what works in 2026 with verified terminal output.",
+    "content": "Linux Remote Desktop: RDP, VNC, Wayland (2026)\n\nI tested xrdp, TigerVNC, SSH X11 forwarding, and RustDesk across Ubuntu 26.04 and Fedora 44. Here is what works in 2026 with verified terminal output.\n\nby Sarah L.\nJune 25, 2026\n\nBy Sarah L.\n\nJune 25, 2026\n\n950\n\nSarah’s Networking Brief: I manage remote access for a fleet of production Linux servers, and the one rule that has never failed me is this: never expose a raw VNC port to the internet. Every method I cover below comes with a security note, because convenience means nothing if your box gets popped.\n\nRemote desktop access on Linux used to be straightforward. You installed xrdp or TigerVNC, opened a port, and connected. In 2026, that simplicity is gone. Wayland has replaced X11 as the default display server on Ubuntu, Fedora, and most major distributions, and it breaks every traditional assumption about how screen sharing works.\n\nI spent a week testing every remote desktop method across Ubuntu 26.04 LTS and Fedora 44 to figure out what actually works right now. Here are my findings, with verified terminal output from live VMs so you can see exactly what each command produces.\n\nWhy Traditional Remote Desktop Is Breaking on Linux (2026)\n\nX11 gave applications direct access to the framebuffer. That made VNC and X11 forwarding trivial: you just grabbed the display and sent it over the network. Wayland throws a wrench into this by design. Compositors like Mutter (GNOME) and KWin (KDE) now mediate every pixel an application renders, and they do not hand that data to just any process that asks for it. I learned this the hard way when I tried to use x11vnc on a fresh Fedora 44 install and got nothing but a blank screen.\n\nThe practical consequence is that classic tools like x11vnc, which grab the physical X display, simply fail under Wayland. They cannot see the screen. TigerVNC’s new w0vncserver (shipped in version 1.16.0) works around this by using the PipeWire screen capture pipeline, but it requires the xdg-desktop-portal ScreenCast API. That is a fundamentally different architecture from the old model.\n\nRDP via xrdp sidesteps the problem entirely because it runs its own X session through xorgxrdp . You get a fresh Xorg display, not the physical screen. This is why xrdp has become the most reliable remote desktop method on Wayland-era systems.\n\nPro Tip: If you need to share your actual physical screen (the one you are sitting in front of), use gnome-remote-desktop’s built-in RDP or VNC server on GNOME 46+. It integrates with PipeWire natively and works under Wayland without any extra configuration.\n\nHow to Set Up xrdp for RDP on Ubuntu (2026)\n\nxrdp is the most reliable remote desktop server for Ubuntu in 2026. It runs its own Xorg session through the xorgxrdp module, so it does not care whether your default session is Wayland or X11. The Ubuntu 26.04 repos ship xrdp 0.10.1, which supports H.264 encoding for smoother graphics. I have this running on three production servers and it has not missed a beat.\n\nInstall xrdp and its Xorg module:\n\nfosslinux@ubuntu:~$ sudo apt-get update \u0026\u0026 sudo apt-get install -y xrdp xorgxrdp\nHit:1 http://security.ubuntu.com/ubuntu resolute-security InRelease\nHit:2 http://us.archive.ubuntu.com/ubuntu resolute InRelease\nHit:3 http://us.archive.ubuntu.com/ubuntu resolute-updates InRelease\nReading package lists...\nSetting up xorgxrdp (1:0.10.2-1build1) ...\nSetting up xrdp (0.10.1-4.1) ...\n\nVerify the service is running and listening on port 3389:\n\nfosslinux@ubuntu:~$ sudo systemctl status xrdp --no-pager\n● xrdp.service - xrdp daemon\nLoaded: loaded (/usr/lib/systemd/system/xrdp.service; enabled; preset: enabled)\nActive: active (running) since Wed 2026-06-24 23:48:00 EDT\nMain PID: 29466 (xrdp)\nJun 24 23:48:00 ubuntu xrdp[29466]: [INFO ] starting xrdp with pid 29466\nJun 24 23:48:00 ubuntu xrdp[29466]: [INFO ] listening to port 3389 on 0.0.0.0\n\nOpen the firewall port. Ubuntu ships with UFW installed but inactive by default, so the rule gets added but you need to decide whether to enable the firewall:\n\nfosslinux@ubuntu:~$ sudo ufw allow 3389/tcp\nRules updated\nRules updated (v6)\n\nConnect from Windows using mstsc.exe (Remote Desktop Connection) or from macOS using Microsoft Remote Desktop from the App Store. Enter your Ubuntu machine’s IP address and log in with your regular Linux credentials. You will get a full GNOME desktop session inside the RDP window.\n\nAlso Read\n\nMaximize functionality with these tmux plugins \u0026 extensions\n\nTcpdump unpacked: Networking diagnostics in Linux made easy\n\n10 key Linux telnet commands and techniques not to miss\n\nInsight: xrdp creates a separate X session, not a mirror of your physical screen. If you are logged in locally on Wayland, the RDP session starts its own X11 desktop. This is a feature, not a bug: it means your local session stays private while the remote user gets their own workspace.\n\nHow to Set Up xrdp for RDP on Fedora (2026)\n\nFedora 44 ships xrdp 0.10.6 in its main repositories, which is the latest upstream release with eight CVE security fixes patched in April 2026. You do not need EPEL or any third-party repo on Fedora. I was impressed that Fedora ships the latest version while Ubuntu lags behind at 0.10.1.\n\nInstall xrdp directly with DNF:\n\n[fosslinux@fedora ~]$ sudo dnf install -y xrdp xorgxrdp\nInstalling:\nxrdp x86_64 1:0.10.6-2.fc44 updates 3.5 M\nxorgxrdp x86_64 0:0.10.5-1.fc44 updates 177 k\nInstalling dependencies:\ntigervnc-server-common noarch 1:1.16.2-1.fc44 updates 122 k\ntigervnc-x11-server x86_64 1:1.16.2-1.fc44 updates 3.7 M\nComplete!\n\nEnable and start the service. Fedora runs xrdp as an unprivileged user ( xrdp:xrdp ), which is a security improvement over running as root:\n\n[fosslinux@fedora ~]$ sudo systemctl enable --now xrdp\n[fosslinux@fedora ~]$ sudo systemctl status xrdp --no-pager\n● xrdp.service - xrdp daemon\nLoaded: loaded (/usr/lib/systemd/system/xrdp.service; enabled; preset: disabled)\nActive: active (running) since Wed 2026-06-24 23:51:12 EDT\nMain PID: 7803 (xrdp)\nJun 24 23:51:12 fedora xrdp[7803]: [INFO ] listening to port 3389 on 0.0.0.0\nJun 24 23:51:12 fedora xrdp[7803]: [INFO ] Switched user:group to xrdp:xrdp\n\nOpen the firewall port with firewalld:\n\n[fosslinux@fedora ~]$ sudo firewall-cmd --permanent --add-port=3389/tcp\nsuccess\n[fosslinux@fedora ~]$ sudo firewall-cmd --reload\nsuccess\n\nSELinux note: On Fedora 44, I tested the xrdp_enable SELinux boolean and confirmed it is no longer defined. xrdp works out of the box with SELinux in Enforcing mode. You do not need to configure any SELinux booleans for xrdp on modern Fedora.\n\n[fosslinux@fedora ~]$ sudo setsebool -P xrdp_enable 1\nBoolean xrdp_enable is not defined\n\nWhy It Matters: Fedora 44’s xrdp 0.10.6 patches eight CVEs including CVE-2026-32105 and CVE-2026-33689. If you are running an older xrdp version (especially the 0.9.x branch, which is end-of-life), update immediately. The v0.9.27 release note explicitly states it is only maintained for severe security vulnerabilities.\n\nHow to Set Up TigerVNC on Ubuntu (2026)\n\nTigerVNC is the right choice when you want a virtual display, not a mirror of your physical screen. The Ubuntu 26.04 repos ship TigerVNC 1.15.0, which includes the standalone server and common utilities. I prefer TigerVNC over xrdp when I need to run a persistent desktop session that survives network disconnections.\n\nInstall the TigerVNC server packages:\n\nfosslinux@ubuntu:~$ sudo apt-get install -y tigervnc-standalone-server tigervnc-common\nSetting up tigervnc-common (1.15.0+dfsg-2build1) ...\nupdate-alternatives: using /usr/bin/tigervncconfig to provide /usr/bin/vncconfig\nSetting up tigervnc-standalone-server (1.15.0+dfsg-2build1) ...\nupdate-alternatives: using /usr/bin/tigervncserver to provide /usr/bin/vncserver\nupdate-alternatives: using /usr/bin/Xtigervnc to provide /usr/bin/Xvnc\n\nSet a VNC password before starting your first session. The password is stored in ~/.vnc/passwd and is separate from your Linux login password:\n\nfosslinux@ubuntu:~$ vncpasswd\nPassword: ********\nVerify: ********\nWould you like to enter a view-only password (y/n)? n\n\nCreate a startup configuration at ~/.vnc/xstartup to define which desktop environment or window manager to launch:\n\nfosslinux@ubuntu:~$ mkdir -p ~/.vnc\nfosslinux@ubuntu:~$ cat \u003e ~/.vnc/xstartup \u003c\u003c 'EOF'\n#!/bin/sh\nunset SESSION_MANAGER\nunset DBUS_SESSION_BUS_ADDRESS\nexec gnome-session\nEOF\nfosslinux@ubuntu:~$ chmod +x ~/.vnc/xstartup\n\nStart the VNC server on display :1 (which listens on port 5901):\n\nAlso Read\n\nHow to Uninstall Applications by Command Line in Ubuntu\n\nHow to reload a Tmux config file\n\nCreating, Deleting, and Managing Directories on Linux\n\nfosslinux@ubuntu:~$ vncserver :1 -geometry 1920x1080 -depth 24\nNew 'X' desktop is ubuntu:1\nStarting applications specified in /home/fosslinux/.vnc/xstartup\nLog file is /home/fosslinux/.vnc/ubuntu:1.log\n\nSecurity: Never leave VNC ports exposed to the internet without an SSH tunnel. VNC traffic is not encrypted by default. I always wrap it in SSH:\n\nfosslinux@local:~$ ssh -L 5901:localhost:5901 fosslinux@REMOTE_IP\n\nThen connect your VNC viewer to localhost:5901 on your local machine. The SSH tunnel encrypts everything.\n\nWorth Knowing: TigerVNC 1.16.0 added w0vncserver , a VNC server for Wayland compositors. It uses PipeWire to capture the screen, similar to how gnome-remote-desktop works. If you are on Ubuntu 26.04 with TigerVNC 1.15.0, you will not have w0vncserver yet; it requires version 1.16.0 or newer.\n\nHow to Use SSH X11 Forwarding (2026)\n\nSSH X11 forwarding lets you run individual graphical applications from a remote machine and display them on your local desktop. It is not a full remote desktop; it is more like launching a single app that happens to run on another computer. I use this constantly for running GUI configurators on headless servers without installing a full desktop environment.\n\nX11 forwarding is enabled by default on both Ubuntu and Fedora. I verified this on both VMs:\n\nfosslinux@ubuntu:~$ grep 'X11Forwarding' /etc/ssh/sshd_config\nX11Forwarding yes\n\nTo use it, install xauth on the remote machine (it is pre-installed on both Ubuntu and Fedora) and connect with the -X flag:\n\nfosslinux@ubuntu:~$ sudo apt-get install -y xauth\nfosslinux@local:~$ ssh -X fosslinux@REMOTE_IP\nfosslinux@REMOTE_IP:~$ xeyes\n\nThe xeyes window appears on your local desktop, but it is actually running on the remote machine. The -Y flag enables trusted X11 forwarding, which skips some security checks. Use -X unless you have a specific reason for -Y .\n\nWayland limitation: SSH X11 forwarding only works if your local display is running X11. If you are on a Wayland session, you need an Xwayland compatibility layer (which GNOME and KDE provide automatically) or the forwarding will fail with Can't open display .\n\nThe Wayland Remote Desktop Reality (2026)\n\nWayland does not just break old tools; it also introduces a new standard for how applications access the screen. The xdg-desktop-portal ScreenCast API is the official way for applications to capture screen content under Wayland. I spent two days debugging a black screen in Discord before I realized the portal backend was missing. Every major desktop environment now ships a portal backend:\n\nGNOME: xdg-desktop-portal-gnome (uses Mutter’s built-in screencast)\n\nKDE: xdg-desktop-portal-kde (uses KWin’s screen capture)\n\nwlroots (Sway, Hyprland): xdg-desktop-portal-wlr\n\nCOSMIC: xdg-desktop-portal-cosmic\n\nBoth Ubuntu 26.04 and Fedora 44 ship gnome-remote-desktop , which is GNOME’s built-in remote desktop daemon. It supports RDP and VNC natively, works under Wayland, and integrates with PipeWire for screen capture. This is the cleanest way to get remote desktop access on a modern GNOME system.\n\nfosslinux@ubuntu:~$ dpkg -l | grep gnome-remote-desktop\nii gnome-remote-desktop 50.0-0ubuntu2 amd64 Remote desktop daemon for GNOME using PipeWire\n\nOn Fedora, the same package is present at version 50~beta. Enable it through GNOME Settings (Settings \u003e Sharing \u003e Remote Desktop) or via the command line with grdctl .\n\nAlso Read\n\nFreeBSD 16 Goes GPL-Free: What Linux Users Need to Know\n\nWhat Is Btrfs and Why Silent Data Loss Matters: A 2026 Beginner Guide\n\nTop Linux Networking Commands (2026 Mega-Guide)\n\nPipeWire is the audio and video backbone that makes all of this work. Both VMs had PipeWire pre-installed: version 1.6.2 on Ubuntu and 1.6.7 on Fedora. The portal packages were also present:\n\nfosslinux@ubuntu:~$ dpkg -l | grep -E 'xdg-desktop-portal|pipewire'\nii xdg-desktop-portal 1.21.1+ds-1ubuntu3 all\nii xdg-desktop-portal-gnome 50.0-0ubuntu1 amd64\nii pipewire 1.6.2-1ubuntu1 amd64\n\nHow to Install and Configure RustDesk on Ubuntu (2026)\n\nRustDesk is an open-source remote desktop application written in Rust. It is the closest thing to a self-hosted TeamViewer that actually works well. With 117,000 GitHub stars and active development, it is the most popular open-source remote desktop tool in 2026. I switched from TeamViewer to RustDesk last year and have not looked back.\n\nThe catch: RustDesk is not in the APT or DNF repositories on any major distribution. I confirmed this on both Ubuntu and Fedora. You need to download it from GitHub or install it via Flatpak.\n\nfosslinux@ubuntu:~$ apt-cache search rustdesk\n(no output)\n\nDownload the latest .deb package from the RustDesk GitHub releases page and install it:\n\nfosslinux@ubuntu:~$ wget https://github.com/rustdesk/rustdesk/releases/download/1.4.8/rustdesk-1.4.8-x86_64.deb\nfosslinux@ubuntu:~$ sudo dpkg -i rustdesk-1.4.8-x86_64.deb\n\nRustDesk works out of the box with their public relay server, but for production use I strongly recommend self-hosting your own rustdesk-server . The public relay is free but shared among thousands of users, so latency and reliability vary. Self-hosting gives you full control over your data and connection quality.\n\nWayland support: RustDesk has experimental Wayland support since version 1.2.0. Screen capture works through PipeWire, but remote access to the login screen s",
+    "content_type": "text/html",
+    "query": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.3927272727272727,
+    "source_quality": "social",
+    "source_quality_score": 0.1,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/99d4d0af6e42697950261f6e.json b/data/research-evidence/99d4d0af6e42697950261f6e.json
new file mode 100644
index 0000000..fb92410
--- /dev/null
+++ b/data/research-evidence/99d4d0af6e42697950261f6e.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:44:09.650799Z",
+  "content_sha256": "495511060ca48561a0e9a592112cc5adcffbbf74a7c69c711b1eec0937b97f3b",
+  "result": {
+    "title": "Solving the remote, unattended access problem on Wayland | Eduard's Blog",
+    "url": "https://edu4rdshl.dev/posts/solving-the-remote-unattended-access-problem-on-wayland/",
+    "snippet": "Getting remote, unattended access to Wayland sessions can be challenging due to its security model. I found that using a simple WireGuard VPN setup worked perfectly.",
+    "content": "Solving the remote, unattended access problem on Wayland\nContents\n\nSolving the remote, unattended access problem on Wayland\n\nIntroduction\n\nIf you’re on the Linux world, you may have heard of Wayland . For good or for bad. It’s a modern display server protocol that aims to replace the aging X11 system. One of the key features of Wayland is its focus on security and simplicity, but it isn’t free. There have been a lot of issues from simple daily usage, app-specific problems, but notoriously, remote unattended access has been a significant challenge. Let’s focus on the unattended aspect.\n\nThe problem\n\nThe main problem with unattended remote access is that Wayland does not allow applications to capture the screen or input events unless they are explicitly granted permission each time . This means that traditional remote desktop solutions like TeamViewer or AnyDesk, which rely on full-screen, and even full session access by default (for unattended access), do not work with Wayland, as of today, and I even doubt they ever will. The same applies to alternatives such as RustDesk, and on my experience, it’s unreliable, slow, and harder to setup in case you want a self-hosted instance.\n\nIt’s a significant limitation for users who need to access their systems remotely without physical presence, which is a common situation. I personally experience this when traveling, or even simply when I want to go to the office and need something from my main desktop (I work from home).\n\nThe solution?\n\nThere is not a single, global solution for it, sorry. As everything on the Wayland world, it depends on the DE/WM implementation of it. In my case, I have been using Gnome since 1 year ago , which is one of the best DEs for Wayland support.\n\nGnome Remote Desktop\n\nGnome offers gnome-remote-desktop , which tries to solve the problem. However, it isn’t something that you can just enable and then connect from anywhere, but it’s the key to achieving unattended access on Wayland in this post, for the following reasons:\n\nDesktop Sharing\n\nGnome does offer the normal, RDP-like experience called “Desktop Sharing”, allowing you to connect to your current Wayland session remotely, but don’t allow you to unlock the computer. To enable it, go to Settings \u003e System \u003e Remote Desktop \u003e Desktop Sharing \u003e turn on “Screen Sharing”. You will also need to configure the access credentials on that screen.\n\nRemote Login\n\nAdditionally, Gnome supports a “Remote Login” feature, which enables you to log in to a Wayland session remotely without needing physical access to the machine. It works on LAN . To enable it, go to Settings \u003e System \u003e Remote Desktop \u003e Remote Login \u003e turn on “Remote Login”. You will also need to configure the access credentials on that screen.\n\nIt’s the feature that we are going to use to achieve unattended access.\n\nWireguard\n\nWireguard is a modern VPN solution that is easy to set up and use. As any VPN, their main purpose is to help you to securely connect devices, without the need to expose them directly to the internet. The trick, is to have a public VPS, which you can find for a few dollars a month on providers like OVH Cloud, Hetzner or Vultr. I found a 4vCPU, 8GB RAM, and 72GB storage instance on OVH Cloud for $52/year.\n\nI used wireguard-install to setup my WireGuard server, so I’m not going into the details of the installation process here.\n\nTLDR: run the script and follow the prompts. Once finished, if you want to add a new client, run the script again.\n\nThe setup looks like it:\n\nImportant notes\n\nConfigure your firewall on your VPS to allow incoming WireGuard traffic on the port configured in the WireGuard settings. It can be found in /etc/wireguard/wgX.conf , in the ListenPort field.\nConfigure the firewall on the machine where you want remote access to accept connections on the “Remote Login” port (default is 3389).\nIf you experience connection drops, enable PersistentKeepalive on the client’s [Peer] configuration, setting it to 25 seconds.\nMake sure that the WireGuard clients are configured to allow incoming traffic from devices on the VPN. The client’s configuration should be something like this (in case you used 10.66.66.x as the VPN subnet):\n\n10\n11\n12\n13\n14\n15\n16\n\n[Interface]\nPrivateKey = \u003cyour_private_key\u003e\nAddress = 10.66.66.2/32,fd66:66:66::2/128\nDNS = 1.1.1.1,1.0.0.1\n\n# Uncomment the next line to set a custom MTU\n# This might impact performance, so use it only if you know what you are doing\n# See https://github.com/nitred/nr-wg-mtu-finder to find your optimal MTU\n# MTU = 1420\n\n[Peer]\nPublicKey = \u003cyour_peer_public_key\u003e\nPresharedKey = \u003cyour_preshared_key\u003e\nEndpoint = \u003cyour_vps_ip\u003e:\u003cyour_vps_port\u003e\nPersistentKeepalive = 25\nAllowedIPs = 10.66.66.0/24,fd66:66:66::/64 # You can be even more specific with allowed IPs if you want\n\nWireGuard client configuration\n\nLinux\n\nIf you’re using NetworkManager on Linux , it’s as simple as:\n\n$ nmcli connection import type wireguard file \u003cpath-to-your-client-config\u003e # The client config needs a name that complies with the Linux interface naming conventions. e.g `wg0.conf`\n\nIt will automatically configure your VPN to start on boot. You can manually check with nmcli connection show and then check for the connection.autoconnect field.\n\nTip: you might want to set ipv4.never-default and ipv6.never-default to yes to prevent the VPN from being used as the default route and only use it for specific traffic on its network.\n\nAndroid, Windows, and macOS\n\nAndroid, Windows, and macOS clients can use the official WireGuard app to import the configuration file.\n\nRemote Access\n\nNote: you need to keep your WireGuard VPN connection active on the device that you want to access remotely.\n\nNow that we have our WireGuard VPN set up, we can use it to access our Gnome desktop remotely. Here’s how to do it:\n\nConnect to your WireGuard VPN from your client device.\nUse an RDP client (like Remmina or Microsoft Remote Desktop) to connect to your Gnome desktop’s IP address on the VPN (e.g., 10.66.66.2).\nLog in using the credentials you set up in the “Remote Login” settings.\n\nThe setup on Remmina should look like this:\n\nNow you’re ready to connect to your Gnome desktop from anywhere! It does work really well.\n\nLogin Screen\n\nDesktop Environment\n\nAlso, your session’s state is saved, so you can easily reconnect later and continue where you left off.\n\nAdditional notes\n\nAs long as the same principle is maintained, it is possible to achieve the same result in different ways. For example, you could use OpenVPN instead of WireGuard, or, in case that you don’t have a remote VPS, you can use solutions like Cloudflare Tunnels, or Ngrok. DDNS may also be an option.\n\nConclusion\n\nIt was a very cool experience setting up remote access to my Wayland session using WireGuard. The combination of a VPN and RDP worked seamlessly, and I can now access my desktop from anywhere with ease. I’d to say that WireGuard is one of the best pieces of software I’ve ever used lately.\n\nHappy remote accessing!\n\nlinux , gnome , wayland\n\nremote access wayland linux gnome\n\nThis post is licensed under CC BY 4.0 by the author.\n\nShare",
+    "content_type": "text/html",
+    "query": "Welche konkreten Schritte sind für die Härtung von Wayland/X11 Remote Access erforderlich?",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.42,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "REVIEW-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/9b6b4cb17ae3122856676b8d.json b/data/research-evidence/9b6b4cb17ae3122856676b8d.json
new file mode 100644
index 0000000..b77953f
--- /dev/null
+++ b/data/research-evidence/9b6b4cb17ae3122856676b8d.json
@@ -0,0 +1,25 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:43:38.4445765Z",
+  "content_sha256": "c3cfb973a86252af703b26d8cb49c6eff015e8829a0b0dd9e4b2449677beb007",
+  "result": {
+    "title": "X11 Application Support - Wayland",
+    "url": "https://wayland.freedesktop.org/docs/book/Xwayland.html",
+    "snippet": "Being able to run existing X11 applications is crucial for the adoption of Wayland, especially on desktops, as there will always be X11 applications that have not been or cannot be converted into Wayland applications, and throwing them all away would be prohibitive.",
+    "content": "X11 Application Support\n\nIntroduction\n\nBeing able to run existing X11 applications is crucial for the adoption of\nWayland, especially on desktops, as there will always be X11 applications that\nhave not been or cannot be converted into Wayland applications, and throwing\nthem all away would be prohibitive. Therefore a Wayland compositor often needs\nto support running X11 applications.\n\nX11 and Wayland are different enough that there is no “simple” way to translate\nbetween them. Most of X11 is uninteresting to a Wayland compositor. That,\ncombined with the gigantic implementation effort needed to support X11, makes it\nintractable to just write X11 support directly in a Wayland compositor. The\nimplementation would be nothing short of a real X11 server.\n\nTherefore, Wayland compositors should use Xwayland, the X11 server that lives in\nthe Xorg server source code repository and shares most of the implementation\nwith the Xorg server. Xwayland is a complete X11 server, just like Xorg is, but\ninstead of driving the displays and opening input devices, it acts as a Wayland\nclient. The rest of this chapter talks about how Xwayland works.\n\nFor integration and architecture reasons, while Xwayland is a Wayland client of\nthe Wayland compositor, the Wayland compositor is an X11 client of Xwayland.\nThis circular dependency requires special care from the Wayland compositor.\n\nTwo Modes for Foreign Windows\n\nIn general, windows from a foreign window system can be presented in one of two\nways: rootless and rootful (not rootless).\n\nIn rootful mode, the foreign window system as a whole is represented as a window\n(or more) of its own. You have a native window, inside which all the foreign\nwindows are. The advantage of this approach in Xwayland’s case is that you can\nrun your favourite X11 window manager to manage your X11 applications. The\ndisadvantage is that the foreign windows do not integrate with the native\ndesktop. Therefore this mode is not usually used.\n\nIn rootless mode, each foreign window is a first-class resident among the native\nwindows. Foreign windows are not confined inside a native window but act as if\nthey were native windows. The advantage is that one can freely stack and mix\nnative and foreign windows, which is not possible in rootful mode. The\ndisadvantage is that this mode is harder to implement and fundamental\ndifferences in window systems may prevent some things from working. With\nrootless Xwayland, the Wayland compositor must take the role as the X11 window\nmanager, and one cannot use any other X11 window manager in its place.\n\nThis chapter concentrates on the rootless mode, and ignores the rootful mode.\n\nArchitecture\n\nA Wayland compositor usually takes care of launching Xwayland. Xwayland works in\ncooperation with a Wayland compositor as follows:\n\nXwayland architecture diagram\n\nAn X11 application connects to Xwayland just like it would connect to any X\nserver. Xwayland processes all the X11 requests. On the other end, Xwayland is a\nWayland client that connects to the Wayland compositor.\n\nThe X11 window manager (XWM) is an integral part of the Wayland compositor. XWM\nuses the usual X11 window management protocol to manage all X11 windows in\nXwayland. Most importantly, XWM acts as a bridge between Xwayland window state\nand the Wayland compositor’s window manager (WWM). This way WWM can manage all\nwindows, both native Wayland and X11 (Xwayland) windows. This is very important\nfor a coherent user experience.\n\nSince Xwayland uses Wayland for input and output, it does not have any use for\nthe device drivers that Xorg uses. None of the xf86-video-* or xf86-input-*\nmodules are used. There also is no configuration file for the Xwayland server.\nFor optional hardware accelerated rendering, Xwayland uses GLAMOR.\n\nA Wayland compositor usually spawns only one Xwayland instance. This is because\nmany X11 applications assume they can communicate with other X11 applications\nthrough the X server, and this requires a shared X server instance. This also\nmeans that Xwayland does not protect nor isolate X11 clients from each other,\nunless the Wayland compositor specifically chooses to break the X11 client\nintercommunications by spawning application specific Xwayland instances. X11\nclients are naturally isolated from Wayland clients.\n\nXwayland compatibility compared to a native X server will probably never reach\n100%. Desktop environment (DE) components, specifically X11 window managers, are\npractically never supported. An X11 window manager would not know about native\nWayland windows, so it could manage only X11 windows. On the other hand, there\nmust be an XWM that reserves the exclusive window manager role so that the\nWayland compositor could show the X11 windows appropriately. For other DE\ncomponents, like pagers and panels, adding the necessary interfaces to support\nthem in WWM through XWM is often considered not worthwhile.\n\nX Window Manager (XWM)\n\nFrom the X11 point of view, the X window manager (XWM) living inside a Wayland\ncompositor is just like any other window manager. The difference is mostly in\nwhich process it resides in, and the few extra conventions in the X11 protocol\nto support Wayland window management (WWM) specifically.\n\nThere are two separate asynchronous communication channels between Xwayland and\na Wayland compositor: one uses the Wayland protocol, and the other one, solely\nfor XWM, uses X11 protocol. This setting demands great care from the XWM\nimplementation to avoid (random) deadlocks with Xwayland. It is often nearly\nimpossible to prove that synchronous or blocking X11 calls from XWM cannot cause\na deadlock, and therefore it is strongly recommended to make all X11\ncommunications asynchronous. All Wayland communications are already asynchronous\nby design.\n\nWindow identification\n\nIn Xwayland, an X11 window may have a corresponding wl_surface object in\nWayland. The wl_surface object is used for input and output: it is referenced by\ninput events and used to provide the X11 window content to the Wayland\ncompositor. The X11 window and the wl_surface live in different protocol\nstreams, and they need to be matched for XWM to do its job.\n\nWhen Xwayland creates a wl_surface on Wayland, it will also send an X11\nClientMessage of type atom “WL_SURFACE_ID” to the X11 window carrying the\nwl_surface Wayland object ID as the first 32-bit data element. This is how XWM\ncan associate a wl_surface with an X11 window. Note that the request to create a\nwl_surface and the ID message may arrive in any order in the Wayland compositor.",
+    "content_type": "text/html",
+    "query": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.3507692307692308,
+    "source_quality": "primary",
+    "source_quality_score": 0.88,
+    "actionable": true,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/9bcc7f9cb2366ce41246d7b3.json b/data/research-evidence/9bcc7f9cb2366ce41246d7b3.json
new file mode 100644
index 0000000..aa699f7
--- /dev/null
+++ b/data/research-evidence/9bcc7f9cb2366ce41246d7b3.json
@@ -0,0 +1,25 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T21:46:10.8725679Z",
+  "content_sha256": "4b753594cdde25fd707335831795a59d84be5b93fa53fae77101f9697457083e",
+  "result": {
+    "title": "GraphQL Introspection: Risks, Abuse Patterns, and Production-Ready Mitigations | ASOasis - All about Tech",
+    "url": "https://asoasis.tech/articles/2026-05-17-0253-graphql-introspection-security-concerns/",
+    "snippet": "Understand GraphQL introspection risks and how to secure production APIs: restrict or disable introspection, enforce allowlists, rate limits, and robust auth.",
+    "content": "Image used for representation purposes only.\n\nOverview\n\nGraphQL introspection is a powerful feature that lets clients query a server for its schema—types, fields, arguments, directives, and deprecations. It underpins great DX (developer experience): auto-complete in IDEs, code generation, and interactive docs. But the same capability also offers attackers a near-perfect map of your API surface. This article explains the risks, common mistakes, and a practical, defense-in-depth approach to running GraphQL safely in production.\n\nWhy introspection increases risk\n\nIntrospection can disclose:\n\nComplete type system, including hidden relationships and legacy fields you thought nobody used anymore.\n\nArguments and default values that may hint at internal identifiers, enums, or even secrets if defaults are misused.\n\nDeprecation reasons and descriptions that leak implementation details or roadmaps.\n\nCustom directives that reveal internal behaviors (authorization, caching, rate limits) and sometimes environment-specific URLs.\n\nIn federated setups, service-specific metadata; in some implementations, SDL for subgraphs can be exposed if not gated.\n\nFor an attacker, this eliminates guesswork. With one request, they gain reconnaissance for follow-up enumeration, privilege probing, and targeted injection or resource-exhaustion attempts.\n\nThreat models and abuse patterns\n\nSchema reconnaissance: Run an introspection query, export to visual tools, and identify high-value mutations, admin fields, or n+1-heavy lists.\n\nPrivilege probing: Compare field-level auth behavior across types and arguments discovered via introspection.\n\nDoS amplification: Craft deeply nested queries and fragments based on the exact graph shape; combine with batching to increase server load.\n\nError-driven discovery: Even if mutations are protected, detailed error messages plus schema knowledge can reveal role names, tenant boundaries, or internal IDs.\n\nFederation leakage: In some stacks, special fields (for example, service-SDL endpoints) can reveal internal composition details if left open to the public internet.\n\nRecognizing introspection in the wild\n\nMost introspection queries reference special fields and types with double underscores:\n\n__schema, __type, __typename\n\n__Type, __Field, __InputValue\n\nA minimal example:\n\nquery Introspection {\n__schema {\ntype s { name kind }\n\nAttackers may alias or fragment these, but the underlying names never change. Look for these tokens in logs, WAF rules, and SIEM dashboards.\n\nCommon production misconfigurations\n\nLeaving GraphiQL/Playground enabled in production, often with default CORS.\n\nAllowing anonymous introspection on public origins or from untrusted IPs.\n\nOverly helpful error formatting: stack traces, field suggestions (“Did you mean …?”) and full path traces.\n\nExposing legacy/deprecated fields indefinitely; deprecation notes that disclose internals or timelines.\n\nUsing default argument values that encode secrets or internal IDs.\n\nMitigation strategy: defense in depth\n\nNo single control is sufficient. Combine the following measures based on your risk and tooling.\n\n1) Disable or strictly gate introspection in production\n\nBest default: disable introspection for the public runtime. Keep it enabled only in development and internal environments.\n\nIf your workflow needs runtime introspection (for example, internal explorers or schema registries), require strong authentication and restrict by role, network, and origin.\n\nExample (JavaScript, graphql-js) denying introspection via a validation rule:\n\nimport { NoSchemaIntrospectionCustomRule } from 'graphql' ;\nimport depthLimit from 'graphql-depth-limit' ;\nimport { createComplexityLimitRule } from 'graphql-validation-complexity' ;\n\nconst validationRules = [\nNoSchemaIntrospectionCustomRule , // blocks __schema/__type\ndepthLimit ( 10 ), // control nested depth\ncreateComplexityLimitRule ( 1500 ) // cap total cost\n];\n\n// Attach validationRules in your server adapter of choice\n\nTip: Many servers also expose a simple flag to turn off introspection; use both the flag and a validation rule for belt-and-suspenders hardening.\n\n2) Prefer persisted/allowlisted operations\n\nUse persisted queries: the client sends only a hash (ID) and the server resolves it to a pre-approved query.\n\nBlock execution of arbitrary text operations at the edge (CDN/WAF) so only known query IDs are accepted.\n\nBenefits: reduces attack surface, stabilizes performance, and simplifies anomaly detection.\n\nOperational pattern:\n\nGenerate query IDs during build.\n\nPublish allowlist to the gateway and/or CDN.\n\nReject unknown IDs with a generic 4xx.\n\n3) Enforce depth, complexity, and time budgets\n\nDepth limits: cap maximum nesting to stop pathological traversals.\n\nComplexity scoring: assign cost per field/argument and set a global ceiling per request.\n\nQuery timeouts: cancel execution after a safe threshold; return a generic error.\n\nBatching limits: cap the number of operations per request.\n\n4) Lock down explorers and schema tooling\n\nDisable GraphiQL/Playground in production or protect behind SSO/VPN.\n\nIf keeping an explorer for on-call teams, ensure the same RBAC and network controls apply as for the API itself.\n\n5) Sanitize errors and logs\n\nRemove stack traces and internal paths from client-facing errors; keep them in server logs only.\n\nTurn off field suggestion text in errors if your server/framework supports it.\n\nReturn uniform error messages on authorization failures to avoid oracle effects.\n\n6) Harden schema hygiene\n\nAvoid secrets in default argument values and descriptions.\n\nKeep descriptions factual but not revealing (no internal hostnames, buckets, or roadmaps).\n\nActually delete deprecated fields on schedule; don’t let them linger as low-hanging fruit.\n\nReview custom directives that might disclose internal policies in introspection.\n\n7) Federation and composition notes\n\nTreat service-level schemas as sensitive. Limit who can request composition/SDL outputs at runtime.\n\nPrefer private network paths (or service accounts) between gateway and subgraphs; block public access to subgraph endpoints where possible.\n\n8) Observe, alert, and block\n\nLogging: record operation name, query signature/hash, depth, complexity, latency, and whether introspection tokens were present.\n\nDetection: alert on spikes in requests containing “__schema” or “__type”, especially from new origins or IP ranges.\n\nWAF: add body-inspection rules for the double-underscore tokens and known introspection fragments; rate-limit matches aggressively.\n\nQuick-start hardening checklist\n\nDisable introspection for public traffic.\n\nUse persisted queries with an allowlist at the CDN/gateway.\n\nEnforce depth ≤ 10 and complexity ceilings tailored to your graph.\n\nDisable GraphiQL/Playground on the public internet.\n\nSanitize error messages; log stack traces server-side only.\n\nAdd WAF rules for “__schema”/\"__type\" and rate-limit matches.\n\nReview schema descriptions, defaults, and deprecations for leakage.\n\nIn federated setups, restrict composition/SDL endpoints to trusted networks.\n\nTesting your controls\n\nPositive tests: ensure allowed persisted operations work under normal and high load.\n\nNegative tests: attempt introspection, deep nesting, high-cost queries, and batched operations; verify denials and alerts.\n\nTooling: use common security scanners and GraphQL explorers internally to validate that controls don’t break legitimate workflows.\n\nTrade-offs and safe enablement\n\nThere are valid reasons to keep introspection available—dynamic clients, rapid prototyping, or internal developer portals. If you must enable it:\n\nScope it: authz-bound and network-restricted; short-lived tokens; audit logs.\n\nTimebox it: enable during maintenance windows only.\n\nMirror it: provide a sanitized, documentation-only schema instead of the full production graph.\n\nConclusion\n\nIntrospection is not inherently unsafe—running it unauthenticated in production is. Treat your GraphQL schema as sensitive metadata and control how, when, and by whom it can be discovered. With disabled or tightly gated introspection, persisted queries, query cost controls, sanitized errors, and disciplined schema hygiene, you preserve GraphQL’s DX advantages without handing attackers a blueprint of your backend.\n\nTags\n\nGraphQL\n\nSecurity\n\nAPI Security\n\nIntrospection\n\nAuthorization\n\nRate Limiting\n\nDevSecOps\n\nRelated Posts\n\nSoftware Engineering\n\nGraphQL Schema Stitching and Type Merging: A Practical Guide\n\nA practical guide to GraphQL schema stitching and type merging with patterns, code, performance tips, and pitfalls for building a reliable gateway.\n\nASOasis\n\nMay 13, 2026\n\nRead More\n\n8 min",
+    "content_type": "text/html",
+    "query": "GraphQL Introspection Sicherheit current official documentation version support",
+    "language": "en-US",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.3333333333333333,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "actionable": true,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/9fda1b104d8b578b4fe700d6.json b/data/research-evidence/9fda1b104d8b578b4fe700d6.json
new file mode 100644
index 0000000..c8d5ec1
--- /dev/null
+++ b/data/research-evidence/9fda1b104d8b578b4fe700d6.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:44:07.4500631Z",
+  "content_sha256": "2682c9b48782028933ea9fba974baba3a1e06b9a6d8fedaebfc95fe040c129b8",
+  "result": {
+    "title": "Management von Sicherheitsvorfällen: Prävention und Reaktion",
+    "url": "https://smct-management.de/management-von-sicherheitsvorfaellen/",
+    "snippet": "Hier geht es um die konkrete Vorgehensweise bei der Erkennung, Behandlung und Nachbereitung von Sicherheitsvorfällen. Die Anforderungen umfassen das Einrichten von Meldestellen, die Dokumentation von Vorfällen und die Bewertung von Risiken.",
+    "content": "Startseite » Unser Blog » Informationsmanagementsysteme » Management von Sicherheitsvorfällen\nManagement von Sicherheitsvorfällen\n\nInformationsmanagementsysteme\n\nDas  Management von Sicherheitsvorfällen  (oft auch als Incident Management bezeichnet) ist ein unverzichtbarer Baustein jedes Informationssicherheitskonzepts. Unternehmen sind täglich verschiedensten Bedrohungen ausgesetzt, seien es Cyberangriffe, interne Sicherheitslücken oder menschliche Fehler. Umso wichtiger ist es, Sicherheitsvorfälle frühzeitig zu erkennen, zielgerichtet zu melden und konsequent zu bearbeiten. Ein strukturiertes Vorgehen sichert nicht nur den laufenden Betrieb, sondern schützt auch das Ansehen des Unternehmens und reduziert mögliche finanzielle Schäden.\n\nProzesse, Rollen und Verantwortlichkeiten beim Erkennen, Melden und Bearbeiten von Sicherheitsvorfällen :\n\nEin klar definierter Incident-Management-Prozess beginnt bereits bei der Prävention und Vorbereitung. Alle Mitarbeitenden sollten wissen, wie sie einen Vorfall melden und welche Informationen dabei entscheidend sind. In vielen Organisationen übernimmt ein Informationssicherheitsbeauftragte ISB oder das Vorfallteam (Reaktionsteam) die zentrale Koordination: Sie sind für die Einordnung des Vorfalls, die Kommunikation mit den beteiligten Abteilungen und die Veranlassung der nötigen Sofortmaßnahmen verantwortlich.\n\nWichtig ist, dass sämtliche Rollen und Verantwortlichkeiten schriftlich festgehalten werden. Dies umfasst neben dem Incident-Manager auch IT-Experten, Fachbereichsleiter, Datenschutzbeauftragte und ggf. externe Dienstleister. Nur so lassen sich Reibungsverluste vermeiden und eine schnelle Reaktion gewährleisten.\n\nManagement von Sicherheitsvorfällen – BSI IT-Grundschutz\n\nDas BSI IT-Grundschutz-Kompendium ist in Deutschland die zentrale Referenz, wenn es um die Einführung und den Betrieb eines ganzheitlichen Informationssicherheitsmanagementsystems ( ISMS ) geht. Es bietet praxisnahe Bausteine und Maßnahmen, die Unternehmen und Behörden dabei unterstützen, ihre IT-Infrastruktur systematisch abzusichern. Ein essenzieller Teil davon ist das Incident Management, also die effektive Handhabung von Sicherheitsvorfällen.\n\nBSI IT-Grundschutz\n\nDer Bundesamt für Sicherheit in der Informationstechnik (BSI) verfolgt mit dem IT-Grundschutz das Ziel, einheitliche und anerkannte Standards in Deutschland zu etablieren. Unternehmen und Organisationen, die sich an diesen Bausteinen orientieren, schaffen eine solide Basis für ihre Informationssicherheit . Darüber hinaus besteht die Möglichkeit, das eigene ISMS nach ISO/IEC 27001 auf Basis von IT-Grundschutz zertifizieren zu lassen. Dadurch erhalten Sie sowohl national als auch international eine anerkannte Bestätigung Ihres Sicherheitsniveaus.\n\nIT-Grundschutz-Bausteine\n\nDas Incident Management ist im IT-Grundschutz-Kompendium kein isoliertes Thema, sondern fest in die Gesamtsystematik integriert. Typischerweise findet man in den Prozess-Bausteinen (ORP-Bausteine) konkrete Hinweise für den Aufbau und Betrieb eines strukturierten Umgangs mit Sicherheitsvorfällen. Beispielsweise:\n\nORP.1 „Organisation“\nDieser Baustein legt fest, wie Verantwortlichkeiten und Rollen definiert sein sollten. Für das Incident Management bedeutet das, ein Incident-Management-Team zu benennen und Eskalationswege sowie Kommunikationskanäle klar zu regeln.\n\nORP.3 „Sicherheitsvorfälle und Notfälle“\nHier geht es um die konkrete Vorgehensweise bei der Erkennung, Behandlung und Nachbereitung von Sicherheitsvorfällen. Die Anforderungen umfassen das Einrichten von Meldestellen, die Dokumentation von Vorfällen und die Bewertung von Risiken.\n\nORP.4 „Notfallmanagement“\nZwar bezieht sich dieser Baustein vorrangig auf das übergreifende Krisen- und Notfallmanagement , überschneidet sich jedoch mit dem Incident Management, sobald ein Ereignis von kritischer Schwere vorliegt. Die im Baustein empfohlenen Prozesse tragen zur Minimierung von Ausfallzeiten und Schäden bei.\n\nVorgehensweise nach dem BSI-Standard\n\nVorbereitung und Planung\nErstellen Sie zunächst ein Sicherheitskonzept (z. B. auf Basis von BSI Standard 200-2 „IT-Grundschutz-Methodik“), in dem festgehalten wird, welche Szenarien besonders relevant sind.\nDefinieren Sie Rollen: Wer leitet das Incident-Response-Team, wer übernimmt die forensische Analyse, wer kommuniziert nach außen?\n\nErkennung und Bewertung von Vorfällen\nSetzen Sie geeignete Überwachungsmechanismen ein (SIEM-Systeme, Log-Management), um Anomalien frühzeitig zu erkennen.\nBewerten Sie jeden Vorfall anhand definierter Kriterien, beispielsweise unter Nutzung einer Risikomatrix (BSI-Standard 200-3 „Risikomanagement“).\n\nEindämmung und Wiederherstellung\nSobald ein Incident bestätigt ist, greifen Sie auf die im Grundschutz-Kompendium empfohlenen Maßnahmen zurück: Netzwerksegmentierung, Account-Sperrungen, Systemisolation etc.\nHalten Sie sich an klare Ablaufpläne (Runbooks), in denen Schritt für Schritt erläutert wird, wie Systeme zu bereinigen und wieder in Betrieb zu nehmen sind.\n\nDokumentation und Nachbereitung\nProtokollieren Sie alle Maßnahmen und Ereignisse. Nur so können Sie später Schwachstellen identifizieren und Verbesserungen vornehmen.\nFühren Sie ein „Lessons Learned“ durch. Der BSI-Ansatz legt Wert auf den stetigen Verbesserungsprozess, damit künftige Vorfälle effizienter gehandhabt werden können.\n\nWie lässt sich ein Incident-Response-Konzept erstellen?\n\nEin Incident-Response-Konzept definiert aufbauend auf Risikobewertungen und den spezifischen Anforderungen der Organisation die grundlegenden Abläufe im Ernstfall. Es umfasst vor allem:\n\nErkennung\nMonitoring-Systeme, Intrusion-Detection/Prevention-Systeme oder SIEM-Lösungen ( Security Information and Event Management) unterstützen beim Aufspüren von Anomalien.\nEinstufung und Priorisierung: Jeder Vorfall wird anhand definierter Kriterien bewertet, um die Relevanz und Dringlichkeit zu bestimmen.\n\nReaktion\nAbhängig vom Schweregrad leitet das Incident-Management-Team Maßnahmen ein – von einer einfachen Passwortzurücksetzung bis hin zur vorübergehenden Stilllegung betroffener Systeme.\n\nKommunikation\nDie interne und externe Kommunikation – etwa mit Geschäftspartnern oder Behörden – erfolgt nach klaren Richtlinien, um Gerüchten und Fehlinformationen vorzubeugen.\nWiederherstellung: Systeme und Prozesse werden wieder an den Normalbetrieb herangeführt, wobei Korrekturmaßnahmen implementiert und dokumentiert werden.\n\nStep by Step: Management von Sicherheitsvorfällen\n\nNachfolgend findest du eine praxiserprobte Schritt-für-Schritt-Anleitung für das Management von Sicherheitsvorfällen (Incident Management). Die einzelnen Phasen helfen dir, im Falle eines Vorfalls strukturiert zu agieren, Zuständigkeiten zu klären und Schäden so gering wie möglich zu halten.\n\nSchritt-für-Schritt-Anleitung für das Management von Sicherheitsvorfällen\n\nVorbereitung (Preparation)\nRollen und Verantwortlichkeiten definieren\nBestimme ein Incident-Management-Team (z. B. IT-Leiter, Sicherheitsbeauftragter, Fachbereichsleiter).\nLege die Zuständigkeiten fest und dokumentiere sie in einem Organigramm oder einem Handbuch.\nStelle sicher, dass alle relevanten Kontaktdaten vorliegen (intern und extern).\nIncident-Response-Plan erstellen\nDefiniere Notfallprozesse für verschiedene Szenarien (z. B. Malware-Befall, DDoS-Attacke, Datenleck).\nErstelle Runbooks/Playbooks: Schritt-für-Schritt-Anleitungen für die Reaktion auf einen Vorfall.\nIntegriere die Kommunikationsstrategie (intern sowie extern).\nTechnische und organisatorische Vorbereitung\nImplementiere Überwachungssysteme (z. B. SIEM, Intrusion Detection Systems).\nRichte ein Ticketing-System oder ein zentrales Meldesystem für Vorfälle ein.\nSchulen und sensibilisieren: Alle Mitarbeiter müssen wissen, wie sie einen Vorfall erkennen und an wen sie sich wenden sollen.\n\nErkennung (Detection)\nMonitoring und Alarmierung\nNutze aktive Überwachungstools (Log-Management, SIEM), die Anomalien automatisch melden.\nEtabliere klare Alarmierungswege (E-Mail, SMS, Dashboard-Benachrichtigungen).\nManuelles Reporting ermöglichen\nStelle sicher, dass Mitarbeiter über ein einfaches Meldesystem (z. B. per Hotline, Ticket-System) Verdachtsfälle weitergeben können.\nFördere eine „Meldekultur“ durch Awareness-Kampagnen.\nErste Bewertung\nBestimme, ob es sich um einen sicherheitsrelevanten Vorfall, eine Falschmeldung oder ein internes Testereignis handelt.\nBei ernstem Verdacht: Sofort das Incident-Management-Team informieren.\n\nAnalyse und Einstufung (Analysis \u0026 Classification)\nVorfall untersuchen\nAnalysiere Logfiles, Firewall-Meldungen, Systemprozesse oder Netzwerktraffic.\nIdentifiziere betroffene Systeme, Daten und mögliche Schwachstellen.\nSchweregrad und Priorität festlegen\nNutze eine Risikomatrix oder fest definierte Kriterien, um den Vorfall einzustufen (z. B. kritisch, hoch, mittel, niedrig).\nBei hohen oder kritischen Vorfällen: Sofort das Management bzw. die Geschäftsleitung involvieren.\nFestlegung der nächsten Schritte\nBasierend auf der Einstufung entscheidet das Incident-Management-Team über das weitere Vorgehen (z. B. Teilabschaltung von Systemen, Einleiten eines Notfallplans).\n\nEindämmung und Beseitigung (Containment \u0026 Eradication)\nEindämmungsmaßnahmen umsetzen\nSperre betroffene User-Accounts oder segmentiere das Netzwerk, um eine weitere Ausbreitung zu verhindern.\nSchalte Systeme mit hohem Risiko ggf. vom Netzwerk ab, bis die Ursache geklärt ist. Dokumentiere alle Schritte sorgfältig.\nBeseitigung des Angriffsvektors\nAktualisiere Patches, entferne schädliche Software oder ersetze kompromittierte Komponenten.\nPrüfe alle Systeme, die mit dem betroffenen System in Kontakt standen, um Folgeschäden zu minimieren.\nBestätigte Lösung\nStelle sicher, dass die Ursache behoben und keine Hintertüren oder weitere Infektionen zurückgeblieben sind.\nFühre ggf. Penetrationstests oder forensische Analysen durch, um eine vollständige Säuberung zu garantieren.\n\nWiederherstellung (Recovery)\nSysteme wieder in Betrieb nehmen\nStarte Systeme und Dienste nacheinander, um mögliche erneute Kompromittierungen frühzeitig zu erkennen.\nÜberprüfe Logfiles und Überwachungssysteme, während die Systeme hochfahren.\nKontrolle der Funktionalität\nTeste, ob alle Anwendungen und Prozesse einwandfrei laufen.\nPrüfe, ob Sicherheitsupdates, Konfigurationen und neue Richtlinien korrekt angewendet wurden.\nGeplante Kommunikation\nInformiere alle relevanten Stakeholder (Mitarbeiter, Kunden, Partner) über den erfolgreichen Abschluss der Maßnahmen.\nStelle sicher, dass vereinbarte Kommunikationswege und -inhalte eingehalten werden.\n\nNachbereitung (Lessons Learned \u0026 Continuous Improvement)\nFühre ein Nachbearbeitungsmeeting mit allen beteiligten Parteien durch.\nAnalysiere, was gut lief und wo Schwachstellen lagen (Prozesse, Technik, Kommunikation).\nVerbesserungsmaßnahmen ableiten\nPasse den Incident-Response-Plan und die Runbooks an, wenn Mängel erkannt wurden.\nPlane zusätzliche Schulungen oder Sensibilisierungskampagnen, falls menschliche Fehler im Vordergrund standen.\nDokumentation und Berichte\nErfasse sämtliche Erkenntnisse in einem Abschlussbericht.\nTeile relevante Informationen mit betroffenen Abteilungen oder externen Stellen (z. B. Datenschutzbehörden, falls personenbezogene Daten betroffen waren).\nÜberprüfe die Effektivität der umgesetzten Maßnahmen und setze ggf. neue KPIs (Key Performance Indicators) für zukünftige Vorfälle.\n\nFAQ – Management von Sicherheitsvorfällen (Incident Management)\n\nWas ist Incident Management?\nIncident Management bezeichnet den Prozess, mit dem ein Unternehmen auf Sicherheitsvorfälle (z. B. Cyberangriffe, Datenlecks, Systemausfälle) reagiert. Ziel ist es, potenzielle Schäden frühzeitig zu erkennen, zu begrenzen und langfristige Folgen zu minimieren. Dabei spielen sowohl organisatorische als auch technische Maßnahmen eine wichtige Rolle.\n\nWarum ist ein Incident-Response-Konzept so wichtig?\nEin strukturiertes Incident-Response-Konzept hilft, in Krisensituationen den Überblick zu behalten und schnell die richtigen Maßnahmen zu ergreifen. Statt im Ernstfall improvisieren zu müssen, folgen alle Beteiligten klar definierten Prozessen und Verantwortlichkeiten. Das spart Zeit und Ressourcen und reduziert die Ausfall- oder Schadensdauer erheblich.\n\nWer trägt die Verantwortung für das Incident Management?\nIn der Regel wird ein Incident-Manager oder ein Incident-Response-Team mit der Koordination betraut. Dieses Team setzt sich aus IT-Sicherheitsexperten, Mitgliedern der Geschäftsleitung sowie gegebenenfalls Fachbereichsleitern zusammen. Auch der Datenschutzbeauftragte und externe Dienstleister können Teil des Teams sein, je nach Art und Schwere des Vorfalls.\n\nWelche Phasen umfasst ein typischer Incident-Management-Prozess?\nEin gängiges Vorgehensmodell gliedert sich in folgende Phasen:\nVorbereitung (Preparation)\nErkennung (Detection)\nAnalyse und Einstufung (Analysis \u0026 Classification)\nEindämmung und Beseitigung (Containment \u0026 Eradication)\nWiederherstellung (Recovery)\nNachbereitung / Lessons Learned (Post-Incident Review)\n\nWelche Tools und Vorgehensweisen sind im Incident Management üblich?\nSIEM-Systeme (Security Information and Event Management) Sammeln und analysieren Logdaten, um verdächtige Aktivitäten zu erkennen.\nIntrusion Detection/Prevention Systeme\nÜberwachen den Datenverkehr auf Anomalien und blockieren potenzielle Angriffe.\nForensik-Tools\nErmöglichen die technische Analyse kompromittierter Systeme.\nTicketing-Systeme\nDienen zur strukturierten Erfassung, Bearbeitung und Nachverfolgung von Vorfällen.\nPlaybooks/Runbooks\nDokumentieren Handlungsschritte für verschiedene Angriffsszenarien.\n\nWie schnell sollte ein Vorfall gemeldet werden?\nJe schneller, desto besser. Eine rasche Meldung kann verhindern, dass sich ein kleiner Vorfall zu einem gravierenden Sicherheitsproblem ausweitet. Viele Organisationen definieren interne Service-Level-Agreements (SLAs), die feste Zeitfenster für die Meldung und Bearbeitung von Vorfällen vorgeben.\n\nWann sollte man externe Stellen informieren?\nDas",
+    "content_type": "text/html",
+    "query": "Welche konkreten Schritte sind für die Erkennung von Vorfällen bei Wayland/X11 Remote Access erforderlich?",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.37,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "REVIEW-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/a44891c23d230559770fd36b.json b/data/research-evidence/a44891c23d230559770fd36b.json
new file mode 100644
index 0000000..547e3bd
--- /dev/null
+++ b/data/research-evidence/a44891c23d230559770fd36b.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:12:27.6797822Z",
+  "content_sha256": "ce654bc0abaf463a23308dae3df46980618ca1962c7f4110053a2f50ccfa5414",
+  "result": {
+    "title": "Cloud Storage Security: Secure GCP Buckets with IAM, Encryption, and Best Practices | CloudWebSchool",
+    "url": "https://cloudwebschool.com/docs/gcp/storage-services/cloud-storage-security/",
+    "snippet": "Learn how to secure Cloud Storage buckets. Covers IAM, uniform bucket-level access, public access prevention, CMEK encryption, VPC Service Controls, and audit logging.",
+    "content": "Cloud Storage Security: Secure GCP Buckets with IAM, Encryption, and Best Practices\n\nCloud Storage buckets hold some of the most sensitive data in a GCP\nenvironment: database backups, user uploads, compliance records, build\nartefacts, and internal reports. A new bucket is private and encrypted by\ndefault, but that is the starting point, not the destination. Securing a\nbucket properly means configuring access control, preventing accidental public\nexposure, choosing the right encryption model, and setting up logging. This\npage explains how all of those controls fit together.\n\nWhat Cloud Storage security actually means\n\nA bucket is not secure just because it exists. When you create a new\nCloud Storage bucket ,\nit starts out private and encrypted. Those two facts give many beginners\nthe impression that the job is done. It is not.\n\nThe storage unit analogy\n\nThink of a bucket like a self-storage unit. When you rent it, the door\nlocks automatically and only you have a key. That is “private by\ndefault.” But locking the door is the starting point, not the\nfinished product. You still need to decide who else gets a key and what\nthey can do, whether to add a second lock for the most sensitive boxes\ninside, whether to install a security camera, and whether to put a sign\non the gate saying no outside visitors without prior approval. Uniform\naccess, least-privilege IAM, public access prevention, and audit\nlogging are those decisions. The automatic lock solves one thing;\neverything else requires your deliberate choices.\n\nReal security comes from four things working together:\n\nAccess control that is easy to reason about. If you do\nnot enable uniform bucket-level access, individual objects can have their\nown ACLs that grant access completely independently of your IAM policy.\nYour bucket can look locked down in the IAM console while specific objects\nare readable by anyone.\n\nGuardrails against human error. The single most common\ncause of a storage breach is not a sophisticated attack. It is someone\naccidentally making a bucket public, or granting a service account more\naccess than it needs. Controls like public access prevention and\nOrganisation Policies exist precisely to prevent this class of mistake.\n\nDeliberate encryption choices. The default encryption is\ngood. For regulated data or situations where you need to control the\nkey lifecycle, you need to understand CMEK and decide whether it applies\nto your situation.\n\nLogging where it matters. Admin Activity logs are on by\ndefault and free. Data Access logs are off by default and expensive. You\nneed to understand which buckets require object-level audit trails and\nenable logging deliberately.\n\nUnderstood together, Cloud Storage security is about removing ambiguity\nfrom access control, adding guardrails against misconfiguration, and\nbuilding an audit trail proportionate to the sensitivity of the data.\n\nHow Cloud Storage security works\n\nCloud Storage security is a set of layered controls. Each layer addresses a\ndifferent threat. Understanding each one helps you decide which to apply\nand in what order.\n\nPrivate by default\n\nEvery new bucket is private. No one outside your project can access it\nwithout a valid GCP identity and an IAM binding granting them a role on\nthe bucket or the project. There is no extra step required to keep a bucket\nprivate. The risk comes when you actively grant access, either intentionally\nor by mistake.\n\nIAM and identities\n\nAccess to Cloud Storage is controlled through\nCloud IAM .\nYou grant a role to an identity (a service account, a user account, or a\ngroup) either at the bucket level or at the project level. Project-level\ngrants apply to every bucket in the project, which is why they require\ncareful thought. Bucket-level grants are narrower and almost always the\nright choice for application service accounts.\n\nThe key IAM principle to follow is\nleast privilege :\ngrant the minimum role on the most specific resource needed for the task.\n\nLegacy ACLs vs modern IAM-only access\n\nCloud Storage supports two access control models. The legacy model (called\nfine-grained access) evaluates both IAM and per-object ACLs in parallel.\nThe modern model, enabled by turning on uniform bucket-level access,\ndisables ACLs entirely and makes IAM the only control.\n\nThe hidden ACL problem\n\nOn a bucket without uniform bucket-level access, an individual object can\nbe publicly readable even when the bucket IAM policy is entirely private.\nA developer runs a script that uploads a file and sets its ACL to\nallUsers . The IAM policy still says private. The object is\nnow public. You would not see this by looking at the bucket in the\nconsole. You would only find it by inspecting that specific object’s\nACL directly. Uniform bucket-level access removes this entire class of\nproblem.\n\nThe legacy model exists for backwards compatibility. If you are building\nanything new, use uniform bucket-level access from the start. See the\nCloud Storage IAM vs ACLs\npage for a detailed comparison of both models and how to migrate existing\nbuckets.\n\nPublic access prevention\n\nPublic access prevention is a bucket setting that blocks any IAM binding\ngranting access to allUsers or allAuthenticatedUsers .\nIt is a hard guardrail. Even if someone with the right permissions tries to\nmake the bucket public, the setting prevents it. For buckets that should\nnever be public, this is a simple and important control.\n\nEncryption at rest and in transit\n\nAll data stored in Cloud Storage is encrypted at rest using AES-256. All\ndata in transit is encrypted using TLS. Both of these are on by default\nand cannot be disabled. You do not need to configure anything to get\nencryption; it happens automatically.\n\nCustomer-managed encryption keys (CMEK)\n\nBy default, the encryption keys are managed by Google. If you need to\ncontrol the key lifecycle for regulatory reasons, contractual requirements,\nor because you want the ability to cut off access by revoking the key, you\ncan configure a bucket to use a key from\nCloud KMS\nthat you manage. This is called CMEK. It adds operational complexity and\nshould be applied deliberately, not by default.\n\nLogging and monitoring\n\nCloud Storage integrates with\nCloud Audit Logs\nto record two categories of events. Admin Activity logs capture\nbucket-level changes (creating a bucket, modifying IAM policy, changing\nlifecycle configuration). These are always on and always free. Data Access\nlogs capture individual object reads and writes. These are off by default\nand can generate very high volumes of data.\n\nVPC Service Controls\n\nVPC Service Controls\nlets you define a security perimeter around GCP services including Cloud\nStorage. Access to buckets inside the perimeter is blocked for requests\noriginating outside it, regardless of IAM. This is primarily a data\nexfiltration control: it prevents a compromised identity from copying data\nto a bucket in an external project or organisation.\n\nThese controls are not all-or-nothing. Knowing when each one applies and\nwhich to prioritise for your situation is what the rest of this page\ncovers.\n\nUniform bucket-level access\n\nUniform bucket-level access is the single most important configuration\nchange you can make to a new bucket. It disables legacy ACLs so that IAM\nis the only way to grant or deny access. Without it, individual objects can\nhave ACLs that override the bucket IAM policy in ways that are difficult to\naudit.\n\nEnable it at bucket creation. It becomes permanent after 90 days, which is\na feature: it prevents temporary disables that could expose objects through\nACLs.\n\n# Enable uniform bucket-level access at bucket creation\ngcloud storage buckets create gs://my-app-secure-data \\\n--location=europe-west2 \\\n--uniform-bucket-level-access\n\n# Enable it on an existing bucket\ngcloud storage buckets update gs://my-app-existing-bucket \\\n--uniform-bucket-level-access\n\n# Verify the setting\ngcloud storage buckets describe gs://my-app-secure-data \\\n--format= \"value(iamConfiguration.uniformBucketLevelAccess.enabled)\"\n\nNote\n\nOnce uniform bucket-level access has been enabled for 90 days, it cannot\nbe disabled. This is intentional. The 90-day window gives you time to\ncatch problems and revert; after that, the simpler access model is locked\nin. If you are enabling it on an existing bucket, audit the existing ACLs\nfirst and add equivalent IAM bindings before enabling. See\nCloud Storage IAM vs ACLs\nfor the migration process.\n\nLeast-privilege IAM for Cloud Storage\n\nThe principle of least privilege means granting the minimum role on the\nmost specific resource needed. For Cloud Storage, that means:\n\nGrant roles at the bucket level, not the project level. A project-level grant applies to every bucket in the project.\n\nChoose the narrowest role that covers the actual need.\n\nSeparate read and write identities where practical.\n\nThe standard roles and when to use each:\n\nroles/storage.objectViewer — read-only access to objects, no bucket configuration access\n\nroles/storage.objectCreator — upload access only; cannot read existing objects or delete\n\nroles/storage.objectAdmin — full object management; cannot change bucket configuration or IAM policy\n\nroles/storage.admin — full control including bucket configuration; for infrastructure automation only, never for application service accounts\n\nA service account that uploads log files to a bucket should have\nroles/storage.objectCreator on that specific bucket, not\nroles/storage.admin on the project. A compromised upload worker\nshould not be able to read the data it just wrote, let alone access other\nbuckets. For the broader principles behind this, see\nPrinciple of Least Privilege .\n\n# Grant objectViewer on a specific bucket to a service account\ngcloud storage buckets add-iam-policy-binding gs://my-app-data \\\n--member= \"serviceAccount:reader@my-project.iam.gserviceaccount.com\" \\\n--role= \"roles/storage.objectViewer\"\n\n# Grant objectCreator on a specific bucket (upload-only)\ngcloud storage buckets add-iam-policy-binding gs://my-app-uploads \\\n--member= \"serviceAccount:uploader@my-project.iam.gserviceaccount.com\" \\\n--role= \"roles/storage.objectCreator\"\n\n# View all IAM bindings on a bucket\ngcloud storage buckets get-iam-policy gs://my-app-data\n\nPublic access prevention\n\nPublic access prevention blocks any IAM binding that would grant access to\nallUsers or allAuthenticatedUsers . It applies at\nthe bucket level and acts as a hard guardrail. Even an identity with full\nadmin on the bucket cannot make it public while this setting is active.\n\nEnable it on every bucket that should never serve public content. For\norganisation-wide coverage, enforce the Organisation Policy\nconstraints/storage.publicAccessPrevention . This applies\npublic access prevention to all buckets across your GCP organisation,\nregardless of individual bucket configuration, and means it cannot be\noverridden by anyone working within the organisation.\n\n# Enable public access prevention on a specific bucket\ngcloud storage buckets update gs://my-app-sensitive-data \\\n--public-access-prevention\n\n# Check the current setting\ngcloud storage buckets describe gs://my-app-sensitive-data \\\n--format= \"value(iamConfiguration.publicAccessPrevention)\"\n\nOrganisation-level enforcement\n\nEnforcing constraints/storage.publicAccessPrevention at the\norganisation level is the strongest protection. It means that even if a\nbucket is created without the setting enabled, any attempt to make it\npublic is blocked at the Organisation Policy level. Apply it as a default\nacross your organisation and create exceptions only for buckets that\ngenuinely need to serve public content.\n\nVPC Service Controls\n\nVPC Service Controls\naddresses a different threat than IAM and public access prevention. IAM\ncontrols who can access a bucket. VPC Service Controls controls where\nrequests can come from, regardless of the caller’s identity.\n\nA Service Controls perimeter wraps one or more GCP projects and services.\nCloud Storage requests that originate from outside the perimeter are blocked,\neven if the caller holds a valid IAM binding. This prevents a scenario where\na compromised credential is used from outside the perimeter to exfiltrate\ndata to a bucket in another project or organisation.\n\nVPC Service Controls is appropriate for environments handling sensitive or\nregulated data where you need both identity-based and network-based access\nrestrictions. For most applications, correct IAM and public access prevention\nare sufficient. VPC Service Controls is the additional layer for high-security\nor compliance-driven environments.\n\nCustomer-managed encryption keys\n\nBy default, Cloud Storage encrypts your data with Google-managed AES-256\nkeys. You do not configure this and cannot disable it. For most workloads,\nthis is entirely sufficient.\n\nCustomer-managed encryption keys (CMEK)\nlet you supply a key from Cloud KMS instead. When you configure a CMEK on\na bucket, all objects written to it are encrypted using your key. The\nadvantage is control: you can audit key use in Cloud KMS logs, rotate the\nkey, and revoke access to it. If you revoke the key, Cloud Storage can no\nlonger decrypt those objects.\n\nSome regulatory frameworks, including certain HIPAA and financial\ncompliance requirements, mandate that you control the encryption key\nlifecycle. If that applies to your situation, CMEK is the right choice. If\nit does not, the operational complexity is not worth the addition. See the\ncomparison table below.\n\n# Configure a bucket to use a CMEK key for all new objects\ngcloud storage buckets update gs://my-app-regulated-data \\\n--default-encryption-key=projects/my-project/locations/europe-west2/keyRings/my-ring/cryptoKeys/my-key\n\n# Verify the CMEK configuration\ngcloud storage buckets describe gs://my-app-regulated-data \\\n--format= \"value(encryption)\"\n\nDo this first\n\nThe Cloud Storage service agent for your project must have\nroles/cloudkms.cryptoKeyEncrypterDecrypter on the KMS key\nbefore you configure the bucket to use it. If you skip this step, every\nobject write to that bucket will fail wit",
+    "content_type": "text/html",
+    "query": "GCP Cloud Storage Security – härten und sicher betreiben current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.52,
+    "source_quality": "primary",
+    "source_quality_score": 0.88,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/a79175497be2d324b1d75b89.json b/data/research-evidence/a79175497be2d324b1d75b89.json
new file mode 100644
index 0000000..46c93a9
--- /dev/null
+++ b/data/research-evidence/a79175497be2d324b1d75b89.json
@@ -0,0 +1,25 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:06:25.3613097Z",
+  "content_sha256": "dfe036144759f9a8c768b184f6cb0b3897bc15ed14bc5b318977b001e8e84776",
+  "result": {
+    "title": "Cloud Security Best Practices: Anwendung, typische Fehler, Praxiswissen und saubere Workflows",
+    "url": "https://hacking-kurse.de/it-security-websecurity/cloud-security-best-practices",
+    "snippet": "Umfassender Leitfaden zu Cloud Security Best Practices mit Fokus auf IAM, Netzwerksegmentierung, Logging, Verschlüsselung, Fehlkonfigurationen, Incident Response und praxistauglichen Sicherheitsworkflows in AWS, Azure und containerisierten Umgebungen.",
+    "content": "Cloud Security Best Practices: Anwendung, typische Fehler, Praxiswissen und saubere Workflows\n\nCloud Security beginnt nicht mit Tools, sondern mit Verantwortungsgrenzen und Angriffsflächen\n\nCloud Security scheitert in der Praxis selten an fehlenden Produkten. Sie scheitert an falschen Annahmen. Viele Teams gehen davon aus, dass ein Cloud-Provider die Umgebung bereits ausreichend absichert. Tatsächlich schützt der Provider primär die zugrunde liegende Infrastruktur, nicht automatisch die konkrete Nutzung. Genau an dieser Stelle entstehen die meisten Vorfälle: falsch gesetzte Berechtigungen, öffentlich erreichbare Verwaltungsoberflächen, unkontrollierte Secrets, ungehärtete Images, unüberwachte Logs und unklare Zuständigkeiten zwischen Plattform-, Entwicklungs- und Security-Teams.\n\nDie erste Best Practice ist deshalb ein präzises Verständnis des Shared-Responsibility-Modells. In IaaS-Umgebungen liegt deutlich mehr Verantwortung beim Kunden als in SaaS-Diensten. Wer virtuelle Netzwerke, Security Groups, IAM-Rollen, Storage-Buckets, Container-Registries und Schlüsselmaterial selbst verwaltet, trägt auch die Verantwortung für deren sichere Konfiguration. Ein Team, das diese Trennlinie nicht sauber dokumentiert, baut zwangsläufig blinde Flecken auf. Grundlagen dazu finden sich in Cloud Security Grundlagen , während die Unterschiede zwischen Service-Modellen in Cloud Security Modelle und Cloud Security Iaas klar werden.\n\nAus Pentest-Sicht ist die Cloud vor allem deshalb attraktiv, weil Fehlkonfigurationen schnell skalieren. Eine einzige zu weit gefasste IAM-Policy kann hunderte Ressourcen betreffen. Ein versehentlich öffentliches Storage-Objekt kann sensible Daten weltweit exponieren. Eine ungesicherte CI/CD-Pipeline kann direkt in produktive Accounts deployen. Anders als in klassischen Rechenzentren sind Änderungen in Minuten ausgerollt, aber auch Angreifer bewegen sich in derselben Geschwindigkeit. Cloud Security muss deshalb als Kombination aus Architektur, Governance, Detection und Reaktionsfähigkeit verstanden werden.\n\nEin realistischer Sicherheitsansatz beginnt mit einer systematischen Erfassung der Angriffsfläche. Dazu gehören Management-Interfaces, APIs, Service Accounts, Federation-Mechanismen, Build-Systeme, Container-Images, Secrets-Stores, Datenbanken, Message Queues, serverlose Funktionen und externe Integrationen. Wer nur auf klassische Netzwerkgrenzen schaut, verfehlt die eigentliche Cloud-Angriffsfläche. In modernen Umgebungen sind Identitäten und APIs oft kritischer als offene Ports. Das ist der Grund, warum Cloud Security Identity und Cloud Security Access Control in jeder belastbaren Sicherheitsarchitektur zentral sind.\n\nEin weiterer Kernpunkt ist die Trennung von Komfort und Sicherheit. Cloud-Plattformen sind darauf optimiert, Bereitstellung zu vereinfachen. Standardkonfigurationen priorisieren häufig Verfügbarkeit und schnelle Nutzbarkeit, nicht maximale Härtung. Wer produktive Workloads mit Default-Einstellungen startet, übernimmt implizit Risiken. Das betrifft offene Egress-Pfade, breit vergebene Rollen, fehlende Log-Retention, unverschlüsselte Snapshots, nicht rotierte Schlüssel und permissive Netzwerkregeln. Best Practices bedeuten daher nicht, einzelne Häkchen zu setzen, sondern sichere Baselines zu definieren und technisch durchzusetzen.\n\nSaubere Workflows entstehen erst dann, wenn Security nicht nachträglich prüft, sondern vorab in Architektur und Deployment eingebaut wird. Das betrifft Naming-Konventionen, Tagging, Account-Strukturen, Trennung von Entwicklungs- und Produktionsumgebungen, Freigabeprozesse für privilegierte Rollen und automatisierte Policy-Checks. Ohne diese Disziplin wird jede Cloud-Umgebung mit der Zeit inkonsistent. Inkonsistenz ist aus Angreifersicht ideal, weil sie Ausnahmen, vergessene Altlasten und unüberwachte Sonderfälle erzeugt.\n\nFeatured Empfehlung: Cybersecurity strukturiert lernen\n\n★ FEATURED\n\nEmpfohlener Bereich auf Hacking-Kurse.de\n\nLernpfade für Ethical Hacking, Pentesting und IT-Security\n\nStarte strukturiert in die Cybersecurity und lerne Schritt für Schritt, wie Angreifer denken, wie Schwachstellen entstehen und wie Sicherheitsanalysen praktisch durchgeführt werden.\n\nDie Lernpfade auf Hacking-Kurse.de richten sich an Einsteiger, Fortgeschrittene und alle, die Ethical Hacking, Red Teaming oder IT-Security nicht nur oberflächlich verstehen möchten.\n\nZu den Lernpfaden\n\nIdentity und IAM sind in der Cloud die eigentliche Sicherheitsgrenze\n\nIn klassischen Netzwerken galt lange die Perimeter-Sicherheit als primäre Verteidigungslinie. In der Cloud ist diese Sicht unzureichend. Die eigentliche Grenze verläuft über Identitäten, Rollen, Tokens und Berechtigungen. Wer IAM falsch aufsetzt, verliert Kontrolle über nahezu alle anderen Schutzmaßnahmen. Ein kompromittierter Benutzer mit überprivilegierter Rolle kann Logs löschen, Snapshots exfiltrieren, neue Schlüssel erzeugen, Instanzen starten oder Sicherheitsregeln verändern. Deshalb ist Least Privilege keine theoretische Empfehlung, sondern die wichtigste operative Maßnahme.\n\nEin häufiger Fehler ist die Vergabe generischer Admin-Rollen an Entwickler, Automatisierung oder externe Dienstleister. Das passiert oft aus Zeitdruck: Deployment schlägt fehl, also wird temporär eine breite Rolle vergeben. Aus temporär wird dauerhaft. In Audits und Pentests zeigt sich regelmäßig, dass Service Principals, CI-Bots oder Terraform-Runner deutlich mehr Rechte besitzen als nötig. Solche Identitäten sind besonders kritisch, weil sie selten interaktiv genutzt werden und dadurch weniger auffallen. Vertiefung bieten Cloud Security Iam und Identity Security Authentication .\n\nEine belastbare IAM-Strategie folgt einigen harten Regeln. Menschliche Benutzer erhalten keine dauerhaften Hochprivilegien. Administrative Zugriffe laufen über dedizierte Rollen mit starker Authentisierung, klarer Genehmigung und vollständiger Protokollierung. Maschinenidentitäten werden pro Anwendung, Umgebung und Zweck getrennt. Rollen werden nicht nach Teams, sondern nach konkreten Aktionen modelliert. Policies werden deny-orientiert gedacht, nicht allow-orientiert improvisiert. Besonders wichtig ist die Trennung zwischen Lese-, Änderungs- und Berechtigungsverwaltungsrechten. Wer Ressourcen verwalten darf und gleichzeitig IAM ändern kann, besitzt faktisch Vollkontrolle.\n\nKeine gemeinsamen Admin-Accounts und keine dauerhaften Root-Zugriffe im Tagesbetrieb\n\nService Accounts strikt pro Anwendung und Umgebung trennen, niemals wiederverwenden\n\nPrivilegierte Aktionen nur über kurzlebige Rollen, MFA und nachvollziehbare Freigaben ausführen\n\nEin weiterer Praxispunkt ist die Kontrolle von Vertrauensbeziehungen. In vielen Cloud-Umgebungen dürfen Rollen von anderen Accounts, Diensten oder Workloads übernommen werden. Diese Trust Policies sind ein bevorzugter Angriffspfad, wenn sie zu breit formuliert sind. Ein Beispiel: Eine Rolle erlaubt Annahme durch jeden Principal aus einem Partner-Account, obwohl nur ein einzelner Build-Service nötig wäre. Wird dieser Partner kompromittiert, ist der Sprung in die eigene Umgebung möglich. Dasselbe gilt für OIDC-Federation mit CI-Systemen. Wenn Claims nicht präzise validiert werden, kann ein Angreifer Tokens missbrauchen, um produktive Rollen zu übernehmen.\n\nAuch Secrets-Management gehört unmittelbar zu IAM. API-Keys in Repositories, Umgebungsvariablen in Klartext, hartcodierte Zugangsdaten in Images oder lokale Credentials auf Build-Runnern sind in Cloud-Umgebungen besonders gefährlich, weil sie oft direkten API-Zugriff ermöglichen. Gute Praxis bedeutet: kurzlebige Credentials, zentrale Secret Stores, automatische Rotation, Zugriff nur über Rollen und vollständige Nachvollziehbarkeit. Ergänzend lohnt der Blick auf It Security Secret Management und Identity Security Mfa .\n\nAus Angreifersicht sind IAM-Fehler deshalb so wertvoll, weil sie meist leise ausnutzbar sind. Es braucht keinen Exploit im klassischen Sinn. Oft genügt legitimer API-Zugriff mit zu vielen Rechten. Genau deshalb müssen Berechtigungen nicht nur initial sauber modelliert, sondern kontinuierlich überprüft werden: Welche Rollen wurden 90 Tage nicht genutzt, welche Aktionen sind nie erforderlich, welche Benutzer besitzen indirekt Admin-Rechte über Gruppen, welche Service Accounts können neue Tokens erzeugen oder Policies anhängen? Diese Fragen entscheiden darüber, ob ein kompromittiertes Konto ein lokaler Vorfall bleibt oder zur vollständigen Übernahme der Cloud-Umgebung führt.\n\nNetzwerkdesign in der Cloud: Segmentierung, Egress-Kontrolle und unsichtbare Fehlannahmen\n\nCloud-Netzwerke wirken auf den ersten Blick einfacher als klassische VLAN- und Routing-Landschaften. Genau darin liegt eine Gefahr. Virtuelle Netzwerke, Subnetze, Security Groups, Network ACLs, Peering, Private Endpoints und Load Balancer erzeugen eine Komplexität, die leicht unterschätzt wird. Viele Sicherheitsprobleme entstehen nicht durch offen sichtbare Fehlkonfigurationen, sondern durch falsche mentale Modelle. Ein Team glaubt etwa, eine Datenbank sei intern, weil sie keine öffentliche IP besitzt. Tatsächlich ist sie über Peering aus mehreren Netzen erreichbar, oder ein kompromittierter Workload im selben Subnetz kann lateral zugreifen.\n\nBest Practice bedeutet hier, Netzwerkdesign nicht nach Bequemlichkeit, sondern nach Vertrauenszonen aufzubauen. Entwicklungs-, Test- und Produktionsumgebungen werden getrennt. Management-Zugänge laufen nicht über dieselben Pfade wie Anwendungsdatenverkehr. Datenbanken, Message Broker und interne APIs erhalten nur die minimal nötigen Ingress-Regeln. Noch wichtiger ist die Kontrolle des Egress. Viele Umgebungen erlauben standardmäßig ausgehende Verbindungen ins Internet. Das erleichtert Updates, aber auch Datenabfluss, Command-and-Control und das Nachladen weiterer Werkzeuge nach einer Kompromittierung.\n\nEine saubere Segmentierung in der Cloud ist nicht identisch mit klassischer Segmentierung im Rechenzentrum, aber die Prinzipien bleiben gleich. Wer Zonen nicht trennt, ermöglicht laterale Bewegung. Wer Egress nicht kontrolliert, verliert Sicht auf Exfiltration. Wer Management-Interfaces öffentlich erreichbar macht, lädt zu Passwort-Spraying, Token-Missbrauch und API-Enumeration ein. Ergänzend sind Netzwerksicherheit Segmentierung , Netzwerksicherheit Zero Trust und It Security Zero Trust Architektur relevant.\n\nEin typischer Fehler in Cloud-Projekten ist die Vermischung von Erreichbarkeit und Autorisierung. Nur weil ein Dienst intern erreichbar ist, ist er nicht sicher. Interne APIs ohne starke Authentisierung, Admin-Panels hinter einem privaten Load Balancer oder Datenbanken mit schwachen Netzwerkfiltern sind in kompromittierten Umgebungen schnell angreifbar. Angreifer benötigen nicht zwingend Internetzugriff auf ein Ziel. Ein einziger initial kompromittierter Container oder eine missbrauchte Serverless-Funktion reicht oft aus, um interne Dienste zu scannen und zu missbrauchen.\n\nIn Pentests zeigt sich außerdem regelmäßig, dass Security Groups historisch wachsen. Für ein Troubleshooting wird Port 22 temporär geöffnet, für einen Partnerzugriff ein CIDR-Bereich ergänzt, für einen Migrationsjob eine breite Regel gesetzt. Monate später sind diese Ausnahmen noch aktiv. Deshalb müssen Netzwerkregeln versioniert, begründet und regelmäßig bereinigt werden. Regeln ohne Eigentümer oder ohne nachvollziehbaren Zweck gehören entfernt. Besonders kritisch sind 0.0.0.0/0-Freigaben auf Verwaltungsports, Datenbanken, Message Queues und internen Dashboards.\n\nEin praxisnaher Ansatz ist die Kombination aus privater Standardarchitektur und expliziten Ausnahmen. Dienste werden zunächst nicht öffentlich bereitgestellt. Externe Erreichbarkeit erfolgt nur über definierte Entry Points wie WAF, Reverse Proxy oder API Gateway. Administrative Zugriffe laufen über Bastion- oder Identity-basierte Zugangsmodelle, nicht über dauerhaft offene Management-Ports. Zusätzlich sollte jeder sensible Dienst eine zweite Schutzschicht besitzen: Netzwerk plus Authentisierung, nicht entweder oder.\n\nWer Cloud-Netzwerke sauber betreibt, betrachtet sie nicht isoliert. Netzwerkdesign muss mit IAM, Logging und Workload-Härtung zusammenspielen. Ein restriktives Netz ohne Logs hilft wenig, wenn verdächtige Verbindungen nicht sichtbar sind. Eine gute Segmentierung verliert an Wert, wenn kompromittierte Rollen Sicherheitsregeln selbst ändern dürfen. Genau deshalb sind Netzwerk- und Identitätskontrollen in der Cloud untrennbar miteinander verbunden.\n\nSponsored Links\n\nDaten schützen heißt mehr als Verschlüsselung aktivieren\n\nWenn über Datensicherheit in der Cloud gesprochen wird, fällt fast immer zuerst das Thema Verschlüsselung. Das ist richtig, aber unvollständig. Verschlüsselung schützt Daten nur innerhalb bestimmter Bedrohungsmodelle. Sie verhindert nicht automatisch unberechtigte API-Zugriffe, Fehlfreigaben, Missbrauch legitimer Rollen oder Datenabfluss über kompromittierte Anwendungen. Eine Storage-Bucket-Verschlüsselung ist wertlos, wenn der Bucket öffentlich lesbar ist oder ein kompromittierter Service Account alle Objekte herunterladen darf.\n\nBest Practice beginnt mit Datenklassifizierung. Nicht jede Information braucht dieselben Kontrollen, aber sensible Daten brauchen definierte Schutzstufen. Dazu gehören personenbezogene Daten, Zugangsdaten, Schlüsselmaterial, Geschäftsgeheimnisse, Konfigurationsdaten mit Sicherheitsbezug und forensisch relevante Logs. Erst wenn klar ist, welche Daten wo liegen, lassen sich passende Kontrollen umsetzen: Verschlüsselung at rest, TLS in transit, Zugriffstrennung, Tokenisierung, Retention, Backup-Schutz und Löschprozesse. Vertiefend sind Cloud Security Daten , Cloud Security Encryption und Verschluesselung Best Practices sinnvoll.\n\nEin häufiger Praxisfehler ist die Vermischung von Datenhaltung und Berechtigungslogik. Anwendungen speichern sensible Daten in Objektspeichern oder Datenbanken, während Zugriffe über breit vergebene Backend-Rollen laufen. Dadurch wird jede Kompromittierung des Backends automatisch zu ein",
+    "content_type": "text/html",
+    "query": "Cloud IAM, Cloud Secrets, Cloud Service Accounts, Cloud Incident Response, Cloud Access Review, Perfect Forward Secrecy – ein einheitliches, thematisch verknüpftes Handbuch zur Sicherheitspraxis in Cloud-Umgebungen mit Fokus auf Monitoring, Forensik und Sicherheitsmaßnahmen aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.30518518518518517,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "actionable": true,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/a9e0d15abf8a87b3c9747941.json b/data/research-evidence/a9e0d15abf8a87b3c9747941.json
new file mode 100644
index 0000000..ea30fed
--- /dev/null
+++ b/data/research-evidence/a9e0d15abf8a87b3c9747941.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T21:46:10.8725679Z",
+  "content_sha256": "9723b262eaf9c6fe0f616af5e05c8c5385e84e573e06209527e8f561f45fdb9b",
+  "result": {
+    "title": "Microsoft Fabric API for GraphQL Introspection and Schema Export - Microsoft Fabric | Microsoft Learn",
+    "url": "https://learn.microsoft.com/en-us/fabric/data-engineering/api-graphql-introspection-schema-export",
+    "snippet": "Choose schema export when you need a complete schema file for offline use, version control, API gateway integration, or sharing with external teams. Introspection: Query your schema programmatically using the GraphQL introspection system, which is part of the GraphQL standard.",
+    "content": "Table of contents\n\nExit editor mode\n\nAsk Learn\n\nAsk Learn\n\nReading mode\n\nTable of contents\n\nRead in English\n\nAdd\n\nAdd to Plans\n\nEdit\n\nCopy Markdown\n\nPrint\n\nNote\n\nAccess to this page requires authorization. You can try signing in or changing directories .\n\nAccess to this page requires authorization. You can try changing directories .\n\nFabric API for GraphQL introspection and schema export\n\nFeedback\n\nSummarize this article for me\n\nWhen you build applications or integrate external tools with your Fabric API for GraphQL, you need to understand the structure of your API—what types are available, what fields they contain, and how they relate to each other. Whether you're generating client code, creating documentation, or configuring API management tools, accessing your schema definition is essential.\n\nThe Fabric API for GraphQL provides two complementary mechanisms to retrieve schema information: introspection for programmatic runtime queries and schema export for obtaining a complete schema file. Both methods give you access to the same underlying schema, but each serves different workflows and use cases.\n\nTip\n\nWant to see introspection in action? Try the tutorial Connect AI Agents to Fabric API for GraphQL with a local Model Context Protocol (MCP) server . This hands-on guide shows how AI agents use introspection to automatically discover and query your Fabric data using natural language.\n\nWho uses introspection and schema export\n\nIntrospection and schema export are valuable for:\n\nApplication developers building clients that consume Fabric data and need to generate type-safe code\n\nFabric workspace contributors understanding available data structures and testing data access\n\nDevelopment tools and IDEs providing autocomplete and IntelliSense for Fabric GraphQL APIs\n\nAzure API Management integrations that route and secure Fabric GraphQL traffic at the enterprise level\n\nFabric administrators auditing exposed data structures and validating access controls\n\nAI agents and assistants using Model Context Protocol (MCP) to discover and query Fabric data naturally\n\nPower Platform developers understanding Fabric data schemas before building integrations\n\nCI/CD pipelines tracking Fabric GraphQL schema versions and validating compatibility across environments\n\nChoose introspection when you need to query schema information programmatically at runtime, such as powering development tools, enabling AI agents, or implementing dynamic client features. Choose schema export when you need a complete schema file for offline use, version control, API gateway integration, or sharing with external teams.\n\nIntrospection : Query your schema programmatically using the GraphQL introspection system, which is part of the GraphQL standard. Introspection queries allow you to discover types, fields, and relationships dynamically, and they power many GraphQL development tools.\n\nSchema export : Download a complete SDL (GraphQL Schema Definition Language) file that contains your entire schema definition for offline use, sharing, or tool integration.\n\nIntrospection\n\nBy default, introspection is disabled on your API for GraphQL items. This setting can only be toggled by workspace admins. All other users will see a disabled slider.\n\nTo enable introspection:\n\nSelect the API Settings gear icon in the top menu.\n\nFrom the left navigation, select the Introspection page.\n\nSelect the toggle to enable introspection. Enabling introspection exposes schema information to all users with access to the API endpoint.\n\nA confirmation dialog appears. Select Confirm to enable introspection or Cancel to leave it disabled.\n\nIntrospection query example\n\nHere's a quick example of an introspection query to retrieve available types from the schema:\n\nCreate a new query in the GraphQL editor. Select the plus + icon next to existing tabs to open a new query tab.\n\nEnter the following introspection query in the editor:\n\nquery {\n__schema {\ntypes{\nname\n\nSelect the Run button to execute the query.\n\nThe results pane displays a list of all types defined in the schema.\n\nIntrospection queries can return large amounts of information. You can narrow the scope of what you query by being more specific in your introspection request. For example, instead of querying all types, you can query a specific type:\n\nquery {\n__type(name: \"ProductCategory\") {\nname\nkind\nfields {\nname\ntype {\nname\n\nRunning the query returns detailed information about the ProductCategory type:\n\n\"data\": {\n\"__type\": {\n\"name\": \"ProductCategory\",\n\"kind\": \"OBJECT\",\n\"fields\": [\n\"name\": \"ProductCategoryID\",\n\"type\": {\n\"name\": null\n},\n\"name\": \"ParentProductCategoryID\",\n\"type\": {\n\"name\": \"Int\"\n},\n\"name\": \"Name\",\n\"type\": {\n\"name\": \"String\"\n},\n\"name\": \"rowguid\",\n\"type\": {\n\"name\": null\n},\n\"name\": \"ModifiedDate\",\n\"type\": {\n\"name\": null\n\nCommon filtering patterns when processing introspection results include:\n\nExcluding types starting with double underscores ( __ ), which are GraphQL system types\n\nIncluding types starting with specific prefixes like ProductCategory\n\nThese examples demonstrate standard GraphQL introspection syntax that works across any GraphQL implementation. This overview covers basic introspection patterns—for comprehensive details on the introspection system, advanced querying techniques, and additional capabilities, see the GraphQL Foundation's official documentation on introspection .\n\nExport schema\n\nWhen you need a complete, offline copy of your schema definition, use the schema export feature directly from the Fabric portal. Open your API for GraphQL and select Export schema from the toolbar. Your browser downloads an SDL (Schema Definition Language) file containing your complete schema definition.\n\nUnderstanding the SDL file\n\nThe exported file uses GraphQL's Schema Definition Language (SDL), a human-readable format that defines your API's types, fields, and relationships. The SDL file includes:\n\nObject types representing your data entities with their fields\n\nQuery operations that define how to retrieve data\n\nMutation operations for creating, updating, or deleting data\n\nField arguments that specify input parameters and their types\n\nType descriptions providing documentation for each element\n\nYou can open the SDL file in any text editor to review your schema structure. This is particularly useful for understanding the complete API surface before integrating it into your applications.\n\nUsing the exported schema\n\nCommon use cases for the exported SDL file include:\n\nAPI gateway integration : Import into Azure API Management to add authentication, rate limiting, and caching\n\nDevelopment environment setup : Configure IntelliSense in Visual Studio Code for autocomplete and validation\n\nVersion control : Commit to Git or other source control systems to track schema evolution over time\n\nTeam collaboration : Share with external partners or development teams who need to understand your API structure\n\nCode generation : Use with GraphQL code generators to create type-safe clients in TypeScript, C#, Java, or other languages\n\nDocumentation : Generate API reference documentation using tools like GraphQL Voyager or GraphQL Markdown\n\nUnlike introspection queries, schema export doesn't require introspection to be enabled and works regardless of your API's introspection settings. This makes it a reliable way to access your schema definition for administrative and development purposes.\n\nManaging schema changes\n\nGraphQL schemas can evolve over time as you add new types, fields, or capabilities to your API. When the schema changes, exported SDL files become outdated. Consider these practices:\n\nRe-export after changes : Download a fresh SDL file whenever you modify your API schema in Fabric. Schema changes include adding data sources, modifying exposed types, or updating field definitions.\n\nVersion control : Commit each exported schema to your source control system with descriptive commit messages. This creates an audit trail of schema evolution and enables rollback if needed.\n\nCommunication : If external teams or applications depend on your schema, notify them of significant changes. While GraphQL supports additive changes without breaking existing queries, removing or renaming fields can impact clients.\n\nAutomation : For CI/CD pipelines, consider automating schema exports as part of your deployment process to ensure documentation and tooling stay synchronized with your API.\n\nThe person responsible for modifying the API schema (typically a data engineer or API developer) should export and version the updated schema to maintain consistency between the Fabric API and external systems that depend on it.\n\nRelated content\n\nConnect AI Agents to Fabric API for GraphQL with a local Model Context Protocol (MCP) server\n\nFabric API for GraphQL Editor\n\nFabric API for GraphQL schema view and Schema explorer\n\nIntegrate with Azure API Management (APIM)\n\nFeedback\n\nWas this page helpful?\n\nYes\n\nNo\n\nNo\n\nNeed help with this topic?\n\nWant to try using Ask Learn to clarify or guide you through this topic?\n\nAsk Learn\n\nAsk Learn\n\nSuggest a fix?\n\nAdditional resources\n\nLast updated on\n2026-01-21",
+    "content_type": "text/html",
+    "query": "GraphQL Introspection Sicherheit current official documentation version support",
+    "language": "en-US",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.62,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/b42882749038ec510652883c.json b/data/research-evidence/b42882749038ec510652883c.json
new file mode 100644
index 0000000..63cab0e
--- /dev/null
+++ b/data/research-evidence/b42882749038ec510652883c.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:22:06.2752858Z",
+  "content_sha256": "a25c232976e9b41d0d40db054113fa59f9af276dbfc4cbf1adaac96ba2347d22",
+  "result": {
+    "title": "Client Side Prototype Pollution - HackTricks",
+    "url": "https://hacktricks.wiki/de/pentesting-web/deserialization/nodejs-proto-prototype-pollution/client-side-prototype-pollution.html",
+    "snippet": "Bei der Entscheidung, welchen Stack man untersuchen sollte, ist es oft sinnvoll, Stacks mit JavaScript-Library-Dateien ins Visier zu nehmen, da prototype pollution häufig innerhalb dieser Libraries auftritt.",
+    "content": "Sponsored\n\nPrototype Pollution auf Client-Seite\n\nTip\n\nAWS Hacking lernen und üben: HackTricks Training AWS Red Team Expert (ARTE)\nGCP Hacking lernen und üben: HackTricks Training GCP Red Team Expert (GRTE)\nAz Hacking lernen und üben: HackTricks Training Azure Red Team Expert (AzRTE)\nDen vollständigen HackTricks Training-Katalog durchsuchen.\n\nHackTricks unterstützen\n\nSieh dir die Abonnementpläne an!\n\nTritt der 💬 Discord-Gruppe und der Telegram-Gruppe bei , folge @hacktricks_live auf X/Twitter oder sieh dir die LinkedIn-Seite und den YouTube-Kanal an.\n\nTeile Hacking-Tricks, indem du PRs an die HackTricks - und HackTricks Cloud -GitHub-Repos einreichst.\n\nEntdeckung mit automatischen Tools\n\nDie Tools https://github.com/dwisiswant0/ppfuzz , https://github.com/kleiton0x00/ppmap und https://github.com/kosmosec/proto-find können verwendet werden, um Schwachstellen durch prototype pollution zu finden .\n\nAußerdem kannst du die Browser-Erweiterung PPScan verwenden, um die aufgerufenen Seiten automatisch auf Schwachstellen durch prototype pollution zu scannen .\n\nFür Burp-Benutzer ist DOM Invader derzeit die praktischste Option für browserseitige Tests, da damit Query-/Hash-/JSON-Web-Message-Quellen getestet und anschließend automatisch nach Gadgets gescannt werden können.\n\nDOM Invader\n\nDebugging, wo eine Eigenschaft verwendet wird\n\n// Stop debugger where 'potentialGadget' property is accessed\nObject.defineProperty(Object.prototype, \"potentialGadget\", {\n__proto__: null,\nget() {\nconsole.trace()\nreturn \"test\"\n},\n})\n\nDie Ursache von Prototype Pollution finden\n\nSobald eine Prototype-Pollution-Schwachstelle von einem der Tools identifiziert wurde und der Code nicht übermäßig komplex ist, lässt sich die Schwachstelle möglicherweise finden, indem in den Chrome Developer Tools nach Schlüsselwörtern wie location.hash , decodeURIComponent , location.search , postMessage oder Form-to-Object-Helpers gesucht wird. Mit diesem Ansatz kann der verwundbare Abschnitt des JavaScript-Codes genau bestimmt werden. [1]\n\nBei größeren und komplexeren Codebasen besteht eine einfache Methode zum Auffinden des verwundbaren Codes aus den folgenden Schritten: [2]\n\nVerwende ein Tool, um eine Schwachstelle zu identifizieren und einen Payload zu erhalten, der eine Eigenschaft im Constructor setzt. Ein von ppmap bereitgestelltes Beispiel könnte wie folgt aussehen: constructor[prototype][ppmap]=reserved .\n\nSetze einen Breakpoint in der ersten JavaScript-Codezeile, die auf der Seite ausgeführt wird. Aktualisiere die Seite mit dem Payload, sodass die Ausführung an diesem Breakpoint pausiert.\n\nFühre bei pausierter JavaScript-Ausführung das folgende Script in der JS-Konsole aus. Dieses Script signalisiert, sobald die Eigenschaft „ppmap“ erstellt wird, und hilft dabei, ihren Ursprung zu ermitteln:\n\nfunction debugAccess(obj, prop, debugGet = true) {\nvar origValue = obj[prop]\n\nObject.defineProperty(obj, prop, {\nget: function () {\nif (debugGet) debugger\nreturn origValue\n},\nset: function (val) {\ndebugger\norigValue = val\n},\n})\n\ndebugAccess(Object.prototype, \"ppmap\")\n\nNavigieren Sie zurück zum Tab Sources und wählen Sie „Resume script execution“. Die JavaScript-Ausführung wird fortgesetzt, und die Eigenschaft „ppmap“ wird wie erwartet polluted. Das bereitgestellte Snippet erleichtert die Identifizierung der exakten Stelle, an der die Eigenschaft „ppmap“ polluted wird. Durch die Untersuchung des Call Stack können verschiedene Stacks beobachtet werden, an denen die Pollution aufgetreten ist.\n\nBei der Entscheidung, welchen Stack man untersuchen sollte, ist es oft sinnvoll, Stacks zu wählen, die mit JavaScript-Library-Dateien verbunden sind, da Prototype Pollution häufig innerhalb dieser Libraries auftritt. Identifizieren Sie den relevanten Stack, indem Sie prüfen, ob er mit Library-Dateien verknüpft ist (auf der rechten Seite sichtbar, ähnlich wie in der zur Orientierung bereitgestellten Abbildung). In Szenarien mit mehreren Stacks, beispielsweise in den Zeilen 4 und 6, ist der Stack in Zeile 4 die logische Wahl, da er das erste Auftreten der Pollution und damit die Root Cause der Vulnerability darstellt. Durch einen Klick auf den Stack gelangen Sie zum vulnerablem Code.\n\nScript Gadgets finden\n\nDas Gadget ist der Code, der missbraucht wird, sobald eine PP-Vulnerability entdeckt wurde .\n\nWenn die Anwendung einfach aufgebaut ist, können wir nach Keywords wie srcdoc/innerHTML/iframe/createElement suchen , den Source Code überprüfen und feststellen, ob er zu JavaScript-Ausführung führt. Manchmal finden die genannten Techniken überhaupt keine Gadgets. In diesem Fall kann ein reines Source-Code-Review einige interessante Gadgets wie im folgenden Beispiel aufdecken. [1]\n\nBeispiel: Ein PP-Gadget im Mithril-Library-Code finden\n\nSiehe diesen Writeup: https://blog.huli.tw/2022/05/02/en/intigriti-revenge-challenge-author-writeup/ [3]\n\nBrowser-/API-Gadgets, die leicht übersehen werden\n\nAktuelle Forschung von PortSwigger hat gezeigt, dass nicht jedes Gadget im Application Code vorhanden ist . Browser-APIs und verbreitete Libraries akzeptieren häufig plain objects als Optionen/Deskriptoren. Daher werden polluted Properties automatisch geerbt, wenn die Anwendung sie nicht ausdrücklich definiert. [4]\n\nEinige Muster, die zuerst überprüft werden sollten:\n\nfetch(url, options) : Wenn die Seite nur method setzt und body , headers , mode , credentials usw. nicht definiert, können polluted Properties von der Anfrage verwendet werden.\n\nObject.defineProperty(obj, key, descriptor) : Wenn der Deskriptor value , get , set oder configurable auslässt, kann ein polluted Object.prototype den Deskriptor selbst verändern.\n\nDirekter Property-Zugriff auf storage-ähnliche Objekte : localStorage.foo wird durch die Prototype Chain beeinflusst, localStorage.getItem(\"foo\") hingegen nicht.\n\nThird-Party-Analytics-/Tag-Manager-Code : Google Analytics, Google Tag Manager, Adobe DTM und ähnliche Bundles haben in der Vergangenheit Gadget-Properties offengelegt, die in setTimeout , eval , innerHTML oder script.src -Sinks enden.\n\nBeispiel für ein fetch() -Gadget-Muster:\n\nObject.prototype.body = \"name=\u003cimg src=x onerror=alert(1)\u003e\"\n\nfetch(\"/endpoint\", { method: \"POST\" })\n\nBeispiel für den Missbrauch eines Object.defineProperty() -Deskriptors:\n\nObject.prototype.value = '\u003cimg src=x onerror=alert(1)\u003e'\n\nconst victim = {}\nObject.defineProperty(victim, \"html\", {\nconfigurable: false,\nwritable: false,\n})\n\nBei der manuellen Suche nach Gadgets solltest du Code priorisieren, der:\n\nleere Objekte/Arrays erstellt und anschließend obj[key] / arr[index] liest\n\nOptionsobjekte an Browser-APIs übergibt\n\nFormulare , Query-Strings oder Web-Nachrichten in JSON umwandelt und anschließend in den State zusammenführt\n\nnur Truthiness oder den Typ prüft (zum Beispiel if (obj.html) oder typeof arr[0] === \"string\" ), ohne zu überprüfen, ob die Property eine eigene Property ist\n\nAktuelle Muster bei der Gadget-Suche in realen Zielen\n\nAktuelle Client-seitige Writeups und die neuesten Gadget-Sammlungen zeigen weiterhin dasselbe offensive Muster: Zuerst wird eine Pollution-Quelle in einem Parser oder Form-Serializer gefunden, anschließend erfolgt der Pivot zu einer Library-Methode, die ein Objektargument akzeptiert und über vom Angreifer kontrollierte Keys iteriert.\n\nIn der Praxis sind Methoden wie jQuery.attr({...}) , $.get(...) , $.getScript(...) , Event-Helpers, Konfigurationsobjekte von Analytics/Tag-Managern und Sanitizer-Allow-Lists weiterhin gute Stellen für die Suche. Wenn eine Seite ein großes Third-Party-Bundle enthält, solltest du die geladene Version mit dem Payload-Korpus in BlackFans Repository vergleichen, bevor du zu viel Zeit mit dem Reverse Engineering von minifiziertem Code verbringst. [5]\n\nNeukompilierung von Payloads für verwundbare Libraries\n\nhttps://portswigger.net/web-security/cross-site-scripting/cheat-sheet#prototype-pollution\n\nhttps://github.com/BlackFan/client-side-prototype-pollution [5]\n\nUmgehung von HTML-Sanitizern über PP\n\nNützliche Sanitizer-Bypass-Payloads wurden von Michał Bentkowski gesammelt und sind ebenfalls in BlackFans Gadget-Korpus enthalten. Diese sind besonders nützlich, wenn das Ziel vom Angreifer kontrolliertes HTML bereits sanitisiert, die Sanitizer-Konfiguration oder das Allow-List-Objekt jedoch über Prototype Pollution erreichbar ist. [5] [6]\n\nsanitize-html\n\ndompurify\n\nClosure\n\n\u003cscript\u003e\nObject.prototype[\"* ONERROR\"] = 1\nObject.prototype[\"* SRC\"] = 1\n\u003c/script\u003e\n\u003cscript src=\"https://google.github.io/closure-library/source/closure/goog/base.js\"\u003e\u003c/script\u003e\n\u003cscript\u003e\ngoog.require(\"goog.html.sanitizer.HtmlSanitizer\")\ngoog.require(\"goog.dom\")\n\u003c/script\u003e\n\u003cbody\u003e\n\u003cscript\u003e\nconst html = '\u003cimg src onerror=alert(1)\u003e'\nconst sanitizer = new goog.html.sanitizer.HtmlSanitizer()\nconst sanitized = sanitizer.sanitize(html)\nconst node = goog.dom.safeHtmlToNode(sanitized)\n\ndocument.body.append(node)\n\u003c/script\u003e\n\u003c/body\u003e\n\nAktuelle Forschung (2024-2025)\n\nDie Studie Follow My Flow aus dem Jahr 2025 stellte GaLA vor, ein dynamisches Framework zur groß angelegten Suche nach client-side prototype pollution gadgets . [7] Die wichtigste Erkenntnis für pentesters ist, dass die Auswirkungen von client-side PP nicht auf DOM XSS beschränkt sind:\n\ndie Autoren fanden 133 zero-day gadgets auf einer Million Websites\n\nsie machten 23 Websites, die zuvor als „no-impact“ betrachtet wurden , zu echten End-to-End-Exploits\n\nZu den gemeldeten Auswirkungen gehörten XSS , Cookie-Manipulation und URL-Manipulation\n\nEines der Beispiele aus der Praxis war ein Meta- fbevents.js -Gadget , bei dem ein vom Angreifer kontrolliertes geerbtes Array-Element document.cookie erreichte. Ein anderes war ein Vue-Gadget , dem schließlich CVE-2024-6783 zugewiesen wurde.\n\nFür die Suche nach Bugs ist dies eine gute Erinnerung: Wenn bereits eine Pollution-Quelle vorhanden ist, sollte man nicht aufhören, nachdem man nach innerHTML und script.src gesucht hat. Untersuche auch Code, der:\n\nin document.cookie schreibt\n\nRedirect-/URL-Werte erstellt\n\ngeerbte Werte an setTimeout , eval oder dynamische Script-Loader übergibt\n\nArray-Indizes wie arr[0] aus Arrays verwendet, die leer erstellt und nur teilweise initialisiert wurden\n\nReferences\n\n[1] A tale of making internet pollution free - Exploiting Client-Side Prototype Pollution in the wild\n\n[2] Hunting for Prototype Pollution and its Vulnerable Code on JS Libraries\n\n[3] Intigriti “Revenge” Challenge - Author Writeup (Mithril prototype pollution gadget)\n\n[4] Widespread prototype pollution gadgets - PortSwigger Research\n\n[5] BlackFan/client-side-prototype-pollution gadget corpus\n\n[6] Prototype pollution and bypassing client-side HTML sanitizers - Securitum Research\n\n[7] Follow My Flow: GaLA client-side prototype pollution gadget finding framework\n\nTip\n\nAWS Hacking lernen und üben: HackTricks Training AWS Red Team Expert (ARTE)\nGCP Hacking lernen und üben: HackTricks Training GCP Red Team Expert (GRTE)\nAz Hacking lernen und üben: HackTricks Training Azure Red Team Expert (AzRTE)\nDen vollständigen HackTricks Training-Katalog durchsuchen.\n\nHackTricks unterstützen\n\nSieh dir die Abonnementpläne an!\n\nTritt der 💬 Discord-Gruppe und der Telegram-Gruppe bei , folge @hacktricks_live auf X/Twitter oder sieh dir die LinkedIn-Seite und den YouTube-Kanal an.\n\nTeile Hacking-Tricks, indem du PRs an die HackTricks - und HackTricks Cloud -GitHub-Repos einreichst.\n\nSponsored",
+    "content_type": "text/html",
+    "query": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.3342857142857143,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/b9614b02654357832731d887.json b/data/research-evidence/b9614b02654357832731d887.json
new file mode 100644
index 0000000..a7b5302
--- /dev/null
+++ b/data/research-evidence/b9614b02654357832731d887.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:06:27.2323458Z",
+  "content_sha256": "739f4e4338603069dfb507cda19c833b407198e33f1f29bd379ce02a5f6a16f0",
+  "result": {
+    "title": "Cloud IAM Security: AWS, Azure und GCP richtig absichern",
+    "url": "https://a7.de/wiki/cloud-iam-security/",
+    "snippet": "Kurzerklärung: Cloud IAM verwaltet Identitäten und Zugriffsrechte in Cloud-Umgebungen (AWS, Azure, GCP). Überprivilegierte IAM-Rollen sind die häufigste Ursache für Cloud-Datenpannen.",
+    "content": "Inhaltsverzeichnis (8 Abschnitte)\n\nKurzerklärung: Cloud IAM verwaltet Identitäten und Zugriffsrechte in Cloud-Umgebungen (AWS, Azure, GCP). Überprivilegierte IAM-Rollen sind die häufigste Ursache für Cloud-Datenpannen. Best Practices: Least Privilege, kurzlebige Credentials, Managed Identities statt Access Keys, regelmäßige Access Reviews und Automated Policy Analysis mit Cloud-nativen Tools.\n\nCloud IAM ist anders als On-Premises-IAM: alles läuft über APIs, Berechtigungen sind granularer, und ein einziger falsch konfigurierter Service-Account kann zur vollständigen Cloud-Kompromittierung führen.\n\nAWS IAM: Least Privilege umsetzen\n\nDer Root Account darf nur für die initiale Account-Einrichtung verwendet werden. Danach: MFA aktivieren, alle Access Keys löschen, und den Root Account niemals für tägliche Arbeit nutzen. In AWS Organizations sollte der Root Account zusätzlich isoliert werden.\n\nDas Prinzip des Least Privilege bedeutet in AWS: keine Wildcard-Actions, kein \"Resource\": \"*\" , und Conditions wo immer möglich. Eine zu breite Policy erlaubt alle Actions auf alle Ressourcen - eine sichere Policy beschränkt sowohl Actions als auch Ressourcen auf das Notwendige:\n\n\"Effect\" : \"Allow\" ,\n\"Action\" : [\n\"s3:GetObject\" ,\n\"s3:PutObject\"\n],\n\"Resource\" : \"arn:aws:s3:::my-specific-bucket/*\" ,\n\"Condition\" : {\n\"StringEquals\" : {\n\"aws:RequestedRegion\" : \"eu-central-1\"\n\nIAM Access Analyzer findet automatisch Ressourcen die öffentlich oder cross-account zugänglich sind - S3-Buckets, SQS-Queues, KMS-Keys. Die Einrichtung und das Abfragen von Findings erfolgt über die AWS CLI:\n\n# Analyzer erstellen\naws accessanalyzer create-analyzer \\\n--analyzer-name \"company-analyzer\" \\\n--type ACCOUNT\n\n# Findings abfragen\naws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:...\n\nPermission Boundaries ermöglichen delegierte Administration: ein Admin kann keine Rechte vergeben, die er selbst nicht hat. Mit put-user-permissions-boundary wird das Maximum festgelegt, das ein Developer an Berechtigungen erhalten kann.\n\nService Control Policies (SCPs) in AWS Organizations sind Guard Rails für gesamte OUs oder Accounts. Eine typische SCP verhindert EC2-Instanzen und S3-Bucket-Erstellung außerhalb genehmigter Regionen (z. B. eu-central-1 und eu-west-1 ) mit einer Deny-Condition auf StringNotEquals für aws:RequestedRegion .\n\nAWS: Service Accounts und Rollen\n\nAccess Keys gehören nie in EC2-Instanzen, Lambdas oder Container - weder hartgecodiert im Code, noch in .env -Dateien, noch in S3. Der richtige Ansatz ist ein IAM Instance Profile : die Instanz bekommt eine IAM Role zugewiesen und greift automatisch über den Instance Metadata Service (IMDS) auf temporäre Credentials zu. In boto3 werden die Credentials ohne jegliche Konfiguration automatisch verwendet:\n\nimport boto3\ns3 = boto3.client( 's3' ) # Automatisch Instance Role-Credentials\n\n# AWS Secrets Manager für Datenbankpasswörter und API-Keys:\nclient = boto3.client( 'secretsmanager' )\nsecret = client.get_secret_value( SecretId = 'prod/db/password' )\n\nFür Lambda gilt die Execution Role, für ECS/Fargate die Task Role, für EKS IRSA (IAM Roles for Service Accounts).\n\nIMDSv2 erzwingen: IMDSv1 ist ohne Token und anfällig für SSRF-Angriffe. IMDSv2 ist token-basiert und SSRF-resistent. Das Erzwingen erfolgt per CLI:\n\naws ec2 modify-instance-metadata-options \\\n--instance-id i-1234567890abcdef0 \\\n--http-tokens required \\\n--http-put-response-hop-limit 1\n\nDas Hop-Limit auf 1 zu setzen verhindert außerdem Container-Escape-Angriffe, bei denen ein kompromittierter Container die Instance-Credentials stiehlt.\n\nAWS Secrets Manager speichert Datenbankpasswörter und API-Keys verschlüsselt und unterstützt automatische Rotation via Lambda. Secrets werden per secretsmanager create-secret angelegt und per rotate-secret automatisch rotiert - kein Hardcoding im Code nötig.\n\nAzure RBAC und Entra ID\n\nAzure RBAC funktioniert über vier Scope-Ebenen: Management Group, Subscription, Resource Group und einzelne Ressource. Je enger der Scope, desto besser. Owner-Rechte auf Subscription-Level sind fast immer zu breit - korrekt ist z. B. Storage Blob Data Contributor nur auf ein einzelnes Storage Account:\n\naz role assignment create \\\n--assignee user@company.com \\\n--role \"Storage Blob Data Contributor\" \\\n--scope \"/subscriptions/SUB-ID/resourceGroups/rg-data/providers/Microsoft.Storage/storageAccounts/myaccount\"\n\nManaged Identities eliminieren Secret Management vollständig: kein Passwort, kein API-Key, kein Zertifikat im Code. System-assigned Identities sind 1:1 an eine Ressource gebunden, User-assigned Identities können von mehreren Ressourcen geteilt werden. Ein App Service bekommt per az webapp identity assign eine Identität, die Key Vault Policy wird auf die principalId gesetzt, und im Python-Code reicht DefaultAzureCredential() - die Managed Identity wird automatisch verwendet.\n\nAzure AD Conditional Access setzt Zero Trust um: jeder Zugriff wird kontextbasiert geprüft. Eine typische Policy für Admin-Zugriff erfordert ein compliant Device, MFA und Hybrid Azure AD Join gleichzeitig - und setzt die Sign-in Frequency auf 1 Stunde, damit gestohlene Sessions zeitlich begrenzt sind.\n\nGCP IAM und Workload Identity\n\nIn GCP gilt: Google Accounts für Personen, Service Accounts für Anwendungen. Service Accounts sollen nie manuell verwendet werden (kein Einloggen, kein JSON Key Download). Der sichere Ansatz ist Workload Identity Federation für externe Workloads und die direkte Zuweisung von Rollen mit Conditions für interne Services:\n\n# Service Account erstellen\ngcloud iam service-accounts create webapp-sa \\\n--description \"Web App Service Account\" \\\n--display-name \"webapp-sa\"\n\n# Minimal-Permissions mit Resource-Condition\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n--member \"serviceAccount:webapp-sa@PROJECT_ID.iam.gserviceaccount.com\" \\\n--role \"roles/storage.objectViewer\" \\\n--condition \"title=bucket-condition,expression=resource.name.startsWith('projects/_/buckets/my-bucket')\"\n\n# Service Account Key-Erstellung org-weit deaktivieren\ngcloud org-policies set-policy \\\n--project=PROJECT_ID constraints/iam.disableServiceAccountKeyCreation \\\n--value=ENFORCE\n\nWorkload Identity Federation ermöglicht GitHub Actions, Kubernetes und andere externe Services den Zugriff auf GCP ohne JSON Keys. Das Prinzip: ein OpenID Connect Provider (z. B. GitHub) wird bei GCP registriert, GitHub Actions bekommt id-token: write -Permission, und der google-github-actions/auth -Action tauscht den OIDC-Token gegen kurzlebige GCP-Credentials.\n\nOrganization Policies sind die GCP-Entsprechung der AWS SCPs: Constraints für die gesamte Organisation, z. B. OS Login-Pflicht für alle VMs ( constraints/compute.requireOsLogin ) oder die Deaktivierung von Service Account Keys org-weit.\n\nCSPM: Cloud Security Posture Management\n\nCSPM-Tools erkennen automatisch Fehlkonfigurationen in Cloud-Umgebungen. Typische Prüfpunkte sind öffentlich zugängliche S3-Buckets, fehlende MFA-Enforcement für Root Accounts, ungenutzte IAM-Rollen und Access Keys, unverschlüsselte Datenbanken und Speicher, deaktiviertes Logging (CloudTrail, Activity Log) sowie zu offene Security Groups.\n\nAWS Security Hub ist in AWS eingebaut und aggregiert Findings aus GuardDuty, Inspector, Macie und Config. Der CIS AWS Benchmark wird automatisch geprüft. Kosten: 0,001 USD pro Finding.\n\nMicrosoft Defender for Cloud ist das Azure-Äquivalent mit einem Secure Score von 0-100 (Ziel: über 80) und konkreten Handlungsempfehlungen mit Fix-Anleitungen.\n\nWiz und Orca Security sind kommerzielle Multi-Cloud-Lösungen (AWS, Azure, GCP, Kubernetes) mit Attack Path Analysis - sie zeigen, wie weit ein Angreifer ausgehend von einer Fehlkonfiguration in die Infrastruktur eindringen könnte.\n\nCheckov mit Terraform scannt Infrastructure-as-Code präventiv vor dem Deployment und findet Fehlkonfigurationen bevor sie in die Produktion gelangen - die DevSecOps-Integration im CI/CD ist die effektivste Stelle, um CSPM-Findings zu verhindern statt zu beheben.\n\nAWS IAM: Least Privilege umsetzen\n\nDer Root Account darf nur für die initiale Account-Einrichtung verwendet werden. Danach: MFA aktivieren, alle Access Keys löschen, und den Root Account niemals für tägliche Arbeit nutzen. In AWS Organizations sollte der Root Account zusätzlich isoliert werden.\n\nDas Prinzip des Least Privilege bedeutet in AWS: keine Wildcard-Actions, kein \"Resource\": \"*\" , und Conditions wo immer möglich. Eine zu breite Policy erlaubt alle Actions auf alle Ressourcen - eine sichere Policy beschränkt sowohl Actions als auch Ressourcen auf das Notwendige:\n\n\"Effect\" : \"Allow\" ,\n\"Action\" : [\n\"s3:GetObject\" ,\n\"s3:PutObject\"\n],\n\"Resource\" : \"arn:aws:s3:::my-specific-bucket/*\" ,\n\"Condition\" : {\n\"StringEquals\" : {\n\"aws:RequestedRegion\" : \"eu-central-1\"\n\nIAM Access Analyzer findet automatisch Ressourcen die öffentlich oder cross-account zugänglich sind - S3-Buckets, SQS-Queues, KMS-Keys. Die Einrichtung und das Abfragen von Findings erfolgt über die AWS CLI:\n\n# Analyzer erstellen\naws accessanalyzer create-analyzer \\\n--analyzer-name \"company-analyzer\" \\\n--type ACCOUNT\n\n# Findings abfragen\naws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:...\n\nPermission Boundaries ermöglichen delegierte Administration: ein Admin kann keine Rechte vergeben, die er selbst nicht hat. Mit put-user-permissions-boundary wird das Maximum festgelegt, das ein Developer an Berechtigungen erhalten kann.\n\nService Control Policies (SCPs) in AWS Organizations sind Guard Rails für gesamte OUs oder Accounts. Eine typische SCP verhindert EC2-Instanzen und S3-Bucket-Erstellung außerhalb genehmigter Regionen (z. B. eu-central-1 und eu-west-1 ) mit einer Deny-Condition auf StringNotEquals für aws:RequestedRegion .\n\nAWS: Service Accounts und Rollen\n\nAccess Keys gehören nie in EC2-Instanzen, Lambdas oder Container - weder hartgecodiert im Code, noch in .env -Dateien, noch in S3. Der richtige Ansatz ist ein IAM Instance Profile : die Instanz bekommt eine IAM Role zugewiesen und greift automatisch über den Instance Metadata Service (IMDS) auf temporäre Credentials zu. In boto3 werden die Credentials ohne jegliche Konfiguration automatisch verwendet:\n\nimport boto3\ns3 = boto3.client( 's3' ) # Automatisch Instance Role-Credentials\n\n# AWS Secrets Manager für Datenbankpasswörter und API-Keys:\nclient = boto3.client( 'secretsmanager' )\nsecret = client.get_secret_value( SecretId = 'prod/db/password' )\n\nFür Lambda gilt die Execution Role, für ECS/Fargate die Task Role, für EKS IRSA (IAM Roles for Service Accounts).\n\nIMDSv2 erzwingen: IMDSv1 ist ohne Token und anfällig für SSRF-Angriffe. IMDSv2 ist token-basiert und SSRF-resistent. Das Erzwingen erfolgt per CLI:\n\naws ec2 modify-instance-metadata-options \\\n--instance-id i-1234567890abcdef0 \\\n--http-tokens required \\\n--http-put-response-hop-limit 1\n\nDas Hop-Limit auf 1 zu setzen verhindert außerdem Container-Escape-Angriffe, bei denen ein kompromittierter Container die Instance-Credentials stiehlt.\n\nAWS Secrets Manager speichert Datenbankpasswörter und API-Keys verschlüsselt und unterstützt automatische Rotation via Lambda. Secrets werden per secretsmanager create-secret angelegt und per rotate-secret automatisch rotiert - kein Hardcoding im Code nötig.\n\nAzure RBAC und Entra ID\n\nAzure RBAC funktioniert über vier Scope-Ebenen: Management Group, Subscription, Resource Group und einzelne Ressource. Je enger der Scope, desto besser. Owner-Rechte auf Subscription-Level sind fast immer zu breit - korrekt ist z. B. Storage Blob Data Contributor nur auf ein einzelnes Storage Account:\n\naz role assignment create \\\n--assignee user@company.com \\\n--role \"Storage Blob Data Contributor\" \\\n--scope \"/subscriptions/SUB-ID/resourceGroups/rg-data/providers/Microsoft.Storage/storageAccounts/myaccount\"\n\nManaged Identities eliminieren Secret Management vollständig: kein Passwort, kein API-Key, kein Zertifikat im Code. System-assigned Identities sind 1:1 an eine Ressource gebunden, User-assigned Identities können von mehreren Ressourcen geteilt werden. Ein App Service bekommt per az webapp identity assign eine Identität, die Key Vault Policy wird auf die principalId gesetzt, und im Python-Code reicht DefaultAzureCredential() - die Managed Identity wird automatisch verwendet.\n\nAzure AD Conditional Access setzt Zero Trust um: jeder Zugriff wird kontextbasiert geprüft. Eine typische Policy für Admin-Zugriff erfordert ein compliant Device, MFA und Hybrid Azure AD Join gleichzeitig - und setzt die Sign-in Frequency auf 1 Stunde, damit gestohlene Sessions zeitlich begrenzt sind.\n\nFragen zu diesem Thema?\n\nUnsere Experten beraten Sie kostenlos und unverbindlich.\n\nErstberatung\n\nÜber den Autor\n\nChris Wojzechowski\nGeschäftsführender Gesellschafter\n\nE-Mail\n\nPGP 465C26E1AF161AFA\n\nGeschäftsführender Gesellschafter der AWARE7 GmbH mit langjähriger Expertise in Informationssicherheit, Penetrationstesting und IT-Risikomanagement. Absolvent des Masterstudiengangs Internet-Sicherheit an der Westfälischen Hochschule (if(is), Prof. Norbert Pohlmann). Bestseller-Autor im Wiley-VCH Verlag und Lehrbeauftragter der ASW-Akademie. Einschätzungen zu Cybersecurity und digitaler Souveränität erschienen u.a. in Welt am Sonntag, WDR, Deutschlandfunk und Handelsblatt.\n\n10 Publikationen\n\nEinsatz von elektronischer Verschlüsselung - Hemmnisse für die Wirtschaft (2018)\n\nKompass IT-Verschlüsselung - Orientierungshilfen für KMU (2018)\n\nIT Security Day 2025 - Live Hacking: KI in der Cybersicherheit (2025)\n\nLive Hacking - Credential Stuffing: Finanzrisiken jenseits Ransomware (2025)\n\nKeynote: Live Hacking Show - Ein Blick in die Welt der Cyberkriminalität (2025)\n\nAnalyse von Angriffsflächen bei Shared-Hosting-Anbietern (2024)\n\nGänsehaut garantiert: Die schaurigsten Funde aus dem Leben eines Pentesters (2022)\n\nIT Security Zertifizierungen - CISSP, T.I.S.P. \u0026 Co (Live-Webinar) (2023)\n\nSicherheitsforum Online-Banking - Live Hacking (2021)\n\nNipster im Netz und das Ende der Kreidezeit (2017)\n\nIT-Grundschutz-Praktiker (TÜV) IT Risk Manager (DGI)",
+    "content_type": "text/html",
+    "query": "Cloud IAM, Cloud Secrets, Cloud Service Accounts, Cloud Incident Response, Cloud Access Review, Perfect Forward Secrecy – ein einheitliches, thematisch verknüpftes Handbuch zur Sicherheitspraxis in Cloud-Umgebungen mit Fokus auf Monitoring, Forensik und Sicherheitsmaßnahmen current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/becb4d588d02ffe3be64635d.json b/data/research-evidence/becb4d588d02ffe3be64635d.json
new file mode 100644
index 0000000..455e08b
--- /dev/null
+++ b/data/research-evidence/becb4d588d02ffe3be64635d.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:20:30.0381729Z",
+  "content_sha256": "c32ee17fe63ff1b049e391e825ac4bbb7ea0825550897c60acaa1eac35017d08",
+  "result": {
+    "title": "BSI - Ransomware Angriffe - Ransomware – Fakten und Abwehrstrategien",
+    "url": "https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Analysen-und-Prognosen/Ransomware-Angriffe/ransomware-angriffe.html",
+    "snippet": "Ransomware -Angriffe stellen eine der größten Cyberbedrohungen für Staat, Wirtschaft und Gesellschaft dar. Bei einem Ransomware -Angriff werden die Daten auf einem IT -System verschlüsselt und eine Entschlüsselung erst gegen Zahlung eines Lösegeldes (engl. Ransom) in Aussicht gestellt.",
+    "content": "Ransomware – Fakten und Abwehrstrategien\n\nRansomware -Angriffe stellen eine der größten Cyberbedrohungen für Staat, Wirtschaft und Gesellschaft dar.\n\nBedrohung für Jede und Jeden\n\nBei einem Ransomware -Angriff werden die Daten auf einem IT -System verschlüsselt und eine Entschlüsselung erst gegen Zahlung eines Lösegeldes ( engl. Ransom ) in Aussicht gestellt. Immer öfter wird zusätzlich mit der Veröffentlichung der zuvor entwendeten Daten gedroht, um das Opfer zusätzlich unter Druck zu setzen. Ransomware Angriffe zeichnen sich dadurch aus, dass die Auswirkungen auf einen Betroffenen mit dem Einsatz der Ransomware unmittelbar eintreten:\n\nDienstleistungen und Geschäftsprozesse können nicht mehr zur Verfügung gestellt werden.\n\nDie IT des Betroffenen kommt zum Erliegen.\n\nDurch die zunehmende Professionalisierung und Arbeitsteilung auf Angreiferseite sind zudem die Einstiegshürden für die Durchführung von Ransomware -Angriffen deutlich gesunken, was weitere Täter anzieht.\n\nDies bedeutet, dass Ransomware große und kleine Unternehmen treffen kann. Hilfestellungen und Informationen zu Prävention und Reaktion bei Ransomware -Vorfällen stellt das BSI hier zur Verfügung:\n\nBedrohungslage\n\nGemeinsame Publikationen von ANSSI und BSI (teilw. deutsch)\n\nZusammenfassung des Bedrohungsphänomens Ransomware\n\nBedrohungslage, Reaktion und Prävention zu Ransomware\n\nAktuelle Informationen für Unternehmen\n\nPrävention und Detektion\n\nTop 10 Ransomware-Maßnahmen\n\nTop 10 Ransomware-Maßnahmen (Detektion)\n\nBedrohungslage, Reaktion und Prävention zu Ransomware\n\nMaßnahmenkatalog Ransomware\n\nNoMoreRansom-Initiative\n\nAllianz für Cybersicherheit\n\nReaktion\n\nErste Hilfe bei einem schweren IT -Sicherheitsvorfall\n\nUnternehmen\n\nKritische Infrastrukturen und weitere meldepflichtige Unternehmen\n\nVerbraucherinnen und Verbraucher\n\nListe qualifizierter APT-Dienstleister\n\nDem BSI einen Vorfall melden\n\nAnsprechpartner bei der Polizei (ZAC)\n\nNoMoreRansom-Initiative\n\nBedrohungslage, Reaktion und Prävention zu Ransomware\n\nWas ist Ransomware?\n\nDas englische Wort „ransom“ zu Deutsch Lösegeld bezeichnet den Zweck, zu dem Cyberkriminelle Ransomware -Schadprogramme einsetzen. Ransomware in seinen unterschiedlichen Varianten zielt in der Regel auf die Verschlüsselung von Nutzerdaten ab. Nachdem die Daten verschlüsselt wurden, wird versucht, Lösegeld mit der Drohung zu erpressen, dass die Daten erst nach Zahlung des meist digitalen Lösegelds wieder freigegeben werden. Opfer von Ransomware wurden in der Vergangenheit nicht nur Großkonzerne, sondern auch mittelständische Unternehmen Krankenhäusern und Kommunen. Aber auch Privatpersonen können von Ransomware -Angriffen unmittelbar betroffen sein.\n\nWachsende Bedrohungslage\n\nRansomware ist für Kriminelle ein seit Jahren etabliertes Geschäftsmodell und aus Sicht des BSI einer der größten operativen Bedrohungen der Cybersicherheit. Die Qualität der Angriffe steigt stetig und sind diese erst einmal erfolgreich, sind Vorfallsreaktion und -aufarbeitung zeit- und kostenaufwendig. Die Erpressung von Unternehmen und öffentlichen Einrichtungen durch Ransomware ist der am schnellsten wachsende Bereich der Cyberkriminalität und stellt mittlerweile ein großes Problem dar.\n\nMit einer Erpressung – und um nichts Anderes handelt es sich bei diesen Angriffen – lassen sich schnell große Summen \"verdienen\"; abhängig von der Zahlungsfähigkeit des Opfers. Ähnlich zu einer Geiselnahme hat der Angreifer ein enormes Druckmittel in der Hand, wenn durch die Verschlüsselung der kompletten IT -Infrastruktur das wirtschaftliche Überleben eines Unternehmens auf dem Spiel steht oder öffentliche Einrichtungen über eine längere Zeit nur eingeschränkt arbeiten können.\n\nDurch die mittlerweile sehr starke Arbeitsteilung im Cybercrime -Umfeld ist zudem die Einstiegshürde für solche Angriffe massiv gesunken. Es ist heutzutage möglich ohne nennenswerte Vorkenntnisse und ohne großen finanziellen Einsatz möglich, einen Ransomware -Angriff durchzuführen. Zudem ist die Strafverfolgung nicht einfach.\n\nSchutz vor Ransomware -Angriffen\n\nNach Ansicht des BSI wird die Bedrohung durch Ransomware noch immer vielfach unterschätzt. Dabei gibt es wirksame und seit langem erprobte Schutzmaßnahmen. Diese werden aber zu selten umgesetzt. Es besteht kein „Maßnahmenmangel“, sondern ein „Umsetzungsmangel“.\n\nDie einfachste aber nicht alleine ausreichende Maßnahme zum Schutz vor Ransomware und anderer Schadsoftware ist die Sensibilisierung der Mitarbeiterinnen und Mitarbeiter in Unternehmen und öffentlichen Einrichtungen bezüglich der wesentlichen Infektionswege. Dies ist das unbedarfte Öffnen von Anhängen in E-Mails sowie die ungewollte Weiterleitung auf kompromittierte Webseiten im Internet. Hierbei gilt es, ein gesundes Misstrauen gegenüber allen Informationen im Internet und bei allen Kontakten im Internet an den Tag zu legen. Die gleiche Vorsicht schützt auch im privaten Umfeld vor finanziellen und persönlichen Schäden.\n\nNeben dieser Sensibilisierung und dem Einsatz des gesunden Menschenverstandes, gibt es technische und organisatorische Maßnahmen, die den Schutz vor Ransomware -Angriffen erheblich erhöhen.\n\nReaktion: Wenn der Ernstfall eintritt\n\nDoch auch die oben dargestellten Vorsichtsmaßnahmen können keinen hundertprozentigen Schutz vor Ransomware bieten. Sollte es zu einem Sicherheitsvorfall mit Ransomware kommen, gilt es rasch und bedacht zu handeln. Insbesondere für Unternehmen und öffentliche Institutionen ist dann ein geeignetes Krisenmanagement wichtig, das neben den technischen Wiederherstellungsaspekten besonders die notwendige in- und externe Kommunikation berücksichtigt. Dabei ist es sinnvoll, frühzeitig IT -Sicherheitsexperten und -dienstleister hinzuzuziehen, den Vorfall den zuständigen Stellen (wie z. B. dem Landes- CERT und dem Landesbeauftragten für Datenschutz) zu melden und Anzeige beim Landeskriminalamt zu stellen.\n\nGemeinsam gegen Ransomware\n\nUnter den finanziell motivierten Akteuren sind die Betreiber und Affiliates der Ransomware-as-a-Service LockBit aktuell die größte Bedrohung in Deutschland wie auch weltweit. Zusammen mit den IT -Sicherheitsbehörden aus den Vereinigten Staaten, Australien, Kanada, Vereinigten Königreich, Frankreich und Neuseeland, dem U.S. Federal Bureau of Investigation (FBI) und U.S. Multi-State Information Sharing and Analysis Center (MS-ISAC) wurde am 8. Mail 2024 ein aktualisierter gemeinsamer Bericht zum Verständnis der Vorgehensweise dieser Ransomware -Angreifer und möglicher Schutzmaßnahmen veröffentlicht.\n\nWeitere Informationen\n\nDownload Ransomware: Managementabstract Fortschrittliche Angriffe (PDF)\n\nDownload Ransomware: Bedrohungslage 2022 (PDF)\n\nDownload Ransomware: LockBit (PDF)\n\nWeitere Informationen\n\nTop 10 Ransomware-Maßnahmen\n\nTop 10 Ransomware-Maßnahmen (Detektion)\n\nEmotet\n\nZurück zu Analysen und Prognosen\n\nKurz-URL:\n\nhttps://www.bsi.bund.de/dok/ransomware-links",
+    "content_type": "text/html",
+    "query": "Ransomware Detection \u0026 Forensics – präventiv, resilient und Vorfall-basiert gestalten current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "authoritative",
+    "source_quality_score": 0.95,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/c26c146b574d0c7fde06a3e9.json b/data/research-evidence/c26c146b574d0c7fde06a3e9.json
new file mode 100644
index 0000000..bf14515
--- /dev/null
+++ b/data/research-evidence/c26c146b574d0c7fde06a3e9.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:44:07.4500631Z",
+  "content_sha256": "100ac5f8723e7886c518820b749d5ade025b5a0a10485d0153eff5d3fe709351",
+  "result": {
+    "title": "Vorfallsmanagement in NIS2 und KRITIS – OpenKRITIS",
+    "url": "https://www.openkritis.de/massnahmen/vorfallsmanagement.html",
+    "snippet": "Dazu sind durchgängige Prozesse für Vorfallsmanagement und Security Incident Management mit begleitenden Vorgaben und Abläfen notwendig. NIS2 und das KRITIS-Dachgesetz vertiefen die Vorgaben zur Behandlung von Vorfällen bei regulierten Einrichtungen und Betreibern.",
+    "content": "Vorfälle in NIS2 und KRITIS\n\nCybersecurity in KRITIS und NIS2\n\nISMS\n\nBCMS\n\nRisikomanagement\n\nLeitung\n\nPersonal\n\nSupply Chain\n\nVorfälle\n\nAngriffserkennung\n\nIT-Sicherheit\n\nStandards\n\nEinrichtungen und Betreiber müssen Ereignisse, die zu Vorfällen, Störungen und Sicherheitsvorfällen führen können erkennen, behandeln und teilweise an Aufsichtsbehörden melden.\nDazu sind durchgängige Prozesse für Vorfallsmanagement und Security Incident Management mit begleitenden Vorgaben und Abläfen notwendig.\n\nVorfallsmanagement\n\nDefinition\n\nMeldepflichten\n\nAngriffserkennung\n\nNIS2 und das KRITIS-Dachgesetz vertiefen die Vorgaben zur Behandlung von Vorfällen bei regulierten Einrichtungen und Betreibern.\nDie folgende Ausarbeitung führt ISMS-Kernkomponenten anhand der NIS2-Anforderungen für Einrichtungen, sowie der alten KRITIS-Anforderungen von\nRUN - KdA aus.\nAls Orientierung sind die Anforderungen der Durchführungsverordnung DVO (EU) aufgeführt.\n\nBereich\n\nAnforderung\n\nNIS2\nBSIG\n\nKRITIS\nDachG\n\nRUN\nKdA\n\nVorfallsmanagement\n\nProzesse und Vorgaben für das Incident Management von Vorfällen und Notfällen\n\nNS.6\n\nDG.12\n\n? (77-82)\n\nDefinition\n\nFestlegungen zu den Kriterien meldepflichtiger Vorfälle an Aufsichtsbehörden\n\nNS.6\n\nDG.12\n\n? (77)\n\nMeldepflichten\n\nMeldeweg und Pflichten für Vorfallsmeldungen an Behörden\n\nNS.31\n\nDG.23\nDG.24\nDG.25\n\n2/3 (97,100)\n\nAngriffserkennung\n\nKonkrete Vorgaben BSI Angriffserkennung bei Betreibern\n\nNS.30\n\n3‑5 (101‑135)\n\nVorfallsmanagement\n\nIncident Management\n\nFür die Behandlung von Sicherheitsvorfällen in Kritischen Infrastrukturen sind bei Einrichtungen und Betreibern klare Verantwortlichkeiten und Abläufe notwendig.\nDazu muss ein geregeltes Incident Management mit Rollen und Prozessen für die Behandlung von Vorfällen definiert und betrieben werden.\n\nAnforderung\n\nNIS2\nDVO‑EU\n\nKRITIS\nDachG\n\nISO 27001\n2022\n\nRUN\nKdA\n\nVerantwortlichkeiten und Vorgehensmodell\n\n3.1.1\n\nDG.12\n\nA.5.24\n\n3 (77)\n\nBearbeitung von Sicherheitsvorfällen\n\n3.5.1\n3.5.2\n\nDG.12\n\nA.5.25\nA.5.26\n\n3 (78)\n\nDokumentation und Berichterstattung über Sicherheitsvorfälle\n\n3.3.1\n\nDG.12\n\nA.5.28\n\n3 (79)\n\nVerpflichtung der Nutzer zur Meldung von Sicherheitsvorfällen\n\n3.3.1\n3.3.2\n\nDG.12\n\nA.6.8\n\n3 (81)\n\nAuswertung und Lernprozess\n\n3.6.1\n3.6.2\n\nDG.12\n\nA.5.26\nA.5.27\n\n3 (82)\n\nRollen\n\nRollen und Aufgaben für Vorfälle müssen im Geltungsbereich festgelegt werden.\nDie Rollen können Teil vom CERT, CSIRT, SOC oder auch in der Security oder Flächenorganisation beim Betreiber sein.\n\nLeiter Vorfälle : Governance für und Leitung der Vorfallserkennung und -behandlung\n\nVorfallsbehandlung : Reaktionsteam zur operativen Bewältigung von Vorfällen\n\nNotfallmanagement : Reaktives BCM zur Behandlung von Notfällen\n\nStörungsmanagement : Behandlung von betrieblichen Störungen\n\nNIS2 und KRITIS-Dachgesetz\n\nGeregeltes Vorfallsmanagement ist sowohl in NIS2 (BSIG) für Einrichtungen und im KRITIS-Dachgesetz für Betreiber verpflichtend.\nDas Vorfallsmanagement nach NIS2 wird üblicherweise in Security Incident Management mit Fokus auf Sicherheitsvorfälle aus der Cybersecurity sein.\n\nIm KRITIS-Dachgesetz ist ebenfalls Vorfallsmanagement gefordert, aber mehr für die Behandlungen von Notfällen und Beeinträchtigungen der kritischen Dienstleistung.\n\nProzesse\n\nFür den Umgang mit Störungen und Vorfällen müssen zentrale Prozesse im Betrieb der Einrichtungen Anlagen definiert werden, u.a.:\n\nDetektion : Störungen, Angriffe und Vorfälle müssen anhand von Logs, Mustern und Indikatoren im Betrieb erkannt und festgestellt werden\n\nReaktion : Erkannte Vorfälle müssen von Fachpersonal klassifizert und behandelt, und die weitere Bewältigung eingeleitet werden (zum Incident-/Notfall-/Krisen-Management)\n\nMeldungen : Festgestellte Vorfälle und Störungen müssen dokumentiert und gemeldet werden, falls diese meldepflichtig sind (ggf. über die Meldeorganisation)\n\nAuswertung : Vorfälle und Bewältigung müssen für Lessons Learned ausgewertet werden\n\nNachweise\n\nArtefakte als Nachweis für funktionierende Governance für Vorfälle sind u.a.:\n\nErkannte Angriffe\n\nBewältigte Vorfälle\n\nTickets\n\nLessons Learned\n\nup\n\nDefinition\n\nFür die Behandlung und Meldung von Vorfällen ist eine durchgängige Einstufung von Ereignissen und meldepflichten Vorfällen an Aufsichtsbehörden essentiell.\nDetektierte oder gemeldete Ereignissen müssen nach Regeln und Definitionen in Sicherheitsvorfälle und meldepflichtige Störungen hochgestuft werden können – was dann die Meldepflicht nach sich zieht.\n\nAnforderung\n\nNIS2\nDVO‑EU\n\nKRITIS\nDachG\n\nISO 27001\n2022\n\nRUN\nKdA\n\nDefinition meldepflichtiger Vorfälle: schwerwiegende Sicherheitsvorfälle und schwerwiegende Störungen\n\n3.4.1\n3.4.2\nDVO‑EU\n\nDG.23\n\nA.5.25 A.5.28 A.6.8 A.8.15\n\n3 (77)\n\nFestlegung Kriterien\n\nDie Kriterien für Sicherheitsvorfälle (NIS2) und Störungen/Vorfälle (KRITIS-Dachgesetz) sollten so klar, eindeutig und handelbar wie möglich definiert und zugänglich in Aufnahmebögen und Handouts für das Vorfallspersonal dokumentiert werden.\n\nWenn möglich, sollten die Kriterien mit der Leitung abgestimmt und freigegeben werden, und anschließend weitflächig im Rahmen der Vorfallsprozesse kommuniziert werden.\n\nNIS2\n\nEinrichtungen nach NIS2 müssen erhebliche Sicherheitsvorfälle an die Aufsichtsbehörden melden.\nDazu ist eine Definition der Erheblichkeit essentiell, die nach dem BSIG sehr verkürzt ist.\nDer EU Implementing Act , die Durchführungsverordnung kann hier als Orientierung dienen:\n\nFinanzieller Verlust von mehr als 500 Tsd. EUR oder 5 Prozent des Jahresumsatzes\n\nAbfluss von Geschäftsgeheimnissen\n\nTod oder schwere Schädigung der Gesundheit einer natürlichen Person\n\nUnbefugter Zugriff auf Netz- und Informationssysteme → schwerwiegende Betriebsstörungen\n\nWiederholte Sicherheitsvorfälle\n\nKRITIS-Dachgesetz\n\nDas KRITIS-Dachgesetz definiert eine Art von meldepflichtigem Vorfall: ein Ereignis, das die Erbringung einer kritischen Dienstleistung erheblich beeinträchtigt oder beeinträchtigen könnte.\nAusgenommen davon sind Sicherheitsvorfälle nach NIS2 und Vorfälle nach TKG.\n\nup\n\nMeldewesen zu Behörden\n\nNach der Erkennung und parallel zur Behandlung von Vorfällen müssen bestimmte meldepflichtige Vorfälle an Aufsichtsbehörden gemeldet werden.\n\nAnforderung\n\nNIS2\nDVO‑EU\n\nKRITIS\nDachG\n\nISO 27001\n2022\n\nRUN\nKdA\n\nEinrichtung einer Kontaktstelle\n\nDG.1\n\nA.5.5\nA.5.31\n\n3 (100)\n\nMeldepflicht erhebliche Sicherheitsvorfälle\n\nNS.31\n\nA.5.5\nA.5.31\n\nMeldepflicht erhebliche Störungen\n\nDG.23\n\nA.5.5\nA.5.31\n\nFolgeinformationen\n\nNS.31\n\nDG.23\n\nA.5.5\nA.5.28\nA.5.31\n\nMeldepflichten NIS2\n\nRegulierte Einrichtungen und Betreiber kritischer Anlagen müssen nach NIS2 erhebliche Sicherheitsvorfälle an das BSI melden – innerhalb von 24 Stunden mit abgestuften Folge- und Abschlussmeldungen.\nDie Fristen und Inhalte der Meldung sind im Gesetz (BSIG) umfangreich vorgegeben – und müssen im BSI-Portal gemeldet werden.\n\nMeldepflichten KRITIS-Dachgesetz\n\nBetreiber kritischer Anlagen müssen Vorfälle (erhebliche Störungen) nach dem KRITIS-Dachgesetz über die vom BSI und BBK für NIS2 eingerichtete gemeinsame Meldestelle melden – in sehr kurzen Fristen, innerhalb von 24 Stunden, und mit stufenweisen Folgemeldungen.\n\nKontaktstelle\n\nBei Betreibern kritischer Anlagen muss eine jederzeit erreichbare Kontaktstelle für das BSI eingerichtet und registriert werden.\nSie nimmt eigehende Meldungen und Fragen von beiden Seiten an.\n\nNachweise\n\nArtefakte als Nachweis für ein funktionierendes Meldewesen sind u.a.:\n\nGemeldete Vorfälle\n\nDokumentierte Vorfälle\n\nQuittierungen\n\nup\n\nWeitere Informationen\n\nQuellen\n\nGesetz über das Bundesamt für Sicherheit in der Informationstechnik und die Sicherheit in der Informationstechnik von Einrichtungen , BSI-Gesetz vom 2. Dezember 2025\n\nDachgesetz zur Stärkung der physischen Resilienz kritischer Anlagen , KRITIS-Dachgesetz vom 11. März 2026 (BGBl. 2026 I Nr. 66)\n\nReife- und Umsetzungsgradbewertung (RUN) im Rahmen der Nachweisprüfung, Bundesamt für Sicherheit in der Informationstechnik, 09.01.2025\n\nMapping von Anforderungen aus der Konkretisierung der KRITIS-Anforderungen auf RUN-Umsetzungsgrade, Bundesamt für Sicherheit in der Informationstechnik, 09.01.2025\n\nISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements\n\nOpenKRITIS\n\nCybersecurity in KRITIS und NIS2\n\nVorfallsmanagement\n\nup",
+    "content_type": "text/html",
+    "query": "Welche konkreten Schritte sind für die Erkennung von Vorfällen bei Wayland/X11 Remote Access erforderlich?",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.37,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "REVIEW-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/c82933449dacbbf112f04fd7.json b/data/research-evidence/c82933449dacbbf112f04fd7.json
new file mode 100644
index 0000000..d64a04a
--- /dev/null
+++ b/data/research-evidence/c82933449dacbbf112f04fd7.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:22:07.5398453Z",
+  "content_sha256": "d621b5354c6df0eebab998731b91551bf70f2dbfac7baa8125542594957b4556",
+  "result": {
+    "title": "Prototype Pollution Prevention - OWASP Cheat Sheet Series",
+    "url": "https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html",
+    "snippet": "Prototype Pollution is a critical vulnerability that can allow attackers to manipulate an application's JavaScript objects and properties, leading to serious security issues such as unauthorized access to data, privilege escalation, and even remote code execution.",
+    "content": "Query Parameterization\n\nRAG Security\n\nREST Assessment\n\nREST Security\n\nRuby on Rails\n\nSAML Security\n\nSQL Injection Prevention\n\nSecrets Management\n\nSecure AI Model Ops\n\nSecure Cloud Architecture\n\nSecure Code Review\n\nSecure Coding with AI\n\nSecure Product Design\n\nSecuring Cascading Style Sheets\n\nSecurity Terminology\n\nServer Side Request Forgery Prevention\n\nServerless FaaS Security\n\nSession Management\n\nSoftware Supply Chain Security\n\nSubdomain Takeover Prevention\n\nSymfony\n\nTLS Cipher String\n\nThird Party Javascript Management\n\nThird Party Payment Gateway Integration\n\nThreat Modeling\n\nTransaction Authorization\n\nTransport Layer Protection\n\nTransport Layer Security\n\nUnvalidated Redirects and Forwards\n\nUser Privacy Protection\n\nVirtual Patching\n\nVulnerability Disclosure\n\nVulnerable Dependency Management\n\nWebSocket Security\n\nWeb Service Security\n\nXML External Entity Prevention\n\nXML Security\n\nXSS Filter Evasion\n\nXS Leaks\n\nZero Trust Architecture\n\ngRPC Security\n\nPrototype Pollution Prevention Cheat Sheet ¶\n\nExplanation ¶\n\nPrototype Pollution is a critical vulnerability that can allow attackers to manipulate an application's JavaScript objects and properties, leading to serious security issues such as unauthorized access to data, privilege escalation, and even remote code execution.\n\nFor examples of why this is dangerous, see the links in the Other resources section below.\n\nSuggested protection mechanisms ¶\n\nUse \"new Set()\" or \"new Map()\" ¶\n\nDevelopers should use new Set() or new Map() instead of using object literals:\n\nlet allowedTags = new Set ();\nallowedTags . add ( 'b' );\nif ( allowedTags . has ( 'b' )){\n//...\n\nlet options = new Map ();\noptions . set ( 'spaces' , 1 );\nlet spaces = options . get ( 'spaces' )\n\nIf objects or object literals are required ¶\n\nIf objects have to be used then they should be created using the Object.create(null) API to ensure they don't inherit from the Object prototype:\n\nlet obj = Object . create ( null );\n\nIf object literals are required then as a last resort you could use the __proto__ property:\n\nlet obj = { __proto__ : null };\n\nUse object \"freeze\" and \"seal\" mechanisms ¶\n\nYou can also use the Object.freeze() and Object.seal() APIs to prevent built-in prototypes from being modified however this can break the application if the libraries they use modify the built-in prototypes.\n\nNode.js configuration flag ¶\n\nNode.js also offers the ability to remove the __proto__ property completely using the --disable-proto=delete flag. Note this is a defense in depth measure.\n\nPrototype pollution is still possible using constructor.prototype properties but removing __proto__ helps reduce attack surface and prevent certain attacks.\n\nOther resources ¶\n\nWhat is prototype pollution? (Portswigger Web Security Academy)\n\nPrototype pollution (Snyk Learn)\n\nCredits ¶\n\nCredit to Gareth Hayes for providing the original protection guidance in this comment .",
+    "content_type": "text/html",
+    "query": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "reputable_secondary",
+    "source_quality_score": 0.68,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/dc36d30e499078243c6951ad.json b/data/research-evidence/dc36d30e499078243c6951ad.json
new file mode 100644
index 0000000..11922c2
--- /dev/null
+++ b/data/research-evidence/dc36d30e499078243c6951ad.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:06:25.3619265Z",
+  "content_sha256": "5ccd78ff7b6ca91cda3ddebd4f2a3a5640b4a73faa980166c84e617b8a4c464e",
+  "result": {
+    "title": "Sicherheitsarchitektur in der Public Cloud - Informationssicherheit",
+    "url": "https://www.kes-informationssicherheit.de/print/titelthema-it-grundschutz-2/sicherheitsarchitektur-in-der-public-cloud/",
+    "snippet": "Cloud-Sicherheitsarchitektur in der Public Cloud: Praxisnahe Prinzipien zu IAM, Verschlüsselung, Incident Response und AWS Sovereign Cloud.",
+    "content": "Topthemen:\n\nKünstliche Intelligenz\n\nNIS-2\n\nBreadcrumb-Navigation\n\nMit \u003ckes\u003e+ lesen\n\nSicherheitsarchitektur in der Public Cloud\nPrinzipien, Praxis und Fallstricke\n\nCloud-Sicherheit erfordert Umdenken: Wer seine On-Premises-Konzepte einfach in die Cloud hebt, verschenkt Potenzial und schafft neue Risiken. Unsere Autoren erörtern, welche Architekturprinzipien in der Praxis funktionieren, wo typische Stolperfallen lauern und wie Unternehmen eine gute Balance zwischen Sicherheit und Betriebsaufwand finden können.\n\n23.02.2026\n· Gerald Boyne ,\nJens Soeldner ,\nSimon Lehmeyer · Security-Management\n\nLesezeit\n19\nMin.\n\nDie Verlagerung von Workloads in PublicCloud-Umgebungen verändert die Sicherheitsarchitektur grundlegend: Statt physischer Perimeter und dedizierter Hardware treten softwaredefinierte Kontrollen, API-gesteuerte Konfigurationen und ein geteiltes Verantwortungsmodell in den Mittelpunkt. In Beratungsprojekten zeigt sich immer wieder: Viele Unternehmen unterschätzen diesen Paradigmenwechsel und behandeln die Cloud wie ein externes Rechenzentrum, anstatt native Sicherheitsmechanismen konsequent zu nutzen.\n\nDie im Folgenden beschriebenen sechs Architekturprinzipien haben sich in der Praxis als tragfähig erwiesen. Sie gelten grundsätzlich für alle großen Hyperscaler, werden hier aber am Beispiel von Amazon Web Services (AWS) konkretisiert, da dieser Anbieter das breiteste Portfolio an Sicherheitsdiensten vorhält – die Prinzipien lassen sich jedoch auch auf Azure, Google Cloud Platform et cetera übertragen.\n\n(1) Striktes IAM\n\nIn Cloud-Umgebungen ist die Identität der neue Perimeter – dementsprechend sollte ein starkes Identitätsmanagement die erste Verteidigungslinie bilden. Wer eine gültige Berechtigung besitzt, kann von überall auf Ressourcen zugreifen – das macht das Identity- und AccessManagement (IAM) zum kritischsten Sicherheitsbaustein. Das Prinzip der geringstmöglichen Rechtevergabe (Principle of Least Privilege, PoLP) ist zwar nicht neu, aber in der Cloud von besonderer Brisanz: Jede überschüssige Berechtigung ist ein potenzieller Angriffsvektor, der sich über Programmierschnittstellen (APIs) automatisiert ausnutzen lässt. Besonders wichtig sind daher die folgenden Punkte:\n\nTemporäre Credentials statt langlebiger Schlüssel\n\nAccess-Keys mit unbegrenzter Gültigkeit sind ein Relikt aus der Frühzeit der Cloud-Nutzung. In der Praxis findet man sie jedoch noch immer erschreckend häufig – oft in Konfigurationsdateien, manchmal sogar in Git-Repositorys.\n\nDie Umstellung auf rollenbasierte, zeitlich begrenzte Credentials über IAM Roles oder externe IdentityProvider ist heute keine optionale Verbesserung, sondern Pflicht. Für Workloads außerhalb von AWS liefert etwa IAM Roles Anywhere ( https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html ) einen Lösungsansatz, der auch hybride Szenarien abdeckt.\n\nWeiterlesen mit \u003ckes\u003e+\n\nTesten Sie jetzt \u003ckes\u003e+ 30 Tage kostenlos und unverbindlich oder melden Sie sich in Ihrem bestehenden Account an:\n\nEinloggen Registrieren\n\nLesen Sie weiter\n\nDiese Beiträge könnten Sie ebenfalls interessieren.\n\nMit \u003ckes\u003e+ lesen\n\nAusgabe\n1/2026\n\nViel Potenzial – wenig Prüfung?\n\nDer faktischen Übermacht ausländischer Tech-Giganten setzen viele Stimmen Open-Source-Initiativen entgegen. Unser Autor plädiert in seinem Kommentar für eine differenziertere Sicht…\n\nWeiterlesen\n\nMit \u003ckes\u003e+ lesen\n\nAusgabe\n1/2026\n\nSchritt für Schritt zur NIS-2-Umsetzung\n\nDie Anforderungen der NIS-2-Richtlinie der EU und ihrer nationalen Umsetzung dürften eigentlich 2026 niemanden mehr überraschen – dennoch gibt es weiterhin Unsicherheiten im Hinbli…\n\nWeiterlesen\n\nMit \u003ckes\u003e+ lesen\n\nAusgabe\n1/2026\n\nSpielend lernen für mehr Resilienz (2)\n\nIn einer zweiteiligen Reihe betrachten die Autoren, wie Menschen in der Informationssicherheit tatsächlich lernen – und weshalb spielerische Formate wie Serious Games ein ernstzune…\n\nWeiterlesen",
+    "content_type": "text/html",
+    "query": "Cloud IAM, Cloud Secrets, Cloud Service Accounts, Cloud Incident Response, Cloud Access Review, Perfect Forward Secrecy – ein einheitliches, thematisch verknüpftes Handbuch zur Sicherheitspraxis in Cloud-Umgebungen mit Fokus auf Monitoring, Forensik und Sicherheitsmaßnahmen aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.26814814814814814,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/ddb4e478f3be2b5fef4e5a9c.json b/data/research-evidence/ddb4e478f3be2b5fef4e5a9c.json
new file mode 100644
index 0000000..9a398a9
--- /dev/null
+++ b/data/research-evidence/ddb4e478f3be2b5fef4e5a9c.json
@@ -0,0 +1,25 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:23:40.7153377Z",
+  "content_sha256": "448db44ca6b4e7faf58c3da7e19ca40fa9c3b9d7ad48165c71810536a780c5f4",
+  "result": {
+    "title": "AI Lineage and Control: Why Data Provenance Matters | CertifiedData",
+    "url": "https://certifieddata.io/ai-lineage-and-control",
+    "snippet": "Without lineage, AI systems lack true control. Discover how data provenance and lineage create verifiable authority across AI systems.",
+    "content": "AI Governance · Control\n\nAI Lineage and Control: Why Provenance Determines Authority\n\nAI lineage is the documented, verifiable history of every artifact in an AI system's production chain — from raw data through training to individual decisions. Without lineage, control is impossible: you cannot enforce rules you cannot verify. And you cannot verify compliance without a chain of cryptographic evidence linking each artifact to its certified origin. Lineage is not a feature of mature AI programs; it is the precondition for genuine control.\n\nLineage vs. Provenance: A Necessary Distinction\n\nProvenance and lineage are related but distinct concepts. Data provenance answers a backward-looking question: where did this dataset come from? It identifies the source — whether the data was synthetically generated, curated from real-world sources, derived from another dataset, or assembled from multiple origins. Provenance is the origin story.\n\nData lineage extends provenance forward through time. It records not just where the data came from, but what happened to it: what preprocessing steps were applied, what schema transformations occurred, what versions exist, and — critically — what its state was at the precise moment it was certified. Lineage answers: \"where did this come from, what is it now, and how do we know?\"\n\nThis distinction matters for AI governance because the compliance question is typically not about the data's origin alone — it is about the data's state at the time of use. A dataset that was clean and compliant at source may have been transformed in ways that introduce bias or remove required attributes. Lineage, not just provenance, is the relevant record.\n\nData Lineage: The Foundation Layer\n\nData lineage is the first layer of AI lineage because all other governance artifacts depend on it. A model's behavior is determined by its training data. A decision's validity depends on the compliance of the data that trained the model that made the decision. If the data lineage record is absent or incomplete, the governance chain cannot be traced back to its foundation.\n\nA complete data lineage record for an AI training dataset includes: the dataset's origin source with provenance documentation; a log of every transformation applied to the dataset with timestamps and transformation parameters; the SHA-256 fingerprint of the dataset at each major version; and the cryptographic certificate that records the dataset's final certified form. Each element is linked to the next, forming a chain that can be traversed from any point.\n\nCryptographic certification creates the fixed reference points that make the lineage chain verifiable. Without certification, the lineage record is a narrative that can be altered. With certification, each version of the dataset has a hash that is mathematically tied to its content — altering the dataset invalidates the hash, and invalidating the hash reveals the alteration.\n\nModel Lineage: Connecting Training to Deployment\n\nModel lineage records the relationship between a deployed model and its training history. A complete model lineage record includes: the model architecture specification; the training run parameters (hyperparameters, training duration, hardware configuration); the evaluation results against specified benchmarks; and the certified training dataset(s) used in the training run, referenced by their certificate hashes.\n\nThe reference to certified training datasets is the link that connects model lineage to data lineage. When a model card contains the certificate hash of its training dataset, the complete lineage chain from model to data is traversable. When an investigator reviews a deployed model, they can retrieve the training dataset certificate and verify that the data used to train the model was certified, compliant, and traceable to its origin.\n\nModel lineage also serves a forward-looking function. When a model is retrained or fine-tuned, the new model's lineage record references the prior model as a starting point. This creates a lineage graph that captures the entire evolution of the AI system — from initial training through all subsequent updates. Each node in the graph is anchored to certified datasets; each edge records the training or fine-tuning operation. This directly addresses the AI Control Gap at the model layer.\n\nDecision Lineage: Closing the Chain\n\nDecision lineage is the final link: the record that connects an individual AI output to the model and certified dataset that produced it. A complete decision lineage record references the decision identifier, the model version identifier, the model's certified training dataset hash, and the inference timestamp. With this record, any decision can be traced to its complete upstream lineage.\n\nDecision lineage is where governance authority becomes operational. When a regulator asks \"on what data was this decision based?\" the answer is not \"our model was trained on a dataset that we believe was compliant.\" The answer is: \"this decision was produced by model version X, which was trained on dataset Y, which carries certificate Z, which was signed by CertifiedData.io and can be verified at this endpoint.\" The authority for the claim is the cryptographic chain, not the organization's assertion.\n\nThis is why lineage determines authority. Organizations that can provide complete, cryptographically verifiable lineage for their AI decisions have genuine authority to assert compliance. Those that can only provide narrative accounts are asking for trust. In regulatory and legal contexts, trust is not sufficient. See the transparency registry for publicly published certified artifacts.\n\nTrusting Assertions vs. Verifying Facts\n\nThe core distinction between organizations with full lineage and those without is the difference between asking stakeholders to trust assertions and giving stakeholders the ability to verify facts. \"Our training data was compliant\" is an assertion. A signed, publicly verifiable dataset certificate is a fact — a fact that any party with the public key can confirm independently.\n\nEnterprise AI governance programs that aim for verification rather than assertion build lineage infrastructure first. They certify datasets before they train models. They record certified dataset hashes in training logs. They link decision records to model versions. They publish verification endpoints. Each step converts an assertion into a verifiable fact, and the accumulation of verifiable facts is the only foundation for genuine AI control.\n\nFrequently Asked Questions\n\nWhat is AI lineage?\n\nAI lineage is the documented history of every artifact in an AI system's production chain — from raw data through preprocessing, training, model creation, and deployment to individual inference decisions. Full lineage records where each artifact came from, who produced or certified it, and how it was transformed. Without lineage, the authority to assert compliance is based on trust rather than verification.\n\nWhy does lineage determine authority in AI systems?\n\nAuthority in AI governance flows from the ability to verify claims. An organization can claim its training data is ethically sourced and compliance-reviewed — but without a lineage record that cryptographically links the claim to a specific dataset at a specific point in time, the claim cannot be verified. Lineage converts assertions into verifiable facts, which is the basis of genuine authority.\n\nWhat are the three types of AI lineage?\n\nThe three types of AI lineage are data lineage (the history of a dataset from source through all transformations to its certified form), model lineage (the record of a model's training runs, evaluation results, and certified datasets), and decision lineage (the link between an individual AI output and the model and certified dataset that produced it). Full AI governance requires all three.\n\nHow does data lineage differ from data provenance?\n\nData provenance is the origin story of a dataset — where it came from and who created it. Data lineage includes provenance and extends it forward: every transformation and version change the dataset underwent from origin to certified form. Provenance answers \"where did this come from?\" Lineage answers \"what happened to it, and what is it now?\"\n\nHow does cryptographic certification establish AI lineage?\n\nCryptographic certification creates fixed, tamper-evident reference points in the lineage chain. A dataset certificate signed with Ed25519 records the SHA-256 hash of the dataset at certification time. When model training logs reference this certificate hash, and decision records reference the model version, the full lineage chain is anchored in cryptographic evidence at each hop.\n\nAnchor Your AI Lineage Chain with Certified Data\n\nEvery lineage chain starts at the data layer. CertifiedData.io provides the signed, verifiable certificate that every downstream governance artifact depends on.\n\nGenerate a Certified Dataset Verify a Certificate\n\nRelated Topics\n\nAI Control Gap AI Decision Traceability AI Data Provenance Gap AI Decision Governance",
+    "content_type": "text/html",
+    "query": "AI Dataset Integrity und AI Dataset Lineage sind eng verwandt, aber unterschiedliche Konzepte. Beide erfordern Sicherheitsmaßnahmen, aber mit unterschiedlichem Fokus. Ein gemeinsamer Artikel könnte die Sicherheitsaspekte beider Themen konsolidieren und eine umfassendere Anleitung bieten. aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "actionable": true,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/e256a1772cde0b97438331ca.json b/data/research-evidence/e256a1772cde0b97438331ca.json
new file mode 100644
index 0000000..83b0e92
--- /dev/null
+++ b/data/research-evidence/e256a1772cde0b97438331ca.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:04:45.1339132Z",
+  "content_sha256": "08c6cb6f42a9fc5001cde812485abfab1455b796e740c986e3846d27c476abfd",
+  "result": {
+    "title": "Ransomware Protection and Response | CSRC",
+    "url": "https://csrc.nist.gov/Projects/ransomware-protection-and-response",
+    "snippet": "Thanks for helping shape our ransomware guidance! We've published our final version of NIST IR 8374 Revision 1, Ransomware Risk Management: A Cybersecurity Framework Profile. It reflects changes made to the Cybersecurity Framework (CSF) from CSF 1.1 to CSF 2.0 which identifies security objectives that support managing, detecting, responding to, and recovering from ransomware events. NIST is ...",
+    "content": "Ransomware Protection and Response | CSRC\n\nYou are viewing this page in an unauthorized frame window.\n\nThis is a potential security issue, you are being redirected to https://csrc.nist.gov .\n\nOfficial websites use .gov\n.gov website belongs to an official government\norganization in the United States.\n\nSecure .gov websites use HTTPS\nlock (\n\n) or https:// means you’ve safely connected to\nthe .gov website. Share sensitive information only on official,\nsecure websites.\n\nInformation Technology Laboratory\n\nComputer Security Resource Center\n\nProjects\n\nRansomware Protection and Response\n\nShare to Facebook\nShare to X\nShare to LinkedIn\nShare ia Email\n\nProject Links\n\nOverview\n\nNews \u0026 Updates\n\nPublications\n\nOverview\n\nThanks for helping shape our ransomware guidance!  We've published our final version of NIST IR 8374 Revision 1,  Ransomware Risk Management: A Cybersecurity Framework Profile . It reflects changes made to the Cybersecurity Framework (CSF) from CSF 1.1 to CSF 2.0 which identifies security objectives that support managing, detecting, responding to, and recovering from ransomware events. NIST is still actively seeking feedback on resources that can help communities prepare for and recover from ransomware attacks. Please reach out to us at  [email protected]\n\nNIST has also previously published the  Quick Start Guide : Getting Started with Cybersecurity Risk Management | Ransomware .\n\nOur  resources  on tips and tactics for  preparing your organization  for ransomware attacks are here!\n\nVideo: Protecting Your Small Business--Ransomware\n\nFact sheet: How do I stay prepared?\n\nInfographic: Quick steps you can take now\n\nVideo: Tips to Help Your Company Protect Against Ransomware Attacks\n\nRansomware is a type of malicious attack where attackers encrypt an organization’s data and demand payment to restore access.\n\nHere’s an example of how a ransomware attack can occur:\n\nA user is tricked into clicking on a malicious link that downloads a file from an external website.\n\nThe user executes the file, not knowing that the file is ransomware.\n\nThe ransomware takes advantage of vulnerabilities in the user’s computer and other computers to propagate throughout the organization.\n\nThe ransomware simultaneously encrypts files on all the computers, then displays messages on their screens demanding payment in exchange for decrypting the files.\n\nRansomware disrupts or halts an organization’s operations and poses a dilemma for management: does the organization pay the ransom and hope that the attackers keep their word about restoring access, or does the organization not pay the ransom and restore operations themselves?\n\nFortunately, organizations can take steps to prepare for ransomware attacks. This includes protecting data and devices from ransomware and being ready to respond to any ransomware attacks that succeed.\n\nHere are NIST resources that can help you with ransomware protection and response.\n\nMy organization needs to...\n\nGet started with ransomware protection or response efforts\n\nNew!  Tips and tactics for preparing your organization for ransomware attacks:\n\nFact sheet: How do I stay prepared?\n\nInfographic: Quick steps you can take now\n\nVideo: Tips to Help Your Company Protect Against Ransomware Attacks\n\nCybersecurity resources for small businesses :\n\nSmall Business Cybersecurity Corner\n\nVideo: Protecting Your Small Business--Ransomware\n\nProtecting the security of business information and devices :\n\nSecuring Data \u0026 Devices\n\nPreventing and recovering from cybersecurity incidents :\n\nResponding to a Cyber Incident\n\nImprove our protection against ransomware attacks\n\nIn-depth information on protecting data against ransomware:\n\nData Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events   (SP 1800-25)\n\nPreventing ransomware and other malware incidents :\n\nGuide to Malware Incident Prevention and Handling for Desktops and Laptops  (SP 800-83 Rev. 1)\n\nImproving the security of telework , remote access , and bring-your-own-device (BYOD) technologies:\n\nTelework: Working Anytime, Anywhere\n\nGuide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security   (SP 800-46 Rev. 2)\n\nPatching software to eliminate vulnerabilities:\n\nGuide to Enterprise Patch Management Technologies  (SP 800-40 Rev. 3)\n\nCritical Cybersecurity Hygiene: Patching the Enterprise project\n\nUsing application control technology to prevent ransomware execution:\n\nGuide to Application Whitelisting  (SP 800-167)\n\nFinding low-level guidance on securely configuring software to eliminate vulnerabilities:\n\nNational Checklist Program\n\nGetting the latest information on known vulnerabilities :\n\nNational Vulnerability Database\n\nImprove our ability to respond to ransomware incidents\n\nIn-depth information on detecting and responding to ransomware attacks:\n\nData Integrity: Detecting and Responding to Ransomware and Other Destructive Events  (SP 1800-26)\n\nIn-depth information on recovering from ransomware attacks:\n\nData Integrity: Recovering from Ransomware and Other Destructive Events  (SP 1800-11)\n\nPlanning for cybersecurity event recovery :\n\nGuide for Cybersecurity Event Recovery  (SP 800-184)\n\nContingency planning for restoring operations after a disruption caused by ransomware:\n\nContingency Planning Guide for Federal Information Systems  (SP 800-34 Rev. 1)\n\nHandling ransomware and other malware incidents :\n\nGuide to Malware Incident Prevention and Handling for Desktops and Laptops  (SP 800-83 Rev. 1)\n\nHandling cybersecurity incidents in general:\n\nComputer Security Incident Handling Guide  (SP 800-61 Rev. 2)\n\nProject Links\n\nOverview\n\nNews \u0026 Updates\n\nPublications\n\nGroup\n\nApplied Cybersecurity Division\n\nTopics\n\nSecurity and Privacy:\nincident response , ransomware , vulnerability management\n\nRelated Projects\n\nData Security | NCCoE\n\nIncident Response\n\nSmall Business Cybersecurity Corner\n\nGroup\n\nApplied Cybersecurity Division\n\nTopics\n\nSecurity and Privacy:\nincident response , ransomware , vulnerability management\n\nRelated Projects\n\nData Security | NCCoE\n\nIncident Response\n\nSmall Business Cybersecurity Corner\n\nCreated May 04, 2021 , Updated June 11, 2026",
+    "content_type": "text/html",
+    "query": "Ransomware Prevention \u0026 Detection aktuelle offizielle Dokumentation Version Support",
+    "language": "en-US",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.495,
+    "source_quality": "authoritative",
+    "source_quality_score": 0.95,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/ebcb1a54077f9483be3ad2c3.json b/data/research-evidence/ebcb1a54077f9483be3ad2c3.json
new file mode 100644
index 0000000..ed2ed58
--- /dev/null
+++ b/data/research-evidence/ebcb1a54077f9483be3ad2c3.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:12:23.9352803Z",
+  "content_sha256": "7c939c773e5ec3a0ef4f708e9ffde61dafa9aac4afa4d30793d2e078cd6bd9e1",
+  "result": {
+    "title": "Sicherheit  |  Security  |  Google Cloud Documentation",
+    "url": "https://docs.cloud.google.com/docs/security?hl=de",
+    "snippet": "Documentation and resources for helping organizations secure their compute environments, protect data, and comply with regulations using Google Cloud products.",
+    "content": "Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.\n\nHome\n\nDocumentation\n\nSecurity\n\nJetzt kostenlos starten\n\nProof of Concept mit einem Guthaben in Höhe von 300 $ starten\n\nNutzen Sie unsere neuesten generativen KI-Modelle und Tools für die Entwicklung.\n\nSie können mehr als 20 beliebte Produkte wie Compute Engine und KIAI APIs kostenlos nutzen.\n\nKeine automatischen Abbuchungen, keine Verpflichtung.\n\nAngebote für kostenlose Produkte ansehen\n\nMehr als 20 Produkte immer kostenlos nutzen.\n\nSie haben Zugriff auf mehr als 20 kostenlose Produkte für gängige Anwendungsfälle, darunter KI-APIs, VMs, Data Warehouses und mehr.\n\ndescription\n\nGoogle Cloud Übersicht über die Sicherheit\n\nHier erfahren Sie mehr über die physischen, administrativen und technischen Kontrollen, die wir zum Schutz der Daten Ihrer Organisation verwenden.\n\ndescription\n\nIAM-Übersicht\n\nInformationen zur Funktionsweise von IAM in Google Cloud und zur Verwaltung des Zugriffs\n\ndescription\n\nFunktionsweise von Organisationsrichtlinien\n\nInformationen zu Organisationsrichtlinien und -einschränkungen\n\ndescription\n\nAuthentifizierungsmethoden\n\nLernen Sie die wichtigsten Authentifizierungsmethoden und Konzepte zur Bestätigung der Identität eines Nutzers kennen.\n\ndescription\n\nSicherheitsdesign der Infrastruktur\n\nErfahren Sie mehr über die Sicherheitsfunktionen in der technischen Infrastruktur von Google.\n\ndescription\n\nZugriff auf ein Projekt widerrufen\n\nEntfernen Sie den Zugriff eines Nutzers auf ein Google Cloud -Projekt.\n\naccount_tree\n\nBlueprint für Unternehmensgrundlagen\n\nPlanen Sie die Bereitstellung grundlegender Ressourcen in Google Cloud mithilfe von Best Practices. open_in_new\n\nschool\n\nLernpfad für Security Engineers\n\nLernen Sie, wie Sie die Sicherheitsinfrastruktur Ihrer Organisation entwickeln, implementieren und überwachen. open_in_new\n\ncloud\n\nCloud Security Podcast\n\nBranchenexperten sprechen über einige der interessantesten Bereiche der Cloud-Sicherheit. open_in_new\n\ncloud\n\nBlog zur Cloud-Sicherheit\n\nLesen Sie die neuesten Blogbeiträge zu Google Cloud Sicherheitsvorteilen und Kundenberichten. open_in_new\n\nschool\n\nGoogle SIEM- und SOAR-Lernpfad\n\nLernen Sie, wie Sie mit SIEM- und SOAR-Tools Daten parsen, Regeln erstellen, Playbooks entwickeln und auf Vorfälle reagieren. open_in_new\n\nschool\n\nDevSecOps-Lernpfad\n\nLernen Sie, wie Sie die Sicherheitsinfrastruktur Ihrer Organisation entwickeln, implementieren und überwachen. open_in_new\n\nSicherheitsabläufe\n\nSicherheitslücken, Bedrohungen und Fehlkonfigurationen erkennen.\n\nAdvisory Notifications\n\nErhalten Sie zielgerichtete, zeitnahe und konforme Mitteilungen zu Sicherheits- und Datenschutzereignissen in der Google Cloud Console.\n\nscience\n\nCyber Insurance Hub\n\nBewerten Sie den Sicherheitsstatus Ihrer Organisation und wenden Sie sich an Versicherungspartner, um eine exklusive Cyberversicherung und personalisierte Preise zu erhalten.\n\nGoogle Security Operations\n\nMit SIEM- und SOAR-Technologie können Sie Cyberbedrohungen erkennen, untersuchen und darauf reagieren. Signale extrahieren, um Bedrohungen zu erkennen und die Reaktion zu automatisieren.\n\nGoogle Threat Intelligence\n\nMit einem unvergleichlichen Überblick über die globale Bedrohungslage erfahren Sie, wer Ihre Organisation im Visier hat.\n\nModel Armor\n\nVerbessern Sie die Sicherheit von KI-Anwendungen, indem Sie LLM-Prompts und ‑Antworten prüfen.\n\nSecurity Command Center\n\nAngriffsflächen und Sicherheitsmaßnahmen für Ihre Daten verstehen\n\nZugriffsverwaltung\n\nStellen Sie einheitliche, föderierte Identitäten mit den geringsten Berechtigungen bereit, um das Risiko von Datenpannen und anderen Sicherheitsvorfällen zu verringern.\n\nAccess Context Manager\n\nOrganisationsadministratoren ermöglichen, eine differenzierte, attributbasierte Zugriffssteuerung für Projekte und Ressourcen in Google Cloudzu definieren.\n\nCertificate Authority Service\n\nDie Bereitstellung, Verwaltung und Sicherheit privater Zertifizierungsstellen (CAs) vereinfachen, automatisieren und anpassen.\n\nIdentitäts- und Zugriffsverwaltung\n\nDetailgenaue Identitäts- und Zugriffsverwaltung für Google Cloud Ressourcen einrichten.\n\ndescription\n\nRecommender der Identity and Access Management (IAM)\n\nErmitteln Sie übermäßige Berechtigungen mithilfe von Richtlinienstatistiken.\n\naccount_tree\n\nIdentitäts- und Zugriffsverwaltung planen\n\nPlanen Sie Ihr Design so, dass den richtigen Personen aus den richtigen Gründen Zugriff auf die richtigen Ressourcen gewährt wird. open_in_new\n\nschool\n\nZugriffssteuerung und Identitätssicherung\n\nLernen Sie die grundlegenden Features der Cloud-Sicherheit in Bezug auf Zugriffsverwaltung und Identität kennen. open_in_new\n\naccount_tree\n\nPlanungsressourcen für Sicherheit und IAM\n\nPlanen Sie Ihren Ansatz mit Ressourcen des Architecture Center für eine Vielzahl von Themen zur Identitäts- und Zugriffsverwaltung. open_in_new\n\nAnwendungssicherheit\n\nSchützen Sie Ihre Arbeitslasten vor Denial-of-Service-Angriffen, Angriffen auf Webanwendungen und anderen Sicherheitsbedrohungen.\n\nBinärautorisierung\n\nNur vertrauenswürdige Container in Google Kubernetes Engine bereitstellen\n\nZertifikatmanager\n\nKaufen und managen Sie TLS-Zertifikate (SSL) für die Verwendung mit Cloud Load Balancing und Media CDN.\n\nIdentity-Aware Proxy (IAP)\n\nVerwalten Sie den Zugriff auf Anwendungen, die in der App Engine-Standardumgebung, der flexiblen App Engine-Umgebung, in Compute Engine und GKE ausgeführt werden.\n\nFraud Defense\n\nDie Website Ihrer Organisation vor Betrug, Spam und Missbrauch schützen\n\nSicherer Web-Proxy\n\nMigrieren Sie zu Google Cloud , während Sie die vorhandenen Sicherheitsrichtlinien und Anforderungen Ihrer Organisation für ausgehenden Web-Traffic beibehalten.\n\nWeb Risk\n\nBösartige URLs auf der Website Ihrer Organisation und in Clientanwendungen ermitteln\n\nGoogle Cloud Armor\n\nHilft dabei, Ihre Dienste vor DoS- und Webangriffen zu schützen.\n\nCloud Load Balancing\n\nApp-Zugriff mit leistungsfähigem Load-Balancing skalieren und verteilen\n\ndescription\n\nBösartige URLs in Web Risk erkennen\n\nFolgen Sie der Anleitung, um die Beispielanwendung zu installieren und auszuführen, um schädliche URLs in einer Go-Umgebung zu erkennen.\n\nAuditing, Monitoring und Logging\n\nSie können aggregierte Plattform- und Systemlogs Ihrer Organisation mit einer umfassenden Lösung erfassen, speichern, analysieren und überwachen.\n\nAccess Transparency\n\nDurch echtzeitnahe Logs mehr Einblick in den Cloud-Anbieter Ihrer Organisation\n\nAudit Manager\n\nBietet Bewertungen zur Einhaltung von Compliance-Anforderungen.\n\nCloud-Audit-Logs\n\nInformationen zu allen Nutzeraktivitäten (wer, was, wann, wo) in Google Clouderhalten.\n\nCloud-Anbieterzugriffsverwaltung\n\nVerwenden Sie diese Produktgruppe, um schrittweise mehr Transparenz und Kontrolle über den Zugriff auf Ihre in Google Cloudgespeicherten Inhalte zu erhalten.\n\nEndpunktprüfung\n\nErstellt ein Inventar von Geräten mit Chrome OS und Chrome-Browser, die auf die Daten Ihrer Organisation zugreifen.\n\nPersonalized Service Health\n\nErkennen Sie Google Cloud Dienstunterbrechungen, die für Ihre Projekte relevant sind, damit Sie diese effizient verwalten und darauf reagieren können.\n\nEinheitliche Wartung\n\nGeplante Wartung für Google Cloud Dienste verwalten.\n\nCloud Logging\n\nLogdaten und Ereignisse aus Google Cloud und AWS speichern, suchen, analysieren, überwachen und Benachrichtigungen dazu ausgeben.\n\nCloud Monitoring\n\nErhalten Sie Einblick in die Leistung, die Verfügbarkeit und den Gesamtstatus cloudbasierter Anwendungen.\n\nNetwork Intelligence Center\n\nEine einzige Konsole für Netzwerkmonitoring, ‑verifizierung und ‑optimierung verwenden.\n\nCloud Governance\n\nVerwalten Sie Ihre Ressourcen sicher und konform mit Transparenz und Kontrolle über Ihre Cloud-Umgebung.\n\nAssured Workloads\n\nSichern Sie Ihre Arbeitslasten und beschleunigen Sie die Ausführung konformer Arbeitslasten in Google Cloud.\n\nCloud Asset Inventory\n\nProjekt- und dienstübergreifendes Anzeigen, Überwachen und Analysieren von Google Cloud - und Anthos-Assets\n\nOrganisationsrichtliniendienst\n\nZentralisierte und programmatische Kontrolle über die Cloud-Ressourcen Ihrer Organisation.\n\nPolicy Intelligence\n\nMithilfe von Richtlinien können Sie Ressourcen steuern und den Zugriff verwalten, um Ihre Sicherheitskonfiguration proaktiv zu verbessern.\n\nResource Manager\n\nZentralisierte und programmatische Kontrolle über die Cloud-Ressourcen Ihrer Organisation.\n\ninfo\n\nRisikosicherheitsprogramm\n\nReduzieren Sie das Sicherheitsrisiko und erhalten Sie Zugang zu exklusiven Cyberversicherungspolicen, die auf Google Cloud -Kunden zugeschnitten sind.\n\nDatensicherheit\n\nÜbernimmt die Schlüsselverwaltung für Secrets, Laufwerke, Images und Logaufbewahrung.\n\nAPI-Schlüssel\n\nVerwenden Sie die Schlüsselverwaltung für Secrets, Laufwerke, Images und Logaufbewahrung.\n\nCloud External Key Manager\n\nDie Position und Verteilung Ihrer extern verwalteten Schlüssel bestimmen.\n\nCloud HSM\n\nSchutz für kryptografische Schlüssel durch vollständig verwalteten Dienst für Hardwaresicherheitsmodule\n\nCloud Key Management Service\n\nVerschlüsselungsschlüssel in Google Cloudverwalten.\n\nConfidential Computing\n\nSchützen Sie aktive Daten mit Confidential VM, Confidential GKE, Confidential Dataflow, Confidential Managed Service for Apache Spark und Confidential Space.\n\nSecret Manager\n\nAPI-Schlüssel, Passwörter, Zertifikate und andere sensible Daten speichern\n\nSchutz sensibler Daten\n\nSensible Daten ermitteln und entfernen\n\nblock\n\nData Catalog\n\nDaten mit einem vollständig verwalteten, skalierbaren Dienst für die Datenermittlung und Metadatenverwaltung finden und analysieren. (verworfen)\n\nNetzwerksicherheit\n\nNetzwerkressourcen zentral verwalten, eine skalierbare Segmentierung für verschiedene Sicherheitszonen einrichten und Netzwerkbedrohungen erkennen.\n\nChrome Enterprise Premium\n\nVerwenden Sie eine Zero-Trust-Lösung, die sicheren Zugriff mit integriertem Schutz vor Bedrohungen und Daten ermöglicht.\n\nSpectrum Access System\n\nVerwalten Sie die kabellose Kommunikation von Geräten, die im CBRS-Band (Citizens Broadband Radio Spectrum) übertragen werden.\n\nGoogle Cloud Armor\n\nHilft dabei, Ihre Dienste vor DoS- und Webangriffen zu schützen.\n\nCloud Next Generation Firewall\n\nImplementieren Sie erweiterte Schutzfunktionen und umfassende Abdeckung, um Ihre Google Cloud -Arbeitslasten vor internen und externen Angriffen zu schützen.\n\nIdentity-Aware Proxy (IAP)\n\nZugriff auf Anwendungen und VMs anhand von Identität und Kontext beschränken\n\nCloud Interconnect\n\nVerbinden Sie Ihre Infrastruktur nach Ihren Wünschen von überall mit Google Cloud .\n\nCloud Intrusion Detection System\n\nSie erhalten Benachrichtigungen, wenn Cloud Intrusion Detection System schädliche Aktivitäten erkennt.\n\nCloud VPN\n\nVerbinden Sie Ihre Infrastruktur nach Ihren Wünschen von überall mit Google Cloud .\n\nVPC Service Controls\n\nSensible Daten in Google Cloud -Diensten mit Sicherheitsbereichen schützen\n\nÄhnliche Produkte, Leitfäden und Websites\n\nGemini Cloud Assist für Sicherheit und Compliance\n\ndescription\n\nDatenschutz und Privatsphäre\n\nHilfe zu Secrets und Cloud KMS-Schlüsseln\n\ndescription\n\nEmpfehlung für eine behördliche Kontrolle erhalten\n\nEmpfehlungen für das zu verwendende Assured Workloads-Kontrollpaket erhalten.\n\nCompliance und Datenschutz\n\ninfo\n\nCompliance Center\n\nSehen Sie sich Zertifizierungen, Dokumentationen und Prüfungen durch Dritte an, um Ihre Compliance zu unterstützen.\n\ninfo\n\nDatenschutz-Center\n\nHier erfahren Sie, wie wir die Daten der Kunden von Google Cloud und Google Workspace schützen.\n\nAssured Workloads\n\nSichern Sie Ihre Arbeitslasten und beschleunigen Sie die Ausführung konformer Arbeitslasten.\n\nhelp\n\nSupport bei Benachrichtigungen zu Richtlinienverstößen\n\nAntworten auf häufig gestellte Fragen zu Google Cloud -Richtlinienverstößen ansehen open_in_new\n\ninfo\n\nVerfügbarkeit des Datenstandortdienstes\n\nListe der Dienste anzeigen, die für den Datenspeicherort konfiguriert werden können. open_in_new\n\nKontrolle der Datenhoheit durch Partner\n\nErfüllen Sie die Anforderungen an die digitale Souveränität für Google Cloud von Partnern.\n\nSichere Softwarelieferkette\n\nSicherheit der Softwarelieferkette\n\nVerwenden Sie ein modulares Set von Google Cloud Produkten, um Ihre Softwarelieferkette zu schützen.\n\nArtifact Registry\n\nSpeicherung, Verwaltung und Sicherung von Container-Images und Sprachpaketen\n\nArtefaktanalyse\n\nAnalyse der Softwarezusammensetzung, das Speichern und Abrufen von Metadaten.\n\nAssured Open Source Software\n\nStellen Sie Unternehmensnutzern von Open-Source-Software vertrauenswürdige OSS-Pakete zur Verfügung.\n\nCloud Build\n\nContainer in der Google Cloud Infrastruktur kontinuierlich entwickeln, testen und bereitstellen.\n\nBinärautorisierung\n\nNur vertrauenswürdige Container in Google Kubernetes Engine bereitstellen\n\nAuthentifizierung und Identität\n\ninfo\n\nAuthentifizierungsmethoden\n\nGrundlagen der Authentifizierungsmethoden, Konzepte für Google Cloud -Dienste und Hilfe bei der Implementierung oder Fehlerbehebung.\n\nCloud Identity\n\nNutzeridentitäten, Geräte und Anwendungen einfach über eine Konsole verwalten\n\nIdentity Platform\n\nIdentitäts- und Zugriffsverwaltung auf Google-Niveau für Ihre Apps\n\nManaged Service for Microsoft Active Directory\n\nNutzen Sie einen hochverfügbaren, gehärteten Dienst, auf dem ein echtes Microsoft Active Directory (AD) läuft.\n\nTitan-Sicherheitsschlüssel\n\nBietet eine phishingresistente zweite Authentifizierungsstufe für hochrangige Nutzer. open_in_new\n\nschool\n\nZugriffssteuerung und Identitätssicherung\n\nLernen Sie die grundlegenden Features der Cloud-Sicherheit in Bezug auf Zugriffsverwaltung und Identität kennen. open_in_new\n\nWeitere Produkte und Ressourcen\n\nBackup- und DR-Dienst\n\nEin verwalteter Sicherungs- und Notfallwiederherstellungsdienst für den zentralisierten und anwendungskonsistenten Datenschutz in Google Cloud.\n\nAnti Money Laundering AI\n\nGenauigkeit und Effizienz der Erkennung von Geldwäschen erhöhen\n\nNetzwerkdienststufen\n\nOptimieren Sie die Verbindungen zwischen Systemen im I",
+    "content_type": "text/html",
+    "query": "GCP Cloud Storage Security – härten und sicher betreiben aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "primary",
+    "source_quality_score": 0.88,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/ed5d798b31963d39dcde384b.json b/data/research-evidence/ed5d798b31963d39dcde384b.json
new file mode 100644
index 0000000..7ed968c
--- /dev/null
+++ b/data/research-evidence/ed5d798b31963d39dcde384b.json
@@ -0,0 +1,25 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:22:06.2752858Z",
+  "content_sha256": "6359bdb82bfa08a0feb2b73f73db634463101d57fa9ad9da18ad3ec38deca87d",
+  "result": {
+    "title": "What is prototype pollution? | Web Security Academy",
+    "url": "https://portswigger.net/web-security/prototype-pollution",
+    "snippet": "What is prototype pollution? Prototype pollution is a JavaScript vulnerability that enables an attacker to add arbitrary properties to global object prototypes, which may then be inherited by user-defined objects.",
+    "content": "Web Security Academy\n\nPrototype pollution\n\nWhat is prototype pollution?\n\nPrototype pollution is a JavaScript vulnerability that enables an attacker to add arbitrary properties to global object prototypes, which may then be inherited by user-defined objects.\n\nAlthough prototype pollution is often unexploitable as a standalone vulnerability, it lets an attacker control properties of objects that would otherwise be inaccessible. If the application subsequently handles an attacker-controlled property in an unsafe way, this can potentially be chained with other vulnerabilities. In client-side JavaScript, this commonly leads to DOM XSS , while server-side prototype pollution can even result in remote code execution.\n\nIf you're unfamiliar with how prototypes and inheritance work in JavaScript, we recommend reading the following overview before continuing.\n\nJavaScript prototypes and inheritance\n\nLabs\n\nIf you're already familiar with prototype pollution and just want to practice on a series of deliberately vulnerable sites, check out the link below for an overview of all labs in this topic.\n\nLABS View all prototype pollution labs\n\nHow do prototype pollution vulnerabilities arise?\n\nPrototype pollution vulnerabilities typically arise when a JavaScript function recursively merges an object containing user-controllable properties into an existing object, without first sanitizing the keys. This can allow an attacker to inject a property with a key like __proto__ , along with arbitrary nested properties.\n\nDue to the special meaning of __proto__ in a JavaScript context, the merge operation may assign the nested properties to the object's prototype instead of the target object itself. As a result, the attacker can pollute the prototype with properties containing harmful values, which may subsequently be used by the application in a dangerous way.\n\nIt's possible to pollute any prototype object, but this most commonly occurs with the built-in global Object.prototype .\n\nSuccessful exploitation of prototype pollution requires the following key components:\n\nA prototype pollution source - This is any input that enables you to poison prototype objects with arbitrary properties.\n\nA sink - In other words, a JavaScript function or DOM element that enables arbitrary code execution.\n\nAn exploitable gadget - This is any property that is passed into a sink without proper filtering or sanitization.\n\nPrototype pollution sources\n\nA prototype pollution source is any user-controllable input that enables you to add arbitrary properties to prototype objects. The most common sources are as follows:\n\nThe URL via either the query or fragment string (hash)\n\nJSON-based input\n\nWeb messages\n\nPrototype pollution via the URL\n\nConsider the following URL, which contains an attacker-constructed query string:\n\nhttps://vulnerable-website.com/?__proto__[evilProperty]=payload\n\nWhen breaking the query string down into key:value pairs, a URL parser may interpret __proto__ as an arbitrary string. But let's look at what happens if these keys and values are subsequently merged into an existing object as properties.\n\nYou might think that the __proto__ property, along with its nested evilProperty , will just be added to the target object as follows:\n\nexistingProperty1: 'foo',\nexistingProperty2: 'bar',\n__proto__: {\nevilProperty: 'payload'\n\nHowever, this isn't the case. At some point, the recursive merge operation may assign the value of evilProperty using a statement equivalent to the following:\n\ntargetObject.__proto__.evilProperty = 'payload';\n\nDuring this assignment, the JavaScript engine treats __proto__ as a getter for the prototype. As a result, evilProperty is assigned to the returned prototype object rather than the target object itself. Assuming that the target object uses the default Object.prototype , all objects in the JavaScript runtime will now inherit evilProperty , unless they already have a property of their own with a matching key.\n\nIn practice, injecting a property called evilProperty is unlikely to have any effect. However, an attacker can use the same technique to pollute the prototype with properties that are used by the application, or any imported libraries.\n\nPrototype pollution via JSON input\n\nUser-controllable objects are often derived from a JSON string using the JSON.parse() method. Interestingly, JSON.parse() also treats any key in the JSON object as an arbitrary string, including things like __proto__ . This provides another potential vector for prototype pollution.\n\nLet's say an attacker injects the following malicious JSON, for example, via a web message:\n\n\"__proto__\": {\n\"evilProperty\": \"payload\"\n\nIf this is converted into a JavaScript object via the JSON.parse() method, the resulting object will in fact have a property with the key __proto__ :\n\nconst objectLiteral = {__proto__: {evilProperty: 'payload'}};\nconst objectFromJson = JSON.parse('{\"__proto__\": {\"evilProperty\": \"payload\"}}');\n\nobjectLiteral.hasOwnProperty('__proto__'); // false\nobjectFromJson.hasOwnProperty('__proto__'); // true\n\nIf the object created via JSON.parse() is subsequently merged into an existing object without proper key sanitization, this will also lead to prototype pollution during the assignment, as we saw in the previous URL-based example .\n\nPrototype pollution sinks\n\nA prototype pollution sink is essentially just a JavaScript function or DOM element that you're able to access via prototype pollution, which enables you to execute arbitrary JavaScript or system commands. We've covered some client-side sinks extensively in our topic on DOM XSS .\n\nAs prototype pollution lets you control properties that would otherwise be inaccessible, this potentially enables you to reach a number of additional sinks within the target application. Developers who are unfamiliar with prototype pollution may wrongly assume that these properties are not user controllable, which means there may only be minimal filtering or sanitization in place.\n\nPrototype pollution gadgets\n\nA gadget provides a means of turning the prototype pollution vulnerability into an actual exploit. This is any property that is:\n\nUsed by the application in an unsafe way, such as passing it to a sink without proper filtering or sanitization.\n\nAttacker-controllable via prototype pollution. In other words, the object must be able to inherit a malicious version of the property added to the prototype by an attacker.\n\nA property cannot be a gadget if it is defined directly on the object itself. In this case, the object's own version of the property takes precedence over any malicious version you're able to add to the prototype. Robust websites may also explicitly set the prototype of the object to null , which ensures that it doesn't inherit any properties at all.\n\nExample of a prototype pollution gadget\n\nMany JavaScript libraries accept an object that developers can use to set different configuration options. The library code checks whether the developer has explicitly added certain properties to this object and, if so, adjusts the configuration accordingly. If a property that represents a particular option is not present, a predefined default option is often used instead. A simplified example may look something like this:\n\nlet transport_url = config.transport_url || defaults.transport_url;\n\nNow imagine the library code uses this transport_url to add a script reference to the page:\n\nlet script = document.createElement('script');\nscript.src = `${transport_url}/example.js`;\ndocument.body.appendChild(script);\n\nIf the website's developers haven't set a transport_url property on their config object, this is a potential gadget. In cases where an attacker is able to pollute the global Object.prototype with their own transport_url property, this will be inherited by the config object and, therefore, set as the src for this script to a domain of the attacker's choosing.\n\nIf the prototype can be polluted via a query parameter, for example, the attacker would simply have to induce a victim to visit a specially crafted URL to cause their browser to import a malicious JavaScript file from an attacker-controlled domain:\n\nhttps://vulnerable-website.com/?__proto__[transport_url]=//evil-user.net\n\nBy providing a data: URL, an attacker could also directly embed an XSS payload within the query string as follows:\n\nhttps://vulnerable-website.com/?__proto__[transport_url]=data:,alert(1);//\n\nNote that the trailing // in this example is simply to comment out the hardcoded /example.js suffix.\n\nWhat next?\n\nNow that you're familiar with the concepts behind prototype pollution, let's take a look at how you can find these vulnerabilities in real-world applications:\n\nLABS Client-side prototype pollution vulnerabilities\n\nLABS Server-side prototype pollution vulnerabilities\n\nPreventing prototype pollution vulnerabilities\n\nFind prototype pollution vulnerabilities using Burp Suite\n\nTry for free",
+    "content_type": "text/html",
+    "query": "Prototype Pollution Schutz – forensisch untersuchen, präventiv absichern, detektiv überwachen aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "actionable": true,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/ee998c269e4bb1c0912d5ed6.json b/data/research-evidence/ee998c269e4bb1c0912d5ed6.json
new file mode 100644
index 0000000..bb76258
--- /dev/null
+++ b/data/research-evidence/ee998c269e4bb1c0912d5ed6.json
@@ -0,0 +1,25 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:44:09.650799Z",
+  "content_sha256": "d905568fc53b4430450c1b7e8190f771e1a4528dfac590135dffc8264f766d46",
+  "result": {
+    "title": "How to setup VNC on Wayland (Sway) + SDDM for unattended access · GitHub",
+    "url": "https://gist.github.com/itsfolf/1029f674eca3783f2d123521ff6a4ceb",
+    "snippet": "Install both x11vnc and wayvnc. Since SDDM runs under X11 we will be running two separate vnc services, each on it's own port. x11vnc will take care of SDDM, while wayvnc will handle our desktop session. Both services are set up with SSL encryption.",
+    "content": "Instantly share code, notes, and snippets.\n\nitsfolf / vnc.md\n\nLast active\nFebruary 26, 2026 18:24\n\nShow Gist options\n\nDownload ZIP\n\nStar\n\n( 6 )\n\nYou must be signed in to star a gist\n\nFork\n\n( 0 )\n\nYou must be signed in to fork a gist\n\nEmbed\n\nSelect an option\n\nEmbed\nEmbed this gist in your website.\n\nShare\nCopy sharable link for this gist.\n\nClone via HTTPS\nClone using the web URL.\n\nNo results found\n\nLearn more about clone URLs\n\nClone this repository at \u0026lt;script src=\u0026quot;https://gist.github.com/itsfolf/1029f674eca3783f2d123521ff6a4ceb.js\u0026quot;\u0026gt;\u0026lt;/script\u0026gt;\n\nSave itsfolf/1029f674eca3783f2d123521ff6a4ceb to your computer and use it in GitHub Desktop.\n\nEmbed\n\nSelect an option\n\nEmbed\nEmbed this gist in your website.\n\nShare\nCopy sharable link for this gist.\n\nClone via HTTPS\nClone using the web URL.\n\nNo results found\n\nLearn more about clone URLs\n\nClone this repository at \u0026lt;script src=\u0026quot;https://gist.github.com/itsfolf/1029f674eca3783f2d123521ff6a4ceb.js\u0026quot;\u0026gt;\u0026lt;/script\u0026gt;\n\nSave itsfolf/1029f674eca3783f2d123521ff6a4ceb to your computer and use it in GitHub Desktop.\n\nDownload ZIP\n\nHow to setup VNC on Wayland (Sway) + SDDM for unattended access\n\nRaw\n\nvnc.md\n\nHow to setup VNC on Wayland (Sway) + SDDM for unattended access\n\n1. Install both x11vnc and wayvnc\n\nSince SDDM runs under X11 we will be running two separate vnc services, each on it's own port. x11vnc will take care of SDDM, while wayvnc will handle our desktop session. Both services are set up with SSL encryption.\n\nWhile it's technically possible to run a single service with some scripting magic to switch between the two, this was by far the easiest and most reliable way.\n\n2. Set up x11vnc\n\nSet a password\n\n❯ sudo x11vnc -storepasswd [YOUR VNC PASSWORD] /etc/x11vnc.passwd\n\nCreate systemd service\n\nTo run x11vnc on system start, we need to update the service with our authentication settings, create a file under /etc/systemd/system/x11vnc.service.d/override.conf with the following content:\n\n# /etc/systemd/system/x11vnc.service.d/override.conf\n[Service]\nExecStart=\nExecStart=/bin/bash -c \"/usr/bin/x11vnc -auth /var/run/sddm/* -display :0 -forever -noxdamage -repeat -ssl -shared -rfbauth /etc/x11vnc.passwd\"\nRestart=always\nRestartSec=2\n\n[Install]\nWantedBy=multi-user.target\n\n⚠️ It's important not to set the -loop flag so that restarting is handled by systemd, this ensures that x11vnc is always started with the right MIT-MAGIC-COOKIE from sddm ( -auth ) which changes on each session.\n\nEnable x11vnc service\n\n❯ sudo systemctl enable --now x11vnc\n\n3. Set up wayvnc\n\nGenerate certificates\n\nThese can be anywhere you want, I recommend placing them on the wayvnc config directory ~/.config/wayvnc/\n\nopenssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \\\n-keyout key.pem -out cert.pem -subj /CN=localhost \\\n-addext subjectAltName=DNS:localhost,DNS:localhost,IP:127.0.0.1\n\nWayvnc config\n\nCreate a file at $HOME/.config/wayvnc/config ( Replace $USER with your username )\n\naddress =0.0.0.0\nport =5901 # By default, x11vnc runs on port 5900, so we'll be starting wayvnc on 5901\nenable_auth =true\nusername =folf\npassword =*********\nprivate_key_file =/home/$USER/.config/wayvnc/key.pem\ncertificate_file =/home/$USER/.config/wayvnc/cert.pem\n\nEnable the wayvnc service\n\n❯ systemctl enable --user --now wayvnc\n\nThat's it. You will need to set up two separate connections on your client (port 5900 and 5901). The x11vnc connection will show a black screen whenever a session is active.\nIt's safe to directly port forward these services, as both are encrypted and password protected, but connecting through an SSH tunnel is still recommended.\n\nSources\n\nhttps://wiki.archlinux.org/title/x11vnc\nhttps://github.com/any1/wayvnc\nhttps://askubuntu.com/questions/1105598/x11vnc-sddm-systemd-service\n\nTwig6943\n\ncommented\n\nFeb 26, 2026\n\nCopy link\n\nCopy Markdown\n\n@itsfolf wouldnt it make more sense to just set sddm config to use wayland?\n\nitsfolf\n\ncommented\n\nFeb 26, 2026\n\nCopy link\n\nCopy Markdown\n\nAuthor\n\n@itsfolf wouldnt it make more sense to just set sddm config to use wayland?\n\nI don't think that was possible in 2022\n\nSign up for free\nto join this conversation on GitHub .\nAlready have an account?\nSign in to comment",
+    "content_type": "text/html",
+    "query": "Welche konkreten Schritte sind für die Härtung von Wayland/X11 Remote Access erforderlich?",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.42,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "actionable": true,
+    "covered_gap_ids": [
+      "REVIEW-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/f0426ec1b36f486f22cab462.json b/data/research-evidence/f0426ec1b36f486f22cab462.json
new file mode 100644
index 0000000..676508c
--- /dev/null
+++ b/data/research-evidence/f0426ec1b36f486f22cab462.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:43:38.4445765Z",
+  "content_sha256": "aa6fa6010cb015e795fbccce2f353b23741d183223ed1b27dbc0bfd808280bb5",
+  "result": {
+    "title": "Wayland",
+    "url": "https://wayland.freedesktop.org/",
+    "snippet": "Wayland is a replacement for the X11 window system protocol and architecture with the aim to be easier to develop, extend, and maintain. Wayland is the language (protocol) that applications can use to talk to a display server in order to make themselves visible and get input from the user (a person).",
+    "content": "Wayland\n\nWayland\n\nWayland is a replacement for the X11 window system protocol and\narchitecture with the aim to be easier to develop, extend, and\nmaintain.\n\nWayland is the language (protocol) that applications can use to\ntalk to a display server in order to make themselves visible and\nget input from the user (a person). A Wayland server is called\na \"compositor\". Applications are Wayland clients.\n\nWayland also refers to a system architecture. It is not just a\nserver-client relationship between a compositor and applications.\nThere is no single common Wayland server like Xorg is for X11,\nbut every graphical environment brings with it one of many compositor\nimplementations. Window management and the end user experience\nare often tied to the compositor rather than swappable components.\n\nA core part of Wayland architecture is libwayland: an inter-process\ncommunication library that translates a protocol definition in XML to a C\nlanguage API. This library does not implement Wayland, it merely\nencodes and decodes Wayland messages. The actual implementations are\nin the various compositor and application toolkit projects.\n\nWayland does not restrict where and how it is used. A Wayland\ncompositor could be a standalone display server running on Linux\nkernel modesetting and evdev input devices or on many other\noperating systems, or a nested compositor that itself is an X11 or\nWayland application (client). Wayland can even be used in\napplication-internal communication as is done in some web browsers.\n\nInformation:\n\nWayland architecture\n\nWayland FAQ\n\nWayland book\n\nlibwayland documentation\n\nSoftware:\n\nReleases\n\nWayland Git repositories\n\nExtras : some apps and debugging tools\n\nDevelopment:\n\nMailing list\n\nIRC: #wayland on OFTC\n\nPending Wayland patches\n\nContribution instructions for Wayland\n\nWayland bugs",
+    "content_type": "text/html",
+    "query": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben aktuelle offizielle Dokumentation Version Support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "reputable_secondary",
+    "source_quality_score": 0.68,
+    "covered_gap_ids": [
+      "ADAPTIVE-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/f2e68737b44dfdcdb991df43.json b/data/research-evidence/f2e68737b44dfdcdb991df43.json
new file mode 100644
index 0000000..4e018ae
--- /dev/null
+++ b/data/research-evidence/f2e68737b44dfdcdb991df43.json
@@ -0,0 +1,25 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:44:07.4495412Z",
+  "content_sha256": "e3ea542cd31b5f410a4dcc601fd7ce52dd3afc0321acb770a79a6aa17d2f1578",
+  "result": {
+    "title": "Incident Response - strukturiertes Vorgehen bei Vorfällen",
+    "url": "https://www.cyber-security.eu/de/incident-response",
+    "snippet": "Ein Vorfall startet Freitagabend mit auffälligen EDR-Alerts. Weil Notfallkontakte und Rollen geübt sind, übernimmt ein Incident Commander, ein Krisenstab tagt am Samstagvormittag, Forensik wird beauftragt, Kunden werden klar informiert.",
+    "content": "Incident Response\n\nEin Sicherheitsvorfall verlangt einen klaren Prozess, geübte Rollen und vorbereitete Kommunikation. Wer im Ernstfall improvisiert, verliert Zeit und macht Fehler. Diese Seite zeigt die Phasen, Verantwortlichkeiten und typischen Stolpersteine.\n\nFür wen ist diese Seite relevant?\n\nDiese Seite richtet sich an Incident-Manager, SOC- und IT-Leitung, Krisenstabsmitglieder, Datenschutz- und Rechtsfunktionen sowie an Geschäftsführungen, die wissen müssen, wie ihre Organisation auf Vorfälle vorbereitet ist.\n\nWas Incident Response ist\n\nIncident Response umfasst alle organisatorischen und technischen Schritte, mit denen eine Organisation einen Sicherheitsvorfall erkennt, eindämmt, behandelt und daraus lernt. Sie ist mehr als technische Forensik. Kommunikation, Entscheidungswege und Recht sind genauso wichtig.\n\nVorbereitung schlägt Improvisation\n\nIm Vorfall ist keine Zeit, Dinge erstmals zu klären. Wer Rollen, Eskalationswege, Kommunikationsvorlagen und externe Dienstleister vorbereitet hat, gewinnt Zeit und reduziert Schaden.\n\nGeübte Tabletops zeigen häufig sehr früh, dass Notfallkontakte veraltet sind oder Entscheidungswege im Wochenende nicht funktionieren.\n\nTypische Phasen\n\nEin verbreiteter Rahmen (NIST) unterscheidet:\n\n1. Vorbereitung : Pläne, Rollen, Werkzeuge, Übungen\n2. Erkennung und Analyse : Alerts, Triage, Bewertung\n3. Eindämmung : Schaden begrenzen, ohne Forensik zu zerstören\n4. Beseitigung : Ursachen und Persistenz entfernen\n5. Wiederherstellung : kontrollierter Wiederanlauf\n6. Lessons Learned : strukturierte Auswertung und Verbesserungen\n\nRollen und Verantwortlichkeiten\n\nBewährte Rollen sind:\n\n- Incident Commander : koordiniert\n- Technische Analyse : SOC, IT, ggf. externe Forensik\n- Kommunikation : intern, Kunden, Behörden, Medien\n- Recht und Datenschutz : Pflichten, Meldungen, Beweissicherung\n- Krisenstab und Geschäftsführung : Entscheidungen mit Geschäftsfolgen\n- HR , wenn Mitarbeitende betroffen sind\n\nWichtig: klare Stellvertretungen für jede Rolle.\n\nKommunikation im Vorfall\n\nKommunikation entscheidet oft über Reputationsschaden. Vorlagen helfen: erste interne Information, Statusupdates, Kundeninformation, Behördenmeldung, Sprachregelung für die Öffentlichkeit.\n\nGrundregel: nicht spekulieren, klar zwischen bestätigten und vermuteten Fakten unterscheiden.\n\nTechnische Voraussetzungen\n\nWirksame Reaktion braucht:\n\n- Logs über sinnvolle Zeiträume\n- EDR -Telemetrie auf Endpoints und Servern\n- Saubere Identity -Sichtbarkeit\n- Backups und ein dokumentiertes Recovery\n- Verfügbare forensische Werkzeuge und Partner\n\nTypische Fehler\n\nHäufige Schwachpunkte:\n\n- Zu schnelles Aufräumen ohne Forensik\n- Unklare Eskalation am Wochenende\n- Nur reaktive Kommunikation\n- Keine Tabletop-Übungen\n- Backups, deren Wiederherstellung nie getestet wurde\n\nPraxisbeispiel\n\nEin Vorfall startet Freitagabend mit auffälligen EDR-Alerts. Weil Notfallkontakte und Rollen geübt sind, übernimmt ein Incident Commander, ein Krisenstab tagt am Samstagvormittag, Forensik wird beauftragt, Kunden werden klar informiert. Drei Tage später läuft der Betrieb wieder, Lessons Learned werden in Maßnahmen überführt.\n\nCheckliste\n\nIncident-Response-Plan dokumentiert und freigegeben\n\nKlare Rollen mit Stellvertretern\n\nEskalationskette inklusive Recht und Kommunikation\n\nForensik- und EDR-Werkzeuge bereit\n\nExterne Dienstleister vertraglich abrufbar\n\nKommunikationsvorlagen vorbereitet\n\nTabletop-Übung mindestens jährlich\n\nBackups und Wiederherstellung getestet\n\nHäufige Fragen\n\n+ Was ist der wichtigste Schritt?\nDie Vorbereitung. Wer im Vorfall improvisiert, verliert Zeit und macht Fehler.\n+ Wann meldet man einen Vorfall?\nSobald die regulatorische Schwelle erreicht ist. NIS2 und DORA setzen enge Fristen, daher sind Meldewege vorher zu üben.\n+ Wer entscheidet im Krisenfall?\nGeschäftsführung beziehungsweise Krisenstab, basierend auf Vorbereitung und Bewertung durch IT, Security und Recht.\n\nVerwandte Themen\n\nIncident Response Plan\n\nEin guter Incident-Response-Plan ist kurz genug, um im Ernstfall hilfreich zu sein, und konkret genug, um Entscheidungen zu beschleunigen. Diese Seite zeigt eine pragmatische Struktur und typische Inhalte.\n\nWas ist ein SOC?\n\nEin Security Operations Center bündelt Menschen, Prozesse und Technik, um Cyber-Vorfälle früh zu erkennen, strukturiert zu behandeln und nachhaltig zu lernen. Diese Seite zeigt Aufgaben, Modelle und typische Fallstricke.\n\nSIEM\n\nEin SIEM bündelt Log- und Telemetriedaten, korreliert sie und liefert die Grundlage für Detection und Incident Response. Diese Seite erklärt Funktion, wichtige Datenquellen und typische Fehler.\n\nRansomware: Risiken und Erstmaßnahmen\n\nRansomware bleibt eines der teuersten Cyber-Risiken. Sie ist meist die Folge einer Verkettung von Schwächen, nicht eines einzelnen Klicks. Diese Seite zeigt typische Muster, wirksame Maßnahmen und eine geordnete Erstreaktion.\n\nPhishing\n\nPhishing ist nach wie vor einer der häufigsten Einstiegswege. Moderne Angriffe wirken professionell, nutzen vertraute Marken und passen sich an. Technische Filter, Awareness und ein einfacher Meldeweg gehören zusammen.\n\nNIS2 - was Unternehmen wissen müssen\n\nDie NIS2-Richtlinie hebt die Anforderungen an Cyber Security in der EU spürbar an. Diese Seite ordnet die wichtigsten Punkte redaktionell ein, ohne Rechtsberatung zu sein.\n\nAccount Compromise\n\nEin kompromittierter Account ist heute eine der häufigsten Vorfallsformen. Diese Seite erklärt typische Ursachen, frühe Anzeichen und sinnvolle Erstmaßnahmen.\n\nBackup\n\nBackups sind ein zentraler Baustein gegen Datenverlust und Ransomware. Diese Seite erklärt das 3-2-1-Prinzip, Offline- und unveränderliche Backups, Restore-Tests und typische Fehler.\n\nBusiness Email Compromise\n\nBusiness Email Compromise zielt auf Geld- oder Datenflüsse über manipulierte Geschäftsmails - oft mit kompromittierten Postfächern oder täuschend echter Korrespondenz. Diese Seite ordnet Szenarien und Maßnahmen ein.",
+    "content_type": "text/html",
+    "query": "Welche konkreten Schritte sind für die Erkennung von Vorfällen bei Wayland/X11 Remote Access erforderlich?",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.37,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "actionable": true,
+    "covered_gap_ids": [
+      "REVIEW-1"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/f5ef54172f97c98b5975cf8b.json b/data/research-evidence/f5ef54172f97c98b5975cf8b.json
new file mode 100644
index 0000000..c0c756e
--- /dev/null
+++ b/data/research-evidence/f5ef54172f97c98b5975cf8b.json
@@ -0,0 +1,25 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T21:46:10.8725679Z",
+  "content_sha256": "bf481c2f35ea979bac2303fe52eaa93a2031241783dee45152c0a2c443d2c09b",
+  "result": {
+    "title": "Demystifying GraphQL Security: A Comprehensive Guide to Introspection - DEV Community",
+    "url": "https://dev.to/tristankalos/demystifying-graphql-security-a-comprehensive-guide-to-introspection-34fm",
+    "snippet": "The curl introspection command An essential feature for productivity and flexibility Introspection is a handy feature for front-end and client developers. In particular, one of the most significant advantages of GraphQL is its ability to allow them to request only the data they need. Introspection plays a crucial role in this process by enabling them to discover and understand the available ...",
+    "content": "This post by Antoine is easier to read on our blog\n\nWhether or not to disable introspection has been a common debate among GraphQL developers since its inception. In this blog post, we will explain why completely disabling introspection is not necessary and why it can be counterproductive.\n\nMarc-André Giroux, Author of Production Ready GraphQL\n\nWhy is introspection useful?\n\nWhat is introspection?\n\nFirstly, it's essential to understand what Introspection is in GraphQL. It is the ability to provide metadata about its schema, including types, fields, and directives. It allows developers to explore the API structure and understand the available data.\n\nThe simplest way to know if your introspection is open is to fetch it yourself!\n\ncurl --location 'https://example.com/graphql' \\\n--header 'Authorization: Bearer \u003ctoken\u003e' \\\n--header 'Content-Type: application/json' \\\n--data '{\"query\":\"query IntrospectionQuery { __schema { queryType { name } mutationType { name } subscriptionType { name } types { ...FullType } directives { name description locations args { ...InputValue } } } } fragment FullType on __Type { kind name description fields(includeDeprecated: true) { name description args { ...InputValue } type { ...TypeRef } isDeprecated deprecationReason } inputFields { ...InputValue } interfaces { ...TypeRef } enumValues(includeDeprecated: true) { name description isDeprecated deprecationReason } possibleTypes { ...TypeRef } } fragment InputValue on __InputValue { name description type { ...TypeRef } defaultValue } fragment TypeRef on __Type { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name } } } } } } } }\",\"variables\":{}}' \\ \u003e introspection.json\n\nThe curl introspection command\n\nAn essential feature for productivity and flexibility\n\nIntrospection is a handy feature for front-end and client developers. In particular, one of the most significant advantages of GraphQL is its ability to allow them to request only the data they need. Introspection plays a crucial role in this process by enabling them to discover and understand the available types and fields in the schema.\n\nBy disabling introspection, you're essentially taking away a valuable tool that developers can use to improve their productivity and make better-informed decisions about how to structure their queries.\n\nMoreover, Introspection can be a valuable tool for API documentation and discovery. By disabling it in production, you might need to invest additional resources in maintaining separate documentation and keeping it up-to-date. This can increase the complexity of your API maintenance process and potentially lead to inconsistencies between the actual schema and the documentation.\n\nIs introspection really a security concern?\n\nIt seems like a potential security risk\n\nThe main argument for disabling introspection is that it can be a security risk. By allowing introspection, malicious actors can exploit this information to craft targeted attacks against your application. In particular, it can potentially expose additional entry points, such as hidden or undocumented operations that might not be as secure as the rest of your application.\n\nIt can also be a performance issue. When a GraphQL server receives an introspection query, it must traverse the entire schema and gather metadata, which can be time-consuming and resource-intensive.\n\nWhere there's a will; there's a way\n\nAt that point, it might seem obvious to disable introspection for security purposes. The problem is that disabling it is just a \"false good idea\". There is always a simple way to find your schema and craft malicious requests against your GraphQL API.\n\nField suggestion leaks your schema\n\nMost GraphQL engines have a feature called Field Suggestion. When the server receives a query with invalid fields, it will respond with an error message indicating that the requested field does not exist.\n\nHowever, this error message also contains information about fields with similar names that do exist within the schema. This GraphQL feature is called Field Suggestion.\n\n\"errors\": [\n\"message\": \"Cannot query field \\\"space\\\" on type \\\"Query\\\". Did you mean \\\"escape\\\"?\",\n\"locations\": [\n\"line\": 1,\n\"column\": 5\n],\n\"extensions\": {\n\"code\": \"GRAPHQL-VALIDATION-FAILED\"\n\nField suggestion in GraphQL\n\nThis feature can be abused: by sending random field names in a query and gathering the suggestions that the servers send back, one can build back the complete GraphQL Schema! This is an attack called Field Fuzzing.\n\nClairvoyance is an open-source tool created by Nikita Stupin and maintained by Escape that allows developers to retrieve GraphQL introspection data even when disabled using Field Fuzzing.\n\nBy analyzing these error messages, Clairvoyance can determine the structure of the schema and retrieve the necessary introspection data.\n\nOn Apollo and Yoga servers, you can easily disable Field Suggestion using our free, open-source tool GraphQL Armor.\n\nThe frontend knows everything.\n\nObviously, it is possible to recreate the introspection from the traffic generated by a front-end. This means that even if you disable introspection, a determined attacker could still gain access to the schema information by navigating to your application's website.\n\nMy introspection is only enabled on staging\n\nDo you think keeping your introspection open on staging makes your production more secure?\n\nMost of the time, we notice that if your production endpoint is available on https://graphql.example.com/ , your staging environment is accessible through https://staging.graphql.example.com/ . In that case, getting the introspection of your staging is a no-brainer.\n\nLet's say you tried to hide your staging environment on a random URL. At Escape, we developed open-source software to find any GraphQL endpoint related to your main application.\n\nUsing subdomain enumeration, web crawling, and brute forcing, Goctopus can find any of your GraphQL endpoints and know whether introspection or field suggestions are enabled on each of them.\n\nWe use Goctopus in our own platform, Escape, to index all our customer's exposed GraphQL Endpoints. We discovered that a surprisingly high amount of organizations have their staging and development environment open, with introspection activated.\n\nConclusion: don't trade productivity against obscurity\n\nAt Escape, we believe in security by obscurity, and thus we advise not to disable introspection.\n\nYou can keep your introspection enabled: Completely disabling introspection doesn't actually make your server more secure; it just makes it harder for developers to do their jobs.\n\nOptionally, implement role-based access control: If you still don't fill confident in letting your introspection open to the world, you can configure your GraphQL server to enable introspection only for specific user roles, such as administrator or developers, ensuring the feature is accessible only to trusted users. See more details in our documentation.\n\nUltimately, deciding to disable introspection in production depends on your specific use case and requirements. Ensure you provide your developers with the best experience while maintaining a robust application.\n\nFor further actions, you may consider blocking this person and/or reporting abuse",
+    "content_type": "text/html",
+    "query": "GraphQL Introspection Sicherheit current official documentation version support",
+    "language": "en-US",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.3333333333333333,
+    "source_quality": "unknown",
+    "source_quality_score": 0.52,
+    "actionable": true,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/f6974c1056aac2e0c3ec2035.json b/data/research-evidence/f6974c1056aac2e0c3ec2035.json
new file mode 100644
index 0000000..e6617a8
--- /dev/null
+++ b/data/research-evidence/f6974c1056aac2e0c3ec2035.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:43:39.9263703Z",
+  "content_sha256": "65f679e5bfbcda41b10ba4f04c17f3d7c056bb353b2d5802b744e526d1768a1d",
+  "result": {
+    "title": "Wayland",
+    "url": "https://wayland.freedesktop.org/docs/html/",
+    "snippet": "Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a Wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.",
+    "content": "Wayland\n\nWayland\n\nNext\n\nWayland\n\nThe Wayland Protocol\n\nKristian Høgsberg\n\nIntel Corporation\n\n\u003c krh@bitplanet.net \u003e\n\nCopyright © 2012 Kristian Høgsberg, Intel Corporation\n\nPermission is hereby granted, free of charge, to any person obtaining a\ncopy of this software and associated documentation files (the \"Software\"),\nto deal in the Software without restriction, including without limitation\nthe rights to use, copy, modify, merge, publish, distribute, sublicense,\nand/or sell copies of the Software, and to permit persons to whom the\nSoftware is furnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice (including the next\nparagraph) shall be included in all copies or substantial portions of the\nSoftware.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL\nTHE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\nFROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER\nDEALINGS IN THE SOFTWARE.\n\nAbstract\n\nWayland is a protocol for a compositor to talk to\nits clients as well as a C library implementation of\nthat protocol. The compositor can be a standalone\ndisplay server running on Linux kernel modesetting\nand evdev input devices, an X application, or a\nWayland client itself. The clients can be\ntraditional applications, X servers (rootless or\nfullscreen) or other display servers.\n\nTable of Contents\nPreface A. Wayland Protocol Specification wl_display\n- core global object wl_registry\n- global registry object wl_callback\n- callback object wl_compositor\n- the compositor singleton wl_shm_pool\n- a shared memory pool wl_shm\n- shared memory support wl_buffer\n- content for a wl_surface wl_data_offer\n- offer to transfer data wl_data_source\n- offer to transfer data wl_data_device\n- data transfer device wl_data_device_manager\n- data transfer interface wl_shell\n- create desktop-style surfaces wl_shell_surface\n- desktop-style metadata interface wl_surface\n- an onscreen surface wl_seat\n- group of input devices wl_pointer\n- pointer input device wl_keyboard\n- keyboard input device wl_touch\n- touchscreen input device wl_output\n- compositor output region wl_region\n- region interface wl_subcompositor\n- sub-surface compositing wl_subsurface\n- sub-surface interface to a wl_surface wl_fixes\n- wayland protocol fixes B. Client API Introduction wl_argument\nProtocol message argument data types.\nwl_array\nDynamic array.\nwl_display\nRepresents a connection to the compositor and acts as a proxy to the wl_display singleton object.\nwl_event_queue\nA queue for wl_proxy object events.\nwl_interface\nProtocol object interface.\nwl_list\nDoubly-linked list.\nwl_message\nProtocol message signature.\nwl_object\nA protocol object.\nwl_proxy\nRepresents a protocol object on the client side.\nFunctions C. Server API Introduction wl_argument\nProtocol message argument data types.\nwl_array\nDynamic array.\nwl_client wl_display wl_event_loop\nAn event loop context.\nwl_event_source\nAn abstract event source.\nwl_global wl_global_offer wl_interface\nProtocol object interface.\nwl_list\nDoubly-linked list.\nwl_listener\nA single listener for Wayland signals.\nwl_message\nProtocol message signature.\nwl_object\nA protocol object.\nwl_protocol_logger wl_protocol_logger_message wl_registry wl_resource wl_resource_iterator_context wl_shm_buffer\nA SHM buffer.\nwl_shm_pool wl_shm_sigbus_data wl_signal\nA source of a type of observable event.\nwl_socket Functions\n\nNext\n\nPreface",
+    "content_type": "text/html",
+    "query": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.25,
+    "source_quality": "primary",
+    "source_quality_score": 0.88,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/research-evidence/fbc776863a8b1a4ddf261ed0.json b/data/research-evidence/fbc776863a8b1a4ddf261ed0.json
new file mode 100644
index 0000000..1c6bfe8
--- /dev/null
+++ b/data/research-evidence/fbc776863a8b1a4ddf261ed0.json
@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "saved_at": "2026-08-07T20:43:39.9263703Z",
+  "content_sha256": "7bd96a883f684b01f13cb3afe76e7d0f5e12629641b9e3238727d27755c1da8c",
+  "result": {
+    "title": "Chapter 14. Remotely accessing a Wayland-based application | Getting started with the GNOME desktop environment | Red Hat Enterprise Linux | 9 | Red Hat Documentation",
+    "url": "https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/getting_started_with_the_gnome_desktop_environment/remotely-accessing-an-individual-application-wayland_getting-started-with-the-gnome-desktop-environment",
+    "snippet": "The desktop applications shipped with RHEL 9 support both the Wayland and X11 display protocols. However, Wayland is the preferred option when both are available.",
+    "content": "Home\n\nProducts\n\nRed Hat Enterprise Linux\n\nGetting started with the GNOME desktop environment\n\nChapter 14. Remotely accessing a Wayland-based application\n\nFormat Multi-page Single-page View full doc as PDF\n\nChapter 14. Remotely accessing a Wayland-based application\n\nYou can remotely launch a graphical Wayland-based application on a RHEL server and use it from the remote client on Wayland using waypipe .\n\nNote\n\nThe desktop applications shipped with RHEL 9 support both the Wayland and X11 display protocols. However, Wayland is the preferred option when both are available.\n\n14.1. Enabling waypipe on the client and server\nCopy link Link copied to clipboard!\n\nTo be able to launch an individual application on Wayland, you need to install the waypipe package.\n\nPrerequisites\n\nBoth the client and server use the RHEL 9 operating system.\n\nProcedure\n\nInstall the waypipe package on the local system.\n\n# dnf install waypipe\n\nInstall the waypipe package on the remote system.\n\n# dnf install waypipe\n\n14.2. Launching an application remotely using waypipe\nCopy link Link copied to clipboard!\n\nYou can access a graphical application on Wayland on a RHEL server from a remote client using SSH and waypipe .\n\nNote\n\nThis procedure does not work for legacy X11 applications. For X11 applications, see Remotely accessing an individual application on X11 .\n\nPrerequisites\n\nA Wayland display server is running on your system. On RHEL 9, GNOME as a Wayland compositor is the default.\n\nThe waypipe package is installed on both the client and the remote system.\n\nThe application is capable of running natively on Wayland.\n\nProcedure\n\nLaunch the application remotely through waypipe and SSH.\n\n[local-user]$ waypipe -c lz4=9 ssh remote-server application-binary\n\nThe authenticity of host ' remote-server ( 192.168.122.120 )' can't be established.\nECDSA key fingerprint is SHA256: uYwFlgtP/2YABMHKv5BtN7nHK9SHRL4hdYxAPJVK/kY .\nAre you sure you want to continue connecting (yes/no/[fingerprint])?\n\nConfirm that a server key is valid by checking its fingerprint.\n\nContinue connecting by typing yes .\n\nWarning: Permanently added ' remote-server ' (ECDSA) to the list of known hosts.\n\nWhen prompted, type the server password.\n\nremote-user's password:\n[remote-user]$\n\n14.3. Additional resources\nCopy link Link copied to clipboard!\n\nRemotely accessing an individual application on X11 .\n\nKey differences between the Wayland and X11 protocol .",
+    "content_type": "text/html",
+    "query": "Wayland/X11 Remote Access – präventiv, detectiv und forensisch handhaben current official documentation version support",
+    "language": "de-DE",
+    "round": 1,
+    "fetched": true,
+    "relevant": true,
+    "relevance": 0.3927272727272727,
+    "source_quality": "primary",
+    "source_quality_score": 0.88,
+    "covered_gap_ids": [
+      "ADAPTIVE-2"
+    ],
+    "assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
+  }
+}
diff --git a/data/runtime-settings.json b/data/runtime-settings.json
index 679f015..5c7dc3f 100644
--- a/data/runtime-settings.json
+++ b/data/runtime-settings.json
@@ -1,9 +1,17 @@
 {
-  "learning_enabled": false,
+  "source_filter_version": 1,
+  "learning_enabled": true,
   "thinking_enabled": true,
-  "learning_categories": [],
-  "display_categories": [],
-  "thinking_categories": [],
+  "learning_sources": [],
+  "display_sources": [],
+  "thinking_sources": [],
   "view_mode": "neural",
-  "max_display_nodes": 1000
+  "max_display_nodes": 1000,
+  "low_power_mode": false,
+  "processing_mode": "clustered",
+  "autonomous_research_enabled": true,
+  "autonomous_research_idle_only": false,
+  "autonomous_research_min_priority": 0.65,
+  "autonomous_research_max_tasks_per_day": 12,
+  "autonomous_research_tasks_per_cycle": 1
 }
diff --git a/data/source-agent-config-cache.json b/data/source-agent-config-cache.json
new file mode 100644
index 0000000..1fc45d5
--- /dev/null
+++ b/data/source-agent-config-cache.json
@@ -0,0 +1,13 @@
+{
+  "schema_version": 1,
+  "agent": {
+    "id": "agent-2b4febffd8a821c161ab75f3",
+    "name": "heise-security",
+    "enabled": true,
+    "created_at": "2026-08-07T20:03:31.0354669Z",
+    "updated_at": "2026-08-07T20:03:31.0354669Z",
+    "last_seen": "0001-01-01T00:00:00Z"
+  },
+  "tasks": null,
+  "issued_at": "2026-08-07T20:06:59.9985542Z"
+}
diff --git a/data/source-agent-local.db b/data/source-agent-local.db
new file mode 100644
index 0000000..9b8cfca
Binary files /dev/null and b/data/source-agent-local.db differ
diff --git a/data/source-agents.db b/data/source-agents.db
new file mode 100644
index 0000000..cf499d4
Binary files /dev/null and b/data/source-agents.db differ
diff --git a/data/source-agents.db-shm b/data/source-agents.db-shm
new file mode 100644
index 0000000..4433507
Binary files /dev/null and b/data/source-agents.db-shm differ
diff --git a/data/source-agents.db-wal b/data/source-agents.db-wal
new file mode 100644
index 0000000..1f18dfd
Binary files /dev/null and b/data/source-agents.db-wal differ
diff --git a/data2/source-agent-config-cache.json b/data2/source-agent-config-cache.json
new file mode 100644
index 0000000..474954f
--- /dev/null
+++ b/data2/source-agent-config-cache.json
@@ -0,0 +1,54 @@
+{
+  "schema_version": 1,
+  "agent": {
+    "id": "agent-2b4febffd8a821c161ab75f3",
+    "name": "heise-security",
+    "enabled": true,
+    "created_at": "2026-08-07T20:03:31.0354669Z",
+    "updated_at": "2026-08-07T21:48:31.3118246Z",
+    "last_seen": "2026-08-07T21:48:31.3118246Z",
+    "version": "source-agent-integrated-v1.1"
+  },
+  "tasks": [
+    {
+      "id": "task-dkj12z1sifsk",
+      "agent_id": "agent-2b4febffd8a821c161ab75f3",
+      "name": "CERT-Bund Warn- und Informationsdienst - Aktuelle Sicherheitshinweise",
+      "type": "rss",
+      "url": "https://wid.cert-bund.de/content/public/securityAdvisory/rss",
+      "enabled": true,
+      "poll_interval": "1h",
+      "categories": [
+        "security",
+        "certbund",
+        "wid"
+      ],
+      "max_items": 20,
+      "config": {
+        "refetch_seen": "false"
+      },
+      "created_at": "2026-08-07T21:26:52.0614053Z",
+      "updated_at": "2026-08-07T21:26:52.0614053Z"
+    },
+    {
+      "id": "task-dkj06qg66yg8",
+      "agent_id": "agent-2b4febffd8a821c161ab75f3",
+      "name": "heise Security - Nur die Alerts",
+      "type": "rss",
+      "url": "https://www.heise.de/security/Alerts/feed.xml",
+      "enabled": true,
+      "poll_interval": "1h",
+      "categories": [
+        "security",
+        "heise"
+      ],
+      "max_items": 20,
+      "config": {
+        "refetch_seen": "false"
+      },
+      "created_at": "2026-08-07T20:44:45.6866186Z",
+      "updated_at": "2026-08-07T20:44:45.6866186Z"
+    }
+  ],
+  "issued_at": "2026-08-07T21:48:31.3150711Z"
+}
diff --git a/data2/source-agent-local.db b/data2/source-agent-local.db
new file mode 100644
index 0000000..556e0ec
Binary files /dev/null and b/data2/source-agent-local.db differ
diff --git a/data2/source-agent-local.db-shm b/data2/source-agent-local.db-shm
new file mode 100644
index 0000000..4882d01
Binary files /dev/null and b/data2/source-agent-local.db-shm differ
diff --git a/data2/source-agent-local.db-wal b/data2/source-agent-local.db-wal
new file mode 100644
index 0000000..16db65b
Binary files /dev/null and b/data2/source-agent-local.db-wal differ
diff --git a/deployment/docker-compose.full.yml b/deployment/docker-compose.full.yml
index f82d7d8..d4e1edf 100644
--- a/deployment/docker-compose.full.yml
+++ b/deployment/docker-compose.full.yml
@@ -108,6 +108,7 @@ services:
     environment:
       BRAIN_MODE: brain
       BRAIN_LISTEN_ADDR: :8090
+      BRAIN_PUBLIC_URL: ${BRAIN_PUBLIC_URL:-}
       BRAIN_DATA_DIR: /app/data
       BRAIN_KNOWLEDGE_DIRS: /sources/knowledge
       BRAIN_STAGING_DIRS: /sources/staging
diff --git a/deployment/docker-compose.source-agent.yml b/deployment/docker-compose.source-agent.yml
index 3520164..9456c74 100644
--- a/deployment/docker-compose.source-agent.yml
+++ b/deployment/docker-compose.source-agent.yml
@@ -5,6 +5,8 @@ services:
     build:
       context: ..
     restart: unless-stopped
+    ports:
+      - "${BRAIN_AGENT_PORT:-8092}:8090"
     environment:
       BRAIN_MODE: agent
       BRAIN_LISTEN_ADDR: :8090
@@ -19,6 +21,8 @@ services:
       BRAIN_AGENT_ALLOW_PRIVATE: ${BRAIN_AGENT_ALLOW_PRIVATE:-false}
     volumes:
       - source-agent-state:/app/data
+    extra_hosts:
+      - "host.docker.internal:host-gateway"
     read_only: true
     tmpfs: [/tmp:size=32m]
     security_opt: [no-new-privileges:true]
diff --git a/docker-compose.yml b/docker-compose.yml
index 040ba1c..93196a1 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -4,10 +4,11 @@ services:
     container_name: glpi-neural-brain
     restart: unless-stopped
     ports:
-      - "8090:8090"
+      - "${BRAIN_PORT:-8090}:8090"
     environment:
       BRAIN_MODE: ${BRAIN_MODE:-brain}
       BRAIN_LISTEN_ADDR: ":8090"
+      BRAIN_PUBLIC_URL: ${BRAIN_PUBLIC_URL:-}
       BRAIN_DATA_DIR: /app/data
       BRAIN_KNOWLEDGE_DIRS: /sources/knowledge
       BRAIN_STAGING_DIRS: /sources/staging
@@ -90,6 +91,8 @@ services:
       BRAIN_SOURCE_INBOX_INTERVAL: ${BRAIN_SOURCE_INBOX_INTERVAL:-30s}
       BRAIN_SOURCE_INBOX_BATCH_SIZE: ${BRAIN_SOURCE_INBOX_BATCH_SIZE:-12}
       BRAIN_SOURCE_INBOX_MIN_SIMILARITY: ${BRAIN_SOURCE_INBOX_MIN_SIMILARITY:-0.55}
+      BRAIN_SOURCE_INBOX_MIN_PRIORITY: ${BRAIN_SOURCE_INBOX_MIN_PRIORITY:-0.55}
+      BRAIN_SOURCE_INBOX_NOVELTY_FLOOR: ${BRAIN_SOURCE_INBOX_NOVELTY_FLOOR:-0.35}
       BRAIN_SOURCE_INBOX_MIN_RESULTS: ${BRAIN_SOURCE_INBOX_MIN_RESULTS:-2}
       BRAIN_SOURCE_INBOX_FRESH_MAX_AGE: ${BRAIN_SOURCE_INBOX_FRESH_MAX_AGE:-168h}
       BRAIN_AUTONOMOUS_RESEARCH_ENABLED: ${BRAIN_AUTONOMOUS_RESEARCH_ENABLED:-false}
diff --git a/internal/config/config.go b/internal/config/config.go
index d4bc7c5..9a970bd 100644
--- a/internal/config/config.go
+++ b/internal/config/config.go
@@ -13,6 +13,7 @@ import (
 type Config struct {
 	Mode                                string
 	ListenAddr                          string
+	BrainPublicURL                      string
 	DataDir                             string
 	KnowledgeDirs                       []string
 	StagingDirs                         []string
@@ -113,6 +114,8 @@ type Config struct {
 	SourceInboxInterval      time.Duration
 	SourceInboxBatchSize     int
 	SourceInboxMinSimilarity float64
+	SourceInboxMinPriority   float64
+	SourceInboxNoveltyFloor  float64
 	SourceInboxMinResults    int
 	SourceInboxFreshMaxAge   time.Duration
 	AgentBrainURL            string
@@ -158,6 +161,7 @@ func Load() (Config, error) {
 	cfg := Config{
 		Mode:                                strings.ToLower(env("BRAIN_MODE", "brain")),
 		ListenAddr:                          env("BRAIN_LISTEN_ADDR", ":8090"),
+		BrainPublicURL:                      strings.TrimRight(strings.TrimSpace(os.Getenv("BRAIN_PUBLIC_URL")), "/"),
 		DataDir:                             abs,
 		KnowledgeDirs:                       paths("BRAIN_KNOWLEDGE_DIRS"),
 		StagingDirs:                         paths("BRAIN_STAGING_DIRS"),
@@ -257,6 +261,8 @@ func Load() (Config, error) {
 		SourceInboxInterval:                 duration("BRAIN_SOURCE_INBOX_INTERVAL", 30*time.Second),
 		SourceInboxBatchSize:                integer("BRAIN_SOURCE_INBOX_BATCH_SIZE", 12),
 		SourceInboxMinSimilarity:            number("BRAIN_SOURCE_INBOX_MIN_SIMILARITY", 0.55),
+		SourceInboxMinPriority:              number("BRAIN_SOURCE_INBOX_MIN_PRIORITY", 0.55),
+		SourceInboxNoveltyFloor:             number("BRAIN_SOURCE_INBOX_NOVELTY_FLOOR", 0.35),
 		SourceInboxMinResults:               integer("BRAIN_SOURCE_INBOX_MIN_RESULTS", 2),
 		SourceInboxFreshMaxAge:              duration("BRAIN_SOURCE_INBOX_FRESH_MAX_AGE", 168*time.Hour),
 		AgentBrainURL:                       strings.TrimRight(strings.TrimSpace(os.Getenv("BRAIN_AGENT_BRAIN_URL")), "/"),
@@ -307,6 +313,12 @@ func Load() (Config, error) {
 		}
 		return cfg, nil
 	}
+	if cfg.BrainPublicURL != "" {
+		u, err := url.Parse(cfg.BrainPublicURL)
+		if err != nil || u.Host == "" || (u.Scheme != "http" && u.Scheme != "https") || u.User != nil {
+			return Config{}, fmt.Errorf("BRAIN_PUBLIC_URL must be an absolute http(s) URL without userinfo")
+		}
+	}
 	if cfg.SourceInboxInterval < 5*time.Second || cfg.SourceInboxInterval > 24*time.Hour {
 		return Config{}, fmt.Errorf("BRAIN_SOURCE_INBOX_INTERVAL must be between 5s and 24h")
 	}
@@ -316,6 +328,12 @@ func Load() (Config, error) {
 	if cfg.SourceInboxMinSimilarity < 0 || cfg.SourceInboxMinSimilarity > 1 {
 		return Config{}, fmt.Errorf("BRAIN_SOURCE_INBOX_MIN_SIMILARITY must be between 0 and 1")
 	}
+	if cfg.SourceInboxMinPriority < 0 || cfg.SourceInboxMinPriority > 1 {
+		return Config{}, fmt.Errorf("BRAIN_SOURCE_INBOX_MIN_PRIORITY must be between 0 and 1")
+	}
+	if cfg.SourceInboxNoveltyFloor < 0 || cfg.SourceInboxNoveltyFloor > 1 {
+		return Config{}, fmt.Errorf("BRAIN_SOURCE_INBOX_NOVELTY_FLOOR must be between 0 and 1")
+	}
 	if cfg.SourceInboxMinResults < 1 || cfg.SourceInboxMinResults > 20 {
 		return Config{}, fmt.Errorf("BRAIN_SOURCE_INBOX_MIN_RESULTS must be between 1 and 20")
 	}
diff --git a/internal/config/config_test.go b/internal/config/config_test.go
index 0937bcd..0c5f1d6 100644
--- a/internal/config/config_test.go
+++ b/internal/config/config_test.go
@@ -216,3 +216,37 @@ func TestLoadAgentModeRequiresBootstrapConnection(t *testing.T) {
 		t.Fatal("expected missing agent bootstrap configuration error")
 	}
 }
+
+func TestLoadBrainPublicURL(t *testing.T) {
+	t.Setenv("BRAIN_DATA_DIR", t.TempDir())
+	t.Setenv("BRAIN_PUBLIC_URL", "https://brain.example.org/")
+	cfg, err := Load()
+	if err != nil {
+		t.Fatal(err)
+	}
+	if cfg.BrainPublicURL != "https://brain.example.org" {
+		t.Fatalf("unexpected public URL: %q", cfg.BrainPublicURL)
+	}
+}
+
+func TestLoadRejectsInvalidBrainPublicURL(t *testing.T) {
+	t.Setenv("BRAIN_DATA_DIR", t.TempDir())
+	t.Setenv("BRAIN_PUBLIC_URL", "brain.example.org")
+	if _, err := Load(); err == nil {
+		t.Fatal("expected invalid BRAIN_PUBLIC_URL error")
+	}
+}
+
+func TestLoadSourceInboxPriorityClassifierSettings(t *testing.T) {
+	t.Setenv("BRAIN_DATA_DIR", t.TempDir())
+	t.Setenv("BRAIN_SOURCE_INBOX_MIN_SIMILARITY", "0.58")
+	t.Setenv("BRAIN_SOURCE_INBOX_MIN_PRIORITY", "0.61")
+	t.Setenv("BRAIN_SOURCE_INBOX_NOVELTY_FLOOR", "0.33")
+	cfg, err := Load()
+	if err != nil {
+		t.Fatal(err)
+	}
+	if cfg.SourceInboxMinSimilarity != .58 || cfg.SourceInboxMinPriority != .61 || cfg.SourceInboxNoveltyFloor != .33 {
+		t.Fatalf("unexpected source inbox classifier config: %+v", cfg)
+	}
+}
diff --git a/internal/engine/engine.go b/internal/engine/engine.go
index adcd4af..c47fddb 100644
--- a/internal/engine/engine.go
+++ b/internal/engine/engine.go
@@ -1050,6 +1050,12 @@ func (e *Engine) Status() map[string]any {
 		if inbox, err := e.SourceInbox.Stats(context.Background()); err == nil {
 			status["source_inbox"] = inbox
 		}
+		status["source_inbox_classifier"] = map[string]any{
+			"version":        SourceInboxClassifierVersion,
+			"min_similarity": e.Cfg.SourceInboxMinSimilarity,
+			"min_priority":   e.Cfg.SourceInboxMinPriority,
+			"novelty_floor":  e.Cfg.SourceInboxNoveltyFloor,
+		}
 	}
 	return status
 }
diff --git a/internal/engine/source_inbox.go b/internal/engine/source_inbox.go
index 1de1125..c5f9af2 100644
--- a/internal/engine/source_inbox.go
+++ b/internal/engine/source_inbox.go
@@ -4,6 +4,7 @@ import (
 	"context"
 	"fmt"
 	"log/slog"
+	"math"
 	"strings"
 	"time"
 
@@ -12,6 +13,19 @@ import (
 	"github.com/local/glpi-neural-brain/internal/sourceagent"
 )
 
+const SourceInboxClassifierVersion = 2
+
+type sourceInboxClassification struct {
+	Status        string
+	Priority      float64
+	Semantic      float64
+	Freshness     float64
+	TaskContext   float64
+	EventSignal   float64
+	Reason        string
+	MatchedNodeID string
+}
+
 func (e *Engine) SetSourceInbox(store *sourceagent.Store) { e.SourceInbox = store }
 
 func (e *Engine) evidenceAcquisitionEnabled() bool {
@@ -19,6 +33,9 @@ func (e *Engine) evidenceAcquisitionEnabled() bool {
 }
 
 func (e *Engine) sourceInboxLoop(ctx context.Context) {
+	// Classify once immediately so newly ingested or migration-requeued documents
+	// do not wait a full interval after startup.
+	e.processSourceInbox(ctx)
 	ticker := time.NewTicker(e.Cfg.SourceInboxInterval)
 	defer ticker.Stop()
 	for {
@@ -67,18 +84,11 @@ func (e *Engine) processSourceInbox(ctx context.Context) {
 			_ = e.SourceInbox.ReleaseInbox(ctx, item.ID, "knowledge vectors are not ready")
 			continue
 		}
-		relevance := 0.0
-		matched := ""
-		if len(hits) > 0 {
-			relevance = hits[0].Score
-			matched = hits[0].NodeID
-		}
-		status := "archived"
-		if relevance >= e.Cfg.SourceInboxMinSimilarity {
-			status = "candidate"
+		classification := e.classifySourceInboxItem(item, hits[0].Score, hits[0].NodeID, time.Now().UTC())
+		if classification.Status == "candidate" {
 			candidateCount++
 		}
-		meta := make(map[string]any, len(item.Metadata)+4)
+		meta := make(map[string]any, len(item.Metadata)+12)
 		for key, value := range item.Metadata {
 			meta[key] = value
 		}
@@ -86,13 +96,99 @@ func (e *Engine) processSourceInbox(ctx context.Context) {
 		meta["exact_comparisons"] = stats.ExactComparisons
 		meta["coarse_comparisons"] = stats.CoarseComparisons
 		meta["candidate_pool"] = stats.CandidatePool
-		_ = e.SourceInbox.CompleteClassification(ctx, item.ID, status, relevance, matched, meta)
+		meta["classification_version"] = SourceInboxClassifierVersion
+		meta["classification_reason"] = classification.Reason
+		meta["semantic_similarity"] = classification.Semantic
+		meta["priority_score"] = classification.Priority
+		meta["freshness_score"] = classification.Freshness
+		meta["task_context_score"] = classification.TaskContext
+		meta["event_signal_score"] = classification.EventSignal
+		_ = e.SourceInbox.CompleteClassification(ctx, item.ID, classification.Status, classification.Priority, classification.MatchedNodeID, meta)
 	}
 	if e.Broker != nil {
-		e.Broker.Publish(model.Activity{Type: "source.inbox.classified", Source: "brain", Phase: "source-inbox", Message: fmt.Sprintf("Source-Inbox: %d Dokumente geprüft · %d als Wissenskandidaten vorgemerkt", len(items), candidateCount), Strength: .36, Metadata: map[string]any{"documents": len(items), "candidates": candidateCount, "minimum_similarity": e.Cfg.SourceInboxMinSimilarity}})
+		e.Broker.Publish(model.Activity{Type: "source.inbox.classified", Source: "brain", Phase: "source-inbox", Message: fmt.Sprintf("Source-Inbox: %d Dokumente geprüft · %d als Wissenskandidaten vorgemerkt", len(items), candidateCount), Strength: .36, Metadata: map[string]any{"documents": len(items), "candidates": candidateCount, "minimum_similarity": e.Cfg.SourceInboxMinSimilarity, "minimum_priority": e.Cfg.SourceInboxMinPriority, "novelty_floor": e.Cfg.SourceInboxNoveltyFloor, "classifier_version": SourceInboxClassifierVersion}})
 	}
 }
 
+func (e *Engine) classifySourceInboxItem(item sourceagent.InboxDocument, semantic float64, matchedNodeID string, now time.Time) sourceInboxClassification {
+	freshness := sourceInboxFreshness(item, now)
+	taskContext := sourceInboxTaskContext(item)
+	eventSignal := sourceInboxEventSignal(item)
+	priority := clampInboxScore(0.65*semantic + 0.15*taskContext + 0.10*freshness + 0.10*eventSignal)
+	status := "archived"
+	reason := "zu geringe Nähe zur bestehenden Wissensbasis und keine ausreichend starken Aktualitäts-/Quellensignale"
+	if semantic >= e.Cfg.SourceInboxMinSimilarity {
+		status = "candidate"
+		reason = "direkte semantische Nähe zur bestehenden Wissensbasis"
+	} else if semantic >= e.Cfg.SourceInboxNoveltyFloor && priority >= e.Cfg.SourceInboxMinPriority {
+		status = "candidate"
+		reason = "neues, ausreichend KB-nahes Material mit zusätzlichem Quellen-, Aktualitäts- oder Advisory-Signal"
+	}
+	return sourceInboxClassification{Status: status, Priority: priority, Semantic: semantic, Freshness: freshness, TaskContext: taskContext, EventSignal: eventSignal, Reason: reason, MatchedNodeID: matchedNodeID}
+}
+
+func sourceInboxFreshness(item sourceagent.InboxDocument, now time.Time) float64 {
+	t := item.Document.PublishedAt
+	if t.IsZero() {
+		t = item.Document.DiscoveredAt
+	}
+	if t.IsZero() {
+		t = item.ReceivedAt
+	}
+	if t.IsZero() {
+		return .25
+	}
+	age := now.Sub(t)
+	if age < 0 {
+		age = 0
+	}
+	switch {
+	case age <= 24*time.Hour:
+		return 1
+	case age <= 7*24*time.Hour:
+		return .85
+	case age <= 30*24*time.Hour:
+		return .55
+	case age <= 90*24*time.Hour:
+		return .25
+	default:
+		return .10
+	}
+}
+
+func sourceInboxTaskContext(item sourceagent.InboxDocument) float64 {
+	contextText := strings.ToLower(strings.Join(append(append([]string{}, item.Document.Categories...), item.Document.SourceName, item.Document.SourceBaseURL), " "))
+	for _, marker := range []string{"security", "sicherheit", "advisory", "alert", "vulnerability", "vulnerabil", "cve", "incident", "patch", "release", "threat", "bedroh", "exploit"} {
+		if strings.Contains(contextText, marker) {
+			return 1
+		}
+	}
+	if len(item.Document.Categories) > 0 {
+		return .65
+	}
+	if strings.TrimSpace(item.Document.SourceName) != "" {
+		return .40
+	}
+	return .20
+}
+
+func sourceInboxEventSignal(item sourceagent.InboxDocument) float64 {
+	text := strings.ToLower(item.Document.Title + " " + strings.Join(item.Document.Categories, " ") + " " + item.Document.SourceName)
+	for _, marker := range []string{"0-day", "0day", "zero-day", "cve-", "kritisch", "critical", "actively exploited", "aktiv ausgenutzt", "backdoor", "authentifizierung umgehen", "authentication bypass", "remote code", "rce", "schadcode", "malware", "kompromitt"} {
+		if strings.Contains(text, marker) {
+			return 1
+		}
+	}
+	for _, marker := range []string{"angreifer", "attack", "sicherheitslücke", "sicherheitsleck", "vulnerability", "security update", "sicherheitsupdate", "patch", "update", "exploit", "datenleck", "security", "firewall", "advisory"} {
+		if strings.Contains(text, marker) {
+			return .75
+		}
+	}
+	return .20
+}
+
+func clampInboxScore(v float64) float64 { return math.Max(0, math.Min(1, v)) }
+
 func (e *Engine) sourceInboxResearch(ctx context.Context, query string, limit int, freshnessSensitive bool) []model.ResearchResult {
 	if e.SourceInbox == nil || !e.Cfg.SourceInboxEnabled || limit < 1 {
 		return nil
diff --git a/internal/engine/source_inbox_test.go b/internal/engine/source_inbox_test.go
new file mode 100644
index 0000000..d33b4cd
--- /dev/null
+++ b/internal/engine/source_inbox_test.go
@@ -0,0 +1,40 @@
+package engine
+
+import (
+	"testing"
+	"time"
+
+	"github.com/local/glpi-neural-brain/internal/config"
+	"github.com/local/glpi-neural-brain/internal/sourceagent"
+)
+
+func testInboxEngine() *Engine {
+	return &Engine{Cfg: config.Config{SourceInboxMinSimilarity: .55, SourceInboxMinPriority: .55, SourceInboxNoveltyFloor: .35}}
+}
+
+func TestSourceInboxSecurityAlertCanBecomeCandidateBelowSemanticThreshold(t *testing.T) {
+	now := time.Date(2026, 8, 7, 20, 0, 0, 0, time.UTC)
+	item := sourceagent.InboxDocument{Document: sourceagent.Document{Title: "Veeam One für Schadcode-Attacken anfällig", PublishedAt: now.Add(-2 * time.Hour), SourceName: "heise Security - Nur die Alerts", Categories: []string{"Security", "Alerts"}}, ReceivedAt: now}
+	got := testInboxEngine().classifySourceInboxItem(item, .49, "kb-veeam", now)
+	if got.Status != "candidate" || got.Priority < .55 || got.Semantic != .49 {
+		t.Fatalf("curated fresh security alert should remain searchable, got %+v", got)
+	}
+}
+
+func TestSourceInboxNoveltyFloorStillArchivesUnrelatedAlert(t *testing.T) {
+	now := time.Date(2026, 8, 7, 20, 0, 0, 0, time.UTC)
+	item := sourceagent.InboxDocument{Document: sourceagent.Document{Title: "Critical Security Advisory for unrelated appliance", PublishedAt: now, SourceName: "Security Alerts", Categories: []string{"Security"}}, ReceivedAt: now}
+	got := testInboxEngine().classifySourceInboxItem(item, .21, "kb-unrelated", now)
+	if got.Status != "archived" {
+		t.Fatalf("very low KB proximity must still be archived, got %+v", got)
+	}
+}
+
+func TestSourceInboxHighSemanticSimilarityRemainsCandidate(t *testing.T) {
+	now := time.Now().UTC()
+	item := sourceagent.InboxDocument{Document: sourceagent.Document{Title: "Evergreen Backup Guide"}, ReceivedAt: now.Add(-200 * 24 * time.Hour)}
+	got := testInboxEngine().classifySourceInboxItem(item, .72, "kb-backup", now)
+	if got.Status != "candidate" {
+		t.Fatalf("direct semantic match must remain candidate, got %+v", got)
+	}
+}
diff --git a/internal/sourceagent/agent.go b/internal/sourceagent/agent.go
index 88ef3a2..650312f 100644
--- a/internal/sourceagent/agent.go
+++ b/internal/sourceagent/agent.go
@@ -49,6 +49,24 @@ type Runner struct {
 	mu         sync.RWMutex
 	remote     RemoteConfig
 	wake       chan struct{}
+	diagMu     sync.RWMutex
+	diag       runnerDiagnostics
+}
+
+type runnerDiagnostics struct {
+	StartedAt             time.Time
+	ConfigSource          string
+	CacheLoadedAt         time.Time
+	LastConfigAttemptAt   time.Time
+	LastConfigSuccessAt   time.Time
+	LastConfigError       string
+	LastHeartbeatAt       time.Time
+	LastHeartbeatSuccess  time.Time
+	LastHeartbeatError    string
+	LastConnectionErrorAt time.Time
+	LastConnectionError   string
+	LastTaskRunAt         time.Time
+	LastTaskError         string
 }
 
 type bootstrapConfig struct {
@@ -109,13 +127,15 @@ func NewRunner(cfg RunnerConfig) (*Runner, error) {
 	if err != nil {
 		return nil, err
 	}
-	return &Runner{
+	r := &Runner{
 		cfg:        cfg,
 		http:       &http.Client{Timeout: cfg.HTTPTimeout},
 		sourceHTTP: research.NewSafeHTTPClient(cfg.AllowPrivate, cfg.HTTPTimeout),
 		state:      state,
 		wake:       make(chan struct{}, 1),
-	}, nil
+	}
+	r.diag.StartedAt = time.Now().UTC()
+	return r, nil
 }
 func (r *Runner) Close() error {
 	if r == nil || r.state == nil {
@@ -133,7 +153,56 @@ func (r *Runner) Status() map[string]any {
 	r.mu.RLock()
 	remote := r.remote
 	r.mu.RUnlock()
-	return map[string]any{"ok": true, "mode": "agent", "agent_id": r.cfg.AgentID, "brain_url": r.cfg.BrainURL, "configured_tasks": len(remote.Tasks), "config_issued_at": remote.IssuedAt, "version": r.cfg.Version}
+	r.diagMu.RLock()
+	d := r.diag
+	r.diagMu.RUnlock()
+	loopbackURL := false
+	if u, err := url.Parse(r.cfg.BrainURL); err == nil {
+		host := strings.ToLower(u.Hostname())
+		loopbackURL = host == "localhost" || host == "127.0.0.1" || host == "::1"
+	}
+	lastSuccess := d.LastConfigSuccessAt
+	if d.LastHeartbeatSuccess.After(lastSuccess) {
+		lastSuccess = d.LastHeartbeatSuccess
+	}
+	connected := !lastSuccess.IsZero() && (d.LastConnectionErrorAt.IsZero() || !d.LastConnectionErrorAt.After(lastSuccess))
+	state := "never_connected"
+	if connected {
+		state = "connected"
+		if d.LastConfigError != "" || d.LastHeartbeatError != "" {
+			state = "degraded"
+		}
+	} else if !lastSuccess.IsZero() {
+		state = "disconnected"
+	} else if d.ConfigSource == "cache" {
+		state = "cached_config_only"
+	}
+	warning := ""
+	// Loopback is perfectly valid for a native same-host test. Only surface the
+	// Docker-specific warning when the Agent is not actually connected.
+	if loopbackURL && !connected {
+		warning = "Brain URL points to loopback. In separate Docker containers, localhost/127.0.0.1 means the Agent container, not the Brain container. Use a shared service name or host.docker.internal:<published-port>."
+	}
+	hint := ""
+	errText := strings.ToLower(d.LastConnectionError)
+	switch {
+	case strings.Contains(errText, "http 401") || strings.Contains(errText, "unauthorized"):
+		hint = "The Brain rejected this token. The Agent may no longer be registered in that Brain, may be disabled, or the token was rotated. Create/verify the Agent in the Brain UI and update BRAIN_AGENT_TOKEN."
+	case strings.Contains(errText, "http 404"):
+		hint = "The configured URL does not expose the Brain Agent API. Verify BRAIN_AGENT_BRAIN_URL and the published Brain port."
+	case warning != "":
+		hint = "For separate Docker containers, do not use 127.0.0.1/localhost as the Brain URL."
+	}
+	return map[string]any{
+		"ok": true, "mode": "agent", "agent_id": r.cfg.AgentID, "brain_url": r.cfg.BrainURL,
+		"brain_connected": connected, "connection_state": state, "brain_url_warning": warning, "connection_hint": hint,
+		"configured_tasks": len(remote.Tasks), "config_source": d.ConfigSource, "cache_loaded_at": d.CacheLoadedAt,
+		"config_issued_at": remote.IssuedAt, "version": r.cfg.Version, "started_at": d.StartedAt,
+		"last_config_attempt_at": d.LastConfigAttemptAt, "last_config_success_at": d.LastConfigSuccessAt, "last_config_error": d.LastConfigError,
+		"last_heartbeat_at": d.LastHeartbeatAt, "last_heartbeat_success_at": d.LastHeartbeatSuccess, "last_heartbeat_error": d.LastHeartbeatError,
+		"last_connection_error_at": d.LastConnectionErrorAt, "last_connection_error": d.LastConnectionError,
+		"last_task_run_at": d.LastTaskRunAt, "last_task_error": d.LastTaskError,
+	}
 }
 
 func (r *Runner) loop(ctx context.Context) {
@@ -141,14 +210,32 @@ func (r *Runner) loop(ctx context.Context) {
 	defer refresh.Stop()
 	run := time.NewTicker(30 * time.Second)
 	defer run.Stop()
-	_ = r.refreshConfig(ctx)
+	heartbeat := time.NewTicker(time.Minute)
+	defer heartbeat.Stop()
+
+	// Heartbeat independently of config loading. This lets the Brain see the
+	// Agent even when its task configuration is temporarily broken.
+	if err := r.sendHeartbeat(ctx, Heartbeat{AgentID: r.cfg.AgentID, Version: r.cfg.Version, Status: "starting"}); err != nil {
+		slog.Warn("source agent initial heartbeat failed", "brain_url", r.cfg.BrainURL, "error", err)
+	}
+	if err := r.refreshConfig(ctx); err != nil {
+		slog.Warn("source agent config refresh failed", "brain_url", r.cfg.BrainURL, "error", err)
+	} else {
+		slog.Info("source agent connected to brain", "brain_url", r.cfg.BrainURL, "tasks", len(r.currentTasks()))
+	}
 	r.runDue(ctx)
 	for {
 		select {
 		case <-ctx.Done():
 			return
 		case <-refresh.C:
-			_ = r.refreshConfig(ctx)
+			if err := r.refreshConfig(ctx); err != nil {
+				slog.Warn("source agent config refresh failed", "brain_url", r.cfg.BrainURL, "error", err)
+			}
+		case <-heartbeat.C:
+			if err := r.sendHeartbeat(ctx, Heartbeat{AgentID: r.cfg.AgentID, Version: r.cfg.Version, Status: "online", Metadata: map[string]any{"configured_tasks": len(r.currentTasks())}}); err != nil {
+				slog.Warn("source agent heartbeat failed", "brain_url", r.cfg.BrainURL, "error", err)
+			}
 		case <-run.C:
 			r.runDue(ctx)
 		case <-r.wake:
@@ -157,35 +244,72 @@ func (r *Runner) loop(ctx context.Context) {
 	}
 }
 
+func (r *Runner) currentTasks() []Task {
+	r.mu.RLock()
+	defer r.mu.RUnlock()
+	return append([]Task(nil), r.remote.Tasks...)
+}
+
 func (r *Runner) refreshConfig(ctx context.Context) error {
+	r.diagMu.Lock()
+	r.diag.LastConfigAttemptAt = time.Now().UTC()
+	r.diagMu.Unlock()
 	req, err := http.NewRequestWithContext(ctx, http.MethodGet, r.cfg.BrainURL+"/api/v1/agent/config", nil)
 	if err != nil {
+		r.recordConfigResult(err)
 		return err
 	}
 	r.auth(req)
 	resp, err := r.http.Do(req)
 	if err != nil {
+		r.recordConfigResult(err)
 		return err
 	}
 	defer resp.Body.Close()
 	if resp.StatusCode/100 != 2 {
-		return fmt.Errorf("brain config returned HTTP %d", resp.StatusCode)
+		b, _ := io.ReadAll(io.LimitReader(resp.Body, 4096))
+		err := fmt.Errorf("brain config HTTP %d: %s", resp.StatusCode, strings.TrimSpace(string(b)))
+		r.recordConfigResult(err)
+		return err
 	}
 	var cfg RemoteConfig
 	if err := json.NewDecoder(io.LimitReader(resp.Body, 4<<20)).Decode(&cfg); err != nil {
+		r.recordConfigResult(err)
 		return err
 	}
 	if cfg.Agent.ID != "" && cfg.Agent.ID != r.cfg.AgentID {
-		return fmt.Errorf("brain returned config for unexpected agent %q", cfg.Agent.ID)
+		err := fmt.Errorf("brain returned config for unexpected agent %q", cfg.Agent.ID)
+		r.recordConfigResult(err)
+		return err
 	}
 	r.mu.Lock()
 	r.remote = cfg
 	r.mu.Unlock()
 	r.saveCachedConfig(cfg)
-	_ = r.sendHeartbeat(ctx, Heartbeat{AgentID: r.cfg.AgentID, Version: r.cfg.Version, Status: "online", Metadata: map[string]any{"configured_tasks": len(cfg.Tasks)}})
+	r.recordConfigResult(nil)
+	if err := r.sendHeartbeat(ctx, Heartbeat{AgentID: r.cfg.AgentID, Version: r.cfg.Version, Status: "online", Metadata: map[string]any{"configured_tasks": len(cfg.Tasks)}}); err != nil {
+		slog.Warn("source agent heartbeat after config refresh failed", "error", err)
+	}
 	return nil
 }
 
+func (r *Runner) recordConfigResult(err error) {
+	r.diagMu.Lock()
+	defer r.diagMu.Unlock()
+	now := time.Now().UTC()
+	if err != nil {
+		r.diag.LastConfigError = err.Error()
+		r.diag.LastConnectionErrorAt = now
+		r.diag.LastConnectionError = err.Error()
+		return
+	}
+	r.diag.LastConfigSuccessAt = now
+	r.diag.LastConfigError = ""
+	r.diag.ConfigSource = "brain"
+	r.diag.LastConnectionErrorAt = time.Time{}
+	r.diag.LastConnectionError = ""
+}
+
 func (r *Runner) runDue(ctx context.Context) {
 	r.mu.RLock()
 	tasks := append([]Task(nil), r.remote.Tasks...)
@@ -217,6 +341,9 @@ func (r *Runner) runDue(ctx context.Context) {
 
 func (r *Runner) runTask(ctx context.Context, task Task) {
 	started := time.Now().UTC()
+	r.diagMu.Lock()
+	r.diag.LastTaskRunAt = started
+	r.diagMu.Unlock()
 	docs, err := r.pollTask(ctx, task)
 	if err == nil && len(docs) > 0 {
 		for start := 0; start < len(docs); start += r.cfg.BatchSize {
@@ -234,6 +361,13 @@ func (r *Runner) runTask(ctx context.Context, task Task) {
 		}
 	}
 	_ = r.state.FinishTask(ctx, task.ID, started, err)
+	r.diagMu.Lock()
+	if err != nil {
+		r.diag.LastTaskError = err.Error()
+	} else {
+		r.diag.LastTaskError = ""
+	}
+	r.diagMu.Unlock()
 	h := Heartbeat{AgentID: r.cfg.AgentID, Version: r.cfg.Version, Status: "ok", LastRunAt: started, TasksChecked: 1, Documents: len(docs)}
 	if err != nil {
 		h.Status = "error"
@@ -516,23 +650,48 @@ func (r *Runner) sendBatch(ctx context.Context, taskID string, docs []Document)
 	return nil
 }
 func (r *Runner) sendHeartbeat(ctx context.Context, h Heartbeat) error {
+	r.diagMu.Lock()
+	r.diag.LastHeartbeatAt = time.Now().UTC()
+	r.diagMu.Unlock()
 	data, _ := json.Marshal(h)
 	req, err := http.NewRequestWithContext(ctx, http.MethodPost, r.cfg.BrainURL+"/api/v1/agent/heartbeat", bytes.NewReader(data))
 	if err != nil {
+		r.recordHeartbeatResult(err)
 		return err
 	}
 	req.Header.Set("Content-Type", "application/json")
 	r.auth(req)
 	resp, err := r.http.Do(req)
 	if err != nil {
+		r.recordHeartbeatResult(err)
 		return err
 	}
 	defer resp.Body.Close()
 	if resp.StatusCode/100 != 2 {
-		return fmt.Errorf("heartbeat HTTP %d", resp.StatusCode)
+		b, _ := io.ReadAll(io.LimitReader(resp.Body, 4096))
+		err := fmt.Errorf("heartbeat HTTP %d: %s", resp.StatusCode, strings.TrimSpace(string(b)))
+		r.recordHeartbeatResult(err)
+		return err
 	}
+	r.recordHeartbeatResult(nil)
 	return nil
 }
+
+func (r *Runner) recordHeartbeatResult(err error) {
+	r.diagMu.Lock()
+	defer r.diagMu.Unlock()
+	now := time.Now().UTC()
+	if err != nil {
+		r.diag.LastHeartbeatError = err.Error()
+		r.diag.LastConnectionErrorAt = now
+		r.diag.LastConnectionError = err.Error()
+		return
+	}
+	r.diag.LastHeartbeatSuccess = now
+	r.diag.LastHeartbeatError = ""
+	r.diag.LastConnectionErrorAt = time.Time{}
+	r.diag.LastConnectionError = ""
+}
 func (r *Runner) auth(req *http.Request) {
 	req.Header.Set("Authorization", "Bearer "+r.cfg.Token)
 	req.Header.Set("X-Brain-Agent-ID", r.cfg.AgentID)
@@ -597,6 +756,12 @@ func (r *Runner) loadCachedConfig() {
 	r.mu.Lock()
 	r.remote = cfg
 	r.mu.Unlock()
+	r.diagMu.Lock()
+	if r.diag.ConfigSource == "" {
+		r.diag.ConfigSource = "cache"
+	}
+	r.diag.CacheLoadedAt = time.Now().UTC()
+	r.diagMu.Unlock()
 }
 
 type localState struct {
diff --git a/internal/sourceagent/sourceagent_test.go b/internal/sourceagent/sourceagent_test.go
index 970ef5e..7c64900 100644
--- a/internal/sourceagent/sourceagent_test.go
+++ b/internal/sourceagent/sourceagent_test.go
@@ -89,3 +89,90 @@ func TestSitemapIndexCollectsChildURLs(t *testing.T) {
 		t.Fatalf("unexpected sitemap items: %+v", items)
 	}
 }
+
+func TestRunnerStatusDoesNotTreatCachedConfigAsLiveConnection(t *testing.T) {
+	r := &Runner{
+		cfg:    RunnerConfig{BrainURL: "http://127.0.0.1:8091", AgentID: "agent-test", Version: "test"},
+		remote: RemoteConfig{IssuedAt: time.Now().UTC(), Tasks: []Task{{ID: "cached-task"}}},
+		diag:   runnerDiagnostics{ConfigSource: "cache", CacheLoadedAt: time.Now().UTC()},
+	}
+	st := r.Status()
+	if st["brain_connected"] != false {
+		t.Fatalf("cached config must not be reported as live connection: %+v", st)
+	}
+	if st["connection_state"] != "cached_config_only" {
+		t.Fatalf("unexpected state: %+v", st)
+	}
+	if st["brain_url_warning"] == "" {
+		t.Fatalf("expected loopback warning: %+v", st)
+	}
+}
+
+func TestRunnerStatusReportsFreshBrainConnection(t *testing.T) {
+	now := time.Now().UTC()
+	r := &Runner{
+		cfg:    RunnerConfig{BrainURL: "http://brain:8090", AgentID: "agent-test", Version: "test"},
+		remote: RemoteConfig{IssuedAt: now},
+		diag:   runnerDiagnostics{ConfigSource: "brain", LastConfigAttemptAt: now.Add(-time.Second), LastConfigSuccessAt: now},
+	}
+	st := r.Status()
+	if st["brain_connected"] != true || st["connection_state"] != "connected" {
+		t.Fatalf("expected live connection: %+v", st)
+	}
+}
+
+func TestRunnerStatusAcceptsConnectedLoopbackForNativeTest(t *testing.T) {
+	now := time.Now().UTC()
+	r := &Runner{
+		cfg:    RunnerConfig{BrainURL: "http://127.0.0.1:8091", AgentID: "agent-test", Version: "test"},
+		remote: RemoteConfig{IssuedAt: now},
+		diag:   runnerDiagnostics{ConfigSource: "brain", LastConfigSuccessAt: now, LastHeartbeatSuccess: now},
+	}
+	st := r.Status()
+	if st["brain_connected"] != true {
+		t.Fatalf("expected connected loopback to be accepted: %+v", st)
+	}
+	if st["brain_url_warning"] != "" {
+		t.Fatalf("connected native loopback must not be warned as broken: %+v", st)
+	}
+}
+
+func TestEnsureInboxClassifierVersionRequeuesArchivedOnce(t *testing.T) {
+	ctx := context.Background()
+	store, err := OpenStore(t.TempDir())
+	if err != nil {
+		t.Fatal(err)
+	}
+	defer store.Close()
+	agent, _, err := store.CreateAgent(ctx, "agent-a", "Agent A")
+	if err != nil {
+		t.Fatal(err)
+	}
+	task, err := store.UpsertTask(ctx, Task{ID: "task-a", AgentID: agent.ID, Name: "Security", Type: "rss", URL: "https://example.org/feed", Enabled: true, PollInterval: "1h", MaxItems: 10})
+	if err != nil {
+		t.Fatal(err)
+	}
+	_, err = store.Ingest(ctx, agent.ID, task.ID, []Document{{URL: "https://example.org/a", Title: "Security update", Text: "Dies ist ein ausreichend langer Sicherheitsartikel mit mehreren Details, damit das Dokument in die Source Inbox aufgenommen und klassifiziert werden kann."}})
+	if err != nil {
+		t.Fatal(err)
+	}
+	claimed, err := store.ClaimInbox(ctx, 1)
+	if err != nil || len(claimed) != 1 {
+		t.Fatalf("claim failed: %#v %v", claimed, err)
+	}
+	if err := store.CompleteClassification(ctx, claimed[0].ID, "archived", .4, "kb-1", map[string]any{}); err != nil {
+		t.Fatal(err)
+	}
+	n, err := store.EnsureInboxClassifierVersion(ctx, 2)
+	if err != nil || n != 1 {
+		t.Fatalf("expected one requeued archived item, n=%d err=%v", n, err)
+	}
+	items, err := store.ListInbox(ctx, "received", 10)
+	if err != nil || len(items) != 1 {
+		t.Fatalf("expected requeued received item: %#v %v", items, err)
+	}
+	n, err = store.EnsureInboxClassifierVersion(ctx, 2)
+	if err != nil || n != 0 {
+		t.Fatalf("classifier migration must be one-shot, n=%d err=%v", n, err)
+	}
+}
diff --git a/internal/sourceagent/store.go b/internal/sourceagent/store.go
index 8684865..cbf3347 100644
--- a/internal/sourceagent/store.go
+++ b/internal/sourceagent/store.go
@@ -63,6 +63,9 @@ func (s *Store) init(ctx context.Context) error {
 			config_json TEXT NOT NULL DEFAULT '{}', created_at_ns INTEGER NOT NULL, updated_at_ns INTEGER NOT NULL
 		) WITHOUT ROWID`,
 		`CREATE INDEX IF NOT EXISTS idx_source_tasks_agent ON source_tasks(agent_id, enabled, updated_at_ns)`,
+		`CREATE TABLE IF NOT EXISTS source_meta (
+			key TEXT PRIMARY KEY, value TEXT NOT NULL
+		) WITHOUT ROWID`,
 		`CREATE TABLE IF NOT EXISTS source_inbox (
 			id TEXT PRIMARY KEY, agent_id TEXT NOT NULL, task_id TEXT NOT NULL, external_id TEXT NOT NULL DEFAULT '',
 			url TEXT NOT NULL, canonical_url TEXT NOT NULL, title TEXT NOT NULL, published_at_ns INTEGER NOT NULL DEFAULT 0,
@@ -85,6 +88,43 @@ func (s *Store) init(ctx context.Context) error {
 	return nil
 }
 
+func (s *Store) EnsureInboxClassifierVersion(ctx context.Context, version int) (int, error) {
+	if version < 1 {
+		version = 1
+	}
+	s.mu.Lock()
+	defer s.mu.Unlock()
+	tx, err := s.db.BeginTx(ctx, nil)
+	if err != nil {
+		return 0, err
+	}
+	defer tx.Rollback()
+	current := 0
+	var raw string
+	err = tx.QueryRowContext(ctx, `SELECT value FROM source_meta WHERE key='inbox_classifier_version'`).Scan(&raw)
+	if err != nil && !errors.Is(err, sql.ErrNoRows) {
+		return 0, err
+	}
+	if err == nil {
+		_, _ = fmt.Sscanf(raw, "%d", &current)
+	}
+	if current >= version {
+		return 0, tx.Commit()
+	}
+	res, err := tx.ExecContext(ctx, `UPDATE source_inbox SET status='received', updated_at_ns=? WHERE status='archived'`, time.Now().UTC().UnixNano())
+	if err != nil {
+		return 0, err
+	}
+	requeued64, _ := res.RowsAffected()
+	if _, err := tx.ExecContext(ctx, `INSERT INTO source_meta(key,value) VALUES('inbox_classifier_version',?) ON CONFLICT(key) DO UPDATE SET value=excluded.value`, fmt.Sprint(version)); err != nil {
+		return 0, err
+	}
+	if err := tx.Commit(); err != nil {
+		return 0, err
+	}
+	return int(requeued64), nil
+}
+
 func GenerateToken() (string, string, error) {
 	buf := make([]byte, 32)
 	if _, err := rand.Read(buf); err != nil {
@@ -181,7 +221,7 @@ func (s *Store) ListAgents(ctx context.Context) ([]Agent, error) {
 		return nil, err
 	}
 	defer rows.Close()
-	var out []Agent
+	out := make([]Agent, 0)
 	for rows.Next() {
 		var a Agent
 		var en int
@@ -198,6 +238,18 @@ func (s *Store) ListAgents(ctx context.Context) ([]Agent, error) {
 	return out, rows.Err()
 }
 
+func (s *Store) TouchAgent(ctx context.Context, id string) error {
+	result, err := s.db.ExecContext(ctx, `UPDATE source_agents SET last_seen_ns=? WHERE id=?`, time.Now().UTC().UnixNano(), id)
+	if err != nil {
+		return err
+	}
+	n, _ := result.RowsAffected()
+	if n == 0 {
+		return sql.ErrNoRows
+	}
+	return nil
+}
+
 func (s *Store) Authenticate(ctx context.Context, token string) (Agent, error) {
 	if strings.TrimSpace(token) == "" {
 		return Agent{}, errors.New("empty agent token")
@@ -267,6 +319,13 @@ func (s *Store) UpsertTask(ctx context.Context, t Task) (Task, error) {
 	if strings.TrimSpace(t.AgentID) == "" {
 		return Task{}, errors.New("agent_id required")
 	}
+	var agentExists int
+	if err := s.db.QueryRowContext(ctx, `SELECT 1 FROM source_agents WHERE id=?`, t.AgentID).Scan(&agentExists); err != nil {
+		if errors.Is(err, sql.ErrNoRows) {
+			return Task{}, fmt.Errorf("unknown source agent %q; create/register the agent in the Brain first", t.AgentID)
+		}
+		return Task{}, err
+	}
 	cats, _ := json.Marshal(uniqueStrings(t.Categories))
 	cfg, _ := json.Marshal(t.Config)
 	now := time.Now().UTC()
@@ -291,7 +350,7 @@ func (s *Store) ListTasks(ctx context.Context, agentID string) ([]Task, error) {
 		return nil, err
 	}
 	defer rows.Close()
-	var out []Task
+	out := make([]Task, 0)
 	for rows.Next() {
 		var t Task
 		var en int
@@ -518,7 +577,7 @@ func (s *Store) ListInbox(ctx context.Context, status string, limit int) ([]Inbo
 		return nil, err
 	}
 	defer rows.Close()
-	var out []InboxDocument
+	out := make([]InboxDocument, 0)
 	for rows.Next() {
 		d, err := scanInbox(rows)
 		if err != nil {
diff --git a/internal/web/server.go b/internal/web/server.go
index c8e69b9..f4a372b 100644
--- a/internal/web/server.go
+++ b/internal/web/server.go
@@ -29,6 +29,7 @@ type Server struct {
 	Graph        *graph.Store
 	Broker       *activity.Broker
 	APIKey       string
+	PublicURL    string
 	SourceAgents *sourceagent.Store
 }
 
@@ -88,7 +89,23 @@ func (s *Server) headers(next http.Handler) http.Handler {
 	})
 }
 func (s *Server) handleStatus(w http.ResponseWriter, r *http.Request) {
-	writeJSON(w, 200, s.Engine.Status())
+	out := s.Engine.Status()
+	if s.SourceAgents != nil {
+		ctx, cancel := contextTimeout(r, 5*time.Second)
+		defer cancel()
+		if agents, err := s.SourceAgents.ListAgents(ctx); err == nil {
+			online := 0
+			for _, a := range agents {
+				if !a.LastSeen.IsZero() && time.Since(a.LastSeen) < 15*time.Minute {
+					online++
+				}
+			}
+			tasks, _ := s.SourceAgents.ListTasks(ctx, "")
+			stats, _ := s.SourceAgents.Stats(ctx)
+			out["source_agents"] = map[string]any{"registered": len(agents), "online": online, "tasks": len(tasks), "inbox": stats, "brain_url": s.PublicURL}
+		}
+	}
+	writeJSON(w, 200, out)
 }
 func (s *Server) handleGraph(w http.ResponseWriter, r *http.Request) {
 	writeJSON(w, 200, s.Graph.Snapshot())
diff --git a/internal/web/source_agents.go b/internal/web/source_agents.go
index 0aa9385..97bb4d4 100644
--- a/internal/web/source_agents.go
+++ b/internal/web/source_agents.go
@@ -38,9 +38,25 @@ func (s *Server) handleListSourceAgents(w http.ResponseWriter, r *http.Request)
 		writeJSON(w, 500, map[string]string{"error": err.Error()})
 		return
 	}
-	tasks, _ := s.SourceAgents.ListTasks(ctx, "")
-	stats, _ := s.SourceAgents.Stats(ctx)
-	writeJSON(w, 200, map[string]any{"agents": agents, "tasks": tasks, "inbox": stats})
+	tasks, err := s.SourceAgents.ListTasks(ctx, "")
+	if err != nil {
+		writeJSON(w, 500, map[string]string{"error": err.Error()})
+		return
+	}
+	stats, err := s.SourceAgents.Stats(ctx)
+	if err != nil {
+		writeJSON(w, 500, map[string]string{"error": err.Error()})
+		return
+	}
+	// Keep collection fields JSON-stable. A nil Go slice serializes as null,
+	// which previously crashed the Source Agents UI when there were no tasks.
+	if agents == nil {
+		agents = []sourceagent.Agent{}
+	}
+	if tasks == nil {
+		tasks = []sourceagent.Task{}
+	}
+	writeJSON(w, 200, map[string]any{"agents": agents, "tasks": tasks, "inbox": stats, "brain_url": s.PublicURL})
 }
 func (s *Server) handleCreateSourceAgent(w http.ResponseWriter, r *http.Request) {
 	if !s.sourceStoreAvailable(w) || !s.adminAuthorized(w, r) {
@@ -61,7 +77,7 @@ func (s *Server) handleCreateSourceAgent(w http.ResponseWriter, r *http.Request)
 		writeJSON(w, 400, map[string]string{"error": err.Error()})
 		return
 	}
-	writeJSON(w, http.StatusCreated, map[string]any{"agent": a, "token": token, "token_notice": "Der Token wird nur in dieser Antwort im Klartext ausgegeben."})
+	writeJSON(w, http.StatusCreated, map[string]any{"agent": a, "token": token, "brain_url": s.PublicURL, "token_notice": "Der Token wird nur in dieser Antwort im Klartext ausgegeben."})
 }
 func (s *Server) handlePatchSourceAgent(w http.ResponseWriter, r *http.Request) {
 	if !s.sourceStoreAvailable(w) || !s.adminAuthorized(w, r) {
@@ -109,7 +125,7 @@ func (s *Server) handleRotateSourceAgentToken(w http.ResponseWriter, r *http.Req
 		writeJSON(w, 404, map[string]string{"error": err.Error()})
 		return
 	}
-	writeJSON(w, 200, map[string]any{"token": token, "token_notice": "Der neue Token wird nur in dieser Antwort im Klartext ausgegeben."})
+	writeJSON(w, 200, map[string]any{"token": token, "brain_url": s.PublicURL, "token_notice": "Der neue Token wird nur in dieser Antwort im Klartext ausgegeben."})
 }
 func (s *Server) handleListSourceTasks(w http.ResponseWriter, r *http.Request) {
 	if !s.sourceStoreAvailable(w) || !s.adminAuthorized(w, r) {
@@ -247,6 +263,7 @@ func (s *Server) handleAgentConfig(w http.ResponseWriter, r *http.Request) {
 		writeJSON(w, 500, map[string]string{"error": err.Error()})
 		return
 	}
+	_ = s.SourceAgents.TouchAgent(ctx, a.ID)
 	writeJSON(w, 200, cfg)
 }
 func (s *Server) handleAgentHeartbeat(w http.ResponseWriter, r *http.Request) {
diff --git a/internal/web/static/source-agents.html b/internal/web/static/source-agents.html
index a20b7b2..59888ab 100644
--- a/internal/web/static/source-agents.html
+++ b/internal/web/static/source-agents.html
@@ -10,13 +10,14 @@
 <header><div><strong>SOURCE AGENTS</strong><small>Verteilte Quellenbeobachtung · Inbox vor SearXNG</small></div><nav><a href="/">BRAIN</a><a href="/analysis.html">ANALYSE</a></nav></header>
 <main>
   <section class="panel auth"><div><h2>Administration</h2><p>Falls <code>BRAIN_API_KEY</code> gesetzt ist, wird er nur in dieser Browser-Session gehalten.</p></div><input id="apiKey" type="password" placeholder="BRAIN_API_KEY (optional)"><button id="saveKey">Übernehmen</button></section>
+  <section id="brainURLWarning" class="panel hidden"></section>
   <section class="stats" id="stats"><article><b id="agentCount">0</b><span>Agents</span></article><article><b id="taskCount">0</b><span>Tasks</span></article><article><b id="candidateCount">0</b><span>Inbox-Kandidaten</span></article><article><b id="receivedCount">0</b><span>Queue</span></article></section>
   <section class="grid">
     <article class="panel"><h2>Agent anlegen</h2><label>Name<input id="agentName" placeholder="Security News Frankfurt"></label><label>ID (optional)<input id="agentID" placeholder="security-frankfurt"></label><button id="createAgent">AGENT ERSTELLEN</button><pre id="tokenOutput" class="token-output hidden"></pre></article>
     <article class="panel"><h2>Polling-Aufgabe</h2><label>Agent<select id="taskAgent"></select></label><div class="two"><label>Typ<select id="taskType"><option>rss</option><option>atom</option><option>sitemap</option><option>web</option></select></label><label>Intervall<input id="taskInterval" value="4h"></label></div><label>Name<input id="taskName" placeholder="Microsoft Security Blog"></label><label>URL<input id="taskURL" placeholder="https://example.org/feed.xml"></label><label>Kategorien<input id="taskCategories" placeholder="Security, Microsoft"></label><label>Max. Elemente pro Lauf<input id="taskMaxItems" type="number" min="1" max="500" value="20"></label><label class="check"><input id="taskRefetchSeen" type="checkbox"> Bereits bekannte URLs erneut auf Inhaltsänderungen prüfen</label><button id="createTask">TASK SPEICHERN</button></article>
   </section>
   <section class="panel"><div class="title-row"><div><h2>Agents</h2><p>Tokenrechte: config · heartbeat · ingest. Kein Graph-/Adminzugriff.</p></div><button id="reload">AKTUALISIEREN</button></div><div id="agents" class="cards"></div></section>
-  <section class="panel"><div class="title-row"><div><h2>Source Inbox</h2><p>Nur als <b>candidate</b> klassifizierte Dokumente werden vor SearXNG durchsucht. Graph-Nodes entstehen erst nach tatsächlichem Claim-Grounding.</p></div><select id="inboxFilter"><option value="">alle</option><option>received</option><option>processing</option><option>candidate</option><option>archived</option><option>used</option></select></div><div class="table-wrap"><table><thead><tr><th>Status</th><th>Titel / Quelle</th><th>Relevanz</th><th>Agent / Task</th><th>Eingang</th></tr></thead><tbody id="inbox"></tbody></table></div></section>
+  <section class="panel"><div class="title-row"><div><h2>Source Inbox</h2><p><b>candidate</b> berücksichtigt KB-Nähe, kuratierten Task-Kontext, Aktualität und News-/Advisory-Signale. Graph-Nodes entstehen erst nach tatsächlichem Claim-Grounding.</p></div><select id="inboxFilter"><option value="">alle</option><option>received</option><option>processing</option><option>candidate</option><option>archived</option><option>used</option></select></div><div class="table-wrap"><table><thead><tr><th>Status</th><th>Titel / Quelle</th><th>Priorität / KB-Nähe</th><th>Agent / Task</th><th>Eingang</th></tr></thead><tbody id="inbox"></tbody></table></div></section>
 </main>
 <div id="toast"></div>
 <script src="/source-agents.js"></script>
diff --git a/internal/web/static/source-agents.js b/internal/web/static/source-agents.js
index 2602e96..5ed5319 100644
--- a/internal/web/static/source-agents.js
+++ b/internal/web/static/source-agents.js
@@ -1,18 +1,199 @@
 (() => {
-  const $=id=>document.getElementById(id); let snapshot={agents:[],tasks:[],inbox:{}};
-  $('apiKey').value=sessionStorage.getItem('brain_api_key')||'';
-  $('saveKey').onclick=()=>{sessionStorage.setItem('brain_api_key',$('apiKey').value.trim());toast('API-Key für diese Session gespeichert.');loadAll()};
-  function headers(){const h={'Content-Type':'application/json'},key=sessionStorage.getItem('brain_api_key')||'';if(key)h.Authorization=`Bearer ${key}`;return h}
-  async function api(path,opt={}){const res=await fetch(path,{...opt,headers:{...headers(),...(opt.headers||{})}});const data=await res.json().catch(()=>({}));if(!res.ok)throw new Error(data.error||`HTTP ${res.status}`);return data}
-  function toast(msg){const t=$('toast');t.textContent=msg;t.classList.add('show');setTimeout(()=>t.classList.remove('show'),3500)}
-  function esc(v){return String(v??'').replace(/[&<>"']/g,c=>({'&':'&amp;','<':'&lt;','>':'&gt;','"':'&quot;',"'":'&#39;'}[c]))}
-  function when(v){if(!v)return 'nie';const d=new Date(v);if(Number.isNaN(d.getTime()))return 'nie';return d.toLocaleString()}
-  async function loadAll(){try{snapshot=await api('/api/source-agents');render();await loadInbox()}catch(e){toast(e.message)}}
-  function render(){const {agents=[],tasks=[],inbox={}}=snapshot;$('agentCount').textContent=agents.length;$('taskCount').textContent=tasks.length;$('candidateCount').textContent=inbox.candidate||0;$('receivedCount').textContent=(inbox.received||0)+(inbox.processing||0);$('taskAgent').innerHTML=agents.map(a=>`<option value="${esc(a.id)}">${esc(a.name)} · ${esc(a.id)}</option>`).join('');$('agents').innerHTML=agents.length?agents.map(a=>{const own=tasks.filter(t=>t.agent_id===a.id),online=a.last_seen&&Date.now()-new Date(a.last_seen).getTime()<15*60*1000;return `<div class="card"><div class="card-head"><div><b>${esc(a.name)}</b><small>${esc(a.id)}</small></div><span class="${online?'status-online':'status-offline'}">● ${online?'online':'offline'}</span></div><small>Version ${esc(a.version||'—')} · letzter Kontakt ${esc(when(a.last_seen))}</small>${a.last_error?`<p>${esc(a.last_error)}</p>`:''}<div class="actions"><button data-rotate="${esc(a.id)}">TOKEN ROTIEREN</button><button data-toggle="${esc(a.id)}" data-enabled="${a.enabled}">${a.enabled?'DEAKTIVIEREN':'AKTIVIEREN'}</button><button data-delete-agent="${esc(a.id)}">LÖSCHEN</button></div>${own.map(t=>`<div class="task"><b>${esc(t.name)} · ${esc(t.type)} · ${esc(t.poll_interval)}</b><span>${esc(t.url)}</span><div class="actions"><button data-delete-task="${esc(t.id)}">TASK LÖSCHEN</button></div></div>`).join('')}</div>`}).join(''):'<p class="muted">Noch keine Agenten konfiguriert.</p>';wireActions()}
-  function wireActions(){document.querySelectorAll('[data-rotate]').forEach(b=>b.onclick=async()=>{try{const d=await api(`/api/source-agents/${b.dataset.rotate}/rotate-token`,{method:'POST'});showToken(b.dataset.rotate,d.token);await loadAll()}catch(e){toast(e.message)}});document.querySelectorAll('[data-toggle]').forEach(b=>b.onclick=async()=>{try{await api(`/api/source-agents/${b.dataset.toggle}`,{method:'PATCH',body:JSON.stringify({enabled:b.dataset.enabled!=='true'})});await loadAll()}catch(e){toast(e.message)}});document.querySelectorAll('[data-delete-agent]').forEach(b=>b.onclick=async()=>{if(!confirm('Agent inklusive Tasks löschen?'))return;try{await api(`/api/source-agents/${b.dataset.deleteAgent}`,{method:'DELETE'});await loadAll()}catch(e){toast(e.message)}});document.querySelectorAll('[data-delete-task]').forEach(b=>b.onclick=async()=>{try{await api(`/api/source-tasks/${b.dataset.deleteTask}`,{method:'DELETE'});await loadAll()}catch(e){toast(e.message)}})}
-  function showToken(id,token){const brain=location.origin;$('tokenOutput').textContent=`Token nur jetzt kopieren:\n${token}\n\nAgent-ENV:\nBRAIN_MODE=agent\nBRAIN_AGENT_BRAIN_URL=${brain}\nBRAIN_AGENT_ID=${id}\nBRAIN_AGENT_TOKEN=${token}`;$('tokenOutput').classList.remove('hidden')}
-  $('createAgent').onclick=async()=>{try{const d=await api('/api/source-agents',{method:'POST',body:JSON.stringify({id:$('agentID').value.trim(),name:$('agentName').value.trim()})});showToken(d.agent.id,d.token);$('agentName').value='';$('agentID').value='';await loadAll()}catch(e){toast(e.message)}};
-  $('createTask').onclick=async()=>{const agent=$('taskAgent').value;if(!agent)return toast('Zuerst einen Agent anlegen.');const task={name:$('taskName').value.trim(),type:$('taskType').value,url:$('taskURL').value.trim(),enabled:true,poll_interval:$('taskInterval').value.trim(),categories:$('taskCategories').value.split(',').map(x=>x.trim()).filter(Boolean),max_items:Number($('taskMaxItems').value)||20,config:{refetch_seen:$('taskRefetchSeen').checked?'true':'false'}};try{await api(`/api/source-agents/${encodeURIComponent(agent)}/tasks`,{method:'POST',body:JSON.stringify(task)});$('taskName').value='';$('taskURL').value='';await loadAll();toast('Polling-Aufgabe gespeichert.')}catch(e){toast(e.message)}};
-  async function loadInbox(){try{const status=$('inboxFilter').value;const d=await api(`/api/source-inbox?limit=100${status?`&status=${encodeURIComponent(status)}`:''}`);$('inbox').innerHTML=(d.documents||[]).map(x=>`<tr><td><span class="pill ${esc(x.status)}">${esc(x.status)}</span></td><td><a href="${esc(x.document.canonical_url||x.document.url)}" target="_blank" rel="noreferrer">${esc(x.document.title)}</a><br><span class="muted">${esc(x.document.source_name||x.document.source_base_url||'')}</span></td><td>${(Number(x.relevance||0)*100).toFixed(0)}%</td><td>${esc(x.agent_id)}<br><span class="muted">${esc(x.task_id)}</span></td><td>${esc(when(x.received_at))}</td></tr>`).join('')}catch(e){toast(e.message)}}
-  $('inboxFilter').onchange=loadInbox;$('reload').onclick=loadAll;loadAll();setInterval(loadAll,30000);
+  const $ = id => document.getElementById(id);
+  let snapshot = {agents: [], tasks: [], inbox: {}, brain_url: ''};
+
+  $('apiKey').value = sessionStorage.getItem('brain_api_key') || '';
+  $('saveKey').onclick = () => {
+    sessionStorage.setItem('brain_api_key', $('apiKey').value.trim());
+    toast('API-Key für diese Session gespeichert.');
+    loadAll();
+  };
+
+  function headers() {
+    const h = {'Content-Type': 'application/json'};
+    const key = sessionStorage.getItem('brain_api_key') || '';
+    if (key) h.Authorization = `Bearer ${key}`;
+    return h;
+  }
+
+  async function api(path, opt = {}) {
+    const res = await fetch(path, {...opt, headers: {...headers(), ...(opt.headers || {})}});
+    const data = await res.json().catch(() => ({}));
+    if (!res.ok) throw new Error(data.error || `HTTP ${res.status}`);
+    return data;
+  }
+
+  function toast(msg) {
+    const t = $('toast');
+    t.textContent = msg;
+    t.classList.add('show');
+    setTimeout(() => t.classList.remove('show'), 3500);
+  }
+
+  function esc(v) {
+    return String(v ?? '').replace(/[&<>"']/g, c => ({'&':'&amp;','<':'&lt;','>':'&gt;','"':'&quot;',"'":'&#39;'}[c]));
+  }
+
+  function when(v) {
+    if (!v) return 'nie';
+    const d = new Date(v);
+    if (Number.isNaN(d.getTime()) || d.getUTCFullYear() <= 1970) return 'nie';
+    return d.toLocaleString();
+  }
+
+  function browserUsesLoopback() {
+    return ['localhost', '127.0.0.1', '::1'].includes(location.hostname);
+  }
+
+  async function loadAll() {
+    try {
+      const raw = await api('/api/source-agents');
+      snapshot = {
+        ...raw,
+        agents: Array.isArray(raw.agents) ? raw.agents.filter(Boolean) : [],
+        tasks: Array.isArray(raw.tasks) ? raw.tasks.filter(Boolean) : [],
+        inbox: raw.inbox && typeof raw.inbox === 'object' ? raw.inbox : {},
+      };
+      render();
+      await loadInbox();
+    } catch (e) {
+      toast(e.message);
+    }
+  }
+
+  function render() {
+    const agents = Array.isArray(snapshot.agents) ? snapshot.agents : [];
+    const tasks = Array.isArray(snapshot.tasks) ? snapshot.tasks : [];
+    const inbox = snapshot.inbox && typeof snapshot.inbox === 'object' ? snapshot.inbox : {};
+    $('agentCount').textContent = agents.length;
+    $('taskCount').textContent = tasks.length;
+    $('candidateCount').textContent = inbox.candidate || 0;
+    $('receivedCount').textContent = (inbox.received || 0) + (inbox.processing || 0);
+
+    $('taskAgent').innerHTML = agents.map(a =>
+      `<option value="${esc(a.id)}">${esc(a.name)} · ${esc(a.id)}${a.last_seen ? '' : ' · noch nie verbunden'}</option>`
+    ).join('');
+
+    const bw = $('brainURLWarning');
+    if (!snapshot.brain_url) {
+      const dockerHint = browserUsesLoopback() && location.protocol === 'http:'
+        ? ` Für einen separaten Docker-Agent auf demselben Host wäre typischerweise <code>http://host.docker.internal:${esc(location.port || '8090')}</code> erreichbar.`
+        : '';
+      bw.classList.remove('hidden');
+      bw.innerHTML = `<b>BRAIN_PUBLIC_URL ist nicht gesetzt.</b><p>Die Browser-Adresse <code>${esc(location.origin)}</code> ist nicht automatisch eine vom Agent erreichbare Adresse.${dockerHint} Setze am Brain eine explizite <code>BRAIN_PUBLIC_URL</code>, damit neu erzeugte Agent-Konfigurationen keine falsche Loopback-Adresse übernehmen.</p>`;
+    } else {
+      bw.classList.add('hidden');
+      bw.innerHTML = '';
+    }
+
+    $('agents').innerHTML = agents.length ? agents.map(a => {
+      const own = tasks.filter(t => t.agent_id === a.id);
+      const lastSeenMs = a.last_seen ? new Date(a.last_seen).getTime() : 0;
+      const hasSeen = Number.isFinite(lastSeenMs) && lastSeenMs > 0 && new Date(a.last_seen).getUTCFullYear() > 1970;
+      const online = hasSeen && Date.now() - lastSeenMs < 15 * 60 * 1000;
+      const stateText = online ? 'online' : (hasSeen ? 'offline' : 'registriert / noch nie verbunden');
+      return `<div class="card">
+        <div class="card-head"><div><b>${esc(a.name)}</b><small>${esc(a.id)}</small></div><span class="${online ? 'status-online' : 'status-offline'}">● ${stateText}</span></div>
+        <small>Version ${esc(a.version || '—')} · letzter Kontakt ${esc(when(a.last_seen))} · Tasks ${own.length}</small>
+        ${a.last_error ? `<p>${esc(a.last_error)}</p>` : ''}
+        <div class="actions"><button data-rotate="${esc(a.id)}">TOKEN ROTIEREN</button><button data-toggle="${esc(a.id)}" data-enabled="${a.enabled}">${a.enabled ? 'DEAKTIVIEREN' : 'AKTIVIEREN'}</button><button data-delete-agent="${esc(a.id)}">LÖSCHEN</button></div>
+        ${own.map(t => `<div class="task"><b>${esc(t.name)} · ${esc(t.type)} · ${esc(t.poll_interval)}</b><span>${esc(t.url)}</span><div class="actions"><button data-delete-task="${esc(t.id)}">TASK LÖSCHEN</button></div></div>`).join('')}
+      </div>`;
+    }).join('') : '<p class="muted">In dieser Brain-Datenbank ist kein Agent registriert. Ein nur per ENV gestarteter Agent registriert sich aus Sicherheitsgründen nicht selbst; der Agent muss zuerst hier erstellt werden, damit sein Token im Brain bekannt ist.</p>';
+
+    wireActions();
+  }
+
+  function wireActions() {
+    document.querySelectorAll('[data-rotate]').forEach(b => b.onclick = async () => {
+      try {
+        const d = await api(`/api/source-agents/${b.dataset.rotate}/rotate-token`, {method: 'POST'});
+        showToken(b.dataset.rotate, d.token, d.brain_url);
+        await loadAll();
+      } catch (e) { toast(e.message); }
+    });
+    document.querySelectorAll('[data-toggle]').forEach(b => b.onclick = async () => {
+      try {
+        await api(`/api/source-agents/${b.dataset.toggle}`, {method: 'PATCH', body: JSON.stringify({enabled: b.dataset.enabled !== 'true'})});
+        await loadAll();
+      } catch (e) { toast(e.message); }
+    });
+    document.querySelectorAll('[data-delete-agent]').forEach(b => b.onclick = async () => {
+      if (!confirm('Agent inklusive Tasks löschen?')) return;
+      try {
+        await api(`/api/source-agents/${b.dataset.deleteAgent}`, {method: 'DELETE'});
+        await loadAll();
+      } catch (e) { toast(e.message); }
+    });
+    document.querySelectorAll('[data-delete-task]').forEach(b => b.onclick = async () => {
+      try {
+        await api(`/api/source-tasks/${b.dataset.deleteTask}`, {method: 'DELETE'});
+        await loadAll();
+      } catch (e) { toast(e.message); }
+    });
+  }
+
+  function showToken(id, token, brainURL = '') {
+    let brain = (brainURL || snapshot.brain_url || '').trim();
+    let note = '';
+    if (!brain) {
+      if (browserUsesLoopback() && location.protocol === 'http:') {
+        brain = `http://host.docker.internal:${location.port || '8090'}`;
+        note = `\n\nHINWEIS: ${location.origin} ist eine Loopback-Adresse des Browsers. Für einen separaten Docker-Agent wurde deshalb host.docker.internal vorgeschlagen. Alternativ BRAIN_PUBLIC_URL am Brain setzen.`;
+      } else {
+        brain = location.origin;
+        note = '\n\nHINWEIS: BRAIN_PUBLIC_URL ist nicht gesetzt. Prüfe, ob diese Adresse vom Agent wirklich erreichbar ist.';
+      }
+    }
+    $('tokenOutput').textContent = `Token nur jetzt kopieren:\n${token}\n\nAgent-ENV:\nBRAIN_MODE=agent\nBRAIN_AGENT_BRAIN_URL=${brain}\nBRAIN_AGENT_ID=${id}\nBRAIN_AGENT_TOKEN=${token}${note}`;
+    $('tokenOutput').classList.remove('hidden');
+  }
+
+  $('createAgent').onclick = async () => {
+    try {
+      const d = await api('/api/source-agents', {method: 'POST', body: JSON.stringify({id: $('agentID').value.trim(), name: $('agentName').value.trim()})});
+      showToken(d.agent.id, d.token, d.brain_url);
+      $('agentName').value = '';
+      $('agentID').value = '';
+      await loadAll();
+    } catch (e) { toast(e.message); }
+  };
+
+  $('createTask').onclick = async () => {
+    const agent = $('taskAgent').value;
+    if (!agent) return toast('Zuerst einen Agent im Brain anlegen. Ein Agent darf auch offline sein, um Tasks zugewiesen zu bekommen.');
+    const task = {
+      name: $('taskName').value.trim(), type: $('taskType').value, url: $('taskURL').value.trim(), enabled: true,
+      poll_interval: $('taskInterval').value.trim(), categories: $('taskCategories').value.split(',').map(x => x.trim()).filter(Boolean),
+      max_items: Number($('taskMaxItems').value) || 20, config: {refetch_seen: $('taskRefetchSeen').checked ? 'true' : 'false'}
+    };
+    try {
+      await api(`/api/source-agents/${encodeURIComponent(agent)}/tasks`, {method: 'POST', body: JSON.stringify(task)});
+      $('taskName').value = '';
+      $('taskURL').value = '';
+      await loadAll();
+      toast('Polling-Aufgabe gespeichert.');
+    } catch (e) { toast(e.message); }
+  };
+
+  async function loadInbox() {
+    try {
+      const status = $('inboxFilter').value;
+      const d = await api(`/api/source-inbox?limit=100${status ? `&status=${encodeURIComponent(status)}` : ''}`);
+      $('inbox').innerHTML = (d.documents || []).map(x => {
+        const m = x.metadata && typeof x.metadata === 'object' ? x.metadata : {};
+        const priority = Number(m.priority_score ?? x.relevance ?? 0);
+        const semantic = Number(m.semantic_similarity ?? x.relevance ?? 0);
+        const freshness = Number(m.freshness_score ?? 0);
+        const signal = Number(m.event_signal_score ?? 0);
+        const reason = m.classification_reason ? `<br><span class="muted">${esc(m.classification_reason)}</span>` : '';
+        return `<tr><td><span class="pill ${esc(x.status)}">${esc(x.status)}</span></td><td><a href="${esc(x.document.canonical_url || x.document.url)}" target="_blank" rel="noreferrer">${esc(x.document.title)}</a><br><span class="muted">${esc(x.document.source_name || x.document.source_base_url || '')}</span>${reason}</td><td><b>${(priority * 100).toFixed(0)}%</b><br><span class="muted">KB ${(semantic * 100).toFixed(0)}% · frisch ${(freshness * 100).toFixed(0)}% · Signal ${(signal * 100).toFixed(0)}%</span></td><td>${esc(x.agent_id)}<br><span class="muted">${esc(x.task_id)}</span></td><td>${esc(when(x.received_at))}</td></tr>`;
+      }).join('');
+    } catch (e) { toast(e.message); }
+  }
+
+  $('inboxFilter').onchange = loadInbox;
+  $('reload').onclick = loadAll;
+  loadAll();
+  setInterval(loadAll, 30000);
 })();
diff --git a/run-agent.ps1 b/run-agent.ps1
new file mode 100644
index 0000000..eea8467
--- /dev/null
+++ b/run-agent.ps1
@@ -0,0 +1,45 @@
+param(
+    [switch]$NoEnv
+)
+
+$ErrorActionPreference = "Stop"
+Set-StrictMode -Version Latest
+
+$ProjectRoot = $PSScriptRoot
+Set-Location $ProjectRoot
+
+function Import-DotEnv {
+    param([Parameter(Mandatory = $true)][string]$Path)
+
+    Get-Content -LiteralPath $Path | ForEach-Object {
+        $line = $_.Trim()
+        if (-not $line -or $line.StartsWith("#")) { return }
+
+        $parts = $line.Split("=", 2)
+        if ($parts.Count -ne 2) { return }
+
+        $name = $parts[0].Trim()
+        $value = $parts[1].Trim()
+        if (-not $name) { return }
+
+        if (($value.StartsWith('"') -and $value.EndsWith('"')) -or
+            ($value.StartsWith("'") -and $value.EndsWith("'"))) {
+            $value = $value.Substring(1, $value.Length - 2)
+        }
+
+        [Environment]::SetEnvironmentVariable($name, $value, "Process")
+    }
+}
+
+if (-not $NoEnv) {
+    $envFile = Join-Path $ProjectRoot ".env.agent"
+    if (Test-Path -LiteralPath $envFile) {
+        Import-DotEnv -Path $envFile
+    }
+    else {
+        Write-Warning ".env.agent nicht gefunden. Es werden vorhandene Umgebungsvariablen und Programm-Defaults verwendet."
+    }
+}
+
+go run ./cmd/brain
+exit $LASTEXITCODE