48 / PRODUCTION CONTROL / POLICY DECISION + ENFORCEMENT

GUARDRAILS
& POLICIES.

Guardrails & Policies — слой управляемых ограничений AI-системы. Policy определяет, что разрешено, запрещено или требует дополнительных условий. Guardrail превращает это правило в реальный enforcement point: блокирует, преобразует, ограничивает, отправляет на approval или разрешает операцию.

Ключевой принцип: критические ограничения не должны существовать только как текст в system prompt. Чем опаснее side effect, тем жёстче enforcement должен находиться вне модели.

00. ARCHITECTURAL STATUS

ПОЛИТИКА ДОЛЖНА ДОХОДИТЬ ДО ТОЧКИ ИСПОЛНЕНИЯ

Тема относится к production layer и одновременно касается Quality Engine: правила должны оцениваться на нескольких границах, а самые критичные запреты — реально исполняться host/runtime слоем.

TYPEPRODUCTIONCross-cutting runtime control.

DEFAULTONБазовые policy checks постоянно доступны.

ENABLE WHENALWAYS / CONTEXTUALHard boundaries всегда; semantic checks по контексту.

SEPARATE COMPONENTYESОтдельная логическая responsibility / interface.

LIVES INR08 + FABRICQuality Engine + Production Fabric.

COMPLEXITYLOW → HIGHНачать с кода, схем, scopes и approval.

IMPLEMENT: YES / EARLY

Минимум 80% ценности: central policy function, tool wrappers как enforcement points, deterministic parameter validation, risk classification, approval gate для high-risk действий, tenant/data boundaries, output redaction/release check и audit trail. Не нужен «safety swarm» из нескольких LLM-agents.

01A. ARCHITECTURE BOUNDARIES & OPERATIONS

EXPLICIT SYSTEM CONTRACT

A. BOUNDARY WITH NEIGHBORS

№45 Verification проверяет correctness конкретного результата; №48 решает, допустим ли action/output по policy. №47 Evals измеряет, работают ли guardrails на наборе кейсов. №49 HITL реализует human approval/handoff, когда policy требует человека. №51 Permissions & Secrets задаёт технические scopes/credentials; policy может сузить permission, но не расширить. №52 Security описывает threat model и обход границ; №48 — общий enforcement framework.

B. PREREQUISITES / CROSS-REFERENCES

Prerequisites: №12 Tools, №41 Executive Architecture, №42 Events, №45 Verification, №46 Observability, №47 Evals. Forward references: №49 approval/HITL, №50 contracts, №51 permissions/secrets, №52 injection/security, №53 sandbox, №76 privacy/governance.

C. PLANE PLACEMENT

REQUEST-TIME: YES — input/output/tool gates. CONTROL PLANE: YES — policy registry, versions, deployment, shadow/canary. DATA PLANE: YES — enforcement на data/tool boundaries. OFFLINE: YES — tests, evals, incident regression, policy analysis.

D. FAILURE & OPERATIONS CONTRACT

Success: decision evaluated and enforced before protected action. Retryable: transient policy dependency failure only where retry is safe. Permanent: DENY, invalid parameters, forbidden scope. Idempotency: approval/action tokens bound to exact operation. State: policy_id/version, decision, reason, obligations, subject, action hash. Trace: every sensitive enforcement decision.

E. WHAT THIS TOPIC DOES NOT OWN

№48 не владеет identity management, secret storage, prompt-injection threat model, sandbox runtime, request verification, human workflow или всей privacy/governance системой. Она владеет POLICY DECISION + ENFORCEMENT CONTRACT между этими слоями.

01. FIRST PRINCIPLE

POLICY ≠ PROMPT

Prompt может влиять на поведение модели. Guardrail должен контролировать фактическое исполнение.

SOFT INSTRUCTION

«Не отправляй письма без подтверждения» в system prompt.

Полезно как guidance, но модель может ошибиться, неправильно интерпретировать контекст или быть атакована.

