OpenClaw щодня: authorization graph, policy data і permissions як продукт

openclaw · 2026-07-28

1. Новий кут: OpenClaw потребує authorization plane, не тільки allowlist

Allowlist tools — потрібний мінімум, але для живого OpenClaw цього мало. Краще думати так: кожна дія має subject → action → object → context → evidence.

Приклад: hugo-agent може write тільки content/openclaw/YYYY-MM-DD.md, може git push тільки після hugo --quiet, не може читати personal MEMORY.md у групових каналах, а Telegram-бот має інші права, ніж локальний TUI.

2. OpenFGA / SpiceDB як модель для agent permissions

OpenFGA і SpiceDB корисні не тому, що їх треба одразу ставити поруч із домашнім OpenClaw, а тому що вони дають правильну мову: relations, tuples, usersets, resources.

Практична схема для OpenClaw:

subject: agent:hugo-daily
action: publish
object: repo:devsecops-hugo/path:content/openclaw
context:
  channel: cron
  validation: hugo_quiet_passed
  branch: main

Це сильніше за “агенту можна git”. Дозвіл стає привʼязаним до ресурсу, контексту й доказу.

3. Cedar / Casbin / OPAL для policy-as-data

Cedar добре підходить як приклад читабельної authorization policy: principal, action, resource, condition. Apache Casbin корисний, якщо потрібна легка RBAC/ABAC-модель у своєму adapter-і. OPAL додає важливий шар: policy і policy data мають оновлюватися без redeploy агента.

Для OpenClaw це дає практичний патерн:

  • policy/agents.cedar або policy/openclaw.csv — хто що може;
  • policy/data.json — active projects, allowed paths, channels, quiet hours;
  • receipts/*.jsonl — що policy вирішила і чому;
  • review.md — які дозволи треба звузити після тижня реальних run-ів.

4. Конфігураційна ідея: permission diff перед кожним новим workflow

Перед новою автоматизацією OpenClaw має генерувати короткий diff:

+ agent:openclaw-research may read content/openclaw/*.md
+ agent:openclaw-research may fetch https sources
+ agent:openclaw-research may write content/openclaw/YYYY-MM-DD.md
- agent:openclaw-research may push without validation
- agent:openclaw-research may access private memory in shared channels

Це простий, але сильний UX: людина ревʼюїть не промпт, а зміну повноважень.

5. Практичний workflow для Hugo-публікацій

  1. source-scout читає старі пости й зовнішні джерела, але не пише в repo.
  2. writer створює тільки today markdown у дозволеному path.
  3. validator запускає hugo --quiet і повертає pass/fail.
  4. publisher отримує право git add/commit/push тільки якщо validation pass і diff містить лише дозволені files.
  5. receipt-writer зберігає URL-и, headline-и, validation result і commit hash у локальний ledger.

Це не overengineering для daily content. Це нормальна межа між research, write, verify і publish.

6. 10 практичних ідей OpenClaw на сьогодні

  1. Authorization graph для агентів — markdown/JSON карта: agent → allowed actions → resources → approval tier.
  2. Permission diff перед новою skill — кожна Skill Workshop proposal показує, які tools/path/channel permissions потрібні.
  3. Policy receipt ledger — кожна risky дія пише decision: allow/deny, policy id, resource і validation gate.
  4. Channel-aware permissions — той самий агент у Telegram DM має більше прав, ніж у group chat або Discord ambient room.
  5. Path-scoped publisher — Hugo publisher не може змінити config/theme/layouts без окремого approval.
  6. Quiet-hours policy data — cron може писати файли вночі, але не пушити шум у Telegram, якщо немає incident.
  7. Tool-call simulation — перед live run OpenClaw показує predicted tools і питає approval тільки на нові capabilities.
  8. Weekly permission shrink — агент аналізує невикористані дозволи й пропонує прибрати їх.
  9. Fresh-source gate — daily posts проходять policy: URL не використовувався, headline не повторюється, тема має новий кут.
  10. Break-glass scope — emergency agent отримує короткий TTL і тільки read/diagnose/report, не repair-by-default.

7. Матеріали й відео

Висновок

Сильний OpenClaw setup — це не “агенту довіряю”. Це permissions як продукт: явні ресурси, вузькі дії, policy data, receipts і регулярне звуження доступу. Сьогоднішній практичний крок: описати один recurring workflow як authorization graph і прибрати з нього всі “може все”.