Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/microsoft/agent-governance-toolkit/llms.txt

Use this file to discover all available pages before exploring further.

This page answers the most common technical questions from customers, partners, and evaluators of the Agent Governance Toolkit. For installation help, see the Quick Start. For design boundaries that aren’t bugs, see the Known Limitations page. For architecture deep-dives, refer to the How It Works page.
Short answer: They are complementary — AGT enforces governance at the agent execution level (runtime), while the Foundry Control Plane provides centralised fleet management, observability, and lifecycle operations at the organisational level. Think of AGT as the enforcement engine and the Foundry Control Plane as the management dashboard.
AspectAgent Governance ToolkitFoundry Control Plane
ScopePer-agent runtime security and policy enforcementOrganisation-wide fleet management, monitoring, and lifecycle
Where it runsIn-process middleware or sidecar alongside each agentCentralised Azure service
What it doesIntercepts every agent action, enforces policy, verifies identity, auditsProvides agent inventory, health monitoring, lifecycle operations, centralised policy definition
LatencySub-millisecond (<0.1ms p99)Dashboard/API-level
LicenceOpen-source (MIT)Azure managed service
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.
Deployment patterns: Azure AI Foundry Agent Service (tightest integration, no sidecar needed), AKS Sidecar, Azure Container Apps, or a hybrid mix.
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.
TypeCouplingDeveloper EffortWhat It Means
Native MiddlewareDeepestMinimalGovernance runs as a first-class middleware layer. Every action passes through it automatically. No changes to agent logic.
NativeDeepMinimalHooks directly into the framework’s native extension points (e.g., Semantic Kernel filters/plugins).
AdapterModerateLowA thin wrapper class bridging the framework’s API to AGT. Typical: LangChainKernel(agent=my_agent).
Middleware/PipelineModerateLowHooks into lifecycle callbacks or pipeline stages. In Haystack, it’s a pipeline component; in OpenAI Agents SDK, it’s an async hook.
PluginLightestMinimalDrop-in plugin in platforms that support marketplaces (e.g., Dify Marketplace).
Deployment GuideN/AVariesNot a code integration — a documented deployment pattern for Azure AI Foundry.
Which should you choose?
  • 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: 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.
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")
What this enables:
  • Enterprise SSO — Agents authenticate with the same Entra ID used by your organisation.
  • Conditional Access — Apply Entra Conditional Access policies to agent identities.
  • 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.
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.In-process reload (explicit):
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 needed
The reload operation acquires a write lock, clears the existing policy cache, loads all policy files from the directory, releases the lock, and applies new policies to all subsequent evaluations.OPA Remote Server (hot reload): 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.Sidecar deployment: In Kubernetes sidecar deployments, update the policy ConfigMap and the sidecar picks up the new policies while the agent container continues running uninterrupted.
ScenarioApproach
Development/testingCall 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
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.
Aspectagent-hypervisoragent-runtime (agentmesh-runtime)
PyPI Packageagent-hypervisoragentmesh-runtime
RoleCanonical implementationThin re-export wrapper
Why it existsPrimary development packagePyPI name collision avoidance with AutoGen
Import pathfrom hypervisor import Hypervisorfrom hypervisor import Hypervisor (same)
Most users should install the consolidated distribution with pip install agent-governance-toolkit[full], which includes the hypervisor/runtime subsystem. The individual package names are documented only to explain the PyPI naming.
What the hypervisor / runtime provides:
FeatureDescription
Execution Rings (Ring 0–3)Graduated privilege levels based on trust score. Ring 0 = system (highest), Ring 3 = sandbox (most restricted).
Session IsolationMulti-agent sessions with VFS namespacing and DID-bound identity.
Saga OrchestrationMulti-step transactions with automatic compensation (rollback).
Kill SwitchImmediate or graceful termination of runaway agents with audit trail.
Joint LiabilityAttribution tracking across multi-agent collaborations with bonded reputation.
Temporary Ring Elevation (Sudo)Agents can request temporary privilege escalation with a TTL that auto-expires.
Short answer: Any agent type. AGT is framework-agnostic and vendor-independent by design — the core packages have zero vendor dependencies.AGT works with Azure AI Foundry, AWS Bedrock, Google ADK, LangChain, CrewAI, AutoGen, OpenAI Agents SDK, and 20+ other frameworks. The core governance packages (agent-governance-toolkit-core, agent-governance-toolkit-runtime, etc.) depend only on pydantic and cryptography — no Azure/Microsoft services required.AGT follows an adapter pattern: core governance packages are vendor-neutral, 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.
Run agt doctor to verify — it shows all installed packages and confirms none require cloud connectivity.
Short answer: Every tool call, message send, and delegation is intercepted in deterministic application code before the model’s intent reaches the wire.AGT enforces governance through a multi-stage pipeline:
pre_input → pre_tool → post_tool → pre_output
At each stage, the policy engine (YAML/OPA/Cedar) evaluates the action against loaded rules in under 0.1ms. If the action is denied, GovernanceDenied is raised before any external call is made — the action never executes. If allowed, an immutable audit log entry is written.Security boundary note: AGT enforces at the application middleware layer, not at the OS kernel level. The policy engine and agents share the same process boundary. For OS-level isolation, run each agent in a separate container. See the Known Limitations page for full detail and recommended layered defence.
Short answer: If the policy engine encounters a runtime error during evaluation (not a deny decision — an unexpected exception), it denies the action rather than allowing it through. This prevents governance from silently failing open during errors.Concretely:
  • If policy files cannot be loaded at startup → actions are denied until policies are successfully loaded.
  • If OPA/Cedar backend returns an unexpected error → the built-in fallback evaluates and denies if no explicit allow rule matches.
  • If the policy evaluator has no policies loaded at all → the default action is allow (permissive default).
The last point is important: a policy evaluator with no policies loaded is fail-open, not fail-closed. Always use agt lint-policy and agt doctor in CI to confirm policies are loaded and the default action in production is deny. Use strict mode (deny-by-default) to require explicit allow rules for every permitted action.
Short answer: Run agt verify --evidence ./agt-evidence.json --strict. This checks all 10 OWASP Agentic AI Top 10 controls and produces a signed attestation.
# Step 1: Enable runtime evidence collection in your agent
# (set evidence_mode=True on your PolicyEvaluator)

# Step 2: Run your agent through a representative workload to collect evidence

# Step 3: Run the compliance check
agt verify --evidence ./agt-evidence.json --strict
The command outputs a pass/fail report mapping each ASI-01 through ASI-10 control to the AGT controls covering it. With --strict, it exits with code 1 if any control is not fully covered — suitable for blocking a CI pipeline.You can also embed the resulting badge in your README:
# Generate an integrity manifest for release signing
agt verify --evidence ./agt-evidence.json --output-badge ./owasp-badge.json
See the Audit & Compliance page for the full attestation workflow, including how to produce signed decision receipts.

Build docs developers (and LLMs) love

Get started for freeTalk to us