→

POLICY DECISION

Runtime вычисляет: SEND_EMAIL → REQUIRE_APPROVAL.

Результат структурированный и versioned.

→

ENFORCEMENT

Tool wrapper физически не вызывает API без approval token, связанного с точными параметрами письма.

Если policy существует только в natural-language prompt, это soft guardrail. Для high-risk side effects нужен реальный PEP — Policy Enforcement Point.

02. MASTER PIPELINE

ПРОВЕРКИ НА НЕСКОЛЬКИХ ГРАНИЦАХ

IDENTITY / TENANTКто выполняет задачу и в каком security/data scope.

→

INPUT POLICYAllowed input, data class, source trust, size, format.

→

CONTEXT POLICYЧто можно передать модели, tool, provider, subagent.

→

MODEL / PLANAI предлагает reasoning path, output или action.

→

OUTPUT POLICYSchema, secrets, PII, evidence, release rules.

→

TOOL INTENTAction type, resource, parameters, risk, reversibility.

→

PEP / APPROVALALLOW / DENY / REDACT / REQUIRE_APPROVAL.

→

EXECUTE + READBACKActual effect, outcome verification, audit.

Один финальный moderation pass недостаточен: к моменту проверки ответа tool уже мог совершить внешний side effect.

03. POLICY DECISION CONTRACT

РЕШЕНИЕ ДОЛЖНО БЫТЬ СТРУКТУРИРОВАННЫМ

{
  "policy_id": "tool.publish.v3",
  "policy_version": "3.2.1",
  "subject": "agent:smm",
  "action": "publish_post",
  "resource": "channel:vk_main",
  "context": {
    "tenant": "brand_A",
    "risk": "high"
  },
  "decision": "REQUIRE_APPROVAL",
  "reason_code": "EXTERNAL_PUBLICATION",
  "obligations": [
    "freeze_exact_payload",
    "redact_secrets",
    "audit"
  ],
  "expires_at": "..."
}

DECISION ENUM

Не только allow / deny

ALLOW — выполнить.

DENY — заблокировать.

REQUIRE_APPROVAL — остановиться и запросить approval.

REDACT / TRANSFORM — удалить или преобразовать запрещённые поля.

ESCALATE — передать более авторитетному policy/human layer.

ALLOW может содержать obligations: например «разрешить, но только read-only / до 10 объектов / без PII / с audit».

04. POLICY TAXONOMY

КАКИЕ ПРАВИЛА ОБЫЧНО НУЖНЫ

Identity / Tenant

Кто субъект, к какому tenant принадлежит, какие ресурсы допустимы.

Tool / Action

Какие tools можно вызвать, какие параметры и side effects допустимы.

Data Egress

Какие данные можно передавать внешней модели, API, connector или subagent.

Privacy / Secrets

Redaction, data classes, retention, prohibited fields.

Risk / Money

Monetary limits, irreversible actions, critical domains, approval thresholds.

Release / Publish

Draft vs external publication, destination sensitivity, evidence requirements.

Agent Delegation

Что разрешено передавать другим agents и какие capabilities им делегируются.

Model Eligibility

Какие модели/providers допустимы для определённых data classes / regions / tenants.

Logging / Retention

Что можно записывать в traces, что нужно redact, сколько хранить.

05. HARD / SOFT / HYBRID

НЕ ВСЕ GUARDRAILS ОДИНАКОВО НАДЁЖНЫ

HARD

Deterministic barrier

ACL, DB RLS, schema validation, enum/range check, allowlist, sandbox, amount cap, tenant scope, cryptographic approval token.

Лучший выбор, если правило формализуемо.

SOFT

Semantic judgment

System prompt, classifier, LLM policy judge, semantic risk detector.

Полезен там, где смысл нельзя полностью выразить кодом. Не должен быть единственным барьером для irreversible action.

HYBRID

Best practical stack

