Как я построил guardrails, которые не дали моему AI-агенту пойти вразнос
На третий день мой агент слил 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"ignores+(alls+)?previouss+instructions", r"yous+ares+nows+a", r"disregards+(your|all)s+(rules|instructions)", r"systems*prompts*:", r"<<s*SYSs*>>", ] PII_PATTERNS = { "ssn": r"bd{3}-d{2}-d{4}b", "credit_card": r"bd{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"bd{3}-d{2}-d{4}b", # SSN r"bd{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 не сделают вашего агента умнее. Но они не дадут глупым моментам превратиться в инциденты.
