AZ-008 — Agent Delegation, Mandates, Risk Caps, and Operational Control v1

Status

Acest document definește modelul protocolar pentru agenți în ATLAS ZERO.

Scopul nu este să permitem „autonomie nelimitată”. Scopul este să permitem autonomie controlată, auditabilă și opribilă.

Acest document stabilește:

• delegarea către agenți;
• mandate și scope;
• cap-uri de risc și expunere;
• jurnalizare obligatorie;
• politici de halt, rotate și recover;
• relația dintre owner, operator, agent și protocol.

Acest document se bazează pe:

• AZ-002 pentru obiecte canonice;
• AZ-003 pentru validare și tranziții;
• AZ-004 pentru finalitate;
• AZ-005 pentru BVM și efecte bounded;
• AZ-006 pentru witness și memorie verificabilă;
• AZ-007 pentru bonds, fees și slashing.

Termeni:

• MUST = obligatoriu
• MUST NOT = interzis
• SHOULD = recomandat puternic
• MAY = opțional

1. Obiectiv

AZ-008 răspunde la 10 întrebări fundamentale pentru agenți:

1. Ce este un agent în protocol?
2. Cine poate delega și în ce formă?
3. Cum este definit mandatul agentului?
4. Ce limite de risc pot fi impuse?
5. Cum se dovedește că agentul a acționat în mandat?
6. Cum este jurnalizată decizia și execuția?
7. Cum este oprit sau rotit agentul?
8. Cum sunt tratate încălcările de mandat?
9. Ce diferență există între agent, operator și owner?
10. Cum evităm ca agentul să devină o cheie cu putere totală?

2. Principii

2.1 Minimal authority

Un agent MUST primi doar autoritatea minim necesară pentru scopul său.

2.2 Bounded mandate

Orice agent protocolar MUST acționa sub un mandat finit, explicit și verificabil.

2.3 Auditability

Acțiunile semnificative ale agentului SHOULD lăsa urme verificabile.

2.4 Fail closed

Dacă există ambiguitate, conflict de witness, lipsă de jurnalizare obligatorie sau depășire de cap, acțiunea agentului SHOULD fail closed.

2.5 Separation of roles

Owner, operator, risk manager și halt authority SHOULD fi separați când expunerea economică este semnificativă.

2.6 Rotatability

Un agent MUST putea fi înlocuit, revocat sau rotit fără a distruge activele sau controlul owner-ului.

2.7 Emergency control

Procesele sensibile MUST avea căi de oprire de urgență și recuperare.

3. Definiții

3.1 Agent

Un agent este o entitate protocolară delegată să emită acțiuni într-un scope definit.

Agentul poate fi:

• cheie singulară;
• policy root;
• operator software autorizat;
• Bounded Machine orchestration endpoint;
• cluster de agenți sub aceeași policy.

3.2 Owner

Owner este entitatea economică principală care controlează mandatul de bază și suportă interesul economic final.

3.3 Operator

Operator este entitatea care rulează efectiv agentul sau infrastructura sa.

3.4 Risk Manager

Risk Manager este entitatea care poate ajusta sau bloca limitele de risc în scope-ul permis.

3.5 Halt Authority

Halt Authority este entitatea care poate opri agentul sau un subset al funcțiilor sale.

3.6 Mandate

Mandate este obiectul normativ care definește:

• ce poate face agentul;
• în ce interval;
• în ce limite;
• în ce condiții;
• cu ce obligații de jurnalizare și control.

4. Modelul de identitate pentru agenți

4.1 Agent identity root

Fiecare agent SHOULD avea un agent_identity_root canonical.

Acesta poate ancora:

• cheile curente;
• operator policy;
• bonds;
• mandate references;
• journaling policy;
• rotation state.

4.2 Agent keys

Protocolul SHOULD permite mai multe chei sau sub-policy roles:

• execution key
• logging key
• maintenance key
• halt key
• rotation request key

4.3 Rule

