AI-агент без доступа к вебу упирается в потолок: зачем командам нужен один MCP-шлюз вместо 20 хрупких интеграций

Я — Denis Shokhirev, Agentic AI Systems Architect из Freiburg im Breisgau, Germany, и в DennisCraft AI Studio я собираю production-grade AI-системы на Claude, Supabase, n8n, Doppler и self-hosted Postgres. Самый частый момент, когда агент в проде внезапно «тупеет», выглядит не как сбой модели: он просто не может дотянуться до актуального веб-контекста, API-документации, статуса заказа, тикета или внутренней базы знаний без 20 отдельных костылей.

Проблема не в том, что LLM «недостаточно умная». Проблема в архитектуре доступа к инструментам. Если вашему агенту нужно отдельно знать, как ходить в CRM, ERP, helpdesk, Postgres, документацию, файловое хранилище и внешние сайты, вы очень быстро получаете зоопарк интеграций, где каждый коннектор живет своей жизнью. В regulated-среде это особенно неприятно: аудит доступа, логирование, ротация секретов и контроль прав расползаются по системе.

Почему агент без веб-доступа быстро упирается в потолок

На раннем этапе почти все выглядит приемлемо. Есть prompt, есть пара tools, есть RAG по документации. Агент отвечает, вызывает функцию, пишет в базу. Но как только задача становится операционной, а не демонстрационной, вылезают ограничения.

1. Статичный контекст устаревает быстрее, чем обновляется prompt

Внутренний knowledge base не содержит live-данных: новые статусы поставок, обновления API, изменения в ценах, SLA поставщиков, инциденты в сторонних системах. Если агент не умеет получить внешний контекст по запросу, он начинает уверенно отвечать на вчерашних данных.

2. Локальные интеграции ломаются асимметрично

Один Python-скрипт ходит в Postgres, другой — в Jira через webhook, третий — в REST API поставщика, четвертый — парсит веб-страницы. Пока их 3, команда терпит. Когда их 20, вы уже не знаете, где именно сломался доступ: в auth, в rate limit, в форматах ответа или в политике сети.

3. Контроль доступа превращается в хаос

