agents-harden

agents-harden — официальный навык AWS AgentCore для подготовки AI-агента к production. Он формирует проектный checklist по безопасности, надёжности и производительности: IAM, входная аутентификация, управление секретами, обработка ошибок, валидация payload, rate limits, наблюдаемость, холодный старт, session lifecycle, фоновые задачи и квоты. Навык применим перед запуском агента, при ограничении вызывающих сторон, при проверке production readiness, при throttling или quota errors и при работе с долгими задачами. Он отдельно отделяет свои области от Cedar tool restrictions, outbound credential wiring, A2A auth, качества ответов и диагностики cold start: для этих задач исходный документ направляет к другим навыкам AgentCore. Первый шаг — проверить версию agentcore --version; нужен CLI 0.9.0 или новее. Затем навык читает agentcore/agentcore.json и выясняет ресурсы, framework, память, gateway, credentials, evaluators и network mode PUBLIC или VPC. В IAM checklist входят сужение автоматически созданного широкого Bedrock-доступа до конкретных моделей, ограничение ECR-доступа собственным репозиторием и trust policy с account и source ARN условиями. Если используется InvokeAgentRuntimeCommand, его нужно проверять отдельно от InvokeAgentRuntime: это произвольное shell-выполнение внутри microVM с правами execution role. Для него рекомендуется отдельная IAM policy, CloudTrail/EventBridge alert и валидация пользовательских команд с отказом от shell-метасимволов вроде &&, ;, подстановок, обратных кавычек и pipe. Для входящих вызовов AWS_IAM подходит для внутренних AWS-клиентов, а CUSTOM_JWT — для внешних web/mobile клиентов. Авторизация NONE в production запрещена, потому что endpoint становится доступным любому обладателю URL. При CUSTOM_JWT нужно проверить discovery URL, issuer, JWKS, срок действия токена и выбрать allowedAudience или allowedClients по фактическому claim токена: aud имеет приоритет, если присутствует; client_id используется, когда aud отсутствует. Несовпадение issuer и префикса discovery URL может привести к отказу валидации ещё до проверки бизнес-логики. Код агента должен валидировать обязательные поля, типы, длины строк, числовые диапазоны и форматы идентификаторов. В исходном примере prompt должен быть строкой, не пустым, не длиннее 10 000 символов и очищенным от управляющих символов и лишних пробелов. Ошибки следует логировать внутри с деталями, но возвращать вызывающему безопасное сообщение без stack trace и внутренних деталей. Runtime имеет встроенное ограничение вызовов, а per-user или per-tenant rate limiting должен находиться в приложении или API Gateway. Секреты нельзя хардкодить или передавать как обычные runtime environment variables: credentials регистрируются через agentcore add credential и извлекаются интегрированным provider из Secrets Manager. Для внешних REST API и MCP навык предлагает рассмотреть Gateway targets, чтобы credential и policy enforcement оставались на границе. Наблюдаемость включает X-Ray и CloudWatch, а retention логов нужно задать явно для контроля стоимости. До запуска рекомендуется получить baseline eval по Helpfulness и GoalSuccessRate, а затем включить online evaluation с sampling rate. Для private AWS resources выбирается VPC. Производительность начинается с измерения cold start: типичный новый environment может занимать примерно 20–30 секунд, поэтому важны размер артефакта, imports и module-level initialization. Целевой пакет — менее 200 MB, желательно менее 100 MB; тяжёлые модели, подключения и MCP-клиенты следует откладывать до запроса. Самое сильное ускорение даёт повторное использование одного session_id в многоходовом диалоге или batch, а не новый ID на каждый HTTP request. Жизненный цикл сессии влияет на стоимость и maxVms. Idle environment по умолчанию живёт до idleRuntimeSessionTimeout 900 секунд, а maxLifetime по умолчанию составляет 8 часов; idle VM всё это время занимает квоту. После завершения работы нужно вызывать StopRuntimeSession, для связанных запросов переиспользовать session ID, а таймауты подбирать под форму нагрузки. Для фоновой работы fire-and-forget недостаточен: нужно зарегистрировать add_async_task до старта работы и вызвать complete_async_task в finally, иначе runtime может вернуть response и reclaim-нуть environment по idle timeout. При ошибке maxVms сначала проверяются stop-сессии, генерация ID и idle timeout, и только затем запрашивается увеличение квоты.