Bezpieczeństwo w ClawLabs

1. Infrastruktura

Agenci ClawLabs działają na dedykowanej infrastrukturze, zaprojektowanej z myślą o izolacji i bezpieczeństwie.

• Każdy agent uruchamiany jest na osobnym serwerze VPS — brak współdzielenia zasobów z innymi użytkownikami.
• Serwery zlokalizowane w centrach danych Hetzner w Niemczech (UE), objęte pełną zgodnością z RODO.
• Agenci działają w izolowanych kontenerach Docker z ograniczonym dostępem do sieci.
• Firewall na poziomie serwera z otwartymi wyłącznie niezbędnymi portami.

2. Szyfrowanie danych

Stosujemy wielowarstwowe szyfrowanie na każdym etapie przetwarzania danych.

• Cała komunikacja odbywa się po TLS/SSL — zarówno między przeglądarką a platformą, jak i między platformą a agentami.
• Klucze API zewnętrznych dostawców (OpenAI, Anthropic itp.) szyfrowane algorytmem AES-256-GCM i przechowywane w zaszyfrowanej formie.
• Hasła użytkowników hashowane algorytmem bcrypt z kosztem 12.
• Żadne hasło ani klucz API nie jest przechowywany w formie jawnej.

3. Uwierzytelnianie i kontrola dostępu

Wielopoziomowy system uwierzytelniania chroni dostęp do platformy i agentów.

• Weryfikacja dwuetapowa (2FA) przez e-mail przy każdym logowaniu.
• Rate limiting na endpointach logowania, rejestracji i API — ochrona przed atakami brute-force.
• Izolacja danych na poziomie tenanta — użytkownicy nie mają dostępu do danych innych użytkowników.
• Tokeny prowizyjne z czasem życia 30 minut. Tokeny gateway weryfikowane przy każdym zapytaniu.

4. Audyt i monitoring

Regularnie przeglądamy bezpieczeństwo platformy i reagujemy na potencjalne zagrożenia.

• Regularny audyt kodu pod kątem podatności OWASP Top 10 (SQL Injection, XSS, SSRF, CSRF itp.).
• Automatyczny health-check agentów co 5 minut z alertami przy wykryciu problemów.
• Logowanie zdarzeń bezpieczeństwa bez przechowywania danych osobowych w logach.
• Zero surowego SQL w kodzie — wszystkie zapytania przez ORM (Prisma) z walidacją Zod.

5. Usługi zewnętrzne

Korzystamy wyłącznie z renomowanych dostawców spełniających najwyższe standardy bezpieczeństwa.

• Stripe — Płatności przetwarzane przez Stripe (PCI DSS Level 1, SOC 2). Dane kart nigdy nie trafiają na nasze serwery.
• Hetzner — Serwery agentów w Hetzner Cloud (ISO 27001, SOC 2). Centra danych w UE.
• Vercel — Platforma hostowana na Vercel z automatycznym TLS, ochroną DDoS i SOC 2.

5.1. Ochrona platformowa Vercel

ClawLabs PRO jest hostowany na Vercel. Platforma dostarcza wielowarstwową ochronę na poziomie sieciowym i edge, zanim ruch dotrze do naszej aplikacji:

• Ochrona DDoS — blokada masowego zalewania ruchem rozpoznawanym jako atak wolumetryczny. Utrzymuje dostępność platformy podczas prób przeciążenia.
• Szyfrowanie TLS 1.3 — certyfikaty dla wszystkich endpointów automatycznie wystawiane i odnawiane. Komunikacja przeglądarka ↔ ClawLabs PRO zawsze szyfrowana end-to-end.
• Globalna sieć edge — requesty kończone w najbliższym do użytkownika punkcie sieciowym. Mniejsza powierzchnia ataku, niższe opóźnienia, większa odporność na awarie regionów.
• Walidacja requestów — malformed lub nadmiernie duże żądania są odrzucane przed dotarciem do logiki aplikacji. Dodatkowa warstwa ochrony przed atakami typu request smuggling.
• Szyfrowanie zmiennych środowiskowych — wszystkie sekrety (klucze API, hasła do baz, tokeny) są szyfrowane at-rest. Dostęp tylko podczas wykonywania funkcji.
• Detekcja botów (BotID) — automatyczne rozpoznawanie i blokowanie botów próbujących spamować formularze rejestracji, logowania i chat.
• Firewall na edge — reguły blokowania według IP, kraju, user-agenta lub ścieżki URL wykonywane przed logiką aplikacji. Pozwala szybko zamknąć dostęp w razie ataku.
• Attack Challenge Mode — gdy system wykryje anomalię w ruchu, nowi użytkownicy muszą przejść challenge (podobny do captcha) zanim uzyskają dostęp. Filtruje zautomatyzowany ruch atakujący.

6. Ostatni audyt — kwiecień 2026

W kwietniu 2026 przeprowadziliśmy kompleksowy audyt bezpieczeństwa obejmujący 5 równoległych analiz: uwierzytelnianie, walidacja danych wejściowych, infrastruktura, logika biznesowa i bezpieczeństwo gateway.

Wyniki audytu:

• Ochrona SSRF — blokada prywatnych sieci (RFC 1918, link-local, loopback) w endpointach proxy.
• Kryptograficznie bezpieczne kody weryfikacyjne (crypto.randomInt zamiast Math.random).
• Zaostrzony Content Security Policy — usunięto unsafe-eval, dodano object-src none, base-uri none, frame-ancestors none.
• Fail-closed uwierzytelnianie na wszystkich endpointach cron.
• Restrykcyjny CORS na gateway proxy — tylko domena clawlabs.pro.
• Walidacja regex na wszystkich danych wejściowych trafiających do komend shell.
• Aktualizacja Next.js z 14.1 do 14.2.35 — naprawiono 20 znanych CVE.

