> For the complete documentation index, see [llms.txt](https://eaclouddoc.eauditor.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://eaclouddoc.eauditor.eu/system/bezpieczenstwo.md). # Bezpieczenstwo System eAuditor wykorzystuje mechanizmy ochrony danych, kontroli dostępu oraz zabezpieczenia komunikacji między komponentami. Sposób utrzymania infrastruktury i konfiguracji części zabezpieczeń różni się w zależności od modelu wdrożenia. Ta strona opisuje bezpieczeństwo **eAuditor Cloud** (usługa SaaS) i **eAuditor On-Premise** (instalacja w infrastrukturze organizacji). Wybierz odpowiednią zakładkę w poszczególnych rozdziałach, aby sprawdzić informacje dotyczące używanej wersji. {% hint style="info" %} **Jak czytać tę stronę?** Informacje umieszczone nad zakładkami dotyczą obu modeli. Informacje w zakładce **eAuditor Cloud** lub **eAuditor On-Premise** odnoszą się wyłącznie do wskazanego modelu. Szczegółowy opis historycznych testów V9 AI nie stanowi potwierdzenia identycznego zakresu testów najnowszego wydania ani eAuditor Cloud. {% endhint %} ## Infrastruktura, ochrona i przechowywanie danych Bezpieczeństwo danych zależy zarówno od zastosowanych mechanizmów technicznych, jak i od tego, kto utrzymuje środowisko systemu. {% tabs %} {% tab title="eAuditor Cloud" %} ### Infrastruktura chmurowa i separacja danych * Wszystkie serwery **eAuditor Cloud** zlokalizowane są w **Polsce**, w centrach danych spełniających wymogi **RODO** oraz krajowych przepisów o ochronie danych osobowych. * Lokalizacja infrastruktury: * **Centrum danych OVHcloud w Ożarowie Mazowieckim (Kazimierza Kamińskiego 6, 05-850 Ożarów Mazowiecki, Polska) -** obiekcie zarządzanym przez [**OVHcloud sp. z o.o.**](https://www.ovhcloud.com/pl/), który posiada m.in. certyfikaty **ISO 27001, ISO 27017, ISO 27018, ISO 27701**, a także standardy **SOC 1/2/3** (stan na dzień 13.11.2025). \ Więcej informacji: [Zgodność i certyfikaty OVHcloud](https://www.ovhcloud.com/pl/compliance/) * Każdy Klient posiada **swoją indywidualną bazę danych**, która nie jest współdzielona z innymi usługami ani klientami. * Dane nie są przekazywane poza **Europejski Obszar Gospodarczy (EOG)**. * W celu zapewnienia najwyższego poziomu bezpieczeństwa, Usługa jest regularnie poddawana **testom penetracyjnym** oraz **audytom bezpieczeństwa** przeprowadzanym przez niezależne, wyspecjalizowane podmioty. Więcej pod [linkiem](https://www.eauditor.eu/cloud-trust). ### Lokalizacja i przepływ danych Dane nie są przekazywane poza Europejski Obszar Gospodarczy (EOG). **Wyjątek dotyczy jedynie danych związanych z obsługą płatności**, które są przetwarzane przez operatora Stripe na serwerach zlokalizowanych również poza EOG (w tym w Stanach Zjednoczonych). Obejmuje to wyłącznie informacje potrzebne do realizacji płatności, takie jak: dane nabywcy, dane rozliczeniowe, informacje o subskrypcji oraz szczegóły transakcji. **Nie dotyczy to żadnych danych zbieranych przez system eAuditor cloud**, takich jak inwentaryzacja, monitoring aktywności, polityki bezpieczeństwa, szyfrowanie dysków, dane DLP czy jakiekolwiek informacje techniczne z komputerów Klienta – te pozostają wyłącznie na serwerach w Polsce. Więcej informacji o bezpieczeństwie przetwarzania płatności znajduje się w sekcji [**Bezpieczeństwo płatności i operatora rozliczeń**](#bezpieczenstwo-platnosci-i-operatora-rozliczen). ### Przechowywanie i usuwanie danych Dane przesyłane do **Usługi eAuditor cloud** są zapisywane na **Koncie Klienta** i mogą zostać usunięte przez Klienta w dowolnym momencie. Po zakończeniu świadczenia Usługi, Konto Klienta zostaje zablokowane na okres 14 dni, po czym dane są **trwale usuwane (15 dnia od zamknięcia Konta)**, z zastrzeżeniem obowiązków wynikających z przepisów prawa. Po trwałym usunięciu danych ich **odzyskanie jest technicznie niemożliwe**. Administrator przetwarza dane Klienta po zamknięciu Konta **wyłącznie w zakresie i przez okres niezbędny do realizacji obowiązków prawnych**, w szczególności wynikających z przepisów rachunkowości i podatkowych. {% endtab %} {% tab title="eAuditor On-Premise" %} ### Infrastruktura organizacji eAuditor On-Premise jest instalowany w infrastrukturze wskazanej przez organizację. Miejsce przechowywania danych, konfiguracja sieci, serwera aplikacyjnego, bazy danych i dostępu administracyjnego zależą od przyjętej architektury wdrożenia. Za fizyczne i sieciowe zabezpieczenie środowiska, aktualizowanie systemów serwerowych, przechowywanie danych oraz organizację dostępu odpowiada podmiot utrzymujący wdrożenie - organizacja lub jej dostawca usług IT. Nie należy utożsamiać zasad lokalizacji danych, certyfikatów centrum danych ani retencji konta w eAuditor Cloud z instalacją On-Premise. W tym modelu są one zależne od konkretnego środowiska i przyjętych procedur.
Schemat lokalnego wdrożenia eAuditor On-Premise pokazujący serwer aplikacyjny, bazę danych, konsolę administratora i komputery z agentami.

Schemat lokalnego wdrożenia eAuditor On-Premise pokazujący serwer aplikacyjny, bazę danych, konsolę administratora i komputery z agentami.

{% endtab %} {% endtabs %} ## Szyfrowanie transmisji i komunikacja komponentów Komunikacja **eAgent - eServer** jest zabezpieczana z wykorzystaniem **TLS 1.3**. W przypadku obu modeli mowa o certyfikacie SSL o kluczach długości **4096 bitów** dla komponentów eAgent i eServer. Mechanizmy szyfrowania służą ochronie poufności i integralności przesyłanych informacji. {% tabs %} {% tab title="eAuditor Cloud" %} Dostęp do konsoli eAuditor Cloud odbywa się przez zabezpieczone połączenie **HTTPS**. Szyfrowanie transmisji obejmuje komunikację użytkownika z usługą, wymianę danych pomiędzy komponentami oraz operacje uwierzytelniania. Proces przesyłania danych jest zabezpieczony przy użyciu szyfrowania **SSL/TLS**, co gwarantuje poufność i integralność komunikacji pomiędzy użytkownikiem a usługą. Komunikacja pomiędzy komponentami systemu (**eAgent** oraz **eServer** ) odbywa się z wykorzystaniem protokołu **TLS 1.3**. Zarówno **eAgent**, jak i **eServer** posiadają własne certyfikaty **SSL o długości klucza 4096 bitów**, co zapewnia bardzo wysoki poziom bezpieczeństwa transmisji danych. Szyfrowanie obejmuje zarówno transmisję danych w czasie rzeczywistym, jak i komunikację podczas procesów uwierzytelniania oraz wymiany informacji systemowych. {% hint style="info" %} Konfiguracja zabezpieczeń infrastruktury chmurowej pozostaje po stronie dostawcy usługi. Klient nie musi samodzielnie konfigurować serwera aplikacyjnego ani certyfikatów konsoli. {% endhint %} {% endtab %} {% tab title="eAuditor On-Premise" %} Komunikacja agenta z serwerem wykorzystuje TLS 1.3. Dodatkowo organizacja powinna zapewnić odpowiednie zabezpieczenie dostępu do konsoli internetowej, w szczególności przez konfigurację **HTTPS** i prawidłowe zarządzanie certyfikatami. Zalecana jest konfiguracja certyfikatów i połączenia HTTPS w **Apache Tomcat**. Szczegółowe ustawienia zależą od wersji serwera aplikacyjnego i zastosowanej architektury. {% hint style="warning" %} Nie należy bez weryfikacji kopiować historycznych konfiguracji Tomcat 8.5 lub wcześniejszych środowisk Java do współczesnego wdrożenia. {% endhint %} {% endtab %} {% endtabs %} ## Uwierzytelnianie i kontrola dostępu Dostęp do konsoli jest związany z uwierzytelnieniem użytkownika. Dodatkowa weryfikacja tożsamości ogranicza ryzyko nieautoryzowanego dostępu w razie ujawnienia hasła. Uprawnienia administratorów powinny być nadawane zgodnie z zakresem wykonywanych obowiązków. {% tabs %} {% tab title="eAuditor Cloud" %} ### Uwierzytelnianie wieloskładnikowe (MFA) eAuditor Cloud obsługuje **MFA** za pomocą aplikacji takich jak **Google Authenticator** i **Microsoft Authenticator**. Administrator organizacji może wymagać stosowania MFA przez użytkowników konta. Dostęp do funkcji i danych może być organizowany na podstawie **ról i przypisanych uprawnień (RBAC)**. **Kod jednorazowy przesyłany e-mailem**. Przy logowaniu system wysyła kod na adres użytkownika objętego dodatkową weryfikacją. {% hint style="info" %} Integracje tożsamości, w tym **Microsoft Entra ID**, mogą zależeć od aktualnej wersji i etapu udostępniania funkcji. {% endhint %} {% endtab %} {% tab title="eAuditor On-Premise" %} #### Logowanie z dodatkowym zabezpieczeniem System eAuditor On-Premise umożliwia stosowanie dodatkowych mechanizmów uwierzytelniania, które zwiększają bezpieczeństwo dostępu do konsoli administracyjnej. W zależności od konfiguracji administrator może wymagać dodatkowego potwierdzenia tożsamości użytkownika podczas logowania. Dostępne mechanizmy obejmują: * **Uwierzytelnianie wieloskładnikowe (MFA)** - dodatkową weryfikację tożsamości za pomocą aplikacji Google Authenticator lub Microsoft Authenticator. * **Kod jednorazowy przesyłany e-mailem (2FA)** - podczas logowania system generuje indywidualny kod weryfikacyjny i przesyła go na adres e-mail użytkownika. **Logowanie z kodem jednorazowym (2FA)** Mechanizm 2FA pozwala zabezpieczyć dostęp do konsoli administracyjnej poprzez wymaganie dodatkowego kodu weryfikacyjnego. Logowanie dwuskładnikowe może zostać włączone dla wszystkich administratorów lub wybranych kont użytkowników. System umożliwia określenie parametrów mechanizmu, takich jak: * **Ważność kodu** - czas, przez jaki wygenerowany kod pozostaje aktywny. * **Odstęp między wiadomościami** - minimalny czas pomiędzy kolejnymi wysyłkami kodu. * **Temat i treść wiadomości** - możliwość dostosowania wiadomości e-mail zawierającej kod weryfikacyjny. Do działania uwierzytelniania za pomocą wiadomości e-mail wymagane jest prawidłowe skonfigurowanie serwera SMTP. **Bezpieczeństwo komunikacji** Komunikacja z konsolą administracyjną może być zabezpieczona protokołem HTTPS, który zapewnia szyfrowanie przesyłanych danych. W przypadku uwierzytelniania wykorzystującego certyfikaty i klucze sprzętowe prawidłowa konfiguracja szyfrowanej komunikacji stanowi istotny element ochrony procesu logowania. System umożliwia stosowanie certyfikatów oraz konfigurację zabezpieczeń na poziomie serwera aplikacyjnego Apache Tomcat. Szczegółowy opis konfiguracji poszczególnych metod uwierzytelniania znajduje się w dokumentacji administracyjnej systemu eAuditor On-Premise. {% endtab %} {% endtabs %} ## Kopie zapasowe, dostępność i aktualizacje Kopie zapasowe służą odtwarzaniu danych po awarii. Należy odróżnić kopie wykonywane przez dostawcę usługi Cloud od kopii organizowanych i utrzymywanych w środowisku On-Premise. {% tabs %} {% tab title="eAuditor Cloud" %} Zakres i dostępność kopii zapasowych zależą od wybranego planu subskrypcyjnego: * **Plan FREE** – kopie zapasowe nie są dostępne. * **Plany INV100** oraz **ACT200** – system wykonuje **1 kopię zapasową**, przechowywaną w tej samej lokalizacji, w której działa infrastruktura eAuditor cloud, czyli w **centrum danych OVHcloud w Ożarowie Mazowieckim**. * **Plan DLP300** – dostępne są **2 kopie zapasowe**: * jedna przechowywana w **Ożarowie Mazowieckim**, * druga w **odrębnej lokalizacji na terenie Unii Europejskiej**, spełniającej opisane standardy bezpieczeństwa i zgodności. Kopie wykorzystywane są do odtwarzania danych w przypadku awarii lub utraty dostępności usługi. Dokumentacja nie określa częstotliwości ich wykonywania ani gwarantowanego czasu odtworzenia, dlatego nie należy przyjmować takich parametrów bez uzgodnienia z dostawcą. ### Dostępność usługi Dostawca deklaruje **dostępność eAuditor Cloud na poziomie 99,90% w skali roku**. Szczegółowe warunki świadczenia usługi wynikają z obowiązujących dokumentów umownych i [regulaminu](https://www.eauditor.eu/regulamin-cloud). ### Aktualizacje Nowe wersje eAuditor Cloud oraz poprawki są udostępniane automatycznie. Aktualizacje obejmują poprawki bezpieczeństwa, zmiany funkcjonalne oraz usprawnienia działania usługi. {% endtab %} {% tab title="eAuditor On-Premise" %} ### Kopie zapasowe i odtwarzanie Zasady wykonywania i przechowywania kopii zapasowych zależą od konfiguracji środowiska organizacji. W ramach utrzymania wdrożenia należy określić harmonogram backupu, docelowe lokalizacje, okres retencji i procedurę testowania odtwarzania. ### Dostępność i aktualizacje Dostępność wdrożenia On-Premise zależy od infrastruktury organizacji, sposobu administracji i przyjętych procedur odtwarzania. Aktualizacje aplikacji, systemu operacyjnego, bazy danych oraz serwera aplikacyjnego powinny być planowane w ramach utrzymania środowiska. {% hint style="info" %} Deklaracja dostępności **99,90%** podawana dla eAuditor Cloud nie stanowi automatycznie gwarancji dostępności instalacji On-Premise. {% endhint %} {% endtab %} {% endtabs %} ## Testy i audyty bezpieczeństwa Testowanie bezpieczeństwa pozwala identyfikować potencjalne słabości aplikacji, interfejsów i komponentów instalowanych na komputerach. Zakres opublikowanych informacji o przeprowadzonych testach różni się między Cloud a On-Premise. {% tabs %} {% tab title="eAuditor Cloud" %} Usługa podlega **regularnym testom penetracyjnym i audytom bezpieczeństwa** prowadzonym przez niezależne, wyspecjalizowane podmioty. Informacje o aktualnym zakresie testów Cloud i możliwości udostępnienia dokumentów audytowych należy uzyskać bezpośrednio od dostawcy. {% endtab %} {% tab title="eAuditor On-Premise" %} ### Udokumentowany zakres testów eAuditor V9 AI W systemie **eAuditor V9 AI** wykonano **126 testów podatności**. Według opisu przeprowadzonych prac wykryte podatności zostały przeanalizowane i usunięte. Testy obejmowały: * **modelowanie zagrożeń** - identyfikację zagrożeń, ich klasyfikację i priorytetyzację; * **testy penetracyjne aplikacji webowej i REST API** - ocenę mechanizmów ochronnych i komunikacji; * **testy bezpieczeństwa agenta (aplikacji typu Thick Client)** - ocenę komponentu instalowanego na komputerze. Badane komponenty obejmowały aplikację web eAuditor, agenta oraz REST API wykorzystywane przez agentów. ### Metodyka testowania Do testów aplikacji internetowej zastosowano **OWASP ASVS**, a przy analizie API wykorzystano zalecenia [OWASP REST Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html). Zakres weryfikacji obejmował m.in.: * błędy typu injection (SQL, XML, code i command injection), XSS oraz CSRF; * uwierzytelnianie, autoryzację i możliwość obejścia kontroli dostępu; * niebezpieczne odwołania do obiektów, ujawnianie danych i błędy konfiguracji; * bezpieczeństwo SSL/TLS, podatne komponenty, przekierowania oraz Local/Remote File Inclusion; * bezpieczeństwo danych i poświadczeń przechowywanych przez agenta; * integralność i poufność komunikacji klient-serwer; * zarządzanie pamięcią i zasobami procesu, w tym błędy overflow, format string, type confusion oraz DLL hijacking; * uprawnienia usług i prawidłowość użycia mechanizmów kryptograficznych. W analizie wykorzystywano m.in. **IDA Professional, Hex-Rays Decompiler, Burp Suite Professional, Wireshark, WinDbg, GDB i Process Monitor**. **Nie przeprowadzono audytu kodu źródłowego**. Podatności oceniano z wykorzystaniem **CVSS (Common Vulnerability Scoring System)**, uwzględniając m.in. wektor i złożoność ataku, wymagane uprawnienia, udział użytkownika oraz wpływ na poufność, integralność i dostępność. {% hint style="info" %} Opis dotyczy testowanego wydania **eAuditor V9 AI**. Nie stanowi informacji, że taki sam audyt został wykonany dla każdej późniejszej wersji systemu. {% endhint %} {% endtab %} {% endtabs %} ## Bezpieczna konfiguracja i odpowiedzialność administratora Ochrona systemu wymaga nie tylko mechanizmów wdrożonych przez producenta, ale również prawidłowego zarządzania dostępami, konfiguracją i środowiskiem pracy. {% tabs %} {% tab title="eAuditor Cloud" %} ### Bezpieczeństwo płatności W ramach modelu rozliczeń korzystamy z operatora **Stripe**, co wpływa także na bezpieczeństwo systemu eAuditor cloud. Stripe jest certyfikowanym [**Service Provider Level 1 zgodnym z normą PCI DSS 4.0**](https://docs.stripe.com/security), co oznacza najwyższy poziom bezpieczeństwa w przetwarzaniu danych kart płatniczych. Stripe posiada raporty zgodności typu **SOC 1 i SOC 2 Type II**, zaś wszystkie połączenia API oraz dashboard działają wyłącznie przez bezpieczny kanał HTTPS/TLS. [Więcej.](https://docs.stripe.com/security/guide) Dzięki temu Twoje dane płatnicze oraz informacje o subskrypcji są przetwarzane przez operatora spełniającego rygorystyczne standardy branżowe. ### Obowiązki użytkowników W celu zachowania bezpieczeństwa korzystania z Usługi, poniższe zasady dotyczą wszystkich osób mających dostęp do konta Klienta, zarówno **Użytkowników**, jak i **Administratorów Konta** (zgodnie z definicjami z Regulaminu Usługi): * Korzystać z aktualnej wersji zalecanych przeglądarek internetowych: **Chrome, Edge, Firefox** lub **Safari**. * Regularnie aktualizować przeglądarkę do najnowszej wersji edycyjnej. * Pamiętać, że korzystanie z przeglądarek innych niż zalecane może powodować nieprawidłowe działanie Usługi. * Dbać o ochronę danych dostępowych i nie udostępniać ich osobom nieuprawnionym. * Korzystać z Usługi zgodnie z przepisami prawa oraz zasadami określonymi w Regulaminie Usługi. **Dodatkowe obowiązki Administratora Konta:** * Zarządzanie dostępami Użytkowników i kontrola nad nadawanymi uprawnieniami. * Nadzór nad konfiguracją Konta Klienta. * Reagowanie na podejrzenia nieautoryzowanego dostępu lub naruszenia bezpieczeństwa. Więcej informacji można znaleźć w [**Regulaminie Usługi eAuditor Cloud**](https://app.eauditor.eu/register). {% endtab %} {% tab title="eAuditor On-Premise" %} ### Ograniczanie dostępu w konfiguracji aplikacji eAuditor umożliwia ograniczania dopuszczalnych serwerów oraz ścieżek używanych przez aplikację poprzez plik **`config.properties`**. Rozwiązanie pozwala ograniczać m.in.: * serwery **AD DS** wykorzystywane do importu; * lokalizacje **kopii zapasowych bazy danych**; * ścieżki i serwery wykorzystywane przy **imporcie danych**; * lokalizacje zapisywania **raportów**; * dopuszczalne wartości nagłówków **Host** i **Origin**; * serwery **SMTP** wykorzystywane do wysyłania wiadomości. Przykładowe nazwy parametrów z historycznej dokumentacji: ```properties props.activedirectory.allowedservers = ["172.16.115.17"] props.dbbackup.allowedpaths = ["c:/btc/backup-db/ehelpdesk*"] props.imports.allowedpaths = ["c:/btc/import/*"] props.reportssend.allowedpaths = ["c:/btc/reports/*"] props.imports.allowedservers = ["127.0.0.1","172.16.115.251"] props.headerhost.allowedservers = ["172.16.115.251:8543","dbr-hvdlpdev:8543"] props.headeroriginhost.allowedservers = ["172.16.115.251:8543","dbr-hvdlpdev:8543"] props.smtp.allowedservers = ["127.0.0.1"] ``` Są to **przykłady składni**, a nie gotowy zestaw ustawień do bezpośredniego wklejenia. Adresy i ścieżki należy zastąpić danymi własnego środowiska, a dostępność i znaczenie parametrów potwierdzić dla zainstalowanej wersji. Pusta lista `[]` dla wybranych ustawień wyłączała określoną funkcję (np. import lub backup). ### Bezpieczna komunikacja HTTPS System eAuditor On-Premise umożliwia zabezpieczenie komunikacji pomiędzy przeglądarką użytkownika a konsolą administracyjną za pomocą protokołu HTTPS. Wykorzystanie szyfrowanego połączenia chroni przesyłane dane, w tym informacje uwierzytelniające, przed nieuprawnionym odczytem podczas transmisji. Za obsługę bezpiecznych połączeń odpowiada serwer aplikacyjny **Apache Tomcat**, który umożliwia konfigurację certyfikatów SSL/TLS oraz parametrów szyfrowania. Konfiguracja zabezpieczeń może obejmować: * **Certyfikaty SSL/TLS** - wykorzystywane do zabezpieczenia komunikacji i potwierdzania tożsamości serwera. * **Magazyn certyfikatów Java (JKS)** - służący do przechowywania certyfikatów i kluczy kryptograficznych. * **Protokoły i algorytmy szyfrowania** - dobierane zgodnie z wymaganiami bezpieczeństwa organizacji i możliwościami wykorzystywanego środowiska. Parametry zabezpieczeń powinny być dostosowane do aktualnej wersji serwera aplikacyjnego oraz obowiązujących standardów kryptograficznych. Szczegółowy sposób konfiguracji HTTPS i zarządzania certyfikatami zostanie opisany w odrębnej instrukcji administracyjnej eAuditor On-Premise. ### Obowiązki administratora Organizacja powinna stosować aktualizacje serwera, bazy danych i komponentów pośredniczących, kontrolować dostęp do konsoli, zabezpieczać kopie danych, ograniczać uprawnienia usług i weryfikować poprawność konfiguracji po zmianach środowiska. {% endtab %} {% endtabs %} *** ## Najczęściej zadawane pytania
Czy eAuditor Cloud i On-Premise mają identyczne zabezpieczenia? Nie. Oba modele wykorzystują mechanizmy zabezpieczania komunikacji i dostępu, ale różnią się architekturą, zakresem administracji, sposobem konfiguracji oraz odpowiedzialnością za utrzymanie infrastruktury.
Czy eAuditor Cloud przechowuje dane klientów poza Polską? Zgodnie z deklaracją dostawcy środowiska dane techniczne zbierane przez system przechowywane są w Polsce. Dane związane z płatnościami są przetwarzane odrębnie przez Stripe i mogą być przekazywane poza EOG.
Czy eAuditor Cloud wykonuje kopie zapasowe? Tak, ale zależy to od planu. FREE nie obejmuje kopii zapasowych, INV100 i ACT200 przewidują jedną kopię, a DLP300 dwie kopie w odrębnych lokalizacjach.
Czy eAuditor obsługuje MFA? Tak. eAuditor Cloud oraz eAuditor On-Premise obsługuje aplikacje uwierzytelniające oraz kody e-mail, natomiast w On-Premise dodatkowo token sprzętowy ePass. Dostępność konkretnej metody zależy od modelu i wersji systemu.
Czy system przeszedł testy penetracyjne? Dla eAuditor V9 AI opublikowano opis **126 testów podatności**, obejmujących aplikację webową, REST API i agenta.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://eaclouddoc.eauditor.eu/system/bezpieczenstwo.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.