Skip to content

feat: language parity for require_approval approval chains (TypeScript, .NET, Rust, Go) #3083

Open

Description

Summary

#2478 adds a require_approval verdict plus the approval-chain execution layer (human, LLM judge, and webhook approvers, action binding per ADR-0030, configurable timeouts, and audit linkage) to the Python PolicyEvaluator and govern(). This issue tracks bringing the same approval-chain execution to the other AGT language SDKs, so governance behavior stays consistent across the ecosystem.

The Python wiring is landing under #3067 (PolicyEvaluator / govern integration after ADR-0030). This tracker is the single place to follow the non-Python work.

What Python adds (#2478, #3067)

  • A require_approval verdict that pauses execution and routes the decision to an approval chain.
  • Approval chains: an ordered list of approvers that short-circuits on the first deny.
  • Approver types: human (notification plus vote with a timeout), LLM judge (a model votes allow or deny with a reason, with verdict caching), and webhook (POST the context, expect a JSON verdict).
  • Action-bound, fail-closed coordination per ADR-0030 (action binding plus digest, with a configurable timeout that defaults to deny).
  • Audit records for the approval request, each vote, and the final verdict.

Gap in other SDKs

All four SDKs already recognize the require_approval verdict and carry an approver count, but none implement the approval-chain execution layer (no coordinator, no approver types, no timeout or audit linkage):

SDK Path Current state
TypeScript agent-governance-typescript/ require_approval is a valid policy action in src/policy.ts, no chain execution
.NET agent-governance-dotnet/ PolicyAction.RequireApproval plus an Approvers list in Policy/PolicyDecision.cs, no chain execution
Rust agent-governance-rust/ a "requires-approval" decision plus min_approvals in agentmesh/src/policy.rs, no chain execution
Go agent-governance-golang/ RequiresApproval plus MinApprovals in packages/agentmesh/policy.go, no chain execution

Proposed work

For each SDK, port the approval-chain execution layer on top of the verdict support that already exists:

  • route a require_approval verdict to an ordered approval chain that short-circuits on the first deny
  • implement at least the webhook approver as the MVP, then human and LLM judge approvers where the SDK has the surface for them
  • honor the action-bound, fail-closed semantics from ADR-0030 (action binding plus digest, timeout defaults to deny)
  • record the approval request, votes, and final verdict on the audit trail
  • add tests covering the allow, deny, and timeout paths

One PR per language keeps each change reviewable. Where an approver type does not map cleanly onto a given SDK runtime, note it as not applicable rather than forcing it.

References

Activity

  1. github-actions commented on Jun 16, 2026

    @github-actions

    🟡 Contributor Check: MEDIUM

    Check Result
    Profile MEDIUM
    Credential LOW
    Overall MEDIUM

    Automated check by AGT Contributor Check.

  2. carloshvp commented on Jul 17, 2026

    @carloshvp
    Contributor

    Current parity status:

    This tracker should remain open until the four language slices are resolved. The next unclaimed implementation slice is .NET or Rust.

  3. carloshvp commented on Jul 17, 2026

    @carloshvp
    Contributor

    .NET parity is now implemented in draft PR #3363. It adds the ADR-0030 action-bound approval flow, durable store contract, ordered stages, fail-closed webhook and timeout handling, audit linkage, tamper checks, idempotency, and one-time consume under agent-governance-dotnet/. The zero-required-non-advisory-stage path is explicitly documented as fail-closed, aligned with the safer Go behavior. Local validation: dotnet build AgentGovernance.sln succeeded and dotnet test AgentGovernance.sln passed all 806 tests. This tracker should remain open for review and the remaining Rust slice.

  4. floze-the-genius commented on Jul 22, 2026

    @floze-the-genius

    Hi, I would like to take the remaining Rust slice of #3083.

    I have a local implementation based on ADR-0030 that routes the existing PolicyDecision::RequiresApproval result into an action-bound coordinator. The scope includes a durable store contract, ordered identity/role stages, fail-closed expiry, one-time execution consumption, hash-linked entries, linked audit events, and a runtime-neutral versioned webhook transport.

    Two deliberate choices:

    • LLM output remains advisory and cannot satisfy an approval stage, matching ADR-0030 even though the older tracker text describes an LLM judge more broadly.
    • The core crate does not gain an HTTP runtime dependency; applications adapt their existing client through the webhook transport trait.

    The current local validation is 535 release-workspace tests passing, including 21 focused approval tests. Before I open the PR, does this scope match what you want for the Rust parity slice?

  5. imran-siddique commented on Sep 19, 2026

    @imran-siddique
    Collaborator

    Floze (@floze-the-genius) yes, this scope matches ADR-0030. Please open the Rust PR against current main and link it here.

    Keeping LLM output advisory is required by the accepted design. Keeping the HTTP client outside the core crate is also fine, provided the adapter still verifies who approved and that the response belongs to the exact request.

    Please include tests showing that changed actions, expired approvals and unverified approvers are rejected, and that two workers cannot use the same one-time approval. Show what survives a restart, and distinguish the storage interface from any working persistent implementation.

    Keep #3083 open, since it tracks all four languages. This confirms the proposed scope; implementation review follows on the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions