Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Proposal: runnable reference scenario for unreachable escalation authority and revocation after dispatch

Aperta
  • Qualcosa non va?
#333 8 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Ambito
security, testing

Direzione di ricerca

First resolve the requested decisions: whether this belongs in the community integration or a separate example, and which released runtime/API and TRACE profile to target. Then inspect the merged runner and fixture from #288 and the 14-field contract at integrations/alakris-authority-comparison/comparison-contract.json. Done means a runnable, evidence-backed scenario meets the listed acceptance criteria without claiming unsupported runtime capabilities.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Human-directed proposal for Vladislav Kostitsyn, following Imran's October 15 guidance. @carloshvp (primary), @rajnisht7 (backup): could you confirm the scope, runtime entry point and placement below?

An agent cannot reach its escalation authority; alternatively, authorization valid at dispatch is revoked before the protected effect commits. The proposed reference should make the permitted behavior and the observed effect independently inspectable.

Existing baseline and proposed next step

The shared AAIF evidence-appraisal runner and synthetic executor fixture are already merged through #288, with the provenance clarification in #315. This follows #287 and AAIF WG #13.

The next contribution would connect one agreed AgenTrust runtime path to a disposable protected-effect target and retained target-side observations, building on the fixture rather than claiming that another synthetic counter is new. This issue proposes that work; it does not report a completed integration or independent reproduction.

Proposed acceptance criteria

  • Declare the authorizer, escalation authority, executor, target, policy, original deadline, trusted components and precise effect boundary. Use synthetic identities and a disposable local target.
  • Unreachable authority: record an explicit refusal or a previously authorized, bounded fallback under the declared policy. No current authorization or applicable fallback means no protected commit. Restored connectivity must not reopen the original expired request; a newly authorized request is distinct.
  • Revocation after dispatch: arrange revocation after admission/dispatch but before the executor's final commit check, retain that ordering and observe the target result. State when revocation became visible to the executor; do not claim retroactive cancellation of an already committed effect or a general propagation SLA.
  • Controls: a fresh valid authorization commits exactly once; action/target substitution, forged dispatch, duplicate delivery and expired-request recovery exercise explicit refusal or deduplication outcomes. Uncertain external outcome must remain unknown, not inferred from a receipt.
  • Keep authority, decision, dispatch, committed effect, task outcome and receipt separate, using the existing 14-field contract and evidence states. Publish exact released dependencies, source/build pins, invocation, environment, raw artifacts and hashes.
  • Map the selected released APIs to TRACE references and external execution evidence. A digest, signature or reporting flag alone does not establish an external effect or independent execution. Scenario-local correlation IDs must not be presented as implemented native protocol support.

Validation and boundaries

On October 17, I reran nine existing synthetic boundary tests: unavailable authority, post-dispatch revocation, expired recovery, valid control/duplicate, action tampering, late veto, forged dispatch, veto and prior revocation. All passed against a checkout whose tree exactly matches merge 12353a2b84cb08498221c92965092f70784aa4d7. These validate the existing synthetic baseline only.

egsim research, author-operated implementation records, offline evidence appraisal and independent operator runs remain separate. Radiolaria's proposed restart/source-applicability row remains supplementary; it does not fill a protected-action control. No production, hardware isolation, universal mediation or certification claim is proposed.

The cMCP execution-correlation foundation explicitly remains non-operational. The example must use an implemented released seam or label an adapter-level boundary; gaps belong in the owning core repository. Related scope discussions: #199, #290.

Decision requested: should this extend the existing community integration or live as a separate reference example, and which released runtime/API and TRACE evidence profile should the first implementation target? An Alakris product integration can follow after this scenario is agreed and lands.

Lingua principale
Python
Stelle
5
Fork
27
Merge medio
1g 13h
PR unite (30g)
104

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di agentrust-io/integrations

Tutte le issue di agentrust-io/integrations

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.