<b>Агенту нужен доступ к advertiser-API, но ключи нельзя отдавать “в лоб”</b>

<b>Агенту нужен доступ к advertiser-API, но ключи нельзя отдавать “в лоб”</b>

Если агент ходит в Meta Ads / Google Ads / TikTok Ads API, самая частая ошибка — положить API key в промпт или в общий .env и забыть про границы доступа. Для performance это плохо не “в теории”, а по двум причинам: ключ начинает жить дольше, чем должен, и его нельзя нормально отозвать по сценарию.

Нормальная схема — не один ключ на всё, а разделение:
— отдельный service account / app credential под каждый канал;
— права только на нужные методы: read отдельно, write отдельно;
— короткоживущие токены для агентских задач, длинные — только у оркестратора;
— ротация по расписанию, а не “когда сломалось”.

Ещё один слой — прокси-слой между агентом и API. Агент не должен видеть сырой секрет вообще: он вызывает вашу функцию, а уже она подписывает запрос, логирует действие и режет опасные операции. Так проще поставить лимиты: rate limit, allowlist эндпоинтов, запрет на bulk-edit без human review. 🔒

Логи тоже важны: в них не должно быть access_token, refresh_token, client_secret и full headers. Для дебага достаточно request id, endpoint, статус и latency. Если секреты попали в trace, их потом копируют в Slack, тикеты и LLM-контекст — и проблема становится системной.

Минимальный чек-лист:
— секреты только в secret manager, не в промптах и не в n8n-полях;
— отдельные ключи под prod / sandbox;
— manual approval для spend-changing действий;
— быстрый revoke-путь для каждого ключа.

Если агенту нужен доступ к advertiser-API, вопрос не “можно ли дать ключ”, а “как дать доступ так, чтобы его можно было безопасно отозвать через минуту”.