Cheia care execută tranzacții MUST NOT fie automat și cheia care poate schimba mandatul, decât în configurații low-risk explicite.

5. Mandate object

5.1 Definiție

Mandatul este obiectul central al controlului de agent.

Forma abstractă:

AgentMandate {
  version_major
  version_minor

  mandate_id
  owner_policy
  agent_policy
  operator_policy?
  risk_manager_policy?
  halt_policy

  mandate_scope
  action_permissions
  risk_caps
  journaling_policy
  time_window
  revocation_policy
  supersession_policy?
  recovery_policy?
  bond_requirements?
  metadata_hash?
}

5.2 mandate_id

mandate_id = H("AZ:AGENT_MANDATE:" || canonical_mandate_body)

5.3 Rule

Mandatul MUST fi:

• canonical;
• versionat;
• bounded;
• semnat sau aprobat de policy-urile necesare.

6. Mandate scope

6.1 Scop

mandate_scope definește domeniul operațional.

6.2 Componente posibile

Un scope MAY limita:

• active permise
• mașini permise
• contract selectors permiși
• counterparty classes permise
• market/domain permise
• max number of actions per epoch/day
• geography / compliance domain commitment
• session windows
• protocol subsystems permise

6.3 Rule

Dacă o acțiune nu se află explicit în scope, ea MUST fi interzisă.

7. Action permissions

7.1 Tipuri de acțiuni

Set minim recomandat:

• SUBMIT_TX_VALUE_TRANSFER
• SUBMIT_TX_MACHINE_CALL
• SUBMIT_TX_WITNESS_EMIT
• SUBMIT_TX_INTENT_SUBMIT
• SUBMIT_TX_INTENT_CANCEL
• REQUEST_HALT_SELF
• REQUEST_ROTATION
• TOP_UP_RENT
• SETTLEMENT_ACTION
• ORACLE_FEED_ACTION
• TREASURY_ACTION
• TRADE_EXECUTION_ACTION

7.2 Granularitate

Action permissions SHOULD fi suficient de granulare încât:

• permisiunea de a jurnaliza să nu însemne permisiunea de a cheltui;
• permisiunea de a deschide poziții să nu însemne permisiunea de a retrage capital;
• permisiunea de a executa să nu însemne permisiunea de a schimba mandatul.

7.3 Rule

Acțiunile agentului MUST fi autorizate atât de action_permissions, cât și de celelalte cap-uri relevante.

8. Risk caps

8.1 Obiectiv

Risk caps sunt limitele hard și soft care împiedică agentul să transforme un mandat într-o putere economică nelimitată.

8.2 Categorii de risk caps

Set minim recomandat:

• notional caps
• exposure caps
• loss caps
• leverage caps
• position count caps
• turnover caps
• session caps
• asset concentration caps
• counterparty caps
• dependency caps
• stale-data caps
• latency / freshness caps
• slippage caps
• journaling omission tolerance caps
• drawdown caps

9. Notional caps

9.1 Definiție

Limitează valoarea brută a acțiunilor.

Exemple:

• per action
• per epoch
• per day
• rolling window

9.2 Forma abstractă

NotionalCap {
  asset_or_base_scope
  max_notional_per_action
  max_notional_per_window
  window_kind
  window_size
}

9.3 Rule

O acțiune care ar depăși notional cap MUST fi respinsă.

10. Exposure caps

10.1 Definiție

Limitează expunerea netă sau brută rămasă deschisă.

10.2 Exemple

• total open exposure
• exposure per asset
• exposure per strategy class
• exposure per counterparty class

10.3 Rule

Agentul MUST verifica expunerea deja existentă plus cea propusă. Dacă rezultatul depășește cap-ul, acțiunea este invalidă.

11. Loss caps

11.1 Definiție

Limitează pierderea tolerată.

11.2 Forme posibile

• max loss per action
• max cumulative loss per day
• max drawdown from reference equity
• max adverse movement tolerated until forced halt

11.3 Rule

