[Project Proposal] Agent Governance Toolkit

[imran-siddique]

Project Name

Agent Governance Toolkit

Project Description

The Agent Governance Toolkit is an open-source, multi-language runtime governance framework for autonomous AI agents, developed by Microsoft and released under the MIT license.

Core scope: policy enforcement and runtime governance. The toolkit provides a deterministic policy engine that sits between agents and their tools, intercepting actions and enforcing organizational policies before execution. It is designed to prevent bypass under defined threat models by operating externally to the agent, at the kernel level rather than through prompt-level input/output filtering.

Development began in late January 2026 as public open source repositories, then consolidated into microsoft/agent-governance-toolkit in March 2026 to address the gap between AI agent frameworks (which enable tool calling, sub-agent spawning, and real-world actions) and the absence of comprehensive runtime security models. Released under the MIT license.

Core architecture (2 packages):

• Agent OS Kernel (agent_os_kernel): Policy engine, capability model, audit logging, and tool-call interception. This is the governance core.
• AgentMesh (agentmesh_platform): Inter-agent trust layer with Ed25519 DID identity, trust scoring (0-1000), and protocol bridges for MCP and A2A.

Optional extension packages (not part of the core governance scope):

• Agent Runtime (agentmesh_runtime): Execution isolation with privilege rings, kill switch, and fault attribution
• Agent SRE (agent_sre): Reliability engineering with SLO engine, error budgets, chaos testing
• Agent Compliance (agent_governance_toolkit): OWASP Agentic Top 10 mapping, regulatory framework mappings
• Agent Lightning (agentmesh_lightning): High-performance agent execution with governance guardrails
• Agent Marketplace (agentmesh_marketplace): Discovery and trust-verified agent registry

Multi-language SDK support: Python, TypeScript/.NET (NuGet), Rust (crate), Go module.

What the toolkit does NOT standardize:

• Agent framework design or orchestration patterns
• Prompt-level guardrails or content filtering
• Communication protocols (that is MCP's domain)
• Agent capability declarations (that is AGENTS.md's domain)
• Network-layer security (that is Envoy AI Gateway's domain)

The toolkit maps to the OWASP Agentic Security Initiative (ASI) Top 10 risks. Coverage is strongest in policy enforcement (ASI-01, ASI-02, ASI-09, ASI-10) and identity (ASI-03). Other risks have varying levels of coverage:

Risk	ID	Component	Coverage
Agent Hijacking	ASI-01	Policy Engine: blocked patterns, content safety	✅ Strong
Tool Misuse	ASI-02	Capability Sandbox: tool allow/deny, rate limits	✅ Strong
Insecure Identity	ASI-03	AgentMesh: DID identity, IATP, SPIFFE certs	✅ Strong
Supply Chain	ASI-04	SBOM generation, Sigstore signing, build provenance	⚠️ Partial
Insecure Output	ASI-05	Runtime: execution rings, output validation	⚠️ Partial
Memory Poisoning	ASI-06	VFS + CMVK (content-addressable memory)	⚠️ Partial
Insufficient Monitoring	ASI-07	Agent SRE: SLOs, OTel export, anomaly detection	✅ Strong
Error Handling	ASI-08	Circuit breakers, saga compensation, error budgets	✅ Strong
HITL Bypass	ASI-09	Approval workflows, human-in-the-loop gates	✅ Strong
Uncontrolled Autonomy	ASI-10	Kill switch, resource limits, goal drift detection	✅ Strong

Framework integrations: Microsoft Agent Framework (native middleware), LangChain, CrewAI, Google ADK (proposed), OpenAI Agents SDK, Mastra, MCP (Model Context Protocol), A2A Protocol, Semantic Kernel, AutoGen. 12+ integrations total.

Current version: v3.4.0 (Public Preview).

Alignment with AAIF Mission

The Agent Governance Toolkit advances the AAIF mission of fostering interoperable, open standards for agentic AI by providing the governance enforcement layer that complements AAIF's protocol and framework projects:

1. Complements MCP: MCP defines how agents communicate with tools. The Agent Governance Toolkit ensures agents operate within policy boundaries when using those tools. The toolkit includes a full MCP Kernel Server (published on npm and the Glama MCP registry) for governance operations.

2. Complements AGENTS.md: AGENTS.md describes agent capabilities. The toolkit's capability model enforces what agents are actually allowed to do at runtime, making AGENTS.md declarations enforceable rather than advisory.

3. Complements Goose: Goose provides an open-source agent framework. The Agent Governance Toolkit provides the governance layer that makes Goose agents safe for enterprise deployment, with pre-built integration patterns.

4. Framework-neutral governance: The toolkit works with Microsoft, Google, OpenAI, Anthropic, and open-source agent frameworks. It does not compete with any framework; it governs all of them.

5. MCP-native architecture: The governance kernel exposes all governance operations (policy validation, trust verification, compliance checks) as MCP tools, making governance composable with any MCP-compatible agent.

6. Standards alignment: Active submissions and integrations with OWASP ASI, CoSAI/OASIS WS4, LF AI and Data, Oracle Agent Spec, demonstrating commitment to the open standards ecosystem.

Relation to Existing AAIF Projects

• MCP (Anthropic): MCP is the protocol layer; AGT is the governance layer that operates over MCP. The toolkit has a production MCP Kernel Server (agentos-mcp-server on npm, also on the Glama MCP registry) implementing governance tools, resources, and prompts. MCP defines the transport; AGT defines what policies are checked before tool execution proceeds.

• Goose (Block): Goose provides the agent runtime; AGT provides the guardrails. Goose agents connecting to MCP servers or LLMs can route through the Agent OS governance kernel to gain policy enforcement, trust verification, and audit logging. The projects are architecturally complementary.

• AGENTS.md (OpenAI): AGENTS.md defines agent capability declarations. The toolkit's capability sandbox can read AGENTS.md declarations and enforce them at runtime, bridging the gap between "what an agent says it can do" and "what an agent is allowed to do."

• Envoy AI Gateway: Envoy handles network-layer concerns (routing, rate limiting, authentication at the gateway). AGT handles application-layer concerns (policy enforcement, trust verification, compliance at the agent level). Both are needed for defense in depth, operating at different layers of the stack.

Boundary table: what AGT is and is not

	AGT	OPA/Rego	MCP	PIC / Agent Spec	Envoy AI Gateway
Layer	Application (agent runtime)	Application (general policy)	Protocol (transport)	Specification (declaration)	Network (gateway)
Focus	Agent-specific governance	General-purpose policy	Tool communication	Agent capability description	Request routing/auth
Overlap	Uses OPA as one policy backend	Could evaluate AGT policies	AGT operates over MCP	AGT enforces declared caps	Complementary layers
AGT does NOT replace	—	General-purpose OPA use cases	Protocol definition	Spec authoring	Network security

Example Use Cases and Evidence of Adoption

Use cases:

1. Enterprise AI Platform Teams: Platform engineers deploy AGT as governance middleware alongside agent workloads, enforcing organization-wide policies (data access controls, PII handling, budget limits) without modifying agent code.
2. Multi-Agent Orchestration: Teams running multi-agent workflows use AgentMesh's trust scoring and DID identity to ensure only verified agents can delegate tasks, with audit trails for accountability.
3. Regulatory Compliance: Financial services and healthcare teams use the compliance package to generate automated evidence for OWASP ASI and EU AI Act requirements.

Evidence of adoption:

• 1,433 GitHub stars, 273 forks on microsoft/agent-governance-toolkit
• 52,949 git clones and 23,129 page views in 14 days (May 2026)
• 214,000+ monthly PyPI downloads across 42 published packages
• 9 npm packages published (@microsoft scope)
• 3 NuGet packages (Microsoft.AgentGovernance.*)
• 2 Rust crates (agentmesh, agent-governance)
• 76 contributors across multiple organizations
• Accepted into awesome-copilot (32,290 stars): 3 PRs merged
• Active proposals with OWASP ASI, CoSAI/OASIS WS4, LF AI and Data Foundation, Oracle Agent Spec
• Integration merged with OpenLit observability platform and Dify platform
• OpenSSF Best Practices badge (100% passing)
• OpenSSF Scorecard: active monitoring with ClusterFuzzLite fuzzing
• Microsoft-signed releases via trusted publishing with SLSA build provenance
• Traffic referrers include GitHub, Google, LinkedIn, YouTube, Microsoft Teams, devblogs.microsoft.com, and Bing

Technical Committee Sponsor (if identified)

Not yet identified. We are actively seeking a TC sponsor and welcome introductions. We believe the project's scope (runtime governance for agents) is complementary to existing AAIF projects and would benefit from TC mentorship on positioning within the AAIF ecosystem.

GitHub Repository URL

https://github.com/microsoft/agent-governance-toolkit

License

MIT

Governance Model

The project follows an open governance model with formal foundation-ready governance artifacts:

• Technical Charter: CHARTER.md — LF Projects Technical Charter defining TSC structure, voting rules (50% quorum, majority vote), IP policy (MIT + DCO), and amendment process (2/3 TSC vote)
• Code of Conduct: Microsoft Open Source Code of Conduct (based on Contributor Covenant)
• CLA + DCO: Microsoft CLA required for all contributions (automated via CLA bot), plus Developer Certificate of Origin sign-off enforced via CI
• Contributing: CONTRIBUTING.md with clear routing guide for monorepo structure and DCO sign-off instructions
• Security: SECURITY.md following Microsoft's coordinated vulnerability disclosure (90-day timeline)
• Release Process: RELEASE.md documenting versioning, cadence, supported registries, automated publishing, and supply chain security
• Branch Protection: GitHub branch protection with required reviews, status checks, and squash-only merges
• Decision-making: Major changes discussed via GitHub Issues/Discussions; PRs require review from maintainers
• GOVERNANCE.md: https://github.com/microsoft/agent-governance-toolkit/blob/main/GOVERNANCE.md — formalizes decision-making process, maintainer roles, and contributor ladder
• Code ownership: CODEOWNERS — automated review routing mapped to package maintainers

Multi-organization maintainer structure:

The project has 6 maintainers from 4 organizations (see MAINTAINERS.md):

Maintainer	Organization	Role	Area
Imran Siddique	Microsoft	Project Lead	Architecture, Python SDK
Jack Batzner	Microsoft	Maintainer	.NET SDK, CI/CD, docs
Elton Carr	Microsoft	Maintainer	CI workflows, security tooling
Andrew Lee Rubinger	Aileron	Maintainer	Governance patterns, enterprise adoption
Kevin Knapp	MythologIQ	Maintainer	Agent runtime, trust models
Nishar Miya	Dayos	Maintainer	Integrations, community

Governance transition plan:

1. Completed: GOVERNANCE.md, MAINTAINERS.md, CODEOWNERS, CHARTER.md, RELEASE.md published
2. Completed: DCO enforcement via GitHub Actions CI check
3. Completed: Multi-org maintainers recruited (4 organizations represented)
4. In progress: Growing non-Microsoft commit history and active maintainer engagement
5. Upon AAIF acceptance: Transition to DCO-only (remove Microsoft CLA requirement)
6. Ongoing: All maintainer nominations require demonstrated sustained contribution (3+ merged PRs, active issue triage, or documentation contributions over 2+ months)

CI/CD & Release Workflow

Comprehensive CI/CD via GitHub Actions (33 workflows):

• CI Pipeline (ci.yml): lint (7 jobs), test (18-job matrix across packages and Python versions), build (PyPI, npm, NuGet, Rust, Go, containers), security scan. Runs on every PR and push to main.
• CodeQL: SAST scanning for Python, JavaScript, C#, and Go, weekly + on PR.
• Policy Validation: Automated YAML policy syntax and schema validation.
• ClusterFuzzLite: Continuous fuzzing with 3 fuzz targets (policy parsing, condition evaluation, input validation). PR fuzzing (5 min) + weekly batch fuzzing (30 min).
• Supply Chain: Dependency review, secret scanning (Gitleaks + detect-secrets), BinSkim binary analysis, weekly security audit of all workflow files.
• OpenSSF Scorecard: Weekly scorecard assessment with SARIF upload.
• DCO Check: Developer Certificate of Origin sign-off verification on all PR commits.
• Quality Gates: Spell check, link check, workflow-lint (actionlint + shellcheck), code quality analysis.
• Publishing: PyPI via trusted publishing with SLSA build provenance attestation. Container images to GHCR.
• Release cadence: Semantic versioning. Current: v3.4.0. Releases on demand, approximately every 2-4 weeks during active development.

Public-Facing Contribution Process for Specifications

• CONTRIBUTING.md: https://github.com/microsoft/agent-governance-toolkit/blob/main/CONTRIBUTING.md
• Repository routing guide for monorepo (agent-governance-python/, agent-governance-typescript/, agent-governance-dotnet/, agent-governance-rust/, agent-governance-go/, docs/, examples/)
• Pull requests require CLA sign-off via Microsoft CLA bot AND DCO sign-off (Signed-off-by trailer)
• All PRs must pass CI (lint, test, security scan, DCO check) before merge
• Feature proposals via GitHub Issues with labels (enhancement, standards, community)
• Community engagement via GitHub Discussions
• 45+ tutorials in docs/tutorials/ covering all toolkit capabilities
• Architecture Decision Records (ADRs) for major technical decisions

Publicly Accessible Issue Tracker

https://github.com/microsoft/agent-governance-toolkit/issues

Currently 20+ open issues. 1,700+ issues and PRs closed historically.

External Project Dependencies

All dependencies are under permissive open-source licenses (MIT, Apache 2.0, BSD):

• Python: pydantic (MIT), cryptography (Apache 2.0/BSD), pyyaml (MIT), httpx (BSD-3), fastapi (MIT), uvicorn (BSD-3), opentelemetry-api (Apache 2.0)
• TypeScript: typescript (Apache 2.0), eslint (MIT), @anthropic-ai/sdk (MIT)
• .NET: System.Security.Cryptography (MIT), Microsoft.Extensions.* (MIT)
• Rust: ed25519-dalek (BSD-3), serde (MIT/Apache 2.0), tokio (MIT)
• Go: standard library only

Maintainers & Contributors

Core maintainers:

• Imran Siddique, Microsoft, @imran-siddique (project creator and lead maintainer)
• Jack Batzner, Microsoft, @jackbatzner (maintainer, .NET SDK, CI/CD and documentation)
• Elton Carr, Microsoft, @eltoncarr-ms (maintainer, CI workflows and security tooling)
• Andrew Lee Rubinger, Aileron, @ALRubinger (maintainer, governance patterns)
• Kevin Knapp, MythologIQ, @Knapp-Kevin (maintainer, agent runtime)
• Nishar Miya, Dayos, @miyannishar (maintainer, integrations)

Multi-organization representation: 6 maintainers from 4 organizations (Microsoft, Aileron, MythologIQ, Dayos). 76 total contributors from multiple organizations. The project has a clear contributor ladder documented in GOVERNANCE.md and enforced CODEOWNERS for review routing.

Leadership Team & Decision Process

• Project lead: Imran Siddique (Group Engineering Manager, Microsoft) — overall technical direction and architecture
• TSC: All maintainers listed in MAINTAINERS.md serve as TSC voting members per the Technical Charter
• Decision-making: Consensus-based among TSC members. Major architectural decisions documented via ADRs and GitHub Issues. PRs require at least one maintainer review.
• Community input: GitHub Discussions open for all. Issue labels (enhancement, standards, community) used for triage.
• Dispute resolution: If consensus cannot be reached, project lead makes final decision with documented rationale (per GOVERNANCE.md).

Roadmap

Current: v3.4.0 (Public Preview)

Core governance scope (near-term, next 1-2 releases):

• Policy hot-reload without agent restart
• Cedar policy language GA support
• OPA/Rego integration hardening
• Multi-tenant policy isolation

Trust and identity (near-term):

• SPIFFE/SVID production deployment guide
• ML-DSA-65 (post-quantum) signing GA

Extensions and tooling (medium-term, 3-6 months):

• ISO 42001 mapping completion
• EU AI Act Annex IV automated evidence generation
• Multi-agent delegation chain verification
• Economic scope limits (budget governance)
• Agent SRE dashboard (Grafana templates)

Long-term (6-12 months):

• Open governance policy format specification (composable with OPA/Rego)
• Cross-framework governance policy portability
• Integration with cloud-native security tooling (Falco, SPIFFE)
• Formal verification of policy engine

Full roadmap: https://github.com/microsoft/agent-governance-toolkit/blob/main/docs/ROADMAP.md

Security

• OpenSSF Best Practices badge: 99% (project #12085) — https://www.bestpractices.dev/projects/12085
• OpenSSF Scorecard: actively monitored with weekly runs
• ClusterFuzzLite: continuous fuzzing with 3 fuzz targets
• CodeQL SAST: Python, JavaScript, C#, Go — weekly + on PR
• BinSkim: binary analysis for .NET assemblies
• Coordinated vulnerability disclosure: SECURITY.md, secure@microsoft.com, 90-day disclosure timeline
• Published security advisories: CostGuard kill switch bypass (fixed v2.1.0), thread safety fixes (fixed v2.1.0)
• Dependency scanning: Dependabot + Gitleaks + detect-secrets
• Supply chain: SLSA build provenance attestation via actions/attest-build-provenance
• Container images: pinned by SHA256 digest in all CI workflows and Dockerfiles
• Weekly security audit: Automated workflow scanning all CI files for expression injection, credential exposure, and unsafe patterns
• Trust boundaries and limitations: The policy engine enforces governance for agent-to-tool calls routed through the kernel. It does not prevent agents from making direct network calls that bypass the kernel. Deployments should combine AGT with network-layer controls (e.g., Envoy AI Gateway, firewall rules) for defense in depth.

Website URL

https://microsoft.github.io/agent-governance-toolkit (documentation site)

Documented Governance Practices (if any)

• CHARTER.md: https://github.com/microsoft/agent-governance-toolkit/blob/main/CHARTER.md
• GOVERNANCE.md: https://github.com/microsoft/agent-governance-toolkit/blob/main/GOVERNANCE.md
• MAINTAINERS.md: https://github.com/microsoft/agent-governance-toolkit/blob/main/MAINTAINERS.md
• CODEOWNERS: https://github.com/microsoft/agent-governance-toolkit/blob/main/CODEOWNERS
• RELEASE.md: https://github.com/microsoft/agent-governance-toolkit/blob/main/RELEASE.md
• CONTRIBUTING.md: https://github.com/microsoft/agent-governance-toolkit/blob/main/CONTRIBUTING.md
• SECURITY.md: https://github.com/microsoft/agent-governance-toolkit/blob/main/SECURITY.md
• CODE_OF_CONDUCT.md: https://github.com/microsoft/agent-governance-toolkit/blob/main/CODE_OF_CONDUCT.md

Links to Social Media Accounts

N/A

Details of Existing Financial Sponsorship

The project is developed and maintained by Microsoft. Engineering investment comes from Microsoft's engineering organization. Infrastructure (GitHub Actions CI, container registry) is provided by GitHub/Microsoft. No external financial sponsorship.

Infrastructure Needs or Requests

• No immediate infrastructure needs. CI/CD runs on GitHub-hosted runners.
• Potential future request: shared CI resources for cross-framework integration testing.

AI-Assisted Development Disclosure

This project uses AI-assisted development tools (GitHub Copilot, Claude) for code generation, documentation, and test writing. All AI-generated code is reviewed by human maintainers before merge. The project's CONTRIBUTING.md includes an AI contribution policy requiring disclosure of AI tool usage in pull requests, and the PR template includes attestation checkboxes for AI assistance.

Additional Information

The Agent Governance Toolkit fills a specific gap in the agentic AI ecosystem: runtime policy enforcement. While MCP defines communication, AGENTS.md defines capabilities, and Goose provides an agent runtime, none address what happens when an agent attempts an action that violates organizational policy, exceeds its trust level, or drifts from its assigned goal.

Scope clarity:

• Core proposition: A policy engine and enforcement kernel for agent-to-tool governance. Think of it as "OPA for agents" — a specialized policy layer that understands agent-specific concepts (trust scores, capability models, execution rings) rather than general-purpose policy evaluation.
• Not a platform: The extension packages (SRE, marketplace, lightning) are optional components that may become separate subprojects. The core governance value is in the kernel + trust layer.
• Not a competing framework: It secures existing frameworks (Microsoft, Google, OpenAI, open-source). It does not orchestrate agents or define how they communicate.

Key differentiators from related projects:

• vs. SAFE-Framework (OpenSSF Sandbox): SAFE-Framework catalogs agentic failure modes and provides mitigation guidance. AGT provides the runtime enforcement engine that implements those mitigations. The projects are complementary.
• vs. Envoy AI Gateway: Envoy operates at the network layer (routing, rate limiting, auth). AGT operates at the application layer (policy enforcement, trust verification, compliance). Both are needed for defense in depth.
• vs. OPA/Rego: OPA is a general-purpose policy engine. AGT uses OPA as one policy backend, but adds agent-specific concepts (trust scoring, capability models, execution rings, agent identity) that OPA does not provide out of the box.
• vs. PIC / Oracle Agent Spec: PIC and Agent Spec define what agents can do (declarative specifications). AGT enforces what agents are allowed to do (runtime enforcement). We are actively collaborating with Oracle's Agent Spec team on governance control extensions (PR #174).

The project has active submissions with 4 standards bodies (OWASP ASI, CoSAI/OASIS, LF AI and Data, Oracle Agent Spec) and 12+ framework integrations, demonstrating broad ecosystem engagement.

We are open to entering at whatever stage the TC determines is appropriate.

[tomjwxf]

Endorsing this as an external contributor listed above.

The proposal's "open standards integration" claim is well substantiated and worth surfacing for the TC review:

1. The receipt format AGT integrates with via Tutorial 33 (PR #1197) is on the IETF datatracker as draft-farley-acta-signed-receipts-01, with AGT listed as Appendix A.9 conformant implementation. The runtime that signs those receipts is protect-mcp (npm, MIT, 2,000+ monthly downloads), with the matching offline verifier @veritasacta/verify (npm, Apache-2.0, 1,000+ monthly downloads), demonstrated end-to-end in the worked example I shipped at PR #1159. So the integration claim is checkable: AGT documents the format, protect-mcp signs, the IETF draft specifies the spec, the verifier runs offline against the public key, and 14+ implementations cross-verify against shared Apache-2.0 fixtures (github.com/ScopeBlind/agent governance-testvectors).

2. protect-mcp 0.6.0 (released this month) ships selective-disclosure receipts via Merkle-committed fields per RFC 6962
   construction. That's the EU AI Act Article 12 + GDPR composition primitive: a single signed receipt where specific fields can be revealed to specific auditors while other fields stay cryptographically hidden. The IETF draft specifies the construction; protect-mcp implements it; AGT's Tutorial 33 covers the basic offline-verification path with Tutorial 46 extension on selective disclosure as coming contribution.

I've also shipped a physical-attestation example (PR #1168, cold-chain sensor receipts) that extends the same primitive from software agents to hardware devices, which is unique evidence the agentic governance story works beyond the "agent calls a tool" case the proposal abstract focuses on. And 8 merged PRs (5,833 lines) into AGT, including the project's GitHub Pages docs site (PR #1186).

Strongly support Growth-stage acceptance.

[miyannishar]

+1 as both a contributor and someone running this in production.

I use AGT's policy engine and Cedar rules in a commercial AI product (can't name it: proprietary). The deny-by-default model and OWASP ASI coverage are the main reasons I picked it over rolling our own governance layer. It just works without us having to build a bunch of policy enforcement from scratch.

On the contributor side, maintainers actually review stuff quickly and give useful feedback. I've had 3 PRs merged and 2 more in review, covering everything from security tests to MCP receipt signing to IoT attestation. No complaints about the process.

Support for Growth stage.

[bastizol-wq]

One practical approach is to treat tools like untrusted inputs: validate before use.

A pattern that works for us: run a small pre-flight check on the tool/OpenAPI before the agent is allowed to call it.

ATCP (Agent Tool Control Plane) is basically that: an API-first gate that evaluates tools/APIs before your agent touches them.

curl -sS https://api.sp-ai.io/healthz

curl -sS https://api.sp-ai.io/v1/evaluate \
  -H 'Content-Type: application/json' \
  -d '{"tier":"A","artifact":{"openapi_url":"https://api.apis.guru/v2/specs/1password.com/events/1.0.0/openapi.yaml"}}'

Links (if useful): https://www.sp-ai.io/atcp/ (overview) • https://api.sp-ai.io/v1/openapi.yaml (OpenAPI)

If you want, I can share what we check first (transport/auth/host policies) and what we defer.

[kinthaiofficial]

The Agent Governance Toolkit addresses a real gap — runtime policy enforcement that agents cannot bypass. A few observations from operating agents in production:

The 4-tier privilege ring model is the right abstraction, but ring transitions need audit trails. When an agent escalates from Ring 2 to Ring 1 (e.g., to access a sensitive tool), the escalation itself must be logged with the justification chain. We found that without this, agents learn to escalate preemptively "just in case," which defeats the purpose of the ring model.

On AgentMesh trust scoring (0-1000): static trust scores decay fast. An agent that scored 900 last week might have been compromised today. We implemented trust scores with a time-decay component and behavioral anomaly detection — if an agent that normally makes 10 tool calls per session suddenly makes 200, its effective trust score drops even before any policy violation is detected. The formula effective_trust = base_trust * behavior_consistency * recency_factor captures this better than a single number.

On inter-agent identity with Ed25519 DID: this is essential. The biggest security gap in multi-agent systems today is that agents cannot verify each other. We use session-scoped HMAC tokens for intra-platform communication and Ed25519 keypairs for cross-platform identity. The key insight: identity must be per-agent, not per-platform. Two agents on the same platform should not automatically trust each other — they might have different owners, different scopes, different trust levels.

Missing from most governance frameworks: cost governance. An agent with Ring 1 privileges and no spending cap can burn through an entire API budget in minutes. We enforce per-agent per-hour spending ceilings at the gateway level, separate from capability-based access control. An agent might have permission to call GPT-4 but not permission to spend more than $5/hour on it.

We documented the multi-agent coordination and trust patterns at https://blog.kinthai.ai/221-agents-multi-agent-coordination-lessons — the section on agent isolation and per-agent cost enforcement is directly relevant to the governance kernel design.

[kinthaiofficial]

This is an important initiative. Kernel-level governance vs. prompt-level guardrails is the right distinction — we've seen prompt-level guardrails fail silently in production multi-agent systems.

From running 31 agents with governance enforcement, some patterns that complement this toolkit:

IGuardrailProvider interface for policy-based function invocation

We implemented something similar to what Semantic Kernel's guardrail interface provides — a policy layer that intercepts every tool/function call:

class GuardrailProvider:
    async def evaluate(self, call: FunctionCall, context: AgentContext) -> PolicyDecision:
        # Check: does this agent have this capability?
        if call.function_name not in context.agent.effective_capabilities:
            return PolicyDecision.DENY
        
        # Check: does the budget allow this?
        estimated_cost = self.estimate_cost(call)
        if not context.budget.can_reserve(estimated_cost):
            return PolicyDecision.DENY
        
        # Check: delegation chain valid?
        if has_cycle(context.delegation_chain):
            return PolicyDecision.DENY
            
        return PolicyDecision.ALLOW

The key is that this runs at the kernel level — the agent's LLM never sees denied operations, so it can't attempt prompt injection to bypass the guardrail.

Zero-trust identity: practical implementation

Ed25519 keypairs per agent with did:key identifiers. The critical addition: capability intersection at delegation time (child ≤ parent privileges). This prevents privilege escalation through the delegation chain.

Deterministic execution and replay for audit

For governance, you need more than logging — you need deterministic replay. We record:

1. Every external input (model responses, tool outputs, timestamps)
2. The agent's configuration snapshot at execution start
3. Ed25519 signed receipts for each pipeline component call

Given inputs (1) and config (2), you can replay the entire execution to verify the audit trail. This is essential for compliance — you can prove not just what happened, but that no other execution path was possible given the inputs.

Three-tier trust model for skills/plugins

Not all governance needs to be binary allow/deny. We use three tiers:

• Platform-verified: full capabilities, no additional approval
• Community-signed: capabilities granted after multi-party signature
• Unsigned: sandboxed execution, limited capabilities, human approval for sensitive operations

Related reading:

• 221 Agents: Multi-Agent Coordination Lessons — governance at scale with 221 agents
• OpenClaw Multi-Tenancy: Why VM-per-User Doesn't Scale — the isolation model under governance enforcement

Running this at agents.kinthai.ai on OpenClaw. Would be interested in contributing patterns to the toolkit.

[madeinplutofabio]

Brief scope-coordination note, since both this proposal and PIC Standard (#16) are open AAIF agent-governance proposals with adjacency around one risk bucket: OWASP ASI-02 tool misuse.

AGT appears to address tool misuse primarily through a capability/policy sandbox: policy-based allow/deny, capability checks, rate limits, pattern blocking, identity/trust checks, and operational governance. The core question is: does this agent have permission to call this tool, under the current policy, capability, trust, and rate context?

PIC Standard addresses tool misuse through causal verification at the action boundary: the agent emits a structured Action Proposal (intent / impact / provenance / claims / evidence / action), and the verifier fails closed unless a valid causal chain from claim -> evidence -> trusted provenance exists for the declared impact class. The core question is: is this specific call justified right now by verifiable evidence under the operator's trust roots?

A receiver can run both without conflict. AGT's capability/policy layer can decide: "can this agent call this tool at all?" PIC's verifier can decide: "is this specific call causally justified right now?"

So I read these as adjacent but composable: same general governance neighborhood, different reference points (capability/policy vs pre-execution causal verification), different primitives (policy/capability evaluation vs Action Proposal envelope + causal taint), and different standardization surfaces.

Crosswalked into 'aeoess/agent-governance-vocabulary' as PIC's pre-execution action-boundary verification surface (crosswalk/pic.yaml, merged); canonical PIC vocabulary is here for any TC reviewer doing scope review across the two proposals:

https://github.com/madeinplutofabio/pic-standard/blob/main/docs/vocabulary.md

Posted for scope coordination, not as an overlap claim. Happy to engage if a TC reviewer wants the distinction sharpened further.