Agentic Governance (Mission-Based Auth)

Concept: Vote on Outcomes, not individual Transactions. Instead of voting 5 times ("Pay Deposit", "Send Email", "Update Calendar"), the group votes once on a Mission.

The Flow

1. The Proposal (The Mission)

A user proposes a "Mission" instead of a raw transaction.

• Title: "Host Summer Swim Meet"
• Payload:
  • mission_id: swim_meet_v1
  • budget_limit: $500
  • constraints: "Must be on a Saturday", "Vendor must be 4-star rated".
  • agent_script: workflows/organize_meet.ts

2. The Authorization (The Key)

When the Secret Network proposal passes:

• Lit PKP generates a Session Key (short-lived API Key or JWT).
• Critical: This key is Scoped. It is not a "Root Key". It is bound to the specific Temporal Workflow ID.

3. The Execution (Agent + Temporal)

1. OpenClaw receives the Session Key.
2. OpenClaw triggers the Temporal Workflow (organize_meet).
3. Step 1: Book Venue.
   • Agent finds venue.
   • Agent requests payment.
   • Check: Is amount < $500? Is it part of the swim_meet mission?
   • Result: Approved automatically (using the Session Key).
4. Step 2: Email Members.
   • Agent drafts email.
   • Check: Is this the "Invite" template?
   • Result: Sent.

Safety Architecture

How do we prevent the Agent from draining the treasury?

1. The Policy Engine (OPA)

The Session Key is validated against an Open Policy Agent (OPA) policy embedded in the Governance Proposal.

allow {
  input.action == "venmo_pay"
  input.amount `<= 500`
  input.recipient in approved_vendors
}

2. The "Human-in-the-Loop" Circuit Breaker

If the Agent encounters a situation outside its bounds (e.g., "Venue costs $550"), the Temporal Workflow pauses and triggers a "Clarification Request" (Mini-Vote) to the group chat.

Integration

• Governance: SecretDAO proposal type ExecuteWorkflow.
• Orchestration: Temporal holds the state of the long-running mission.
• Agent: OpenClaw performs the "Intelligent" steps (finding the venue, writing the email).