Când loss cap-ul este atins sau predictibil depășibil în acțiunea propusă, agentul SHOULD:

• refuza acțiunea;
• sau intra în safe mode / halt, conform mandatului.

12. Leverage and complexity caps

12.1 Leverage cap

Dacă sistemul suportă leverage, mandatul MUST definească un max leverage.

12.2 Complexity cap

Mandatul MAY limita:

• număr de hops într-o rută;
• număr de dependințe externe;
• număr de mașini sau witnessuri implicate;
• complexitatea solver-ului permis.

12.3 Rule

Complexitatea permisă SHOULD scadă pe măsură ce impactul economic și suprafața de risc cresc.

13. Freshness and data caps

13.1 Need

Mulți agenți eșuează nu din logică, ci din date stale sau inconsistente.

13.2 Mandatul MAY cere:

• max data age
• max oracle divergence
• max missing feed count
• max witness staleness
• min confirmation strength

13.3 Rule

Dacă datele depășesc limitele de freshness, agentul MUST fail closed sau intra în degraded mode, conform politicii.

14. Journaling policy

14.1 Rol

Mandatul MUST putea impune jurnalizare verificabilă.

14.2 Tipuri de jurnalizare

• pre-action decision log
• post-action execution log
• risk escalation log
• anomaly log
• halt justification log
• rotation log

14.3 JournalingPolicy abstract

JournalingPolicy {
  required_log_types
  timing_mode
  max_logging_delay_ms?
  mandatory_fields_hashes
  omission_tolerance
  anchoring_requirements
}

14.4 timing_mode

Poate fi:

• PRE_ACTION_REQUIRED
• POST_ACTION_REQUIRED
• PRE_AND_POST_REQUIRED
• ON_EXCEPTION_REQUIRED
• BATCH_SUMMARY_ALLOWED

14.5 Rule

Dacă jurnalizarea obligatorie lipsește și politica cere fail-closed, acțiunea agentului MUST fi respinsă.

15. Agent decision records

15.1 Standard

Agenții SHOULD emite agent_decision_record înainte de acțiuni sensibile.

Payload minimal:

AgentDecisionRecord {
  mandate_id
  agent_policy_ref
  decision_id
  action_class
  subject_scope_hash
  input_context_hash
  candidate_route_hash?
  chosen_action_hash
  expected_risk_hash
  expected_bound_checks_hash
  decision_epoch_or_time
}

15.2 Scop

Acest record:

• nu conferă singur permisiune;
• dovedește ce a decis agentul;
• poate fi comparat ulterior cu execuția.

16. Agent execution records

16.1 Standard

După acțiune, agentul SHOULD emite execution_log.

Payload minimal:

AgentExecutionLog {
  mandate_id
  agent_policy_ref
  decision_id?
  action_id
  action_type
  submitted_tx_or_call_ref
  affected_subject_ref
  realized_route_hash?
  realized_risk_hash
  result_commitment_hash
  status_code
  execution_epoch_or_time
}

16.2 Rule

Pentru acțiuni critice, lipsa corelării dintre decision record și execution log SHOULD declanșa incident.

17. Mandate lifecycle

17.1 Stări

Mandatul poate fi în una dintre stările:

• DRAFT
• ACTIVE
• SUSPENDED
• HALTED
• SUPERSEDED
• REVOKED
• EXPIRED

17.2 Tranziții permise

• DRAFT -> ACTIVE
• ACTIVE -> SUSPENDED
• ACTIVE -> HALTED
• ACTIVE -> SUPERSEDED
• ACTIVE -> REVOKED
• ACTIVE -> EXPIRED
• SUSPENDED -> ACTIVE
• SUSPENDED -> HALTED
• SUSPENDED -> REVOKED
• HALTED -> ACTIVE doar dacă recovery policy permite
• HALTED -> SUPERSEDED
• HALTED -> REVOKED

17.3 Rule

Agentul MUST NOT acționa sub mandate terminale sau inactive.

18. Activation

18.1 Mandate activation

