51 / PERMISSIONS & SECRETS / PRODUCTION FABRIC
51 / PRODUCTION / IDENTITY · SCOPES · CREDENTIALS · LEAST PRIVILEGE

PERMISSIONS
& SECRETS.

Permissions & Secrets — инфраструктурный слой, который отвечает на два критических вопроса: кто или что имеет право выполнить действие и как система безопасно получает необходимые credentials, не превращая prompt, memory или logs в хранилище секретов.

Ключевой принцип: AI-модель не должна «иметь пароль». Она должна получать ограниченную способность выполнить конкретное действие через host-controlled capability/tool boundary.
00. ARCHITECTURAL STATUS

МОДЕЛЬ НЕ ДОЛЖНА БЫТЬ SECURITY PRINCIPAL С НЕОГРАНИЧЕННЫМ ДОСТУПОМ

Permissions & Secrets — постоянная production capability. Это отдельная логическая responsibility в Production Fabric: identity, scopes, credentials, secret references, token issuance, rotation/revocation и enforcement.
TYPEPRODUCTIONSecurity / access infrastructure.
DEFAULTONВсе sensitive actions проходят authority checks.
ENABLE WHENALWAYSIdentity/scope layer всегда; secret material только on-demand.
SEPARATE COMPONENTYESLogical security boundary; не обязательно отдельный microservice.
LIVES INPRODUCTION FABRICSupporting infrastructure, не R11.
COMPLEXITYLOW → HIGHНачать с vault/env boundary + scoped tool wrappers.
IMPLEMENT: YES / BEFORE REAL ACTIONS
Минимум 80% ценности: explicit principals, least-privilege scopes, secret references вместо raw values, credentials injected только inside tool boundary, environment/tenant separation, short-lived tokens где возможно, rotation/revocation, redaction и audit. Никакого «LLM security agent» для хранения паролей.
01A. ARCHITECTURE BOUNDARIES & OPERATIONS

EXPLICIT SYSTEM CONTRACT

A. BOUNDARY WITH NEIGHBORS

№48 Guardrails & Policies решает, разрешено ли действие в данном контексте; №51 определяет, имеет ли principal техническую capability выполнить его и какие credentials нужны. №49 HITL может потребовать approval, но approval не создаёт отсутствующий permission. №50 Contracts задаёт shape identity/scope/action claims. №52 Prompt Injection & Agent Security изучает попытки заставить систему злоупотребить уже имеющимися capabilities. №54 Connectors использует auth flows и credentials для конкретных систем. №76 Governance задаёт более широкий data/compliance слой.

B. PREREQUISITES / CROSS-REFERENCES

Prerequisites: №10 State, №12 Tools, №42 Events, №46 Observability, №48 Policies, №50 Contracts. Forward references: №52 Security, №53 Sandbox, №54 Connectors, №60 Artifact Store, №76 Data Governance & Privacy. Более поздние темы — implementation/detail references, не обязательные prerequisites.

C. PLANE PLACEMENT

REQUEST-TIME: YES — permission check и credential injection перед sensitive action. CONTROL PLANE: YES — principals, roles, scopes, secret lifecycle, revocation, policy mapping. DATA PLANE: YES — actual access to APIs/DB/files. OFFLINE: YES — audits, rotation, access review, secret scanning, regression/security tests.

D. FAILURE & OPERATIONS CONTRACT

Success: authorized principal receives minimum capability for exact resource/action and secret never leaks to untrusted context. Retryable: temporary token issuance/vault outage where safe. Permanent: scope missing, principal disabled, revoked credential, forbidden tenant/environment. Idempotency: token/permission operations should not multiply grants. Persist: principal, scope, secret_ref, issuance/revocation metadata, not raw secret. Trace: access decision and credential use, never secret content.

E. WHAT THIS TOPIC DOES NOT OWN

