Microsoft Agent Governance Toolkit integration

Use the integration skill

Copy this skill link into your code agent to add Microsoft Agent Governance Toolkit and Contro1 to your system.

Copy skill link

Key takeaways

• Your agents keep their speed. AGT allows or blocks in code, and only the few calls that truly need judgment pause for a person - Contro1 makes that pause reach the right reviewer and resume safely.
• One timeline finally answers "what did our agents do, and who allowed it?" Every policy decision - allowed, blocked, or escalated to a human - lands in the same history you can hand to an auditor or open during an incident.
• Human attention goes where the risk actually is. A new or low-trust agent faces two reviewers; a proven one just leaves a record. Your team reviews less, and what they review matters.
• A blocked agent does not have to fail. When the policy allows it, the block becomes a question to a person, and the agent continues with their answer instead of crashing the workflow.
• The record survives scrutiny. Work resumes only on a cryptographically signed decision, and nothing an agent writes about itself can soften how it gets reviewed.

Where each system sits

Microsoft Agent Governance Toolkit evaluates policy before a tool or action runs. Contro1 receives the approval request when that policy decision requires a human.

Use Microsoft AGT for policy enforcement. Use Contro1 for human approval routing, signed callbacks, and audit evidence.

Bridge flow

• The agent proposes a tool call.
• Microsoft AGT evaluates policy and returns allow, deny, or require_approval.
• For require_approval, the bridge creates a Contro1 request with policy_context.
• Contro1 routes the request, enforces comment rules, tracks SLA/escalation, and stores evidence.
• The runtime verifies the signed Contro1 callback and resumes only on approved status.

Request payload

The bridge fills context with machine-observed facts: the intercepted tool call, its arguments, and the policy verdict from AGT. If you also forward text the model wrote about its own intent, keep it in a separate agent_reported block - it informs the reviewer but must never change routing, risk_level, or the policy outcome, because a prompt-injected agent writes very persuasive justifications.

{
  "title": "Approve governed tool call: send_email",
  "request_type": "approval",
  "source": {
    "integration": "microsoft-agent-governance-toolkit",
    "framework": "microsoft-agt",
    "workflow_id": "customer-outreach",
    "run_id": "run_123"
  },
  "context": {
    "tool_name": "send_email",
    "action_type": "external_send",
    "resource": "customer:c_8821",
    "environment": "production",
    "summary": "Send account update email to customer c_8821"
  },
  "continuation": {
    "mode": "decision",
    "webhook_url": "https://your-app.example.com/webhooks/contro1"
  },
  "risk_level": "high",
  "policy_trigger": "Outbound customer email requires human approval",
  "policy_context": {
    "source": "microsoft_agt",
    "policy_name": "production-policy",
    "rule_id": "require-approval-for-send-email",
    "rule_reason": "Outbound customer email requires human approval",
    "policy_version": "2026-05-28",
    "enforcement": "require_approval"
  },
  "approval_comment_required": true,
  "external_request_id": "agt:run_123:send_email",
  "correlation_id": "case_customer_outreach_123"
}

Policy context fields

Cover every verdict, not only require_approval

AGT returns permit, forbid, or require_approval on every governed call. The bridge should record all three in Contro1, not only the one that needs a human: permit becomes an audit record (the action ran under policy, logged for the timeline), forbid becomes an audit record with warning severity (the block itself is evidence), and require_approval stays the approval request it is today.

The division of labor stays clean: AGT enforces in sub-millisecond time, Contro1 holds the accountable record. With all three verdicts recorded, one case timeline shows everything the policy decided about an agent, and the Activity view groups it per request.

# permit: the action ran under policy - log it, do not pause it
centcom.log_action(
    action="agt.tool_permitted",
    summary=f"AGT permitted {tool_name}",
    source={"integration": "microsoft-agt", "policy": policy_name},
    outcome="success",
    correlation_id=run_id,
)

# forbid: the block itself is evidence
centcom.log_action(
    action="agt.tool_forbidden",
    summary=f"AGT blocked {tool_name}: {rule_id}",
    source={"integration": "microsoft-agt", "policy": policy_name},
    outcome="blocked",
    severity="warning",
    correlation_id=run_id,
)

Bind AgentMesh identity and trust to the agent registry

AGT identifies agents with DIDs (did:mesh:analyst-001) and scores their behavior on a 0-1000 trust scale. Register the DID as the Contro1 agent identity (actor.agent_id) so every request, audit record, and evidence packet is attributed to the same agent AGT governs, and sync the trust tier into agent metadata.

