.well-known jest zablokowany na Twoim hostingu — i co z tym zrobić

Chciałeś wrzucić plik agent-permissions.json do katalogu .well-known. Hosting odmówił. Let’s Encrypt zarezerwował ten katalog dla siebie i nie zamierza go oddać.

Brzmi jak ślepy zaułek. Nie jest. Przynajmniej na razie.

Skąd w ogóle pomysł z .well-known?

Katalog .well-known to standard RFC 8615 — zarezerwowana ścieżka gdzie serwery publikują informacje o sobie dla automatycznych klientów. Używa go Let’s Encrypt do weryfikacji SSL, ale też inne systemy — DKIM, WebFinger, Apple Pay.

Gdy świat zaczął myśleć o tym jak agenty AI mają wiedzieć co mogą robić na danej stronie, .well-known/agent-permissions.jsonwydawał się naturalnym miejscem. Analogia do robots.txt — jeden plik, jedno miejsce, każdy agent wie gdzie szukać.

Problem w tym że standard nie jest jeszcze zamknięty. A hosting już zablokował katalog.

Trzy obejścia które działają dziś

1. Własna ścieżka + llms.txt

Najprostsze i najskuteczniejsze. Zamiast .well-known/agent-permissions.json tworzysz plik pod dowolną ścieżką:

https://twojadomena.pl/agent-permissions.json

A w llms.txt dodajesz sekcję:

## Agent Permissions
URL: https://twojadomena.pl/agent-permissions.json

Agent który czyta llms.txt — a robi to jako pierwszy krok przy wizycie na stronie — znajdzie ścieżkę do pliku uprawnień. Żadnych katalogów systemowych, żadnych konfliktów z Let’s Encrypt.

Dlaczego to działa: Agenty AI nie są przywiązane do konkretnej ścieżki. Są przywiązane do instrukcji. Jeśli w llms.txtpiszesz „moje uprawnienia są tutaj” — agent tam zajrzy.

2. WordPress REST API endpoint

Jeśli masz WordPress — masz gotowy mechanizm do wystawienia dowolnego endpointu:

add_action( 'rest_api_init', function() {
    register_rest_route( 'ifox/v1', '/agent-permissions', array(
        'methods'             => 'GET',
        'callback'            => 'geo_agent_permissions_json',
        'permission_callback' => '__return_true',
    ) );
} );

function geo_agent_permissions_json() {
    return array(
        '@context'   => 'https://schema.org',
        '@type'      => 'DigitalDocument',
        'name'       => 'Agent Permissions',
        'publisher'  => get_bloginfo( 'name' ),
        'url'        => home_url( '/wp-json/ifox/v1/agent-permissions' ),
        'permissions' => array(
            'read'     => true,
            'search'   => true,
            'purchase' => false,
            'forms'    => array( 'contact', 'newsletter' ),
        ),
        'requires_confirmation' => array( 'purchase', 'account_creation' ),
        'disallow' => array( 'bulk_download', 'scraping', 'training' ),
    );
}

Endpoint dostępny pod:

https://twojadomena.pl/wp-json/ifox/v1/agent-permissions

W llms.txt:

## Agent Permissions
URL: https://twojadomena.pl/wp-json/ifox/v1/agent-permissions

Zaleta: dane dynamiczne — możesz je zmieniać bez edytowania pliku, możesz je generować na podstawie ustawień w panelu WP.

3. Plik JSON w katalogu głównym

Najprostsze ze wszystkich — wrzuć plik bezpośrednio do public_html:

https://twojadomena.pl/agent-permissions.json

Żadnego specjalnego katalogu. Żadnych endpointów. Plik jak każdy inny. Wskaż na niego w llms.txt i gotowe.

Jak wygląda sam plik agent-permissions.json?

Standard nie jest jeszcze zamknięty, ale rozsądna struktura wygląda tak:

{
  "@context": "https://schema.org",
  "@type": "DigitalDocument",
  "name": "Agent Permissions Policy",
  "publisher": "iFOX.pl",
  "dateModified": "2026-04-25",
  "permissions": {
    "read": true,
    "search": true,
    "index": true,
    "purchase": false,
    "account_creation": false,
    "form_submission": ["contact", "newsletter"]
  },
  "requires_confirmation": [
    "purchase",
    "account_creation",
    "data_deletion"
  ],
  "disallow": [
    "bulk_download",
    "training_data_collection",
    "scraping_without_attribution"
  ],
  "contact": "kontakt@twojadomena.pl"
}

Trzy sekcje które mają znaczenie:

permissions — co agent może robić bez pytania. read: true oznacza że agent może czytać treść. purchase: false oznacza że zakupów nie wolno bez osobnej autoryzacji.

requires_confirmation — co wymaga potwierdzenia przez użytkownika przed wykonaniem. To jest implementacja zasady human-in-the-loop na poziomie deklaracji polityki.

disallow — czego agent nie może robić w ogóle. Masowe pobieranie treści do treningu modeli, scraping bez podania źródła, operacje destrukcyjne.

Dlaczego warto to zrobić teraz

Standard .well-known/agent-permissions może się ustabilizować za rok. Może za dwa. Może w ogóle wygrają inne podejścia.

Ale agent permissions jako koncept — jasna deklaracja co agent może robić na Twojej stronie — jest potrzebne już teraz. Agenty które odwiedzają strony bez żadnych wskazówek działają na domysłach. Agenty które mają jasną politykę działają zgodnie z Twoją intencją.

Własna ścieżka + wpis w llms.txt to rozwiązanie które działa dziś, jest zgodne z duchem standardu, i można je podmienić na oficjalną ścieżkę .well-known gdy hosting przestanie ją blokować — jedną zmianą w llms.txt.

Jeden plik. Pięć minut. I Twoja strona mówi agentom AI co mogą, a czego nie.

Sprawdź swoją stronę

Czy Twoja strona ma llms.txt? Czy agenty wiedzą co mogą u Ciebie robić?

Sprawdź w GEO Checker na iFOX.pl — bezpłatne narzędzie które w kilka sekund pokaże co warto poprawić.

Pojęcia użyte w artykule: agent permissions, human-in-the-loop, llms.txt, agent discovery