№51 не владеет context-sensitive business policy, prompt-injection threat model, connector business semantics, human approval lifecycle, sandbox containment или enterprise IAM продуктом целиком. Она владеет IDENTITY → AUTHORIZATION SCOPE → CREDENTIAL DELIVERY → REVOCATION.

01. FIRST PRINCIPLE

НЕ ДАВАЙ МОДЕЛИ СЕКРЕТ — ДАЙ ЕЙ CAPABILITY

BAD

Prompt содержит API key, DB password или OAuth token.

Модель может повторить его в output, tool args, memory, trace или через prompt injection.

BETTER

Model emits structured intent:

send_email(recipient_id, body_ref)

Без raw credential.

HOST

Tool wrapper resolves secret_ref / short-lived token inside protected runtime, checks scope, executes and returns sanitized result.

AI reasoning layer должен знать capability metadata, а не secret material: «можно отправить письмо от account A», но не «вот OAuth refresh token account A».
02. IDENTITY MODEL

КТО ИМЕННО СОВЕРШАЕТ ДЕЙСТВИЕ

USER PRINCIPAL

Human identity

Конкретный пользователь и его tenant/org memberships. Действие может происходить «on behalf of user».

SERVICE PRINCIPAL

System identity

Worker/service/automation account с собственной ограниченной role.

AGENT LOGICAL ID

AI executor identity

Agent/subagent как логический actor в trace. Обычно не хранит credential сам, а использует host capability.

TENANT CONTEXT

Security boundary

К какому customer/workspace относятся data/resources.

WORKLOAD IDENTITY

Runtime instance

Конкретный deployment/process/pod/host может получать machine credential независимо от модели.

DELEGATED IDENTITY

On-behalf-of

Service действует в ограниченном subset прав пользователя, а не от имени супер-аккаунта.

TRACE RULE
Audit event должен различать requesting user, logical agent, runtime service и external account. Иначе невозможно понять, кто реально инициировал и выполнил действие.
03. AUTHN VS AUTHZ

КТО ТЫ ≠ ЧТО ТЕБЕ МОЖНО

AUTHENTICATION / AUTHN

Proof of identity

Система подтверждает principal: session, service identity, signed token, workload credential.

Вопрос: кто это?

AUTHORIZATION / AUTHZ

Allowed capability

Проверяется action/resource/scope/tenant/context.

Вопрос: что этому principal разрешено?

Даже идеально authenticated user не получает автоматически admin capability. И наоборот: наличие API key не означает, что конкретная AI-задача должна иметь право использовать все возможности этого key.
04. LEAST PRIVILEGE

МИНИМАЛЬНО ДОСТАТОЧНЫЕ ПРАВА

CAPABILITY
READ
CREATE
UPDATE
DELETE
ADMIN
Research agent
YES
NO
NO
NO
NO
Draft writer
YES
DRAFT
OWN DRAFT
NO
NO
Publisher
YES
APPROVED
SCOPED
NO
NO
Maintenance worker
SCOPED
SCOPED
SCOPED
BY POLICY
NO
Не выдавать «универсальный Gmail/Drive/DB token» всем агентам. Лучше capabilities по task class: read_mail, create_draft, send_approved_mail — это разные уровни риска.
05. CAPABILITY BOUNDARY

TOOL ДОЛЖЕН БЫТЬ УЖЕ, ЧЕМ API KEY

USER / TASKRequest carries principal + tenant.
EXECUTIVESelects allowed logical capability.
TOOL CONTRACTNarrow operation schema.
AUTHZprincipal × action × resource × scope.
SECRET RESOLVEsecret_ref / token exchange in host.
EXTERNAL APICredential used only here.
SANITIZENo secret returned to model/trace.
EXAMPLE
Даже если service account технически может читать и удалять весь bucket, tool get_report(report_id) должен expose только read нужного prefix/tenant. Security boundary — это не только credential scope, но и узость самого tool interface.
06. WHAT IS A SECRET

ЧТО НЕЛЬЗЯ ПЕРЕДАВАТЬ В PROMPT КАК ОБЫЧНЫЕ ДАННЫЕ

