Każdy serwer MCP to kolejna tajemnica, którą twój agent może wyciec.
Każdy serwer MCP to kolejna tajemnica dostępna online, która powiększa zasięg szkodliwych danych wejściowych. Przeprowadź audyt zakresów tokenów i zastosuj cztery poprawki, które zmniejszą zasięg tych zagrożeń.
Źródła: Every MCP Server You Add Gives Your Agent Another Credential
Zaczyna się niewinnie. W poniedziałek łączy się GitHub, we wtorek Slack, potem Postgres, następnie Notion, a na końcu wewnętrzny serwer fakturujący, który kolega napisał po południu i nigdy nie udokumentował. Każde dodanie sprawia, że agent staje się bardziej funkcjonalny. Każde z nich dodaje też kolejny element do „pierścienia”, który nosi ze sobą.
Problemy zwykle pojawiają się przypadkowo, gdy ktoś naprawia coś niezwiązanego i otwiera plik konfiguracyjny. Sześć serwerów, sześć tajemnic w formie tekstowej, wszystko w katalogu domowym, bez terminu ważności i bez właściciela. W tym momencie MCP przestaje wyglądać jak przydatne narzędzie i zaczyna przypominać obciążenie.
Matematyka
Po kilku miesiącach entuzjazmu typowa konfiguracja wygląda tak:
{
"mcpServers": {
"gh": { "cmd": "gh-mcp", "env": { "GH_TOKEN": "ghp_live_9f2a" } },
"db": { "cmd": "pg-mcp", "env": { "PG_URL": "postgres://app:hunter2@prod/main" } },
"sl": { "cmd": "slk-mcp", "env": { "SLACK_TOKEN": "xoxb-live-771" } }
}
}
Trzy serwery, trzy tajemnice, jeden plik i brak rotacji. Możesz sprawdzić swój własny komputer w ciągu sekund, wyszukując w standardowych folderach konfiguracyjnych ciągi znaków przypominające tokeny.
grep -rIl "ghp_\|xoxb-\|sk-" ~/.config ~/.claude ~/Library 2>/dev/null | wc -l
Ludzie, którzy to uruchamiają, często znajdują więcej, niż się spodziewali. Liczba jedenastu, gdy zakładaliśmy trzy, nie jest niczym nietypowym.
Część, która naprawdę sprawia ból
Dane uwierzytelniające przechowywane na dysku to mniej istotna połowa problemu. Bardziej poważna jest ta, że każdy z tych kluczy znajduje się teraz w rękach jednej osoby podejmującej decyzje, a ta osoba czyta teksty z internetu.
one agent loop
|
+---------+---------+---------+---------+
| | | | |
github slack postgres notion billing
(14 scp) (9 scp) (rw all) (rw ws) (rw all)
| | | | |
+---------+---------+---------+---------+
|
one poisoned input
Komentarz dotyczący problemu, strona w Notion lub wiersz w tabeli mogą każdy z nich zasugerować konkretne działanie, a agent posiada wszystkie niezbędne informacje, by je przeprowadzić. To w istocie problem „zdezorientowanego zastępcy” w nowej oprawie. Agent nie jest skompromitowany – po prostu stara się pomóc i nie potrafi odróżnić twoich instrukcji od tekstu, który jedynie im przypomina.
Mierzenie luki
Przydatnym ćwiczeniem jest rejestrowanie każdego wywołania narzędzia przez dwa tygodnie, a następnie porównywanie tego, co każdy token może robić, z tym, co faktycznie robił. Wynik jednej takiej audytu:
| Service | Granted Scopes | Scopes Used | Utilization |
| -------- | --------------: | ------------------: | ----------: |
| GitHub | 14 | 3 | 21.4% |
| Slack | 9 | 2 | 22.2% |
| Postgres | Full RW | 1 table, reads only | Minimal |
| Notion | Whole workspace | 2 pages | Minimal |
Około czterech piątych przyznanych uprawnień pozostało niewykorzystanych. Ten brak nie wynika z wygody – to efekt „promieni wybuchu”, który dźwigamy, nie otrzymując za to nic w zamian.
Rozwiązania, uszeregowane według korzyści
Jeden token na serwer, dostosowany do jego rzeczywistych zadań. Współdzielone tokeny oznaczają współdzieloną odpowiedzialność. Gdy coś pójdzie nie tak, rejestr audytu powinien wskazywać na serwer, a nie na konkretną osobę.
Domyślnie tylko prawo do odczytu dla wszystkich elementów przechowujących dane. Dwie linijki kodu SQL, dedykowana rola oraz uprawnienia do odczytu tylko tych tabel, które agent rzeczywiście czyta, zmieniają najgorszy scenariusz z utraty tabeli na wyciek zapytania.
create role agent login password 'rotate_me';
grant usage on schema public to agent;
grant select on orders, users to agent;
Tokeny krótkotrwałe zamiast tych trwałych. Niech sejf wydaje uprawnienia na żądanie, których czas ważności wynosi kilka minut. Sekret skradziony we wtorek rano staje się bezwartościowy już we wtorek po południu.
async function tok(srv) {
const r = await fetch(`${VAULT}/issue/${srv}`, { method: "POST" });
const { token, ttl } = await r.json();
return { token, exp: Date.now() + ttl * 1000 };
}
Zapisywanie połączeń, a nie tylko rozmów. Cienka warstwa otaczająca każdą funkcję narzędzia, która rejestruje serwer, argumenty oraz datę i godzinę, to zaledwie kilka linijek kodu. W wymienionym powyżej audycie ujawniło to serwer, który wywoływał punkt końcowy, którego nikt nie prosił o obsługę.
function wrap(name, fn) {
return async (args) => {
log({ srv: name, args, at: Date.now() });
return fn(args);
};
}
Zasada do przyjęcia
Zanim włączysz serwer, wyobraź sobie, że jest wrogi, i zastanów się, czego mógłby osiągnąć bez żadnej pomocy. Jeśli szczera odpowiedź jest nieprzyjemna, ogranicz uprawnienia tego serwera lub go pominij. Nie obiecuj, że naprawisz to później, ponieważ „później” rzadko nadchodzi, a tym bardziej w piątek.
To wszystko nie jest argumentem przeciwko MCP. Rozwiązało ono problem integracji, który sprawiał, że agenci wydawali się zabawkami. Chodzi o to, że każdy dodany serwer to również dodatkowe uprawnienia, a uprawnienia wymagają takiej samej ostrożności, jaką okazałbyś każdemu innemu kluczu używanemu w produkcji.
Podobne materiały
- Praktyczne notatki: Stwórz agenta finansowego opartego na sztucznej inteligencji z serwerem MCP eodhd — Krok po kroku instrukcja do Praktycznych notatek: Stwórz agenta finansowego opartego na sztucznej inteligencji z serwerem MCP eodhd: umowy, sprawdzenia oraz miejsca na kod do wstawienia dla zespołów tworzących systemy MCP bez niego.
- Praktyczne notatki: Czy twój agent może szukać MCP-ów — Krok po kroku instrukcja do Praktycznych notatek: Czy twój agent może szukać MCP-ów: umowy, sprawdzenia oraz miejsca na kod do wstawienia dla zespołów stosujących ten wzorzec.