Hard outer boundary + semantic decision внутри + human approval на unresolved high-risk cases.

Типовой production pattern.

Правило: deterministic first → semantic only when necessary → human for unresolved high-risk.

06. RISK MODEL

РИСК — КОНТЕКСТ, А НЕ МЕТКА SAFE / UNSAFE

RISK AXIS

LOW

MEDIUM

HIGH

PROHIBITED

Reversibility
Можно отменить?

Read-only / preview.

Limited write / easy rollback.

External publish / money / destructive write.

Forbidden class.

Privilege
Какой доступ нужен?

Public / own low-risk data.

Scoped tenant write.

Admin / secrets / sensitive data.

No legitimate scope.

Externality
Кого затронет?

Internal draft.

Team workflow.

Customer / public / legal effect.

Disallowed recipient/resource.

Uncertainty
Насколько понятен intent?

Exact structured request.

Some missing context.

Ambiguous irreversible action.

Contradictory/invalid request.

TYPICAL ROUTING

LOW → ALLOW. MEDIUM → ALLOW WITH CONSTRAINTS + stronger verification. HIGH → REQUIRE_APPROVAL / additional evidence. PROHIBITED → DENY. UNKNOWN → retrieve/clarify/escalate before action.

07. TOOL / ACTION GUARDRAILS

САМАЯ ВАЖНАЯ ГРАНИЦА — ПЕРЕД SIDE EFFECT

ALLOWLIST

Tool scope

Роль/задача получает только разрешённые tools.

SCHEMA

Parameters

Types, enums, ranges, required fields, destination scope.

PREVIEW

Dry run

Показать planned effect до внешнего write.

THRESHOLD

Limits

Money, quantity, recipients, delete count, batch size.

TENANT

Resource bind

Tenant/resource ID не должен быть unrestricted model input.

APPROVAL

Exact action

Approval связан с конкретными параметрами.

IDEMPOTENCY

Duplicate safe

Повтор не создаёт второй side effect.

READBACK

Outcome

После выполнения проверить фактический эффект, а не intent модели.

PROPOSEModel proposes structured action.

→

VALIDATESchema / scope / range / tenant.

→

POLICYALLOW / DENY / APPROVAL / obligations.

→

FREEZE PARAMSCanonical payload/hash.

→

APPROVEIf required, exact action only.

→

EXECUTEProtected tool wrapper.

→

VERIFY OUTCOMEReadback / authoritative state.

08. APPROVAL BINDING

APPROVAL НЕ ДОЛЖЕН БЫТЬ РАЗМЫТЫМ

Approval Token

{
  "approval_id": "APR-...",
  "principal": "user:123",
  "action": "publish_post",
  "resource": "vk:brand_A",
  "payload_hash": "sha256:...",
  "max_effect": {
    "posts": 1
  },
  "expires_at": "...",
  "policy_version": "3.2.1"
}

ANTI-PATTERN

«Разрешаю публиковать»

Такой approval слишком широкий. После получения разрешения модель может изменить текст, канал, аудиторию или параметры.

Правильно: approval связывается с exact canonical payload / resource / principal / expiry. Если параметры изменились — policy evaluation и approval повторяются.

Это защищает от TOCTOU-подобной проблемы: time of check ≠ time of use.

09. INPUT & CONTEXT GUARDRAILS

UNTRUSTED DATA НЕ СТАНОВИТСЯ INSTRUCTION

SOURCE TRUST

Metadata

Каждый источник получает provenance/trust/data class. Retrieved text считается данными, а не privileged instructions.

CONTEXT SCOPE

Need-to-know

В prompt/tool/subagent передаются только разрешённые поля и релевантный slice.

TAINT

Untrusted content

External HTML, email, PDF и connector data могут содержать hostile instructions; deeper threat model — тема №52.

Guardrail classifier полезен, но не является абсолютной истиной. Для критических границ нужно сочетать semantic detection с deterministic scope/permission controls.