Pentru a deveni activ, un mandat SHOULD cere:

• owner authorization;
• agent acceptance sau deployment binding;
• bond requirement satisfied;
• journaling policy known;
• halt policy active;
• optional risk manager confirmation.

18.2 Delayed activation

Mandatul MAY avea valid_from sau activare după epocă anume.

19. Suspension

19.1 Rol

Suspension oprește temporar agentul fără a-l revoca definitiv.

19.2 Use cases

• anomaly investigation
• stale data issue
• bond top-up pending
• operator maintenance
• temporary compliance hold

19.3 Rule

În stare SUSPENDED, agentul MAY păstra unele acțiuni low-risk administrative, numai dacă mandatul le permite explicit.

20. Halt semantics

20.1 Halt

HALTED este stare de oprire de siguranță. În această stare, agentul MUST NOT executa acțiuni operaționale sensibile.

20.2 Halt scopes

Halt-ul MAY fi:

• global pentru agent;
• per action class;
• per asset class;
• per machine/domain;
• per risk tier.

20.3 Trigger sources

Halt poate fi declanșat de:

• halt authority;
• auto-halt logic;
• risk manager;
• bounded machine guard;
• governance emergency path;
• protocol anomaly response.

20.4 Auto-halt triggers

Exemple:

• drawdown cap breached
• journaling omission
• stale oracle threshold exceeded
• contradictory witness
• repeated tx rejections
• bond below threshold
• recovery mode entered

21. Rotation

21.1 Need

Agenții și cheile lor trebuie să poată fi schimbate fără a muta tot capitalul manual.

21.2 Rotation types

• key rotation
• operator rotation
• policy root rotation
• mandate supersession
• journaling endpoint rotation

21.3 Rule

Rotation-ul MUST produce audit trail:

• old identity reference
• new identity reference
• authority path
• effective time
• scope continuity or discontinuity

21.4 Safety

Rotation-ul MUST NOT produce o fereastră ambiguă în care două identități incompatibile pot acționa necontrolat simultan, dacă mandatul nu permite explicit overlap.

22. Recovery

22.1 Recovery policy

Mandatul MAY defini cum se recuperează după halt sau operator compromise.

22.2 Recovery actions

Pot include:

• rebind to new operator
• reduce all caps
• freeze value-moving permissions
• enforce manual approval requirement
• require multi-party reactivation
• force rotation
• exit-only mode

22.3 Rule

Recovery SHOULD fi mai restrictivă decât operarea normală.

23. Exit-only mode

23.1 Definiție

EXIT_ONLY este mod special în care agentul poate:

• închide poziții;
• reduce expuneri;
• jurnaliza;
• top-up costuri critice; dar nu poate:
• deschide noi expuneri;
• crește risc;
• schimba mandatul.

23.2 Use

Acest mod SHOULD fi disponibil pentru sisteme cu expunere semnificativă.

24. Owner / Operator / Agent separation

24.1 Recommendation

Pentru sisteme low-risk, aceste roluri pot coincide. Pentru sisteme medium/high-risk, SHOULD fi separate.

24.2 Why

Separarea reduce:

• single point of catastrophic control;
• operator abuse;
• key compromise blast radius;
• neclaritatea responsabilității.

24.3 Minimum separation

Pentru mandate cu custodie sau execuție de piață semnificativă, owner și halt authority SHOULD NOT fi aceeași cheie de execuție.

25. Risk manager role

25.1 Rol

Risk manager-ul nu trebuie să execute acțiuni economice generale. Rolul său este să ajusteze sau să înghețe cap-urile în limitele permise.

25.2 Permitted actions

• lower caps
• tighten session windows
• activate exit-only mode
• request halt
• require additional witness for future actions
• escalate journaling strictness

25.3 Forbidden by default

Risk manager-ul SHOULD NOT:

• move capital freely;
• enlarge caps peste limitele owner-approved fără nou mandat;
• rotate owner control.

26. Mandate supersession

26.1 Need

