[P0] Specify Governed Action and scoped Permit Protocol v0.1

[0YHR0]

Problem

Policy, approval, Permit, MCP execution, and unknown-outcome reconciliation exist, but they are not
presented as one reusable signature capability. External Agent frameworks cannot yet adopt this
governance path without adopting the full AgentMesh runtime.

Proposal

Define AgentMesh Governed Action Protocol v0.1 and a small Python SDK around:

ActionIntent → PolicyDecision → Approval (optional) → Permit → ExecutionReceipt → Reconciliation

A Permit grants one bounded capability to one principal, action, and resource under explicit
expiry, use count, idempotency, constraints, and policy snapshot. Write gateways must consume it
atomically and retain evidence.

Acceptance criteria

• Versioned schemas exist for Intent, PolicyDecision, Permit, consumption, receipt, and outcome.
• Permit binds principal/delegation, action, resource, constraints, expiry, max uses, and stable
  idempotency key.
• Write execution fails closed for missing, expired, revoked, mismatched, or exhausted Permits.
• Consumption and execution evidence remain replay-safe across crashes and duplicate delivery.
• OUTCOME_UNKNOWN prevents blind replay and exposes an operator reconciliation path.
• The SDK can be used by an external runtime without importing AgentMesh service implementations.
• At least one MCP write and one fake non-MCP external action pass the same protocol tests.
• Audit API explains who requested, who approved, what was allowed, what executed, and final outcome.

Non-goals

• Creating a general-purpose policy language in this issue.
• Giving Agents long-lived unrestricted tool credentials.
• Treating human approval as sufficient without a scoped Permit.

[0YHR0]

Normative Governed Action design is in PR #144: canonical Intent/Decision/Approval/Permit/PermitUse/ActionExecution/Receipt/Reconciliation, including ambiguous-dispatch handling and atomic Permit reservation.

[benrrr56-wq]

Scoping the Permit to one principal, action, and resource under explicit expiry and idempotency lines up with how I think about capability grants. One edge to close: after ExecutionReceipt, a lost response makes the caller unsure whether the side effect landed, so reconciliation must distinguish 'permit consumed, effect unknown' from 'permit unused'. If the Permit carries a use count and an idempotency key, does the protocol define what happens when a retry re-presents a spent permit while the first effect is still un-observed? Writing it down is the diff between an SDK and an interop contract. I build this layer: control what an agent can do, see what it did, prove it with recomputable evidence. https://agentkey.us