10. OUTPUT / ARTIFACT / RELEASE

DRAFT И PUBLICATION — РАЗНЫЕ РИСКИ

Стадия	Проверка	Типичные policy obligations
Model output	Schema / prohibited fields / secret leakage.	REDACT, TRANSFORM, REVISE.
Internal draft	Business rules / evidence / destination class.	Allow internal-only, watermark draft, require citations.
Artifact export	PII, confidential data, file type, metadata.	Redact, encrypt, restrict destination.
External publish/send	Exact recipient/channel/payload/risk.	Approval, freeze payload, audit, readback.

12. AGENT DELEGATION POLICY

A2A НЕ ОТМЕНЯЕТ POLICY

DELEGATION CONTRACT

Передать меньше, чем имеешь

Subagent получает только необходимые context refs, tool scopes, budget, risk level и output contract. Parent agent не должен автоматически передавать все свои credentials/capabilities.

POLICY RE-EVALUATION

Новый boundary

Перед delegation проверяются recipient eligibility, data egress, tenant, model/provider rules и allowed actions. A2A message — не способ обойти tool guardrail.

13. POLICY PRECEDENCE

КОНФЛИКТЫ РЕШАЮТСЯ ДЕТЕРМИНИРОВАННО

MANDATORYLegal/platform/org hard boundaries.

↓

TENANTTenant-specific restrictions.

↓

WORKFLOWTask/process policy.

↓

USER PREFAllowed personalization.

↓

ACTIONCurrent resource/risk/context decision.

Это пример hierarchy, а не универсальный мировой стандарт. Главное: более низкий слой не может расширить запрещённое более высоким hard policy. Conflict resolution должен быть кодом/engine semantics, а не импровизацией модели.

14. PDP & PEP

DECISION POINT ≠ ENFORCEMENT POINT

PDP / POLICY DECISION POINT

Решает

Получает subject, action, resource, context и policy version. Возвращает ALLOW / DENY / REQUIRE_APPROVAL / obligations.

Может быть обычной функцией, модулем, DB rules или policy engine. Не обязан быть отдельным сервисом.

PEP / POLICY ENFORCEMENT POINT

Применяет

Стоит на реальной границе: tool wrapper, API gateway, DB layer, connector, artifact exporter, publisher.

Если PDP сказал DENY, PEP обязан физически остановить операцию.

MOST COMMON FAILURE

Policy engine правильно возвращает DENY, но tool execution path не проверяет decision. Это означает: policy существует в отчёте, но guardrail отсутствует.

15. FAIL-OPEN / FAIL-CLOSED

ЧТО ДЕЛАТЬ, ЕСЛИ POLICY LAYER НЕДОСТУПЕН

Класс действия	Policy service unavailable	Рекомендованное поведение
Low-risk local read	Potentially degradable.	Можно использовать cached/local rule, если это заранее определено.
External write	High uncertainty.	Fail closed или require approval/manual path.
Money / destructive / privileged	Critical.	Fail closed. Не исполнять.
Policy logging outage only	Depends on obligation.	Если audit обязательный — блокировать; иначе queue audit event.

Fail-open/fail-closed — policy decision самого production design. Нельзя случайно получить fail-open только потому, что exception не обработан.

16. VERSIONING & OBSERVABILITY

НУЖНО ЗНАТЬ, КАКАЯ ПОЛИТИКА ПРИНЯЛА РЕШЕНИЕ

VERSION

Policy provenance

policy_id, policy_version, config hash, rollout cohort.

DECISION

Reason code

ALLOW/DENY/... + reason + obligations + subject/action/resource.

OUTCOME

Actual effect

Executed? blocked? approved? parameter drift? readback result?

Policy trace не должен содержать hidden chain-of-thought. Достаточно decision, reason_code, structured facts, references и actual outcome.

17. TESTING & EVALS

GUARDRAILS НУЖНО ТЕСТИРОВАТЬ КАК КОД

UNIT

