15. Безопасность
🔵 Как в Agent OS устроены auth, изоляция, секреты и аудит.
15.1 Конфигурация доступа — сводная таблица
Вся аутентификация/авторизация и секреты в одном месте (детали — в указанных разделах):
| Что контролирует | Где задаётся | Тип | Раздел |
|---|---|---|---|
| Админ-токены (bearer) | auth.admin_tokens — имя → токен или {token, templates} |
YAML | §15.2 |
| Токены из env | auth.admin_token_env / AGENT_OS_ADMIN_TOKEN (имя=токен) |
env | §15.2 |
| Пароли web-логина | auth.users — логин → пароль или {password, templates} |
YAML | §15.2 |
| Роли (скоуп по шаблонам) | templates: [...] у токена/пользователя |
YAML | §15.3 |
| Ключ LLM-провайдера | provider.api_key / DEEPSEEK_API_KEY / AGENT_OS_API_KEY |
YAML/env | §15.4 |
| Идентичность конечных пользователей | auth.web_user_secret_env (HMAC) |
env | §15.8 |
| Токен входящего webhook | inbound.token_env |
env | §15.7 |
| Токен webhook воркфлоу | triggers.webhook.token_env |
env | §15.7 |
| Токены cron/webhook sink'ов | notify[].token_env |
env | §15.7 |
| Токен Telegram-бота | telegram.token_env (в agent.yaml) |
env | §15.4 |
| Пароль IMAP / SMTP | email.imap_password_env, smtp.password_env |
env | §15.4 |
| Ограничение хостов прокси | proxy.allow_hosts |
YAML | §15.6 |
| TLS (сертификат/ключ) | AGENT_OS_TLS_CERT / AGENT_OS_TLS_KEY |
env | §15.5 |
Общий принцип: значения секретов — только в .env; в YAML пишется лишь имя
env-переменной (token_env / password_env). Сами токены и пароли никогда не
логируются.
15.2 Аутентификация админ-API
Защищённые эндпоинты (/v1/agents*, /v1/sessions*, /v1/budgets, /v1/cron,
/v1/workflows*, /v1/dashboard, /v1/users*, /v1/memory*, …) принимают либо
Authorization: Bearer <токен> (API-клиенты), либо cookie agentos_session
(браузер после /login).
- Bearer-токены — из
auth.admin_tokens(картаимя → токен) илиauth.admin_token_env(списокимя=токенчерез запятую/;/перевод строки). - Web-логин — из
auth.users(логин → пароль); выдаётHttpOnlycookie на 12 часов.
Поведение при отказе: если auth настроена, но ни один credential не разрешается — админ-API fails closed (401 на всё). Без токенов и пользователей — открыт (dev-режим). Подробности — §8.3.
15.3 Ролевой доступ (RBAC)
Токен или web-пользователь могут быть ограничены по шаблонам — это скоупед-оператор:
auth:
admin_tokens:
drom-op:
token: "<token>"
templates: [drom-agent] # принципал видит только эти шаблоны
users:
drom-viewer:
password: "<password>"
templates: [drom-agent]
Полный токен (голый имя → токен) = полный доступ. Воркфлоу дополнительно
объявляют свои templates — скоупед-оператор запускает только те, что в его
скоупе (§12.4).
15.4 Обращение с секретами
- Секреты — только в
.env(API-ключи,token_env,password_env). YAML хранит лишь имя переменной окружения, никогда само значение. - Токены не логируются: в access-лог пишется только имя токена/пользователя
(или
invalid), не значение. .envв.gitignore; шаблон —.env.example.
15.5 TLS / HTTPS
Задай AGENT_OS_TLS_CERT и AGENT_OS_TLS_KEY (пути к PEM) — сервер поднимет
HTTPS. Иначе — обычный HTTP (например за reverse-прокси, который терминирует TLS).
15.6 SSRF-защита прокси
/proxy и /proxy/content блокируют приватные, loopback, link-local и
reserved-диапазоны (включая 169.254.169.254) на каждом редиректе.
proxy.allow_hosts дополнительно ограничивает хосты (точное совпадение или
поддомен); пусто = любой публичный хост. Только http/https, порты 80/443.
15.7 Аутентификация webhook'ов
- Входящий webhook
POST /v1/inbound/:template— bearer-токен изinbound.token_env(пусто = открыто, dev). - Webhook воркфлоу
POST /v1/workflows/:name/webhook— токен изtriggers.webhook.token_env; не задан/пуст → все запросы отклоняются. - Cron/webhook sink'и — опциональный
token_envдля bearer-токена.
15.8 Изоляция данных
- Агенты изолированы: один агент не читает контекст другого и не тратит его бюджет (раздел «концепции»).
trace_toolвозвращает только то, что разрешено вызывающему: полный доступ у админа (admin_templates: "*"), ограниченный — у скоупед-админа, а агент конечного пользователя без админ-токена получает user-скоуп изX-User-Idи видит только свою историю (trace_tool).- Память (
memory) и state store скоупятся на пользователя (user_id); без user id — откат к сессии → шаблону → процессу. - Идентичность конечных пользователей по умолчанию подписывается HMAC
(
POST /v1/user-ticket,X-User-Token) — см. §8.8.
15.9 Аудит
- Access-лог (
logs/access.jsonl+logs/access.db) — каждый HTTP-запрос: метод, путь, статус, длительность, IP, user-agent,X-User-Id, имя админ-токена/пользователя. Значения токенов не пишутся. - Событийное хранилище (
logs/events.db) — аудит действий агентов (tool-вызовы, бюджеты, ошибки). - Канонический реестр пользователей (
logs/users.db) — соответствие канал → id.