API KEYS

Provider keys

LLM, search, SaaS, payment, infrastructure APIs.

OAUTH

Tokens

Access/refresh tokens, authorization codes, session credentials.

DATABASE

Credentials

Password, DSN containing password, client certificates.

CRYPTO

Private material

Private keys, signing keys, webhook signing secrets.

SESSION

Browser/session tokens

Cookies, bearer tokens, access session state.

INFRA

Machine secrets

Cloud creds, SSH keys, registry credentials.

RECOVERY

Break-glass

Emergency credentials with broad power.

NOT SECRET

Identifiers

Secret ID/reference can be non-secret if it reveals no credential material and access to resolve it is separately controlled.

07. SECRET REFERENCES

ХРАНИТЬ ССЫЛКУ, А НЕ ЗНАЧЕНИЕ

{
  "connector_id": "gmail:brand_A",
  "credential_ref": "secret://connectors/gmail/brand_A",
  "allowed_scopes": [
    "mail.read",
    "draft.create"
  ],
  "tenant_id": "brand_A",
  "environment": "prod"
}
MODEL-VISIBLE METADATA

Capability without credential

Agent может знать:

  • connector_id;
  • available actions;
  • resource scope;
  • tenant;
  • approval requirement;

Но не должен видеть access token / refresh token / password.

В state/memory желательно хранить credential_ref или connector_id, а actual secret разрешать только runtime principal внутри trusted tool layer.
08. SECRET LIFECYCLE

CREATE → STORE → USE → ROTATE → REVOKE → DELETE

ISSUECredential created by trusted authority.
STOREVault/KMS/OS secret store/env boundary.
REFERENCEApplication stores secret_ref, not raw value.
RESOLVEAuthorized runtime fetches only on demand.
USECredential stays inside client/tool process.
ROTATEReplace before/after compromise or schedule.
REVOKEDisable immediately when no longer trusted.
09. SHORT-LIVED CREDENTIALS

ЛУЧШИЙ SECRET — ТОТ, КОТОРЫЙ СКОРО ПЕРЕСТАНЕТ РАБОТАТЬ

STATIC LONG-LIVED

Simple, high blast radius

Легко внедрить, но leakage может жить месяцами. Использовать только с узкими scopes и rotation.

SHORT-LIVED TOKEN

Better default

Runtime exchanges identity for temporary token with small TTL and narrow audience/scope.

JUST-IN-TIME

Best for sensitive access

Capability создаётся только непосредственно перед operation и исчезает после TTL/use.

Short-lived token не отменяет authorization: он должен быть выдан правильному principal, для нужного audience/resource и минимального scope.
10. ENVIRONMENT SEPARATION

DEV НЕ ДОЛЖЕН ИМЕТЬ PROD CREDENTIALS ПО УМОЛЧАНИЮ

EnvironmentDataCredentialsAllowed side effects
LOCAL / DEVSynthetic/redacted where possible.Dev-only credentials.Mocks/sandbox/test resources.
STAGINGControlled non-prod data.Staging accounts/scopes.Staging-only external resources.
PRODReal tenant data.Prod workload identity / secret refs.Policy/permission controlled.
BREAK-GLASSOnly incident context.Emergency credential.Time-bound, audited, explicit approval.
Самый простой способ снизить blast radius — не иметь production secret в среде, где он вообще не нужен.
11. TENANT ISOLATION

ОДИН CONNECTOR НЕ ДОЛЖЕН СЛУЧАЙНО СТАТЬ КЛЮЧОМ КО ВСЕМ КЛИЕНТАМ