Deterministic

Allowed action passes; forbidden action denied; thresholds exact.

NEGATIVE

Mutation

Изменить tenant/amount/resource после approval и убедиться, что PEP блокирует.

EVALS

Semantic

Adversarial/ambiguous cases для LLM/classifier policy checks.

INCIDENT

Regression

Каждый escape превращать в permanent test family.

SHADOW MODE

Новую policy можно сначала запускать в shadow: decision вычисляется и логируется, но enforcement ещё не применяется для допустимых сценариев. Это помогает измерить false-deny до rollout. Для критических hard boundaries shadow не заменяет реальную защиту.

18. MVP IMPLEMENTATION

НЕ НАЧИНАТЬ С ОТДЕЛЬНОГО «SAFETY AGENT»

policy/
├── registry.yaml
├── versions/
├── authorize.py
├── risk.py
├── obligations.py
├── tests/
│   ├── unit/
│   ├── negative/
│   └── regression/
└── audit.py

tools/
├── wrappers/
│   ├── email.py
│   ├── publish.py
│   ├── database.py
│   └── files.py
└── schemas/

approvals/
├── tokens.py
└── store.py

80% VALUE MVP

Обычный код достаточно

Versioned registry YAML/JSON/PostgreSQL.
authorize(subject, action, resource, context).
Tool wrappers как PEP.
JSON Schema / type / enum / range validation.
Tenant/resource binding host-side.
Risk tier + approval gate.
Exact approval token/hash.
Output redaction/release check.
Audit event на sensitive actions.
Unit + regression tests.

OPA/Cedar или другой policy engine можно добавить позже, когда rules/teams/services действительно потребуют отдельного DSL/engine.

19. FAILURE MODES

КАК GUARDRAILS ЛОМАЮТСЯ В PRODUCTION

ONLY SYSTEM PROMPT

Critical policy существует только как instruction модели.

ADD HARD PEP

FINAL CHECK ONLY

Moderation после того, как tool уже выполнил side effect.

PRE-ACTION GATE

MODEL CHOOSES SCOPE

Tenant/resource ID берётся прямо из свободного model output.

HOST BINDING

VAGUE APPROVAL

Approval не связан с точными параметрами.

HASH EXACT PAYLOAD

DENY WITHOUT ENFORCEMENT

PDP возвращает DENY, но execution path продолжает работу.

PEP MUST BLOCK

FAIL OPEN BY EXCEPTION

Policy check упал, catch продолжил execution.

RISK-BASED FAIL MODE

UNVERSIONED RULES

Невозможно воспроизвести, почему вчера действие было разрешено.

VERSION + TRACE

DUPLICATED POLICIES

Каждый tool wrapper имеет свою расходящуюся копию правил.

CENTRAL DECISION CONTRACT

OVERBLOCKING

Все операции high-friction, пользователи начинают обходить систему.

RISK TIERS + EVALS

20. METRICS

ЧТО ИЗМЕРЯТЬ

PEP

Enforcement Coverage

% sensitive actions, реально проходящих через policy enforcement.

High-risk escape

High-risk actions executed without required gate. Target: zero.

False Deny

Легитимные действия, ошибочно заблокированные policy.

APR

Approval Rate

Доля операций, ушедших к человеку, по сегментам риска.

LAT

Decision Latency

Стоимость policy evaluation в runtime path.

CON

Policy Conflict

Частота конфликтующих rules/configurations.

REG

Regression Escape

Incidents, которые существующий suite должен был поймать.

Guardrail Ablation

Safety/quality delta относительно cost/friction.

Не оптимизировать false-deny изолированно. У low-risk и high-risk действий разный приемлемый trade-off между friction и safety.

21. DESIGN RULES

ПРАВИЛА, КОТОРЫЕ СТОИТ УНЕСТИ В КОД

RULE 01

Hard where formalizable

Если правило можно выразить схемой, ACL, range или scope — не отдавать его LLM.