Uneori mandatul trebuie înlocuit cu o versiune nouă.

26.2 Rule

Supersession MUST define:

• mandate superseded
• authority path
• effective time
• whether old mandate is immediately disabled or overlaps for bounded transition

26.3 Overlap

Dacă overlap-ul este permis, SHOULD fi:

• scurt;
• bounded;
• jurnalizat;
• limitat la activități neconflictuale.

27. Mandate revocation

27.1 Revocation

Revocarea oprește definitiv utilizarea normativă a mandatului.

27.2 Conditions

Trebuie să existe:

• revocation authority path
• timestamp/epoch
• optional reason code
• optional recovery instructions

27.3 Rule

După revocare efectivă, agentul MUST NOT emite acțiuni sub acel mandat.

28. Bond requirements for agents

28.1 Need

Pentru agenți care pot induce pierderi reale, bond-ul operatorului sau al serviciului SHOULD fi obligatoriu.

28.2 Bond dependencies

Bond-ul necesar SHOULD depinde de:

• notional caps
• exposure caps
• custody permissions
• trust tier
• journaling strictness
• external dependency count

28.3 Rule

Dacă bond-ul scade sub minimul cerut:

• mandatul MAY deveni SUSPENDED sau HALTED;
• acțiunile noi SHOULD fi refuzate.

29. Control plane vs execution plane

29.1 Separation

Protocolul SHOULD separa:

• control plane: definește mandat, caps, halt, rotation;
• execution plane: execută acțiuni zilnice în mandat.

29.2 Rule

O cheie de execution plane SHOULD NOT avea drepturi de control plane, decât dacă configurația este foarte low-risk și explicită.

30. Pre-action checks

30.1 Orice acțiune sensibilă a agentului SHOULD verifica:

1. mandat activ
2. action permission valid
3. scope match
4. time window valid
5. risk caps respectate
6. required witness present
7. data freshness validă
8. journaling preconditions satisfăcute
9. bond / rent / operator status valid
10. no active halt in scope

30.2 Rule

Dacă oricare dintre aceste condiții critice pică, agentul SHOULD fail closed.

31. Post-action checks

31.1 După execuție, agentul SHOULD verifica:

1. acțiunea chiar a corespuns deciziei sau documentează deviația;
2. journaling post-action a fost emis dacă e obligatoriu;
3. efectul real nu a depășit caps;
4. state/result references sunt ancorate;
5. orice eroare a fost jurnalizată corect;
6. repeated failure thresholds nu au fost depășite.

31.2 Rule

Dacă post-action checks indică încălcare severă, agentul SHOULD auto-trigger halt sau escalation conform politicii.

32. Deviation handling

32.1 Need

În practică, execuția poate devia de la plan:

• slippage
• partial fill
• route change
• missing dependency
• oracle freshness degrade

32.2 Rule

Mandatul SHOULD specifica deviațiile tolerate.

32.3 Deviation classes

• acceptable deviation
• acceptable with warning
• acceptable only with extra witness
• forbidden deviation

32.4 Forbidden deviation

Dacă deviația e interzisă, agentul MUST abort sau halt, conform politicii.

33. Human override

33.1 Need

Sistemele reale au nevoie uneori de override uman.

33.2 Model

Override-ul SHOULD fi:

• explicit;
• bounded;
• jurnalizat;
• semnat de policy autorizată;
• limitat temporal și contextual.

33.3 Rule

Override-ul uman MUST NOT fi „putere nelimitată invizibilă”. Trebuie să lase urme protocolare.

34. Manual approval gating

34.1 Use case

Pentru acțiuni foarte sensibile, mandatul MAY cere approval manual prealabil.

34.2 Examples

• increase of caps
• treasury move over threshold
• new market/domain activation
• risky recovery action
• restart after critical incident

34.3 Rule

Agentul MUST valida approval witness-ul înainte de acțiune.

35. Agent classes

35.1 Informational agent

Poate doar observa și jurnaliza.

35.2 Advisory agent

