Add external governance checkpoint sample

[jw-ond]

Why are these changes needed?

This PR adds a small AgentChat sample that demonstrates how to wrap an AutoGen tool call with an external governance checkpoint before performing a high-risk action.

The sample builds a deterministic action envelope, computes an action hash, asks either a mock local checkpoint or EXTERNAL_GOVERNANCE_URL for a verdict, and only executes the customer-record export when the verdict and local approval policy allow it. By default, it uses ReplayChatCompletionClient, so it can run without a live model API key.

Related issue number

N/A

Checks

• I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://github.com/microsoft/autogen/blob/main/CONTRIBUTING.md to build and test documentation locally.
• I've added tests (if relevant) corresponding to the changes introduced in this PR.
• I've made sure all auto checks have passed.

Local validation performed:

• python3 -m py_compile python/samples/agentchat_external_governance/main.py
• Created a temporary Python 3.11 venv and installed local editable autogen-core, autogen-agentchat, and autogen-ext packages.
• /tmp/autogen-external-governance-venv/bin/python python/samples/agentchat_external_governance/main.py

The sample printed a require_approval governance decision with decision_id and action_hash, and did not execute the export by default.

[arian-gogani]

This sample demonstrates the right pattern: compute an action hash before execution, ask a governance checkpoint to approve, then execute (or block) based on the verdict.

One implementation reference that goes further: Nobulex produces a full Ed25519-signed receipt at this exact boundary, not just a hash check.

from nobulex import track

@track(agent_id="autogen-agent")
def execute_tool(tool_name, args):
    return tool.run(args)

The @track decorator does what your governance checkpoint does, plus:

• Ed25519 signature (not just a hash, so a third party can verify without trusting the runtime)
• Hash chain (each receipt links to the previous, so tampering with one breaks the trail)
• DENY receipts on exception (blocked actions are recorded, not silent)
• Trust score (accumulates over the receipt history)

The action hash your sample computes maps directly to our action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp_ms})), which is normative implementation guidance in OWASP AST09.

For the AutoGen sample: using @track as the governance checkpoint would make the sample produce independently verifiable evidence, not just a local governance decision.

pip install nobulex | https://nobulex.com/why (visual tamper demo)

[jw-ond]

Thanks for the detailed reference. I agree that signed receipts and hash-chained evidence are valuable once a team wants independently verifiable governance records.

For this AutoGen sample, I would keep the checkpoint interface intentionally dependency-light and vendor-neutral: compute a stable action hash, ask an external governance checkpoint for a verdict before execution, then continue or block based on that verdict.

That keeps the sample useful whether the downstream verifier is OSuite, Nobulex, or another receipt/verifier implementation. Signed receipt layers can be added as an extension without making the base sample depend on one specific vendor.