Bezpieczne agenty AI dla przedsiębiorstw w MCP Toolbox: zestawy narzędzi oparte na intencjach, autoryzacja i logi

Przeniesienie agenta AI z uporządkowanego lokalnego prototypu do chaotycznego środowiska produkcyjnego przedsiębiorstwa jest trudne. Poproszenie LLM o odpowiedź na proste pytania w ramach ustrukturyzowanych tabel jest prostą sprawą, ale poproszenie go o samodzielne zbadanie incydentu bezpieczeństwa wśród terabajtów fragmentarycznych danych, bez tworzenia błędnych informacji czy uszkodzenia czegokolwiek, to zupełnie inny problem.

Model Context Protocol stał się otwartym standardem do łączenia modeli z narzędziami i źródłami danych przedsiębiorstw. Sam protokół jest prosty, jednak jego skuteczne wykorzystanie w produkcji wymaga dyscypliny architektonicznej, która wykracza daleko poza zwykłe udostępnianie kilku surowych API. Poniżej przykładowy scenariusz ilustruje praktyczne lekcje wynikające z tworzenia agentów pracujących z danymi przedsiębiorstw za pomocą MCP Toolbox.

Scenariusz agenta

Współczesne agenty rzadko rozwiązują złożone problemy przedsiębiorstwa przy użyciu jednej tylko funkcji narzędzia. Rzeczywiste operacje wymagają wieloetapowych procesów: pobierania metadanych, weryfikacji stanu, izolowania anomalii, pozyskiwania surowych dowodów oraz syntetyzacji działań. W tym scenariuszu PostgreSQL i BigQuery pełnią rolę ustrukturyzowanych indeksów, które kierują agenta do odpowiednich nieustrukturyzowanych danych w Google Cloud Storage.

1. Weryfikacja stanu w PostgreSQL. Agent najpierw wysyła zapytanie do bazy danych, aby sprawdzić metadane przypadku klienta, poziomy usług oraz identyfikatory aktywnych incydentów.
2. Analiza telemetryczna w BigQuery. Celowe zapytania analityczne pozwalają wyizolować nietypowo wysokie natężenia ruchu oraz pobrać odpowiednie ścieżki plików lub daty zapisu sesji.
3. Szeroki kontekst diagnostyczny w GCS. Posiadając dokładne daty zapisu i klucze obiektów, agent korzysta z narzędzi GCS w celu pobrania pełnych zapisów pakietów oraz nieredagowanych dokumentów dotyczących zagrożeń do dalszej analizy.

Trzy zasady projektowania utrzymują całość w spójności.

1. Tworzenie zestawów narzędzi projektowych wokół intencji

Oferowanie modelowi ogólnych narzędzi takich jak execute_sql, read_file lub describe_schema rzadko przynosi dobry agent. Narzędzia niskiego poziomu zmuszają LLM do wydawania tokenów na domyślanie się struktury przechowywania, kluczy obiektów i schematów, zanim w ogóle rozpocznie się prawdziwy problem. Wiele aplikacji AI zawodzi nie dlatego, że model jest słaby, ale dlatego, że agent nie miał odpowiedniego kontekstu w momencie jego potrzeby. Pomagają trzy praktyki:

• Nadawaj priorytet intencji nad mechaniką. Zamiast surowych elementów przechowywania, udostępniaj specjalnie stworzone narzędzia w rodzaju fetch_threat_intel_report lub get_incident_summary.

Zgrupuj narzędzia w skoncentrowane zestawy. Zestawy specyficzne dla danej dziedziny, na przykład incident-triage, sprawiają, że wybór narzędzi jest deterministyczny i powtarzalny, a niewielka grupa dobrze zaprojektowanych narzędzi biznesowych zawsze przewyższa rozległą kolekcję narzędzi ogólnych.

Pozwól metadaniom przechowywania na wykonywanie filtrowania. Szybkie ścieżki odzyskiwania danych w połączeniu z opisowymi atrybutami obiektów (poziom klienta, etykiety incydentów, etykiety regionów) umożliwiają agentowi skupienie się na istotnych elementach, dzięki czemu nigdy nie pobiera danych, które nie są mu potrzebne.

tools.yaml, który definiuje taki zestaw narzędzi w GCS i bazach danych, wygląda następująco:

# tools.yaml - Intent-Driven GCS & DB Toolset Definition

sources:
  my-agent-gcs-source:
    kind: cloud-storage

  my-agent-pg-source:
    kind: cloud-sql-postgres
    project: my-agent-sec-prod
    instance: customer-db

toolsets:
  incident-triage:
    - get_incident_summary
    - fetch_threat_intel_report

tools:
  - kind: tool
    name: fetch_threat_intel_report
    type: cloud-storage-read-object
    source: my-agent-gcs-source
    description: "Fetch and extract parsed indicators of compromise (IoCs) from a GCS-hosted threat intelligence dossier."
    bucket: customer-diagnostics-vault # Hardcoding prevents cross-bucket traversal attacks

  - kind: tool
    name: get_incident_summary
    type: postgres-sql
    source: my-agent-pg-source
    description: "Retrieve active incident metadata and active session IDs."
    statement: |
      SELECT incident_id, severity, session_id FROM incidents WHERE status = 'ACTIVE'

# BigQuery sources and tools have been omitted to maintain the example's clarity and brevity

2. Zabezpiecz perymetr za pomocą kontekstu zero-trust