Poate produce decision records, dar nu execută economic.

35.3 Execution agent

Poate executa acțiuni bounded.

35.4 Custodial bounded agent

Poate atinge direct fluxuri de valoare în limite stricte.

35.5 Coordinator agent

Poate orchestra alte componente, intenturi sau mașini fără putere economică totală.

35.6 Rule

Clasa agentului SHOULD influența:

• bond requirement
• journaling strictness
• allowed actions
• trust tier
• audit burden

36. Agent capability tiers

36.1 Tier A — Observe

• read-only
• logging only

36.2 Tier B — Recommend

• emits advisory witnesses
• no direct value action

36.3 Tier C — Execute bounded

• submits transactions in scope
• strict caps
• mandatory journaling

36.4 Tier D — Coordinate bounded

• may trigger multiple subsystems
• stronger bond
• stricter control plane

36.5 Tier E — High-impact bounded

• large notional/exposure
• multi-party control recommended
• strongest journaling and halt requirements

37. Agent violation categories

37.1 Minor

• delayed journaling within tolerated window
• repeated non-critical failed attempts
• stale data near threshold but no loss event

37.2 Major

• missing mandatory log
• action outside soft caps
• repeated forbidden deviation attempts
• acting while suspended

37.3 Critical

• action outside hard mandate
• hidden value-moving action
• forged execution log
• acting after revocation
• bypassing halt
• deliberate cap evasion

38. Consequences of violations

38.1 Possible consequences

• reject action
• mark anomaly witness
• reduce caps
• force exit-only mode
• suspend mandate
• halt mandate
• slash operator bond
• revoke delegation
• trigger governance / recovery path

38.2 Rule

Consecințele SHOULD crește progresiv cu severitatea și recidiva.

39. Protocol-native agent control hooks

39.1 Hooks recomandate

• is_mandate_active(mandate_id)
• is_action_permitted(mandate_id, action_type, subject)
• check_risk_caps(mandate_id, proposed_action)
• require_journal_pre(mandate_id, decision_record)
• require_journal_post(mandate_id, execution_log)
• is_agent_halted(scope)
• is_rotation_pending(agent_identity_root)
• get_effective_caps(mandate_id)
• get_required_approvals(mandate_id, action)

39.2 Role

Aceste hook-uri SHOULD fi disponibile contractelor și politicilor standardizate fără interpretări locale.

40. Mandate evaluation function

40.1 Abstract function

EvaluateAgentAction(Mandate M, AgentAction A, Context C) ->
  ALLOW |
  ALLOW_WITH_EXTRA_WITNESS |
  ALLOW_IN_EXIT_ONLY |
  DENY |
  HALT

40.2 Inputs

Evaluarea SHOULD folosi:

• mandate state
• action class
• current caps usage
• witness set
• data freshness status
• anomaly state
• bond state
• time window
• override status

40.3 Rule

Evaluarea MUST fi deterministică pentru aceleași inputuri protocolare.

41. AgentAction abstract model

41.1 Structure

AgentAction {
  agent_policy_ref
  mandate_id
  action_id
  action_type
  subject_ref
  economic_impact_hash
  route_hash?
  required_inputs_hash
  requested_time
}

41.2 Rule

Orice action relevantă SHOULD avea identificator și commitment canonic, chiar dacă payload-ul complet e în altă structură.

42. Time windows and session control

42.1 Need

Mandatul MAY limita când poate opera agentul.

42.2 Controls

• trading session windows
• maintenance windows
• forbidden blackout windows
• approval-only windows
• stricter caps outside prime hours

42.3 Rule

În afara ferestrelor permise, acțiunile MUST fi respinse, cu excepția celor de emergency/recovery permise explicit.

43. Counterparty and domain limits

43.1 Need

Agentul poate fi limitat la anumite:

• venues
• domains
• counterparty classes
• machine ids
• intent domains
• oracle sources

43.2 Rule

Acțiuni către contrapărți sau domenii nepermise MUST fi respinse.