RULE 02

PEP at the effect

Enforcement стоит рядом с реальным side effect, а не только в planner.

RULE 03

Policy narrows permission

Контекстная policy может уменьшить разрешённое, но не выдаёт отсутствующий permission.

RULE 04

Bind approvals

Approval = exact action + resource + params/hash + principal + expiry.

RULE 05

Re-evaluate before execute

Если context/state мог измениться, policy проверяется непосредственно перед use.

RULE 06

Trace decisions

Policy version, decision, reason, obligations и actual outcome должны быть воспроизводимы.

RULE 07

Semantic ≠ absolute

LLM/classifier полезен для смысла, но high-risk boundary должен иметь hard outer layer.

RULE 08

Test negative paths

Проверять не только разрешённые сценарии, но и попытки обхода/изменения параметров.

RULE 09

Minimize friction by risk

Не заставлять low-risk read проходить тот же approval flow, что и irreversible write.

22. PRACTICAL DECISION

СТОИТ ЛИ ДЕЛАТЬ ОТДЕЛЬНЫЙ КОМПОНЕНТ?

Вопрос	Ответ
Стоит ли реализовывать?	Да, рано. Без enforcement граница между reasoning и side effect слишком хрупкая.
Минимум 80% ценности?	Central authorize(), tool PEP, schema/scope validation, risk tiers, exact approval, audit, output release check.
Когда overkill?	Если делать отдельный LLM-agent, policy microservice cluster и сложный DSL для маленького single-user prototype с 2 read-only tools.
Trigger для semantic guardrail?	Rule cannot be formalized; ambiguous data/output; high-risk meaning requires interpretation.
Как измерить uplift?	Escape rate, critical violations, false deny, approval precision, incident rate, cost/friction, ablation.
Можно ли заменить LLM-agent?	В большинстве случаев — да. Code/schema/ACL/tool wrapper/policy function должны быть default.

23. FINAL MAP

POLICY → DECISION → ENFORCEMENT → EVIDENCE

USER / EVENT / AGENT
        ↓
IDENTITY + TENANT + CONTEXT
        ↓
INPUT / DATA POLICY
        ↓
EXECUTIVE / MODEL / PLAN
        ↓
OUTPUT / ACTION INTENT
        ↓
VALIDATE PARAMETERS
        ↓
PDP — POLICY DECISION POINT
        ↓
ALLOW / DENY / REDACT / APPROVAL / ESCALATE
        ↓
PEP — POLICY ENFORCEMENT POINT
        ↓
[ IF APPROVAL ]
freeze exact payload → approve → verify token
        ↓
EXECUTE SIDE EFFECT
        ↓
READBACK / OUTCOME VERIFICATION
        ↓
TRACE:
policy_id + version + reason + obligations + actual result
        ↓
EVALS / INCIDENT REGRESSION / POLICY IMPROVEMENT

CORE PRINCIPLE:

THE MODEL MAY PROPOSE.
THE SYSTEM DECIDES.
THE ENFORCEMENT POINT ACTUALLY BLOCKS OR ALLOWS.

ECC RETROFIT / PRACTICAL HARNESS INTEGRATION

A. Related ECC ideas. Context-as-cache, scoped memory, lifecycle hooks, selective capabilities, feature flags, deterministic enforcement, provider-neutral adapters and eval-gated learning are applied only where relevant to №48 Guardrails & Policies.

B–E. Existing boundary and placement. The existing conceptual boundary, class PRODUCTION, default ON and owner Quality Engine + Production Fabric remain authoritative. Runtime/control/data/offline placement is unchanged; durable state stays outside model context.

F–H. Hooks and contracts. Use bounded PRE_MODEL/POST_MODEL, PRE_TOOL/POST_TOOL, CHECKPOINT and TASK_COMPLETED events as applicable. Illustrative fields and canonical contracts are defined in NEW_CONTRACTS_SPEC.md; no universal schema is implied.

