На третий день мой агент слил email одного клиента в переписку с другим клиентом. Это была не гипотетическая история из доклада на конференции. Это был мой код, в проде, делающий то, что я никогда не тестировал.
Я собрал support-агента на LangGraph и GPT-4o. Он умел искать по базе знаний, подтягивать детали аккаунта и готовить ответы. В staging он работал прекрасно. В проде ему понадобилось ровно 72 часа, чтобы вытащить PII одного пользователя в разговор с другим. Причина оказалась до неловкого простой: модель включила сырой контекст из базы данных прямо в ответ, и ничто в моём пайплайне это не проверяло.
Постфактум фикс был очевиден. Фреймворки для AI-агентов дают вам оркестрацию, вызов инструментов и память. Они не дают вам безопасность. Это уже на вас.
Почему ваш фреймворк не включает guardrails
LangChain, CrewAI, LangGraph, Agents SDK от OpenAI. Выберите любой. Ни один из них не идёт из коробки с валидацией входа, фильтрацией выхода или контролем расходов. Они исходят из того, что вы добавите это сами.
Большинство команд так и не добавляют.
Почему это важно — объясняет простая арифметика. При точности 90% на шаг, агентный workflow из 5 шагов успешен в 59% случаев. Workflow из 10 шагов падает до 35%. На 20 шагах вы на уровне 12%. Каждый незащищённый шаг — это умножение вашей вероятности отказа.
Guardrails не чинят точность. Они ограничивают радиус поражения, когда точность отказывает. Разница между «агент дал неправильный ответ» и «агент дал неправильный ответ, в который попал чей-то номер соцстрахования» — это один output-валидатор.
Следующие две недели я строил стек guardrails. Код ниже — то, к чему я в итоге пришёл.
Четыре guardrail, нужные каждому агенту
Каждому агенту нужна защита в четырёх точках:
Input guardrails ловят prompt injection и вычищают чувствительные данные до того, как их увидит LLM.
Output guardrails валидируют ответы до того, как их увидят пользователи, блокируя галлюцинации и утёкший контекст.
Cost circuit breakers не дают счёту за API улететь в космос из-за зацикливания или неожиданно длинных разговоров.
Tool call validators подтверждают, что агент вызывает только разрешённые инструменты с параметрами, проходящими проверку схемы.
Все четыре умещаются менее чем в 200 строк Python. Накладные расходы по latency — 10–50 мс на слой. Альтернатива — узнавать о сбоях от своих клиентов.
Input guardrails: ловим плохие промпты до выполнения
Ваш input-валидатор работает до того, как LLM вообще увидит промпт. Он делает две вещи: блокирует попытки инъекции и редактирует PII.
import re
from dataclasses import dataclass
@dataclass
class ValidationResult:
is_valid: bool
reason: str = ""
sanitized_input: str = ""
class InputGuardrail:
INJECTION_PATTERNS = [
r"ignore\s+(all\s+)?previous\s+instructions",
r"you\s+are\s+now\s+a",
r"disregard\s+(your|all)\s+(rules|instructions)",
r"system\s*prompt\s*:",
r"<<\s*SYS\s*>>",
]
PII_PATTERNS = {
"ssn": r"\b\d{3}-\d{2}-\d{4}\b",
"credit_card": r"\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b",
"email": r"\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b",
}
def validate(self, user_input: str) -> ValidationResult:
# Check for prompt injection
for pattern in self.INJECTION_PATTERNS:
if re.search(pattern, user_input, re.IGNORECASE):
return ValidationResult(
is_valid=False,
reason=f"Prompt injection detected: {pattern}"
)
# Scrub PII from input
sanitized = user_input
for pii_type, pattern in self.PII_PATTERNS.items():
sanitized = re.sub(pattern, f"[REDACTED_{pii_type.upper()}]", sanitized)
return ValidationResult(
is_valid=True,
sanitized_input=sanitized
)
Это не пуленепробиваемо. Настойчивый атакующий обойдёт основанное на regex обнаружение инъекций. Но оно ловит частые попытки, которые по моему опыту составляют около 80% реальных атак. Для продакшена с чувствительными данными добавьте поверх regex-прохода модель-классификатор (вроде Lakera Guard или дообученного DistilBERT).
Вычистка PII — именно та часть, что спасла бы меня на третий день. Если бы мой input guardrail вырезал email из контекста базы данных до того, как он попал в разговор, утечки бы не случилось.
Output guardrails: останавливаем галлюцинации до пользователя
Валидация выхода — то место, где большинство команд пропускают guardrails вовсе. Модель дала ответ, выглядит разумно, отправляем. Но «выглядит разумно» — это не тот стандарт, на который можно полагаться.
from pydantic import BaseModel, field_validator
from typing import Optional
import json
class AgentResponse(BaseModel):
answer: str
confidence: float
sources: list[str]
@field_validator("confidence")
@classmethod
def check_confidence(cls, v):
if not 0.0 <= v <= 1.0:
raise ValueError("Confidence must be between 0 and 1")
return v
@field_validator("answer")
@classmethod
def check_no_pii_leak(cls, v):
pii_patterns = [
r"\b\d{3}-\d{2}-\d{4}\b", # SSN
r"\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b", # Credit card
]
for pattern in pii_patterns:
if re.search(pattern, v):
raise ValueError("Response contains potential PII")
return v
class OutputGuardrail:
def __init__(self, confidence_threshold: float = 0.7):
self.confidence_threshold = confidence_threshold
def validate(self, raw_response: dict) -> ValidationResult:
try:
response = AgentResponse(**raw_response)
except Exception as e:
return ValidationResult(
is_valid=False,
reason=f"Response failed schema validation: {e}"
)
if response.confidence < self.confidence_threshold:
return ValidationResult(
is_valid=False,
reason=f"Confidence {response.confidence} below threshold"
)
if not response.sources:
return ValidationResult(
is_valid=False,
reason="No sources provided for claim"
)
return ValidationResult(is_valid=True, sanitized_input=response.answer)
Pydantic-модель делает двойную работу. Она навязывает структуру (LLM обязана вернуть JSON с answer, confidence и sources) и прогоняет контентные проверки (никакого PII в выходе). Когда валидация падает, мой агент повторяет запрос с дополнительным контекстом: «Ваш предыдущий ответ отклонён, потому что [причина]. Попробуйте снова».
Два повтора со всё более конкретными инструкциями чинят большинство падений валидации. Если падает три раза — я возвращаю заготовленный fallback-ответ и логирую инцидент.
Kill switch: circuit breaker по расходам и токенам
Это тот guardrail, про который никто не пишет, и именно он стоил мне $400.
У меня был баг, из-за которого агент входил в цикл повторов. Вызов инструмента падал, агент повторял, повтор падал чуть иначе, и агент повторял снова. Каждый повтор сжигал токены на шаге рассуждения плюс на вызове инструмента. Он крутился шесть часов ночью, прежде чем я заметил.
import time
from threading import Lock
class CostCircuitBreaker:
def __init__(
self,
max_tokens_per_request: int = 50_000,
max_tokens_per_session: int = 200_000,
max_api_calls_per_minute: int = 30,
max_daily_spend_usd: float = 50.0,
):
self.max_tokens_per_request = max_tokens_per_request
self.max_tokens_per_session = max_tokens_per_session
self.max_api_calls_per_minute = max_api_calls_per_minute
self.max_daily_spend = max_daily_spend_usd
self._session_tokens = 0
self._minute_calls = []
self._daily_spend = 0.0
self._lock = Lock()
def check_budget(self, estimated_tokens: int) -> ValidationResult:
with self._lock:
# Per-request limit
if estimated_tokens > self.max_tokens_per_request:
return ValidationResult(
is_valid=False,
reason=f"Request needs ~{estimated_tokens} tokens, "
f"limit is {self.max_tokens_per_request}"
)
# Session limit
if self._session_tokens + estimated_tokens > self.max_tokens_per_session:
return ValidationResult(
is_valid=False,
reason="Session token budget exhausted"
)
# Rate limit
now = time.time()
self._minute_calls = [t for t in self._minute_calls if now - t < 60]
if len(self._minute_calls) >= self.max_api_calls_per_minute:
return ValidationResult(
is_valid=False,
reason="API call rate limit exceeded"
)
# Daily spend
estimated_cost = (estimated_tokens / 1_000_000) * 3.00 # ~GPT-4o rate
if self._daily_spend + estimated_cost > self.max_daily_spend:
return ValidationResult(
is_valid=False,
reason="Daily spend limit reached"
)
# All checks passed, record usage
self._session_tokens += estimated_tokens
self._minute_calls.append(now)
self._daily_spend += estimated_cost
return ValidationResult(is_valid=True)
Per-request лимит ловит очевидный случай: одно гигантское контекстное окно, которое прожжёт ваш бюджет. Session-лимит ограничивает суммарные траты на один разговор. Rate-лимит предотвращает шторм повторов. А дневной лимит трат — ваш абсолютный потолок.
Я выставил дневной лимит в $50. Если упираюсь в него — система перестаёт звать API и возвращает ответ «сервис временно недоступен». Я лучше получу простой, чем счёт-сюрприз.
Валидация вызова инструментов: агент не должен звать то, что вы не одобрили
Когда у агента есть доступ к базе данных, файловой системе или внешнему API, валидация вызовов инструментов — не опция. Без неё взломанный или запутавшийся агент может выполнить разрушительную операцию.
class ToolCallGuardrail:
def __init__(self, allowed_tools: dict[str, dict]):
"""
allowed_tools format:
{
"search_knowledge_base": {
"allowed_params": ["query", "top_k"],
"max_calls_per_session": 20,
},
"get_account_info": {
"allowed_params": ["account_id"],
"max_calls_per_session": 5,
},
}
"""
self.allowed_tools = allowed_tools
self._call_counts: dict[str, int] = {}
def validate_tool_call(
self, tool_name: str, params: dict
) -> ValidationResult:
# Tool must be in allowlist
if tool_name not in self.allowed_tools:
return ValidationResult(
is_valid=False,
reason=f"Tool '{tool_name}' is not in the allowlist"
)
tool_config = self.allowed_tools[tool_name]
# Check parameters
for param in params:
if param not in tool_config["allowed_params"]:
return ValidationResult(
is_valid=False,
reason=f"Parameter '{param}' not allowed for {tool_name}"
)
# Check call frequency
count = self._call_counts.get(tool_name, 0)
if count >= tool_config["max_calls_per_session"]:
return ValidationResult(
is_valid=False,
reason=f"Tool '{tool_name}' call limit reached"
)
self._call_counts[tool_name] = count + 1
return ValidationResult(is_valid=True)
Я выбрал default deny. Если инструмента нет в allowlist — агент не может его вызвать. Если параметра нет в списке разрешённых для этого инструмента — вызов отклоняется. Это ловит и попытки джейлбрейка (когда модель пытается вызвать execute_sql или delete_record), и галлюцинированные имена инструментов (что случается чаще, чем вы думаете).
Лимиты частоты вызовов держу отдельно по каждому инструменту, потому что у разных инструментов разный профиль риска. Поиск — дёшево и безопасно вызвать 20 раз. Обновление аккаунта должно происходить максимум раз-два за разговор.
Собираем вместе: продакшен-стек guardrails
Вот как эти четыре части соединяются в реальном пайплайне агента:
User Input
|
[Input Guardrail] --> reject / sanitize
|
[Cost Circuit Breaker] --> check budget
|
[LLM Reasoning]
|
[Tool Call Guardrail] --> validate tool + params
|
[Tool Execution]
|
[LLM Response Generation]
|
[Output Guardrail] --> validate / retry / fallback
|
User Response
Каждый guardrail логирует свои решения. На каждый отказ — структурированная запись с причиной, входом, который его вызвал, и таймстампом. Раз в неделю я гоняю запрос по этим логам в поисках паттернов: если одна и та же попытка инъекции встречается 50 раз — это, вероятно, автоматизированная атака. Если output guardrail отклоняет 15% ответов за низкую уверенность — это проблема качества retrieval, которую надо чинить выше по пайплайну.
Суммарный overhead по latency для всех четырёх guardrails — менее 40 мс (без учёта ML-классификаторов). Для пользователя это невидимо.
Что бы я сделал иначе
Если бы начинал заново, я бы добавил guardrails до написания первой строки логики агента. Описанный здесь каркас — примерно 200 строк Python. Две недели у меня ушло только потому, что я встраивал его в уже существующую систему и параллельно разбирал инцидент с PII.
Мой прогноз: в течение 12 месяцев крупные агентные фреймворки начнут поставлять guardrails как first-class функцию. LangGraph уже движется в эту сторону со своим механизмом interrupt. А пока — вы сами по себе.
Начните с input guardrails и cost circuit breaker. Только эти два предотвратили бы оба моих инцидента (утечку PII и ночной счёт на $400). Добавьте валидацию выхода, когда появится продакшен-трафик, чтобы настроить пороги уверенности. Добавьте валидацию вызова инструментов, если у агента есть доступ на запись хоть к чему-нибудь.
Guardrails не сделают вашего агента умнее. Но они не дадут глупым моментам превратиться в инциденты.