7. Zgłaszanie problemów

Jeśli odkryjesz lukę bezpieczeństwa lub podejrzane zachowanie, prosimy o kontakt: contact@infinityteam.io.

Traktujemy każde zgłoszenie priorytetowo i zobowiązujemy się do odpowiedzi w ciągu 48 godzin.

8. Coordinated Vulnerability Disclosure (CVD)

Stosujemy politykę skoordynowanego ujawniania podatności. Jeśli jesteś badaczem bezpieczeństwa, prosimy o kontakt pod adresem contact@infinityteam.io i przestrzeganie poniższych zasad.

• Odpowiedź w ciągu 48 godzin od zgłoszenia.
• Okno na naprawę i publikację: do 90 dni przed ujawnieniem publicznym.
• W zakresie: clawlabs.pro oraz agenci wdrażani przez platformę.
• Poza zakresem: infrastruktura Hetzner, Vercel, Neon, Stripe — zgłaszaj bezpośrednio u dostawców.
• Kanoniczny security.txt: clawlabs.pro/.well-known/security.txt (RFC 9116).

Nie prowadzimy obecnie programu bug bounty z wypłatą finansową, ale z wdzięcznością umieszczamy badaczy w sekcji podziękowań (po wyrażeniu zgody).

9. Model odpowiedzialności dzielonej (shared responsibility)

Bezpieczeństwo platformy to wspólna odpowiedzialność ClawLabs, naszych dostawców infrastruktury i Użytkownika. Certyfikaty Hetzner/Vercel dotyczą ich infrastruktury — nie zastępują naszej pracy po stronie aplikacji.

10. Co mamy / czego jeszcze nie mamy

Uczciwie: niżej lista tego, co już działa, oraz tego, czego jeszcze nie zrobiliśmy. Wolimy transparentność niż greenwashing.

Mamy:

• TLS 1.2/1.3 na wszystkich endpointach (automatyczne certyfikaty Vercel).
• Hasła użytkowników hashowane bcrypt z kosztem 12.
• Klucze API i tokeny gateway szyfrowane AES-256-GCM per użytkownik.
• Statyczną analizę kodu Semgrep (reguły OWASP) w CI.
• Dependabot — automatyczne PR przy podatnych pakietach npm.
• npm audit w pipeline CI/CD.
• Izolacja agentów w osobnych kontenerach Docker per tenant.
• Rate limiting na krytycznych endpointach (login, signup, API, admin).
• Serwerowy audit trail zgód compliance (RODO, AI Act).
• SPF + DKIM + DMARC na obu domenach (ochrona przed email spoofingiem).
• Szyfrowanie treści rozmów AES-256-GCM at-rest (od 16.04.2026).
• Monitoring błędów w czasie rzeczywistym (Sentry).
• HMAC-SHA256 na callbackach serwerów agentów.
• Ochrona CSRF — weryfikacja nagłówka Origin + Sec-Fetch-Site na żądaniach zmieniających stan.
• Screening sankcji EU — blokada dostępu z RU/BY/IR/KP/SY/CU (Rozporządzenie UE 833/2014, HTTP 451).
• Walidacja JSON Zod na polach konfiguracyjnych agentów — safe-parse zamiast crasha na uszkodzonych danych.
• Polityka rotacji kluczy kryptograficznych zgodna z NIST SP 800-57 (180 dni dla kluczy krytycznych).
• Zgody compliance z TTL 180 dni + wersjonowanie polityki prywatności — automatyczne odnowienie po zmianie (art. 49 RODO).
• Identyfikatory korelacji (x-request-id) w każdym żądaniu — szybka forensyka incydentów i śledzenie zgłoszeń.
• Panel admina za whitelistą adresów e-mail na poziomie middleware — brak enumeracji przez URL.
• Wersjonowanie polityki prywatności — wymuszenie ponownej akceptacji po istotnej zmianie.
• Soft-delete na krytycznych tabelach — brak trwałej utraty danych przy pomyłkach operacyjnych.
• Middleware Prisma z automatycznym szyfrowaniem/deszyfrowaniem wiadomości — niezależne od pamięci programisty.

Jeszcze nie mamy:

• Zewnętrznego pentestu (planowany przy osiągnięciu odpowiedniej skali użytkowników).
• Certyfikatu SOC 2 (dostawcy są certyfikowani — my jeszcze nie).
• Certyfikatu ISO 27001.
• Formalnego programu bug bounty z wypłatami (zobacz §8).

Aktualizujemy tę sekcję po każdym istotnym postępie. Jeśli brakuje Ci czegoś do decyzji o zakupie, napisz: contact@infinityteam.io.

11. Model card — jakich modeli AI używamy

Zgodnie z art. 50 oraz art. 53 AI Act (Rozporządzenie UE 2024/1689) publikujemy listę modeli AI, z którymi integruje się Platforma. Każdy dostawca (GPAI Provider) odpowiada za safety i compliance swojego modelu; ClawLabs jako Deployer odpowiada za bezpieczną transmisję i informowanie użytkowników.

Oficjalne model cards dostawców:

• Anthropic — docs.anthropic.com/claude/docs/models
• OpenAI — platform.openai.com/docs/models
• Google — ai.google.dev/models
• MiniMax — api.minimaxi.chat/docs
• xAI — docs.x.ai
• DeepSeek — api-docs.deepseek.com

Lista modeli może się zmieniać wraz z aktualizacjami dostawców. O znaczących zmianach (np. zmiana wersji modelu domyślnego) powiadamiamy w sekcji „Co nowego” w panelu oraz — jeśli zmienia się jurysdykcja transferu — poprzez modal zgody przy wysyłce pierwszej wiadomości.