I–J. Security and evaluation. Host-side schema, permission, secret, budget, idempotency and audit checks take precedence over LLM output. Optional mechanisms require a feature flag and WITH/WITHOUT ablation; measure quality, acceptance, correction, latency, cost, escalations and severe errors.

K–L. Task profiles and cross-references. A TaskProfile selects the relevant skill, tool/context slice, memory scope and enforcement profile independently from FAST/STANDARD/DEEP. See cross-reference map, hook spec and ablation plan. Provider adapters remain outside the core.

GUARDRAILS& POLICIES.

ПОЛИТИКА ДОЛЖНА ДОХОДИТЬ ДО ТОЧКИ ИСПОЛНЕНИЯ

EXPLICIT SYSTEM CONTRACT

POLICY ≠ PROMPT

ПРОВЕРКИ НА НЕСКОЛЬКИХ ГРАНИЦАХ

РЕШЕНИЕ ДОЛЖНО БЫТЬ СТРУКТУРИРОВАННЫМ

Не только allow / deny

КАКИЕ ПРАВИЛА ОБЫЧНО НУЖНЫ

Identity / Tenant

Tool / Action

Data Egress

Privacy / Secrets

Risk / Money

Release / Publish

Agent Delegation

Model Eligibility

Logging / Retention

НЕ ВСЕ GUARDRAILS ОДИНАКОВО НАДЁЖНЫ

Deterministic barrier

Semantic judgment

Best practical stack

РИСК — КОНТЕКСТ, А НЕ МЕТКА SAFE / UNSAFE

САМАЯ ВАЖНАЯ ГРАНИЦА — ПЕРЕД SIDE EFFECT

Tool scope

Parameters

Dry run

Limits

Resource bind

Exact action

Duplicate safe

Outcome

APPROVAL НЕ ДОЛЖЕН БЫТЬ РАЗМЫТЫМ

Approval Token

«Разрешаю публиковать»

UNTRUSTED DATA НЕ СТАНОВИТСЯ INSTRUCTION

Metadata

Need-to-know

Untrusted content

DRAFT И PUBLICATION — РАЗНЫЕ РИСКИ

MODEL НЕ ДОЛЖНА САМА ВЫБИРАТЬ ЧУЖОЙ RESOURCE SCOPE

A2A НЕ ОТМЕНЯЕТ POLICY

Передать меньше, чем имеешь

Новый boundary

КОНФЛИКТЫ РЕШАЮТСЯ ДЕТЕРМИНИРОВАННО

DECISION POINT ≠ ENFORCEMENT POINT

Решает

Применяет

ЧТО ДЕЛАТЬ, ЕСЛИ POLICY LAYER НЕДОСТУПЕН

НУЖНО ЗНАТЬ, КАКАЯ ПОЛИТИКА ПРИНЯЛА РЕШЕНИЕ

Policy provenance

Reason code

Actual effect

GUARDRAILS НУЖНО ТЕСТИРОВАТЬ КАК КОД

Deterministic

Mutation

Semantic

Regression

НЕ НАЧИНАТЬ С ОТДЕЛЬНОГО «SAFETY AGENT»

Обычный код достаточно

КАК GUARDRAILS ЛОМАЮТСЯ В PRODUCTION

ЧТО ИЗМЕРЯТЬ

Enforcement Coverage

High-risk escape

False Deny

Approval Rate

Decision Latency

Policy Conflict

Regression Escape

Guardrail Ablation

ПРАВИЛА, КОТОРЫЕ СТОИТ УНЕСТИ В КОД

Hard where formalizable

PEP at the effect

Policy narrows permission

Bind approvals

Re-evaluate before execute

Trace decisions

Semantic ≠ absolute

Test negative paths

Minimize friction by risk

СТОИТ ЛИ ДЕЛАТЬ ОТДЕЛЬНЫЙ КОМПОНЕНТ?

GUARDRAILS
& POLICIES.