Trust should also drive who reviews: map low trust tiers to stricter approval policies - two approvals, separation of duties, a senior role - and high tiers to single approval or audit-only. The agent earns autonomy the same way it earns trust, and every threshold change is visible in the evidence.

def approval_policy_for(trust_score: int) -> dict:
    if trust_score < 400:
        return {"mode": "threshold", "required_approvals": 2,
                "required_roles": ["security"], "separation_of_duties": True}
    if trust_score < 700:
        return {"mode": "single", "required_approvals": 1}
    return {}  # high trust: policy may log instead of pausing

request = centcom.create_protocol_request({
    "title": f"Approve governed tool call: {tool_name}?",
    "request_type": "approval",
    "actor": {"agent_id": agent_did, "agent_name": agent_did},
    "approval_policy": approval_policy_for(trust_score),
    "context": {
        "tool_name": tool_name,
        "tool_input": tool_input,
        "machine_observed": {"agent_did": agent_did, "trust_score": trust_score,
                              "verdict_chain": verdicts},
    },
    "continuation": {"mode": "decision", "webhook_url": CALLBACK_URL},
})

Ask a human on soft forbid

A hard forbid should stay a hard forbid. But when a policy author wants "stop and get guidance" rather than "fail", the bridge can convert the block into a free_text request: the agent asks, a person answers with decision_type: respond, and the reply returns to the workflow as input. This keeps GovernanceDenied deterministic while giving governed agents a human-guidance path AGT does not have on its own.

Operational checks: Control Map in CI and registry sync

• Before deploying a policy that requires approval, verify the approval path is satisfiable: run contro1 requests control-map with the policy role and quorum in CI, and fail the policy deployment when the role is unmapped or no reviewer is on shift.
• Sync the AgentMesh inventory into the Contro1 AI Registry (contro1 ai-registry import) with a trust-tier to risk-category mapping, so every AGT-governed agent appears in the EU AI Act readiness view.
• Export signed evidence per agent (GET /v1/agents/:id/evidence) for compliance reviews; each packet carries the policy_context that caused each decision.

Webhook handling

Callbacks include policy_context alongside risk_level, policy_trigger, decision_context, status, response, and protocol_response. Verify X-CentCom-Signature and X-CentCom-Timestamp before doing anything with the result.

Resume only when status is approved. Denied, cancelled, timed_out, invalid signatures, and duplicate callback delivery IDs should fail closed.

Webhooks · Requests API · Audit records and cases

Send full agent traceability

Beyond the approval call, attach identity, a run trace, the tools you invoked, and the context you retrieved. Each field is optional — add what you have. The verified identity always comes from your API key; a caller-supplied actor.agent_id is recorded as a claimed sub-agent until an admin verifies it.

• trace_id / parent_trace_id — link one run (and sub-agent runs) into a single trace.
• tool_calls[] — what the agent tried to do, so reviewers see the actions.
• retrieved_context[] — the data the decision was based on (RAG provenance).
• Then export a signed evidence packet from GET /requests/:id/evidence.

// POST /api/centcom/v1/requests — add these fields to the body you already send.
{
  "request_type": "approval",
  "title": "Refund $4,200 to customer 8831",
  "source": { "integration": "microsoft-agt" },
  "actor": { "agent_id": "billing-agent", "agent_name": "Billing Agent" },
  "trace_id": "trc_<run id>",
  "tool_calls": [{ "name": "lookup_order", "outcome": "success" }],
  "retrieved_context": [{ "source": "policy:refunds", "uri": "kb://policy/refunds" }],
  "continuation": { "mode": "decision" }
}

Agent identity, traceability & signed evidence

Make the approval the gate, not a suggestion

The signed webhook is cryptographic proof of a human decision. Verify it inside the system that executes the action - not inside the agent. Any tool that must never run without human sign-off (payments, deploys, data deletion) should refuse to act without a verified approval; that way no agent, including shadow agents nobody registered, can trigger it by skipping Contro1.

• Verify the signature and reject timestamps older than 5 minutes (replay protection; the timestamp marks callback delivery, not request creation, so long SLAs are unaffected).
• Bind the approval to the exact action parameters via metadata / correlation_id - never treat "an approval arrived" as permission for a different action.
• Execute each request_id exactly once (idempotency on your side).
• When in doubt, confirm state directly with GET /v1/requests/:id using a read-only API key.

Full guardrail pattern with code: Webhooks

Frequently asked questions

Does Contro1 replace Microsoft AGT?

No. Microsoft AGT remains the policy enforcement layer. Contro1 runs the human decision path once policy requires approval.

Is policy_context a policy engine?

No. policy_context is ingestion and evidence metadata. It records which external policy source, policy, and rule caused the review.

Related resources