Dostęp do pojemników produkcyjnych oraz baz danych przedsiębiorstw wiąże się z poważnymi obowiązkami bezpieczeństwa. Agenty przetwarzają dane niestrukturyzowane, takie jak komentarze do zgłoszeń czy opisy alertów, dlatego są naturalnie narażone na ataki typu prompt injection. Atak typu confused-deputy może polegać na zignorowaniu wcześniejszych instrukcji i otwarciu zamiast nich magazynu diagnostycznego Klienta B. Dwie wbudowane funkcje MCP Toolbox pomagają utrzymać ścisłe granice bezpieczeństwa.

Wiązanie parametrów URL

Aby zapobiec temu, by model językowy AI został przekonany do zmiany wrażliwych parametrów, deweloperzy mogą umieścić parametry aplikacji w adresie URL połączenia z serwerem. Narzędzie to wykrywa te parametry zapytania, wiąże je na warstwie transportu i usuwa je ze schematu narzędzia, który otrzymuje model. Model językowy AI nigdy nie widzi parametrów takich jak bucket czy project, więc żadna podmieniona instrukcja nie może nic zmienić:

import asyncio
from toolbox_core import ToolboxClient, Protocol

async def run_incident_triage():
    # Sensitive GCS bucket and GCP project parameters are bound at connection time.
    # The LLM never sees or modifies 'project' or 'bucket' arguments.
    async with ToolboxClient(
        "https://mcp.internal.demo.net/mcp?project=my-agent-sec-prod&bucket=customer-diagnostics-vault",
        protocol=Protocol.MCP_v20260728 # Stateless MCP transport
    ) as toolbox:

        # The Client SDK automatically forwards bound parameters across toolsets
        incident_tools = await toolbox.load_toolset("incident-triage")

        # The agent invokes the tool with only the necessary business argument
        threat_tool = await toolbox.load_tool("fetch_threat_intel_report")
        result = await threat_tool(report_id="INC-89211")

        print("Triage analysis complete:", result)

if __name__ == "__main__":
    asyncio.run(run_incident_triage())

Dokładna autorizacja narzędzi

Konto usługi współdzielonej z szerokimi uprawnieniami to niewłaściwe rozwiązanie. Zamiast tego Toolbox może integrować się z dostawcą tożsamości przedsiębiorstwa za pośrednictwem OAuth2 lub OIDC, dzięki czemu agent działa pod dokładnie tymi danymi tożsamościowymi, które posiada analityk, który rozpoczął proces pracy:

# auth.yaml - MCP Server Auth & Scoped Tools

kind: authServices
name: my-agent-okta-auth
type: generic
audience: my-agent-mcp-toolbox
authorizationServer: https://identity.demo.com/oauth2/default
mcpEnabled: true
scopesRequired:
  - openid
  - profile
---
kind: tool
name: fetch_threat_intel_report
type: cloud-storage-read-object
source: my-agent-gcs-source
description: "Fetch parsed indicators of compromise from GCS"
# Enforce fine-grained tool-level scopes
authRequired:
  - my-agent-okta-auth
scopesRequired:
  - read:gcs_threat_intel
  - tier:enterprise_support

Jeśli operator bez uprawnień read:gcs_threat_intel uruchomi agenta, Toolbox odpowie błędem HTTP 403 Forbidden jeszcze przed pobraniem jakiegokolwiek obiektu przechowywanego.

3. Obserowalność od pierwszego dnia

Debiugowanie autonomicznego agenta różni się od debiugowania aplikacji deterministycznej, ponieważ wymaga możliwości zobaczenia całego łańcucha rozumowania modelu oraz jego interakcji z narzędziami. Serwery MCP powinny być traktowane jako infrastruktura produkcyjna pierwszej klasy, a nie jako tymczasowe skrypty pomocnicze. Wykorzystanie w Toolbox strukturyzowanego logowania oraz metryk wykonywania umożliwia zespołowi inżynieryjnemu monitorowanie częstotliwości wywołań, opóźnień, rozmiarów danych przekazywanych oraz wzorców błędów w czasie:

# Configure MCP Toolbox for structured logging
./toolbox --config "tools.yaml" --log-level info --logging-format json

# Configure MCP Toolbox to export traces and metrics
./toolbox --telemetry-gcp

Każde wywołanie może również wytwarzać ustrukturyzowany zapis wykonania:

# Structured execution log emitted by the MCP Server runtime
logger.info(
    "Tool invoked",
    extra={
        "tool": "fetch_threat_intel_report",
        "storage_source": "gcs://customer-diagnostics-vault",
        "report_id": "INC-89211",
        "bytes_streamed": 1048576,
        "latency_ms": 142.5,
        "request_id": "req-01HX89Z2A",
        "user_email": "analyst@demo.com"
    }
)

Wysyłanie tych strukturyzowanych danych do Cloud Logging oraz śledzenie ich w ramach wieloetapowego procesu szybko pokazuje, czy nagły wzrost opóźnienia wynika z bardzo dużego obiektu w GCS, zapytania w BigQuery bez indeksu, czy też z powolnej pracy samego modelu.

Wniosek

Agent jest tak skuteczny, jak tylko pozwala na to bezstrukturyzowany kontekst umieszczony w jego dyspozycji. Połączenie Google Cloud Storage z MCP Toolbox tworzy zespół agentów, który jest szybki, posiada bogaty kontekst i charakteryzuje się standardem korporacyjnym. Projektowanie narzędzi oparte na intencjach, powiązywanie parametrów URL oraz natywna autoryzacja OIDC umożliwiają modelom dostęp do kluczowych zbiorników danych bez kompromisów w zakresie bezpieczeństwa czy możliwości monitorowania.