44. Safe mode

44.1 Definiție

SAFE_MODE este stare intermediară între operare normală și halt total.

44.2 Effects

În safe mode, agentul MAY:

• reduce caps semnificativ;
• cere extra approvals;
• permite doar subset mic de acțiuni;
• mări strictness-ul la journaling.

44.3 Triggers

• degraded data
• repeated minor anomalies
• low bond margin
• operator warnings
• oracle divergence

45. Multi-agent coordination

45.1 Need

Un owner poate folosi mai mulți agenți.

45.2 Rule

Dacă mai mulți agenți împart aceeași expunere economică, caps SHOULD fi evaluate:

• per-agent
• și aggregate pe owner scope / portfolio scope unde este relevant.

45.3 Conflict control

Protocolul SHOULD evita ca doi agenți diferiți să eludeze caps prin fragmentare de mandat.

46. Shared portfolio caps

46.1 Model

Un PortfolioRiskScope MAY agrega expuneri peste:

• multiple agents
• multiple mandates
• multiple machines/accounts

46.2 Rule

Când mandatele referă același portfolio_scope_ref, evaluarea caps MUST considera totalul agregat relevant.

47. Mandate proofs and light verification

47.1 Goal

Un auditor sau light client SHOULD putea verifica:

• existența mandatului;
• starea lui curentă;
• dacă agentul era autorizat;
• dacă halt/revocation exista;
• dacă jurnalizarea obligatorie a fost emisă.

47.2 Required objects

• mandate object
• activation proof/witnesses
• supersession or revocation witnesses
• decision/execution logs
• optional bond status proof

48. Security goals

Modelul de agenți urmărește patru obiective:

48.1 Delegation soundness

Niciun agent nu poate exercita mai multă autoritate decât cea delegată normativ.

48.2 Cap enforcement

Nicio acțiune validă nu poate depăși cap-urile hard active ale mandatului.

48.3 Audit continuity

Acțiunile semnificative pot fi urmărite prin jurnalizare verificabilă.

48.4 Emergency recoverability

Un agent compromis sau defect poate fi oprit, rotit sau mutat în safe/exit-only mode fără pierderea controlului owner-ului.

49. Anti-patterns de evitat

Protocolul și implementările SHOULD evita:

1. agent key = owner key = halt key = rotation key
2. journaling opțional pentru fluxuri high-impact
3. hard caps doar off-chain și neverificabile
4. override uman fără witness trail
5. rotation fără supersession clar
6. safe mode fără definiție normativă
7. bond requirement absent pentru agenți high-impact
8. fragmented mandates care ocolesc aggregate caps
9. ambiguity între operator și owner liability
10. ability to act after revocation due to stale mandate cache

50. Formula modelului de agent

Agent Control Layer = explicit mandate + bounded action permissions + risk caps + required journaling + halt/rotation/recovery hooks + verifiable accountability

51. Relația cu restul protocolului

• AZ-005 dă mașinilor efecte bounded.
• AZ-006 dă memorie verificabilă.
• AZ-007 face autoritatea costisitoare și penalizabilă.
• AZ-008 face delegarea către agenți controlabilă și auditabilă.

Pe scurt: ATLAS ZERO nu oferă agenților libertate. Le oferă mandat, frâne, jurnal și posibilitatea de a fi opriți.

52. Ce urmează

După AZ-008, documentul corect este:

AZ-009 — Governance Constitution, Constitutional Parameters, and Emergency Powers

Acolo trebuie fixate:

• ce poate schimba guvernanța;
• ce este constituțional și greu de schimbat;
• cum se aprobă upgrade-uri;
• cum funcționează emergency powers fără a distruge finalitatea și predictibilitatea.

Închidere

Un agent util nu este cel care poate face orice. Un agent util este cel care poate face suficient, în limite clare, cu urme verificabile și cu posibilitatea reală de a fi oprit înainte să transforme o eroare locală într-un dezastru sistemic.

Acolo începe autonomia controlată.