AI-апдейт: агентний harness, tool-auth і браузерні дії під контролем

1. Що змінилося

Агенти швидко рухаються від “чат із доступом до tools” до керованого runtime: sandbox, tool search, MCP, subagents, браузерні дії, довгі задачі й audit trail. OpenAI описала Agents API як managed harness для роботи з файлами, tools, зовнішніми або hosted sandboxes і паралельними subagents. Практичний висновок простий: цінність уже не тільки в моделі, а в контурі виконання навколо неї.

Паралельно ринок безпеки почав наздоганяти agentic reality. Check Point випустила early availability для Prompt Attack Detection, який дивиться на MCP tool definitions, tool-call inputs і outputs. Reco заявила Browser Guard для runtime-контролю браузерних AI-дій з урахуванням identity, data і business context. Palo Alto Networks у вересневих нотатках Prisma AIRS додала тестування агентів з Gemini Agent Studio проти prompt injection і jailbreaks.

Для DevSecOps це означає: agent security стає не “перевірити prompt”, а “керувати виконанням”. Потрібні межі для identity, tools, browser, files, network, secrets, memory і publication path.

2. Tool-auth важливіший за красивий prompt

Слабке місце агентів - не тільки ворожий текст, а невірна авторизація дії. MCP у специфікації безпеки для авторизації вимагає PKCE, resource indicators і перевірку, що access token призначений саме MCP server-у; також прямо забороняє просто прокидати client token у downstream API (MCP security considerations).

Це правильний напрям, але OAuth не вирішує все. Офіційні MCP best practices окремо підкреслюють confused deputy, discovery SSRF, state-handle hijacking, local server compromise і надмірні scopes (MCP security best practices). Cloudflare у своєму MCP authorization guide також формулює важливу норму: доступ користувача має обмежувати доступ до конкретних tools, а не тільки до сервера загалом (Cloudflare MCP authorization).

Добра ментальна модель: tool call - це privileged operation. Його треба оцінювати як маленький change request: хто викликає, від чийого імені, з яким scope, на який ресурс, з яким rollback і evidence.

3. Що я б будував в OpenClaw

Найсильніший practical pattern на сьогодні - зробити OpenClaw не “розумним помічником”, а локальним agent control plane. Не треба починати з важкого enterprise IAM. Достатньо трьох локальних реєстрів у knowledge vault або repo:

1. agents.md - agent name, purpose, owner, allowed channels, allowed tools, forbidden actions.
2. tools.md - tool name, resource scope, risk tier, input/output data class, approval rule.
3. receipts/ - короткі записи для кожної дії: intent, files/resources, validation, source links, commit або artifact id.

Після цього кожен workflow стає менш магічним. Hugo publisher знає, що може міняти тільки content/ai/YYYY-MM-DD.md. Telegram bot знає, що group chat не має owner authority. Browser lane знає, що checkout/payment/account-security screens потребують pause. MCP lane знає, що новий tool definition не стає trusted тільки тому, що server authenticated.

4. 10 практичних OpenClaw use-cases

1. Agent harness passport. Для кожного recurring agent-run створити YAML/Markdown: model, tools, sandbox, writable paths, network egress, secrets names, validation command. OpenClaw читає passport перед стартом і блокує run, якщо фактичний доступ ширший.

2. MCP tool registry з diff-gate. Раз на день OpenClaw знімає snapshot tools/list, порівнює descriptions, schemas і server origin. Якщо tool змінив description або scope, workflow переходить у review-only режим до ручного підтвердження.

3. Browser action policy. Для browser automation завести правила: read-only сторінки можна проходити автоматично, form submit - тільки з receipt, платежі й зміни account/security - тільки через explicit approval packet.

4. Telegram topology guard. DM-бот має право на owner-only approvals; group chat - тільки на питання, короткі summaries і read-only lookups. OpenClaw перевіряє source channel перед будь-якою дією з write або external impact.

5. Knowledge-vault source ledger. Для Obsidian/OpenClaw vault кожна synthesized note має sources:, confidence:, last_checked: і allowed_for_action:. Памʼять може пояснювати рішення, але не може сама давати право діяти.

6. Tool-call receipt inbox. Кожен high-impact tool call пише короткий файл у receipts/YYYY-MM-DD/: command/tool, input class, output class, changed files, validation, failure mode. Раз на тиждень агент шукає повторювані ризики.

7. OpenClaw publisher lane. Для Hugo-публікацій зробити жорсткий contract: один target file, duplicate URL scan, Hugo build, git diff --check, optimistic remote head, remote blob verify. Будь-яке відхилення - stop, no retry storm.

8. Prompt-attack fixture pack. Зібрати локальний набір hostile emails, web pages, GitHub comments і MCP tool outputs. OpenClaw проганяє критичні agents проти fixtures після зміни prompt, skill або tool schema.

9. Agent vs skill boundary review. Якщо дія повторюється більше трьох разів, OpenClaw питає: це skill, config, tool чи vault page? Skill - процедура; config - політика; tool - executable capability; vault - evidence і рішення.

10. Day-start operating cockpit. О 09:00 OpenClaw збирає один Markdown: календар, urgent inbox, failed automations, repo status, stale secrets, pending approvals, сьогоднішні публікації. У Telegram іде тільки короткий сигнал, якщо є blocker.

5. Практичний висновок

Наступний крок для персонального OpenClaw - не більше autonomy, а кращий runtime contract. Спочатку опиши agent passports, tool registry і receipts. Потім уже додавай browser automation, MCP tools і background jobs.

Інакше агент буде виглядати продуктивним, але on-call у майбутньому отримає систему, де ніхто не знає, хто мав право натиснути кнопку.