OWASP в 2021 обновил Top 10 и поставил Broken Access Control на 1 место: это была причина 94% протестированных приложений по их данным (OWASP Top 10, 2021, https://owasp.org/Top10/). Для агентных систем это бьет еще сильнее: если каждый tool подключается отдельно, права обычно растут стихийно. В итоге у агента больше полномочий, чем нужно для конкретной задачи.

Что дает один MCP-шлюз вместо россыпи прямых коннекторов

MCP здесь важен не как модное слово, а как паттерн: один стандартизованный слой между моделью и инструментами. Вместо того чтобы учить агента 20 способам доступа, вы даете ему один интерфейс вызова инструментов, а маршрутизацию, аутентификацию, логирование и политику доступа выносите в шлюз.

В моих проектах для DACH B2B это снижает не только число падений, но и операционную стоимость изменений. Когда появляется новый источник данных, я не переписываю логику агента целиком. Я добавляю capability в шлюз, описываю права, подключаю логирование, и агент видит новый инструмент через тот же контракт.

Как выглядит практическая схема в проде

Минимальная рабочая схема обычно простая: Claude получает задачу, вызывает tool через стандартизованный интерфейс, шлюз решает, можно ли этот вызов выполнять, дальше обращается к Postgres, Supabase, вебу или n8n, а результат возвращает в нормализованном виде.

Пример: policy-check перед вызовом инструмента

from typing import Dict

ALLOWED = {
    "support_agent": {"search_docs", "get_order_status"},
    "ops_agent": {"search_docs", "get_order_status", "update_ticket"},
}

def can_call(agent_role: str, tool_name: str) -> bool:
    return tool_name in ALLOWED.get(agent_role, set())

def execute_tool(agent_role: str, tool_name: str, args: Dict):
    if not can_call(agent_role, tool_name):
        raise PermissionError(f"{agent_role} cannot call {tool_name}")
    return {"tool": tool_name, "args": args, "status": "accepted"}

print(execute_tool("support_agent", "get_order_status", {"order_id": "A-441"}))

Это базовая идея, но именно она обычно отсутствует в спешно собранных agent stacks. Сначала команда радуется, что tool вызвался. Потом приходит вопрос от compliance или клиента: кто дал этому агенту право читать эти данные, где это логируется, и можно ли доказать, что доступ был ограничен.

Пример: простой HTTP-шлюз к внутренним инструментам

import express from "express";

const app = express();
app.use(express.json());

app.post("/tool/get_order_status", async (req, res) => {
  const { orderId } = req.body;
  if (!orderId) return res.status(400).json({ error: "missing orderId" });

  res.json({
    orderId,
    status: "in_transit",
    source: "postgres",
    checkedAt: new Date().toISOString()
  });
});

app.listen(3000, () => console.log("gateway on :3000"));

Даже такой примитивный слой уже лучше, чем 10 разрозненных вызовов прямо из агента. На этом уровне можно централизовать audit log, rate limiting, redaction PII и ротацию секретов через Doppler.

Где веб-доступ действительно нужен, а где нет

Не каждому агенту нужен открытый интернет. Но очень многим нужен контролируемый доступ к вебу. Я разделяю 3 сценария.

Контролируемый внешний веб

Проверка документации поставщика, статуса API, публичных регламентов, цен, changelog. Это полезно, но только через allowlist, с кэшированием и логированием запросов.

Внутренний веб и сервисы

Confluence, helpdesk, внутренние панели, customer portal, self-hosted docs. Формально это не «интернет», но для агента это все равно веб-доступ. И именно он часто критичнее внешнего.

Вообще без веба

Есть процессы, где веб не нужен: локальная классификация документов, SQL-аналитика по заранее определенным таблицам, triage по внутренним тикетам. Ошибка — делать из этого универсальное правило для всех задач.

Что проверять перед запуском такого шлюза

Я не советую начинать с broad access и потом «ужимать». В regulated рынках это почти всегда заканчивается долгом по безопасности.

export TOOL_GATEWAY_URL=http://localhost:3000
export ALLOWLIST_DOMAIN=docs.example.com
export LOG_LEVEL=info

curl -X POST "$TOOL_GATEWAY_URL/tool/get_order_status" \
  -H "Content-Type: application/json" \
  -d '{"orderId":"A-441"}'

Практический checklist короткий:

• минимальные права на каждый tool;
• единый audit trail по вызовам;
• секреты вне кода, например через Doppler;
• нормализация ответов, чтобы агент не ловил 12 разных форматов ошибок;
• fallback, если внешний источник недоступен.

Если вы уже используете n8n, не надо выбрасывать его. Я обычно оставляю n8n как оркестратор процессов, а MCP-шлюз — как policy и access layer. Это разные роли, и в связке они работают лучше, чем по отдельности.

FAQ

MCP-шлюз — это замена RAG?

Нет. RAG хорошо закрывает поиск по известному корпусу данных. MCP-шлюз решает другую задачу: стандартизированный, управляемый доступ к инструментам и актуальным источникам.

Можно ли обойтись без веб-доступа вообще?

Да, если задача полностью локальна и не зависит от внешнего состояния. Но как только агент должен принимать решение на актуальных данных, изоляция от веба быстро становится ограничением.

Почему не подключить все API напрямую к агенту?

Потому что сначала это быстро, а потом дорого в сопровождении. Прямые интеграции размазывают auth, ошибки, форматы ответов и аудит по всей кодовой базе.

Подходит ли это для regulated рынков?

Да, именно там это особенно полезно. Один слой доступа проще проверять, логировать и ограничивать, чем десятки самостоятельных коннекторов.

С чего начать, если система уже работает на костылях?

Начните с 3 самых критичных tools и вынесите их за единый gateway. Не пытайтесь мигрировать все сразу; сначала стабилизируйте точку контроля.

Где у вас сейчас настоящий потолок для AI-агента: отсутствие live web context, расползшиеся права доступа или слишком много несвязанных tool-интеграций? Я правда хочу понять, на каком слое у вас ломается прод.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.