Knowledge System · Production Architecture

Tool access — це ще не право діяти

Authority & Action Control Plane відділяє probabilistic planning від deterministic business authority. Модель може запропонувати дію; application layer вирішує, чи вона допустима, хто має право її схвалити, як виконати її рівно один раз і як довести фактичний результат.

Core invariant

LLM intent ≠ tool availability ≠ authorization ≠ approval ≠ authoritative outcome. Це п’ять різних станів.

80/20 control

Найбільший ефект дають deterministic pre-action gate, exact-action approval, idempotency key і authoritative postcondition.

Failure rule

Після невідомого результату write-операції: reconcile first → retry second. Інакше retry сам стає інцидентом.

Reference architecture

10 контрольних шарів перед і після side effect

1 · Principal / identity

Хто реально ініціює дію: user, service, delegated agent або operator. Identity береться з authoritative auth/session layer, а не зі слів моделі.

Exit criterion

Є stable principal ID, tenant, roles, authentication strength і delegation chain.

2 · Task eligibility

До model/tool selection deterministic policy перевіряє, чи цей тип задачі взагалі дозволений для principal, tenant, jurisdiction, data class і current system state.

Exit criterion

Недопустима задача блокується до LLM planning; denial має reason code і audit event.

3 · Capability scope

Agent отримує не “CRM access”, а мінімальну capability: read account, draft refund, create ticket, request approval. Read, draft, write і consequential actions — різні scopes.

Exit criterion

Tool catalog фільтрується за effective scopes; unavailable capability неможливо викликати навіть через prompt injection.

4 · Action contract

Перед side effect формується exact canonical action: target, operation, normalized arguments, amount/resource/version, expected preconditions, idempotency key і expiry.

Exit criterion

Approval та audit прив’язані до action hash, а не до розмитого “дозволяю агенту продовжити”.

5 · Policy + approval gate

Deterministic business rules вирішують, чи дія дозволена автоматично, потребує step-up authentication, human approval або заборонена. Model confidence не замінює authority.

Exit criterion

High-impact дія не може виконатися без required policy decision та exact-action approval.

6 · Execution boundary

Application/tool executor повторно перевіряє identity, scope, freshness, approval і preconditions безпосередньо перед write. Tool schema validation — необхідна, але не є authorization.

Exit criterion

Malformed, stale або over-scoped request fail-closed; executor не покладається на прихований context моделі.

7 · Authoritative postcondition

Після execution система читає system of record і перевіряє фактичний результат: refund існує, ticket створений, permission змінено, commit з’явився. “Tool returned success” недостатньо.

Exit criterion

DONE ставиться тільки після verified postcondition; partial/pending/unknown залишаються окремими станами.

8 · Reconciliation / retry

Після timeout або crash спочатку перевіряється, чи side effect уже відбувся. Blind retry для payment, booking, permission або deployment — це дуже дорогий спосіб дізнатися значення слова duplicate.

Exit criterion

Idempotency key + authoritative lookup вирішують ambiguity; правило: reconcile first → retry second.

9 · Revocation / containment

Revocation principal/session/tool/provider/tenant має поширюватися на pending work. Scoped kill switch зупиняє лише небезпечну capability, не обов’язково весь продукт.

Exit criterion

Pending approvals мають expiry/version binding; revoked scope не може бути відновлений старим serialized state.

10 · Evidence / evals

Release і runtime перевіряють не тільки answer quality, а unauthorized action rate, false deny, approval bypass, stale replay, cross-tenant leakage, duplicate side effects і recovery.

Exit criterion

Є risk-sliced regression suite, trace decision → approval → execution → postcondition і permanent incident-derived cases.

Authority tiers

Не одна “autonomy level”, а різні права на різні дії

R0 · ObserveRead-only public/non-sensitive contextБез write tools; provenance та ACL все одно перевіряються.

R1 · AssistDraft, summarize, recommendOutput не змінює system of record.

R2 · Low-risk writeCreate/update reversible low-impact recordsDeterministic policy, idempotency, postcondition, bounded scope.

R3 · Approved writeRefund, booking, notification, workflow transitionExact-action approval або programmatic policy approval; freshness + target binding.

R4 · ConsequentialPermissions, finance, legal/public-benefit, security containmentStep-up identity, human/business authority, dual controls де потрібно, explicit rollback/redress.

R5 · ProhibitedIrreversible/unsupported/high-blast-radius action поза policyNo tool exposure. Не “попросіть модель бути обережною”, а технічна відсутність capability.

Adversarial / failure evals

Що повинно ламатися в лабораторії, а не у клієнта

— Prompt injection просить використати capability, якої немає в effective scope.
— Tool metadata або MCP description намагається переконати agent обійти approval.
— Approval створений для action A, але model змінює amount/target перед execution.
— Approval старий: policy, account state, price або model/tool version вже змінилися.
— User відкликав permission, поки durable run був paused.
— Cross-tenant ID підставлено у валідний tool schema.
— Executor timeout після фактичного write; retry не повинен створити duplicate.
— Tool повернув success, але authoritative system of record не підтверджує postcondition.
— Parallel branches конфліктують за той самий resource/version.
— Failover на інший provider або tool endpoint не повинен розширити authority.

Staged rollout

1. Inventory усіх tools/actions і business owners.
2. R0/R1 read/draft mode + full trace.
3. Deterministic eligibility та scoped tool catalog.
4. Shadow writes: сформувати action, не виконувати.
5. R2 bounded writes з idempotency/postcondition.
6. R3 exact-action approvals і stale-action tests.
7. R4 лише після risk-sliced evals, revocation та recovery drill.
8. Incident-derived regression suite як постійний release gate.