agent-governance-toolkit
Librarymicrosoft/agent-governance-toolkit
Policy enforcement and security toolkit for autonomous AI agents.
Overview
Provides deterministic policy enforcement, zero-trust identity, and execution sandboxing for AI agents. Covers all OWASP Agentic Top 10 risks. Works with any framework and includes audit logging.
README Preview
🌍 [English](/README.md) | [日本語](./docs/i18n/README.ja.md) | [简体中文](./docs/i18n/README.zh-CN.md) | [한국어](./docs/i18n/README.ko.md)\n\n\n\n# Agent Governance Toolkit\n\n### Ship agents to production without losing sleep\n\n\n \n \n \n\n\n\n \n 🚀 Quick Start ·\n 📋 Specifications ·\n 📦 PyPI ·\n 📝 Changelog\n \n\n\n[](https://github.com/microsoft/agent-governance-toolkit/actions/workflows/ci.yml)\n[](LICENSE)\n[](https://pypi.org/project/agent-governance-toolkit/)\n[](https://www.npmjs.com/package/@microsoft/agent-governance-sdk)\n[](https://www.nuget.org/packages/Microsoft.AgentGovernance)\n[](https://scorecard.dev/viewer/?uri=github.com/microsoft/agent-governance-toolkit)\n[](https://www.bestpractices.dev/projects/12085)\n[](docs/compliance/owasp-agentic-top10-architecture.md)\n\n> [!IMPORTANT]\n> **Public Preview** -- production-quality, Microsoft-signed releases. May have breaking changes before GA.\n\nPolicy enforcement, identity, sandboxing, and SRE for autonomous AI agents. One `pip install`, any framework.\n\n---\n\n## The Problem\n\nYour AI agents call tools, browse the web, query databases, and delegate to other agents. Once deployed, they make decisions autonomously. You need answers to three questions:\n\n**1. Is this action allowed?** An agent with access to `send_email` and `query_database` should not be able to `drop_table`. OAuth scopes and IAM roles control which services an agent can reach, not what it does once connected.\n\n**2. Which agent did this?** In a multi-agent system, five agents might share a single API key. When something goes wrong, "an agent did it" is not an incident response.\n\n**3. Can you prove what happened?** Auditors and regulators need tamper-evident records of every decision: what policy was active, what the agent requested, and why it was allowed or denied.\n\nPrompt-level safety ("please follow the rules") is not a control surface. It is a polite request to a stochastic system. [OWASP LLM01:2025](https:FAQ (3)
TroubleshootingHow to make agent-os governance parity and adapter contract tests hard-fail in CI instead of being masked by soft-fail?
Add a dedicated conformance verification step in the GitHub Actions workflow (.github/workflows/ci.yml) for the agent-os matrix package. Place it before the existing soft-fail test step (pytest tests/ ... || true) and guard it with if: matrix.package == 'agent-os'. Run only pytest tests/test_governance_parity.py tests/test_spec_adapter_contract_conformance.py without || true. This enforces these specific checks while leaving other broad test suites unchanged. Ensure branch protection requires this step.
TroubleshootingWhy does agent-hypervisor RingEnforcer check_command allow denied commands prefixed with a variable assignment or wrapper like env, nohup, or exec (e.g. FOO=x curl)?
Root cause: RingEnforcer.check_command only tests the first word of the command string against DENIED_COMMANDS, so a leading NAME=value assignment or a wrapper (env, exec, nohup, nice, timeout, stdbuf, time, command, builtin) is mistaken for the executable and the real denied command (e.g. curl) is reported as allowed=True. Fix: update agent-hypervisor to the build containing the follow-up patch for issue #4331, which (1) skips leading NAME=value assignments quote-aware, (2) unwraps wrapper commands by parsing their options, and (3) fails closed (denies the command) when a wrapper's options cannot be parsed — unknown option, missing option argument, or env -S. Until patched, callers should not rely on check_command alone: normalize or reject commands containing assignment prefixes/wrappers before invoking it. Note: line-continuation obfuscation (cu\<newline>rl) remains a known separate gap.
TroubleshootingWhy does my agent fail with 'runtime_error:intervention_point_unknown' on its first tool call when using the example policy manifests?
The manifest's intervention_points block doesn't bind pre_tool_call, which 16 of the 19 built-in adapters evaluate (all except a2a, guardrails, and llamaindex). The engine deliberately denies unbound intervention points with runtime_error:intervention_point_unknown, so the agent is blocked on its first tool call. This affects the manifests in examples/policies/african-regulatory/* (15 files), examples/policies/india-regulatory/* (5), examples/policies/production/* (5), examples/policies/lotl_prevention_policy.yaml, and most of examples/policy-templates/*, because they bind only input/output. Workaround: explicitly bind every intervention point your adapter evaluates — add pre_tool_call (and post_tool_call) entries to the manifest's intervention_points with deny/allow semantics matching the policy pack's intent (applying regulatory pattern rules at tool-call points is also the safer direction). You can copy the binding pattern from the manifests fixed in PR #3528 (the crewai, maf, openai-agents, and smolagents examples).