TENANT A credential_ref_Ascope: tenant_A/* TOOLS Aread / draft / approved-send PRODUCTION FABRIC resolve secret by tenant enforce scope before API call never return secret to model TENANT B credential_ref_Bscope: tenant_B/* TOOLS Bread / draft only
Tenant isolation должна поддерживаться одновременно на identity, credential, resource path, database/storage и tool parameter уровнях. Один только system prompt «не смешивай клиентов» не является boundary.
12. DELEGATION

SUBAGENT ПОЛУЧАЕТ МЕНЬШЕ ПРАВ, ЧЕМ PARENT

CAPABILITY DELEGATION

Pass a subset

Parent не передаёт raw credential. Он выдаёт subagent логический capability token/ref с ограниченными action/resource/budget/expiry.

Пример: parent может read+write, subagent получает только read.

ANTI-PATTERN

Credential inheritance

Каждый новый subagent автоматически наследует весь environment, API keys и admin tools parent process.

Это резко увеличивает blast radius prompt injection или ошибки маршрутизации.

DELEGATION RULE
Capability должна быть non-amplifying: delegated actor не может получить больше прав, чем authorized parent, а policy может дополнительно сузить набор действий.
13. PERMISSION + POLICY + HITL

ТРИ РАЗНЫЕ ОСИ

PERMISSION

Can technically

Principal имеет scope post.publish для channel A.

POLICY

Allowed now?

В текущем workflow public publish требует human approval.

HITL

Human decision

Authorized approver approves exact payload. После approval permission всё равно проверяется перед execute.

Approval не выдаёт permission. Пользователь может одобрить действие, которое system principal технически не имеет права выполнить; тогда результат — permission failure, а не «временное повышение прав по воле модели».
14. SECRET REDACTION

СЕКРЕТ НЕ ДОЛЖЕН УТЕКАТЬ ЧЕРЕЗ OBSERVABILITY

SurfaceЧто хранитьЧто не хранить
Prompt / contextconnector_id, capability metadata, secret_ref if safe.Raw token/password/private key.
Trace / logscredential_id/ref, token issuer, scope, outcome.Authorization header, cookie, raw secret.
Memory«Использовать account A» / connector ref.Credential material.
Error messageSAFE code + masked identifier.Full DSN/token/request headers.
ArtifactsSanitized config reference..env, key files, browser session dumps unless explicitly protected.
Redaction нужна как defense-in-depth, но лучше предотвращать попадание secret в logging pipeline вообще.
15. ROTATION & REVOCATION

КОМПРОМЕТИРОВАННЫЙ SECRET ДОЛЖЕН ПЕРЕСТАТЬ РАБОТАТЬ

ROTATE

Replace

Плановая/incident rotation без массового редактирования prompts/configs благодаря secret_ref.

REVOKE

Kill access

Immediate disable token/session/key when principal or connector no longer trusted.

INVALIDATE

Cache

Runtime token caches должны уважать revocation/TTL.

AUDIT

Find usage

Понять, где credential применялся после suspected compromise.

DESIGN BENEFIT
Если code/state хранит secret_ref, rotation меняет значение в одном controlled store. Если raw secret размазан по .env, prompts, JSON, notebooks и workflows — rotation превращается в incident project.
16. BREAK-GLASS ACCESS

ЭКСТРЕННЫЙ ДОСТУП НЕ ДОЛЖЕН СТАТЬ ОБЫЧНЫМ PATH

BREAK GLASS

Exceptional privilege

Для incident recovery может существовать более широкий emergency credential.

  • Manual activation.
  • Short TTL.
  • Named human owner.
  • Strong audit.
  • Reason/ticket required.
  • Post-use review.
NEVER

Не давать модели

Break-glass secret не должен быть доступен обычному agent runtime или prompt. AI может подготовить incident plan, но activation широкого emergency access — отдельный protected control path.

17. CONNECTORS & OAUTH

CONNECTOR AUTH НЕ ДОЛЖЕН ПРОТЕКАТЬ В AGENT LOGIC

USER CONSENTExternal auth flow / tenant admin.
CREDENTIAL STORERefresh/access material protected.
CONNECTOR IDAgent sees logical connection metadata.
ACTION INTENTread / draft / send / upload.
AUTHZ + POLICYprincipal/resource/scope/context.
TOKEN USEConnector/runtime resolves secret.
№54 Connectors подробно разберёт adapter/API mapping/sync semantics. Здесь канонический принцип: connector exposes capability; credential lifecycle остаётся внутри Production Fabric.
18. TESTING

SECURITY BOUNDARY НУЖНО ПРОВЕРЯТЬ НЕГАТИВНЫМИ TESTS

ALLOW

Positive

Correct principal/scope/tenant succeeds.

DENY

Negative

Wrong role/scope/action/resource blocked.

CROSS-TENANT

Isolation

Valid credential A cannot access B resource through parameter manipulation.

LEAK

Secret scanning

Prompts/logs/traces/artifacts checked for credential material.

REVOKE

Revocation

Revoked token stops working within expected window.

ROTATE

Rotation

New secret works; old is removed without app edits.

DELEGATE

No amplification

Subagent cannot expand delegated capability.

FAILURE

Vault outage

High-risk operation fails safely, not with bypass.

19. OBSERVABILITY & AUDIT

ЛОГИРОВАТЬ ИСПОЛЬЗОВАНИЕ, НЕ СЕКРЕТ

WHO

Principal chain

user → agent → runtime service → external account.

WHAT

Capability

action, resource, scope, tenant, policy result.

WHICH CRED

Reference only

credential_ref / key version / token issuer, never raw token.

WHEN

Lifecycle

issued, resolved, used, rotated, revoked.

OUTCOME

Effect

allowed/denied/executed/failed and authoritative result.

ANOMALY

Detection

Unexpected tenant, unusual scope, old key use, excessive credential resolution.

20. FAILURE MODES

КАК PERMISSIONS & SECRETS ЛОМАЮТСЯ

SECRET IN PROMPT
API token помещён в system/user context.
HOST INJECTION ONLY
ONE ADMIN KEY
Все agents используют один credential с полным доступом.
LEAST PRIVILEGE
AGENT INHERITS ENV
Каждый subagent видит все env secrets parent process.
CAPABILITY SUBSET
TENANT FROM MODEL
LLM свободно выбирает tenant/resource ID.
HOST BINDING
RAW SECRET IN LOG
Headers/DSN/cookies попадают в traces.
REDACT / PREVENT
NO REVOCATION
Скомпрометированный credential продолжает жить.
REVOKE + TTL
PROD CRED IN DEV
Локальный prototype может выполнить production side effect.
ENV SEPARATION
APPROVAL = PRIVILEGE
Human approval используется как способ обойти missing permission.
AUTHZ STILL REQUIRED
SECRET IN MEMORY
Long-term memory сохраняет token/password.
STORE REFERENCE ONLY
21. METRICS

ЧТО ИЗМЕРЯТЬ

LP

Least-Privilege Coverage

% sensitive capabilities with narrow scopes instead of broad shared credential.

0

Secret Exposure

Confirmed raw secret occurrences in model context/logs/artifacts. Target: zero.

TTL

Credential Lifetime

Median/max lifetime by credential class.

REV

Revocation Time

Time from revoke decision to unusable credential.

DEN

Denied Access

Permission denials by principal/action/resource.

XT

Cross-Tenant Escape

Unauthorized cross-tenant access. Target: zero.

ROT

Rotation Compliance

% credentials rotated within policy window.

ADM

Broad Credential Count

Number of admin/all-scope secrets reachable by runtime.

22. MVP IMPLEMENTATION

НЕ НУЖНО СРАЗУ СТРОИТЬ СОБСТВЕННЫЙ IAM

security/
├── principals.py
├── authorize.py
├── scopes.py
├── tenant.py
├── secret_refs.py
├── redaction.py
└── tests/

connectors/
├── registry.yaml
└── wrappers/

secrets:
  dev  -> dev secret store
  prod -> vault / protected environment

runtime pattern:
  model sees capability metadata
  model emits action intent
  host validates scope/policy
  wrapper resolves credential_ref
  API call executes
  result sanitized
  raw credential discarded
80% VALUE MVP

Simple security fabric

  • Explicit user/service/tenant principals.
  • Role/scope table in DB/config.
  • Tool allowlist + resource scopes.
  • Separate dev/prod credentials.
  • Secret manager or protected environment outside prompts.
  • Credential references in app state.
  • Runtime injection only in connector/tool client.
  • Masked logs + secret scanning.
  • Rotation/revocation procedure.
  • Negative permission/cross-tenant tests.

Полноценный enterprise IAM/Vault/policy stack подключается, когда scale/compliance/teams justify it.

23. PRACTICAL DECISION

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

ВопросОтвет
Стоит ли реализовывать?Да, до подключения реальных sensitive tools.
Separate Component?YES как отдельная логическая security responsibility в Production Fabric. Это не обязательно отдельный server.
Минимум 80% ценности?Principals, scopes, tenant binding, secret refs, protected injection, env separation, revocation/rotation, audit.
Когда overkill?Писать собственный OAuth/IAM/Vault/KMS stack вместо использования стандартных OS/cloud/library mechanisms.
Trigger?Любой external API, DB, filesystem, connector или privileged side effect, требующий credential.
Как измерить uplift?Secret exposure, cross-tenant escapes, broad credentials, permission failures, rotation/revocation time, security incidents.
Можно ли rule/tool/code вместо LLM-agent?Да, полностью. Security authority должна быть deterministic host infrastructure. LLM может только предложить intent.
24. DESIGN RULES

ПРАВИЛА ДЛЯ РЕАЛЬНОЙ СИСТЕМЫ

RULE 01

Secrets stay outside model

Prompt/context/memory содержат capability refs, не raw credential.

RULE 02

Least privilege

Scope выдаётся по action/resource/tenant, не «на всякий случай».

RULE 03

Host binds identity

Critical principal/tenant/resource не должен свободно выбираться моделью.

RULE 04

Short-lived where possible

Temporary token снижает blast radius leakage.

RULE 05

Delegate subset

Subagent получает не больше parent и обычно меньше.

RULE 06

Separate environments

Dev/staging/prod credentials и resources не смешиваются.

RULE 07

Approval ≠ permission

Human approval не расширяет технические scopes.

RULE 08

Rotate by reference

Приложение знает secret_ref; raw value может меняться независимо.

RULE 09

Audit use, not value

Логировать credential identity/version/scope/outcome без secret material.

25. FINAL MAP

IDENTITY → SCOPE → POLICY → CREDENTIAL → ACTION

USER / EVENT / SYSTEM TASK
        ↓
IDENTITY:
user + tenant + runtime principal
        ↓
REQUESTED CAPABILITY
        ↓
AUTHORIZATION:
principal × action × resource × scope
        ↓
POLICY:
is this allowed NOW?
        ↓
[ HITL if required ]
        ↓
TOOL / CONNECTOR CONTRACT
        ↓
SECRET REF / TOKEN EXCHANGE
        ↓
PROTECTED RUNTIME RESOLVES CREDENTIAL
        ↓
EXTERNAL API / DB / FILESYSTEM
        ↓
SANITIZED RESULT
        ↓
TRACE:
who + capability + scope + credential_ref/version + outcome
        ↓
ROTATE / REVOKE / AUDIT

NEVER:

RAW SECRET
   ↓
PROMPT
   ↓
MODEL
   ↓
MEMORY / LOG / OUTPUT

CORE PRINCIPLE:

THE MODEL SHOULD RECEIVE
A CAPABILITY,
NOT A PASSWORD.

PERMISSION DEFINES
WHAT THE PRINCIPAL CAN DO.

POLICY MAY NARROW THAT PERMISSION,
BUT IT MUST NEVER CREATE
A PRIVILEGE THE PRINCIPAL DOES NOT HAVE.

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 №51 Permissions & Secrets.

B–E. Existing boundary and placement. The existing conceptual boundary, class PRODUCTION, default ON and owner 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.