Technical Q&A for customers, partners, and evaluators of the Agent Governance Toolkit.
See also: Quick Start · Architecture · Known Limitations · OWASP Compliance
- What is the relationship between AGT and the Foundry Control Plane?
- Is the Agent Mesh sidecar only intercepting network-related agent actions?
- What is the practical impact of the different SDK integration types?
- How many SDKs are actually supported — 12 or 6?
- Can an agent identity be linked to Entra IDs?
- If I update a policy at runtime, do I need to restart the agent?
- What is the Microsoft product integration roadmap?
- How does Agent Mesh Runtime interact with Agent Mesh and the Sidecar?
- How does Agent Mesh govern authentications to internal and external resources?
- What is the difference between agent-hypervisor and agent-runtime?
- Is AGT geared towards Foundry agents or any agent type?
- What is the relationship between AGT and Agent 365?
- How is AGT different from DLP and communication compliance policies?
Short answer: They are complementary — AGT enforces governance at the agent execution level (runtime), while the Foundry Control Plane provides centralized fleet management, observability, and lifecycle operations at the organizational level. Think of AGT as the enforcement engine and the Foundry Control Plane as the management dashboard.
| Aspect | Agent Governance Toolkit | Foundry Control Plane |
|---|---|---|
| Scope | Per-agent runtime security and policy enforcement | Organization-wide fleet management, monitoring, and lifecycle |
| Where it runs | In-process middleware or sidecar alongside each agent | Centralized Azure service |
| What it does | Intercepts every agent action, enforces policy, verifies identity, audits | Provides agent inventory, health monitoring, lifecycle operations, centralized policy definition |
| Latency | Sub-millisecond (<0.1ms p99) | Dashboard/API-level |
| License | Open-source (MIT) | Azure managed service |
┌────────────────────────────────────────────────────────┐
│ Foundry Control Plane │
│ ┌──────────────┐ ┌───────────┐ ┌────────────────┐ │
│ │ Agent │ │ Health │ │ Policy │ │
│ │ Inventory │ │ Monitoring│ │ Definition │ │
│ └──────────────┘ └───────────┘ └────────────────┘ │
└────────────────────────┬───────────────────────────────┘
│ Publishes policies, collects telemetry
▼
┌────────────────────────────────────────────────────────┐
│ Agent Governance Toolkit │
│ (runs alongside each agent — middleware or sidecar) │
│ │
│ Policy Engine ──► Identity Verification ──► Audit Log │
│ (<0.1ms) (Ed25519 + DID) (immutable) │
└────────────────────────────────────────────────────────┘
In practice:
- The Control Plane defines and distributes policies, aggregates telemetry, and provides a single pane of glass for operators.
- The Toolkit enforces those policies deterministically at runtime — every tool call, resource access, and inter-agent message is evaluated before execution.
- Foundry Control Plane can report on AGT-enforced events (blocked actions, identity assertions, trust scores) as part of its observability features.
- Azure AI Foundry Agent Service — AGT plugs directly into Foundry's middleware pipeline. No sidecar needed. This is the tightest integration.
- AKS Sidecar — AGT runs as a sidecar container in the same Kubernetes Pod as your agent. The Control Plane manages the fleet; AGT governs each agent.
- Azure Container Apps — Serverless container deployment with AGT governance.
- Hybrid — Foundry middleware for Foundry-native agents + AKS sidecar for custom agents, both feeding into the same Control Plane.
Short answer: No. The sidecar operates at the application layer — intercepting JSON-RPC tool calls, enforcing policy decisions, verifying trust, managing identity, auditing actions, and sanitizing outputs. It is not a network packet inspector; it is a governance proxy.
| Category | What It Does | Layer |
|---|---|---|
| Tool call interception | Intercepts JSON-RPC tools/call messages (MCP protocol) before they reach the target server |
Application (L7) |
| Policy enforcement | Evaluates every action against YAML/OPA/Cedar policy rules — allow, deny, or flag | Application |
| Identity verification | Verifies agent DID (Ed25519 signature), checks trust score thresholds | Cryptographic |
| Capability gating | Ensures the agent has the required capabilities before allowing tool execution | Application |
| Output sanitization | Sanitizes tool results, strips PII, appends verification footers | Application |
| Non-JSON smuggling prevention | Blocks non-JSON payloads that could bypass policy inspection | Application |
| Audit logging | Logs every governance check, violation, and action for compliance | Observability |
| Prompt injection scanning | Scans inputs for injection attacks before they reach the agent | Security |
| Rate limiting | Enforces per-agent, per-tool rate limits | Application |
| Health/readiness probes | Kubernetes /health and /ready endpoints for orchestration |
Infrastructure |
| Metrics export | Governance check counts, violation rates, latency via /api/v1/metrics |
Observability |
- Service mesh sidecars (e.g., Envoy/Istio) operate at Layer 3–4 (TCP/TLS) — they handle mTLS, load balancing, and network routing.
- AGT sidecar operates at Layer 7 (application) — it understands the semantics of agent actions (tool calls, MCP messages, A2A protocol) and makes governance decisions based on what the agent is trying to do, not just where the traffic is going.
Current limitation: Transparent tool-call interception is not yet implemented in the sidecar. The agent or orchestration layer must call the sidecar API explicitly (HTTP calls to
localhost:8081). Transparent interception (via iptables or eBPF) is on the roadmap.
Short answer: The integration type determines how deeply governance is woven into the agent framework's execution pipeline — from a single line of configuration (native middleware) to a lightweight adapter you wrap around your agent. The governance capabilities are identical regardless of type; the difference is developer experience and coupling depth.
| Type | Coupling | Developer Effort | What It Means |
|---|---|---|---|
| Native Middleware | Deepest | Minimal — add middleware to existing pipeline | Governance runs as a first-class middleware layer. Every action passes through it automatically. No code changes to agent logic. |
| Native | Deep | Minimal — import and configure | Hooks directly into the framework's native extension points (e.g., Semantic Kernel filters/plugins). |
| Adapter | Moderate | Low — wrap your agent/kernel | A thin wrapper class that bridges the framework's API to AGT. Typical: LangChainKernel(agent=my_agent). |
| Middleware/Pipeline | Moderate | Low — register as callback/component | Hooks into lifecycle callbacks or pipeline stages. In Haystack, it's a pipeline component; in OpenAI Agents SDK, it's an async hook. |
| Plugin | Lightest | Minimal — install from marketplace | Drop-in plugin in platforms that support marketplaces. In Dify, governance appears as a tool in the Dify Marketplace. |
| Deployment Guide | N/A | Varies | Not a code integration — a documented deployment pattern. For Azure AI Foundry, governance is deployed via infrastructure configuration. |
| Framework | Integration Type | Governance Class | Practical Impact |
|---|---|---|---|
| Microsoft Agent Framework | Native Middleware | GovernanceMiddleware |
Add 1 middleware registration. All tool calls governed automatically. |
| Semantic Kernel | Native (.NET + Python) | SemanticKernelAdapter |
Register as a Semantic Kernel filter. Transparent governance. |
| AutoGen | Adapter | AutoGenKernel |
Wrap your AutoGen agent. Governance injected at tool-call boundaries. |
| LangChain / LangGraph | Adapter | LangChainKernel / LangGraphKernel |
Wrap chains/graphs. Published on PyPI (langgraph-trust). |
| CrewAI | Adapter | CrewAIKernel |
Wrap crew tasks. Trust verification before inter-agent delegation. |
| OpenAI Agents SDK | Middleware | OpenAIAgentsKernel |
Async hooks on tool calls. Published on PyPI (openai-agents-trust). |
| Google ADK | Adapter | GoogleADKKernel |
Plugin-style integration via ADK's extension system. |
| LlamaIndex | Middleware | LlamaIndexAdapter |
TrustedAgentWorker + TrustGatedQueryEngine merged upstream. |
| Haystack | Pipeline | HaystackAdapter |
GovernancePolicyChecker + TrustGate pipeline components. |
| Dify | Plugin | DifyPlugin |
Install from Dify Marketplace. Zero-code governance. |
| Azure AI Foundry | Deployment Guide | MAF Middleware | GovernancePolicyMW, CapabilityGuardMW, AuditTrailMW, RogueDetectionMW. |
- Microsoft Agent Framework or Semantic Kernel → Use native middleware — governance is invisible and automatic.
- LangChain, CrewAI, AutoGen, or Google ADK → Use the adapter — 2–3 lines of code.
- Dify → Install the plugin from the marketplace.
- Azure AI Foundry → Follow the deployment guide for MAF middleware.
All types deliver the same governance capabilities — policy enforcement, identity verification, audit logging, trust scoring.
Short answer: The numbers refer to different things:
- 5 language SDKs — Python, TypeScript, .NET, Rust, Go
- 6 production framework integrations (for AgentMesh specifically) — Dify, LlamaIndex, Agent-Lightning, LangGraph, OpenAI Agents, Haystack
- 12+ framework integrations (for the full toolkit) — includes all 6 above plus Microsoft Agent Framework, Semantic Kernel, AutoGen, LangChain, CrewAI, Google ADK, PydanticAI, and more
| Language | Package | Status |
|---|---|---|
| Python | agent-governance-toolkit[full] |
✅ Full-featured, primary SDK |
| TypeScript | @microsoft/agentmesh-sdk |
✅ Published on npm |
| .NET | Microsoft.AgentGovernance |
✅ Published on NuGet |
| Rust | agentmesh crate |
✅ Published on crates.io |
| Go | github.com/microsoft/agent-governance-toolkit/sdks/go |
✅ Module available |
The AgentMesh package README lists 6 production integrations specific to the trust/identity layer:
| Framework | Stars | Status |
|---|---|---|
| Dify | 65K ⭐ | ✅ Merged in Marketplace |
| LlamaIndex | 47K ⭐ | ✅ Merged upstream |
| Agent-Lightning | 15K ⭐ | ✅ Merged |
| LangGraph | 24K ⭐ | 📦 Published on PyPI |
| OpenAI Agents SDK | — | 📦 Published on PyPI |
| Haystack | 22K ⭐ | 🔄 In Review |
The root README lists all frameworks the entire toolkit supports, including Agent OS policy engine integrations: Microsoft Agent Framework, Semantic Kernel, AutoGen, LangGraph, LangChain, CrewAI, OpenAI Agents SDK, Google ADK, LlamaIndex, Haystack, Dify, Azure AI Foundry, plus community adapters for PydanticAI, Mistral, Anthropic, and Gemini.
The AgentMesh README counts only its own production-merged or PyPI-published integrations (6). The root README counts all integrations across all 7 packages in the toolkit (12+). Both numbers are accurate — they just scope differently.
Short answer: Yes. AgentMesh provides first-class Microsoft Entra Agent ID integration that bridges the toolkit's DID-based identity system with enterprise Entra ID. Agents can authenticate via Azure Managed Identities (both system-assigned and user-assigned), and the toolkit maps DIDs to Entra tenant/client/object IDs.
┌──────────────────────────────────────────────────────────┐
│ Agent Governance Toolkit Identity Layer │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ AgentIdentity (DID: did:agentmesh:<agent-name>) │ │
│ │ ├── Ed25519 keypair (signing/verification) │ │
│ │ ├── Human sponsor (alice@company.com) │ │
│ │ ├── Capabilities (["read:data", "write:reports"]) │ │
│ │ └── Trust score (0–1000) │ │
│ └──────────────────────┬─────────────────────────────┘ │
│ │ bridges to │
│ ┌──────────────────────▼─────────────────────────────┐ │
│ │ EntraAgentID (Entra integration adapter) │ │
│ │ ├── Entra Tenant ID │ │
│ │ ├── Entra Client ID │ │
│ │ ├── Entra Object ID │ │
│ │ ├── JWT claim validation │ │
│ │ └── Conditional Access policy support │ │
│ └──────────────────────┬─────────────────────────────┘ │
│ │ authenticates via │
│ ┌──────────────────────▼─────────────────────────────┐ │
│ │ Azure Managed Identity │ │
│ │ ├── System-assigned (VM, App Service, AKS) │ │
│ │ ├── User-assigned (shared across resources) │ │
│ │ └── IMDS token acquisition (169.254.169.254) │ │
│ └────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
| Component | Source File | Purpose |
|---|---|---|
AgentIdentity |
identity/agent_id.py |
Core DID identity with Ed25519 keys, sponsor, capabilities |
EntraAgentID |
identity/entra_agent_id.py |
Maps DID ↔ Entra tenant/client IDs, bootstraps from IMDS or env vars |
EntraAgentIdentity |
identity/entra.py |
Extended identity binding DID to Entra object IDs, sponsor, scopes, lifecycle states |
EntraAgentRegistry |
identity/entra.py |
Registry of Entra-backed agent identities with lookup by DID or Entra object ID |
EntraManagedIdentity |
identity/managed_identity.py |
Uses Azure IMDS to acquire tokens for Managed Identities |
from agentmesh.identity import AgentIdentity
from agentmesh.identity.entra_agent_id import EntraAgentID
# Create an agent identity linked to Entra
identity = AgentIdentity.create(
name="trading-agent",
sponsor="alice@contoso.com",
capabilities=["read:market-data", "execute:trades"],
)
# Bridge to Entra ID
entra = EntraAgentID(
agent_identity=identity,
tenant_id="your-entra-tenant-id", # or auto-detected from AZURE_TENANT_ID
client_id="your-app-registration-id", # or auto-detected from AZURE_CLIENT_ID
)
# On Azure (AKS, App Service, VM), use Managed Identity
from agentmesh.identity.managed_identity import EntraManagedIdentity
managed = EntraManagedIdentity() # Auto-detects IMDS
token = managed.get_token(scope="https://graph.microsoft.com/.default")- Enterprise SSO — Agents authenticate with the same Entra ID used by your organization.
- Conditional Access — Apply Entra Conditional Access policies to agent identities.
- Lifecycle Management — Entra-backed agents inherit lifecycle states from both AGT and Entra ID.
- RBAC Integration — Agents can be assigned Azure RBAC roles through their Managed Identity.
- Audit Trail — Entra sign-in logs capture agent authentication events alongside human events.
- Credential-less — Managed Identity means no secrets to manage in code or configuration.
Multi-cloud: The toolkit also provides adapters for AWS IAM (instance roles, STS assume-role) and GCP Workload Identity (service accounts, metadata server) in
identity/managed_identity.py.
Short answer: No. Policies can be reloaded at runtime without restarting the agent.
from agent_os.policies import AsyncPolicyEvaluator
evaluator = AsyncPolicyEvaluator(policy_dir="./policies")
# Later, when policies have been updated on disk:
await evaluator.reload_policies(directory="./policies")
# All subsequent evaluations use the new policies — no restart neededThe reload operation:
- Acquires a write lock (blocking concurrent reads momentarily)
- Clears the existing policy cache
- Loads all policy files from the directory
- Releases the lock
- All subsequent evaluations use the new policies
When using OPA as the policy backend in Remote Server mode, you get true policy hot-reload — OPA watches the policy bundle and applies changes automatically:
| Feature | Remote OPA Server | Local CLI | Built-in Fallback |
|---|---|---|---|
| Policy hot-reload | ✅ | ❌ | ❌ |
| Sub-millisecond latency | ✅ | ❌ | ✅ |
| Centralized management | ✅ | ❌ | ❌ |
In sidecar deployments, the governance sidecar can be updated independently of the agent container:
- Update the policy ConfigMap in Kubernetes
- The sidecar picks up the new policies
- The agent container continues running uninterrupted
| Scenario | Approach |
|---|---|
| Development/testing | Call reload_policies() explicitly after editing policy files |
| Production (single agent) | Use OPA Remote Server for automatic hot-reload |
| Production (fleet) | Use Foundry Control Plane to distribute policy updates → sidecar picks up changes via ConfigMap |
| Microsoft Product | Status | Details |
|---|---|---|
| Azure AI Foundry Agent Service | ✅ Available | Native MAF middleware |
| Azure Kubernetes Service (AKS) | ✅ Available | Sidecar deployment with Helm charts |
| Azure Container Apps | ✅ Available | Serverless deployment guide |
| Semantic Kernel | ✅ Available | Native .NET + Python integration |
| Microsoft Agent Framework | ✅ Available | Native middleware integration |
| Microsoft AutoGen | ✅ Available | Adapter integration |
| Microsoft Agent-Lightning | ✅ Merged | RL training governance — merged upstream |
| VS Code Extension | ✅ Available | agent-os-vscode package |
| Azure Monitor | ✅ Available | OpenTelemetry + Prometheus metrics export |
| Microsoft Entra Agent ID | ✅ Available | DID ↔ Entra identity bridge with Managed Identity support |
| Ecosystem | Package | Status |
|---|---|---|
| PyPI | agent-governance-toolkit[full], agent-os-kernel, agentmesh-platform, agentmesh-runtime, agent-sre, agentmesh-marketplace, agentmesh-lightning, openai-agents-trust, langgraph-trust |
✅ Published |
| npm | @microsoft/agentmesh-sdk |
✅ Published |
| NuGet | Microsoft.AgentGovernance |
✅ Published |
| crates.io | agentmesh |
✅ Published |
| Dify Marketplace | Trust verification plugin | ✅ Merged |
The project is MIT-licensed and Microsoft has stated the aspiration to move it into a foundation home for shared community stewardship. Active engagements include OWASP Agent Security Initiative, LF AI & Data Foundation, and CoSAI (Coalition for Secure AI) working groups.
Short answer: These are three distinct layers of the governance stack:
| Component | Role | Analogy |
|---|---|---|
| AgentMesh (platform) | Trust, identity, and governance layer — the "brain" | SSL/TLS for the web |
| Agent Mesh Sidecar | Deployment mode — a local governance proxy in a Kubernetes Pod | Envoy sidecar in Istio |
| Agent Mesh Runtime (agent-runtime / agent-hypervisor) | Execution supervisor — privilege rings, sagas, kill switch | OS kernel / hypervisor |
┌───────────────────────────────────────────────────────────────┐
│ Kubernetes Pod │
│ │
│ ┌──────────────────────┐ ┌───────────────────────────────┐ │
│ │ Agent Container │ │ Governance Sidecar │ │
│ │ │ │ │ │
│ │ Your AI Agent │ │ ┌───────────────────────┐ │ │
│ │ (any framework) │ │ │ AgentMesh (Layer 1) │ │ │
│ │ │ │ │ Identity + Trust │ │ │
│ │ ┌─────────────────┐ │ │ │ DID, Ed25519, IATP │ │ │
│ │ │ Agent Runtime │ │ │ └───────────┬───────────┘ │ │
│ │ │ (in-process) │ │ │ │ │ │
│ │ │ Execution rings │ │ │ ┌───────────▼───────────┐ │ │
│ │ │ Saga orchestr. │ │ │ │ Agent OS (Layer 2) │ │ │
│ │ │ Kill switch │ │ │ │ Policy Engine │ │ │
│ │ └─────────────────┘ │ │ │ YAML / OPA / Cedar │ │ │
│ │ │ │ │ └───────────┬───────────┘ │ │
│ │ Tool call ───────────────► Governance │ Proxy │ │
│ │ ◄─────────────── Allow/Deny │ │ │
│ └──────────────────────┘ └──────────────┼────────────────┘ │
│ ▼ │
│ External APIs / MCP │
└───────────────────────────────────────────────────────────────┘
- Agent wants to act — e.g., call a tool, send a message to another agent, access a resource.
- Agent Runtime checks execution ring — Is this agent in Ring 2 (standard) or Ring 3 (sandbox)? Does it have the privilege level?
- Request goes to AgentMesh (via sidecar or in-process):
- Identity check — Is the caller's DID valid and active?
- Trust check — Does the peer meet the trust score threshold?
- Policy check — Does the Agent OS policy engine allow this action?
- If allowed → Forward to target (MCP server, another agent, external API)
- If denied → Block, return reason, log the violation
- Always → Audit log entry written
| Scenario | AgentMesh | Sidecar | Runtime |
|---|---|---|---|
| Single agent, in-process governance | ✅ (library) | ❌ | Optional |
| Multi-agent on Kubernetes | ✅ | ✅ | ✅ |
| Azure AI Foundry | ✅ (middleware) | ❌ | Optional |
| Multi-step workflows with rollback | ✅ | Optional | ✅ (saga) |
| Emergency agent termination | ✅ | Optional | ✅ (kill switch) |
Short answer: AgentMesh uses different mechanisms for internal (agent-to-agent) and external (agent-to-service) authentication, but both are governed through the same policy engine.
Agent A TrustBridge Agent B
│ │ │
├─── verify_peer(B, min=700)──► │
│ ├──── IATP Challenge ─────────►
│ │ (nonce + timestamp) │
│ ◄──── Signed Response ────────┤
│ │ (Ed25519 signature) │
│ Verify: │
│ 1. DID registered in registry? │
│ 2. Identity active (not revoked)? │
│ 3. Ed25519 signature valid? │
│ 4. Public key matches registry? │
│ 5. Trust score ≥ threshold? │
│ 6. Required capabilities present? │
◄─── Result (verified/denied)│ │
Key controls:
- DID-based identity — Every agent gets a
did:agentmesh:identifier with Ed25519 keypair - Ed25519 challenge-response — Cryptographic proof the peer owns the claimed DID
- Registry-backed verification — Peer must be registered and active
- Trust scoring — Dynamic trust scores (0–1000) with behavioral decay
- Capability scoping — Agents only get access to capabilities they're registered for
- Protocol bridges — A2A, MCP, IATP translated through a unified trust model
| External Resource | How AgentMesh Governs It |
|---|---|
| MCP Servers (tools) | Proxy intercepts tool calls → policy check → allow/deny → audit. Supports allowlists, rate limits, output sanitization. |
| LLM APIs (OpenAI, Azure OpenAI, etc.) | Policy engine can restrict which models, endpoints, and parameters an agent can use. Rate limiting per agent. |
| Databases | Tool-call governance — if the agent accesses a DB through a tool, the proxy enforces policy on that tool call. |
| External APIs | Same tool-call interception pattern. Capability gating ensures agents only call APIs they're authorized for. |
| Cloud Resources | Managed Identity adapters (Entra, AWS IAM, GCP WI) handle authentication. AGT governance layer controls authorization. |
Key distinction:
- Authentication (proving who you are) to external services is handled via managed identities / workload identity — the same credential-less approach used by any Azure service.
- Authorization (what you're allowed to do) is where AgentMesh adds governance — policy enforcement, capability gating, rate limiting, and audit logging sit between the agent and the external resource.
Short answer: They are the same subsystem with different package names. agent-hypervisor is the canonical upstream implementation; agentmesh-runtime (agent-runtime) is a thin re-export wrapper created to avoid a PyPI naming collision with Microsoft AutoGen's agent-runtime package.
| Aspect | agent-hypervisor | agent-runtime (agentmesh-runtime) |
|---|---|---|
| PyPI Package | agent-hypervisor |
agentmesh-runtime |
| Role | Canonical implementation | Thin re-export wrapper |
| Why it exists | Primary development package | PyPI name collision avoidance with AutoGen |
| Tests | 644+ tests | Import compatibility tests |
| Install | pip install agent-hypervisor |
pip install agentmesh-runtime |
| Import | from hypervisor import Hypervisor |
from hypervisor import Hypervisor (same) |
| Feature | Description |
|---|---|
| Execution Rings (Ring 0–3) | Graduated privilege levels based on trust score. Ring 0 = system (highest), Ring 3 = sandbox (most restricted). |
| Session Isolation | Multi-agent sessions with VFS namespacing and DID-bound identity. |
| Saga Orchestration | Multi-step transactions with automatic compensation (rollback). |
| Kill Switch | Immediate or graceful termination of runaway agents with audit trail. |
| Joint Liability | Attribution tracking across multi-agent collaborations. Bonded reputation with collateral slashing. |
| Rate Limiting | Per-agent rate limits to prevent resource exhaustion. |
| Hash-Chained Audit Trail | Tamper-evident, append-only execution logs. |
| Temporary Ring Elevation (Sudo) | Agents can request temporary privilege escalation with a TTL that auto-expires. |
| OS / VM Hypervisor | Agent Hypervisor | Why It Matters |
|---|---|---|
| CPU rings (Ring 0–3) | Execution Rings — privilege levels based on trust score | Graduated access, not binary allow/deny |
| Process isolation | Session isolation — VFS namespacing, DID-bound identity | Rogue agents can't corrupt other sessions |
| Memory protection | Liability protection — bonded reputation, collateral slash | Sponsors have skin in the game |
| System calls | Saga transactions — multi-step ops with automatic rollback | Failed workflows undo themselves |
| Watchdog timer | Kill switch — graceful termination with step handoff | Stop runaway agents without data loss |
Short answer: Any agent type. AGT is framework-agnostic and vendor-independent by design — the core packages (agent-os-kernel, agentmesh-platform, etc.) have zero vendor dependencies.
It works with Azure AI Foundry, AWS Bedrock, Google ADK, LangChain, CrewAI, AutoGen, OpenAI Agents, OpenClaw, and 20+ other frameworks. See the full list in the README.
AGT follows an adapter pattern: core governance packages are vendor-neutral (pydantic + cryptography only), while framework-specific integrations are published as separate packages. This means:
- Foundry agents get native middleware integration (
GovernancePolicyMW,CapabilityGuardMW,AuditTrailMW) — governance is invisible and automatic. - Non-Foundry agents (LangChain, CrewAI, OpenClaw, etc.) use adapters or the sidecar HTTP API — 2–3 lines of code.
- The governance capabilities are identical regardless of framework — policy enforcement, identity verification, audit logging, trust scoring.
See the Independence & Dependency Policy for the full vendor-neutrality matrix and the SDK Integration Types FAQ for framework-by-framework details.
Short answer: They operate at different layers and are complementary. Agent 365 is the M365 control plane for fleet management; AGT is runtime governance middleware for per-action policy enforcement.
| Aspect | Agent Governance Toolkit | Agent 365 |
|---|---|---|
| What it is | Runtime governance middleware | M365 control plane |
| Scope | Per-action enforcement inside each agent | Tenant-level fleet governance |
| Where it runs | In-process middleware or sidecar alongside each agent | Centralized Azure / M365 service |
| What it does | Intercepts every tool call, enforces policy, verifies identity, audits | Agent registry, Entra Agent ID, lifecycle management, admin dashboards, Defender + Purview integration |
| Latency | Sub-millisecond (<0.1ms p99) | Dashboard / API-level |
| Works with | Any framework, any cloud, any runtime | M365 tenant boundary |
| License | Open-source (MIT) | M365 licensed service |
- Agent 365 answers: "Which agents are allowed to exist in my org and what data can they access?"
- AGT answers: "Should this specific agent be allowed to execute this specific tool call right now?"
Agent 365 manages the fleet from the admin center. AGT enforces policy inside each agent's runtime. They are complementary — not competing.
There is no formal integration between them today. AGT is an open-source MIT project; Agent 365 is a licensed M365 service.
Short answer: DLP and communication compliance govern content (sensitive data in messages, prompts, responses). AGT governs actions (tool calls, API invocations, code execution, inter-agent messages). They are complementary layers.
| DLP / Communication Compliance | AGT | |
|---|---|---|
| What it governs | Content — sensitive data in messages, prompts, responses | Actions — tool calls, API invocations, code execution, inter-agent messages |
| When it acts | After content is generated (inspects text) | Before execution (intercepts the action) |
| Enforcement model | Pattern matching on sensitive information types (SITs), regex, classifiers | Deterministic policy rules on action metadata (tool name, agent identity, trust score, parameters) |
| Example | Blocks a message containing a credit card number | Blocks an agent from calling delete_database even if the content contains no sensitive data |
| Scope | M365 workloads (Exchange, Teams, Copilot, extending to agents) | Any runtime, any cloud, any framework |
An agent can do dangerous things without ever touching sensitive content. For example:
- Calling
execute_code("rm -rf /")— no PII, but destructive - Invoking a privileged API with valid but unauthorized parameters — no sensitive data patterns to match
- Sending inter-agent messages that coordinate a multi-step attack — each message is individually benign
DLP won't catch any of these because there's no sensitive content to flag. AGT's policy engine evaluates the action itself (tool name, parameters, agent identity, trust score) and blocks it deterministically in <0.1ms.
Both can block prompt injection. DLP uses content classifiers; AGT uses a dedicated PromptInjectionDetector with 7 attack-type detection. In practice you'd want both layers — DLP for data classification + AGT for action governance.
DLP and communication compliance are data-layer controls. AGT is an action-layer controls. A fully governed agent needs both:
- DLP ensures sensitive data doesn't leak
- AGT ensures the agent doesn't do things it shouldn't
| Package | PyPI | Purpose |
|---|---|---|
| Agent OS | agent-os-kernel |
Stateless policy engine — YAML, OPA/Rego, Cedar policies |
| AgentMesh | agentmesh-platform |
Trust, identity, governance — DID, Ed25519, trust scoring, protocol bridges |
| Agent Runtime | agentmesh-runtime |
Execution rings, saga orchestration, kill switch (re-exports from agent-hypervisor) |
| Agent Hypervisor | agent-hypervisor |
Canonical runtime — session isolation, privilege rings, joint liability |
| Agent SRE | agent-sre |
SLOs, error budgets, circuit breakers, chaos engineering, replay debugging |
| Agent Marketplace | agentmesh-marketplace |
Plugin lifecycle — Ed25519 signing, trust-tiered capability gating |
| Agent Lightning | agentmesh-lightning |
RL training governance — policy-enforced runners, reward shaping |
| Agent Compliance | agent-governance-toolkit |
Unified installer + compliance verification (EU AI Act, HIPAA, SOC2, OWASP) |
| Agent Discovery | agent-discovery |
Shadow AI discovery — find unregistered agents across processes, configs, repos |
| Resource | URL |
|---|---|
| GitHub Repository | https://github.com/microsoft/agent-governance-toolkit |
| Launch Blog Post | https://opensource.microsoft.com/blog/2026/04/02/introducing-the-agent-governance-toolkit-open-source-runtime-security-for-ai-agents/ |
| PyPI (Full Stack) | https://pypi.org/project/agent-governance-toolkit/ |
| npm (TypeScript) | @microsoft/agentmesh-sdk |
| NuGet (.NET) | Microsoft.AgentGovernance |
| DeepWiki | https://deepwiki.com/microsoft/agent-governance-toolkit |
| OWASP Agentic Top 10 | https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ |
| Quick Start Guide | QUICKSTART.md |
| Deployment Guides | docs/deployment/ |