{"owner":"microsoft","repo":"agent-governance-toolkit","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Agent Governance Toolkit - Repository Instructions\n\n## Project Overview\n\nAgent Governance Toolkit is a multi-package OSS monorepo for runtime governance of AI agents:\npolicy enforcement, zero-trust identity, execution sandboxing, SRE, compliance, examples,\ndocs, demos, SDKs, and publishing pipelines.\n\nUse this file for repository-wide routing. When you enter a subdirectory that has its own\n`AGENTS.md`, that narrower file takes precedence.\n\n## Repository Layout Status\n\nThis routing reflects the repo **as it exists today** while reserving room for approved language\nSDK migrations. Language SDKs may live in **standalone top-level directories** at the repository\nroot. For contributor routing, treat `agent-governance-dotnet/`, `agent-governance-golang/`, and\n`agent-governance-rust/` as the canonical standalone language homes.\n\nTreat current paths as a **point-in-time representation**, not a permanent architecture promise.\nWhen a standalone top-level implementation exists for a language, changes for that language should\ngo there rather than into the repo root or an older shared SDK path.\n\n## Where Changes Belong\n\n| Area | Path | Use it for |\n|------|------|------------|\n| Published Python packages | `agent-governance-python/` | First-party reusable Python packages and SDK surfaces meant for direct external consumption |\n| Python runtime and product code | `*/` | Runtime code, applications, policy engines, trust, SRE, compliance, and other Python product surfaces that have not moved into the standalone package home |\n| Current shared SDK paths | `agent-governance-python/agent-mesh/sdks/` | Public SDK APIs and language-specific packaging that still live in the shared layout today |\n| Standalone language implementations | `agent-governance-python/`, `agent-governance-dotnet/`, `agent-governance-golang/`, `agent-governance-rust/`, and other `agent-governance-*` siblings | Top-level language-specific implementations at the repository root; use these as the canonical contributor-facing paths |\n| Docs site | `docs/` | Reference docs, tutorials, architecture, package pages |\n| Runnable examples | `examples/` | Self-contained integrations and worked examples |\n| Interactive demos | `examples/demos/` | Live demos, dashboards, real-service walkthroughs |\n| Release automation | `.github/workflows/` | GitHub Actions release, packaging, SBOM, provenance, and publishing automation |\n| GitHub automation | `.github/` | CI, PR automation, issue templates, policy workflows |\n\n## Routing Rules\n\n1. Prefer the smallest correct scope for a change.\n2. Put third-party integrations in `examples/` or `agent-governance-python/agentmesh-integrations/` before\n   expanding core packages.\n3. Put marketing or ecosystem references in docs only after the integration is real, attributable,\n   and useful to users.\n4. Keep `.github/` changes separate from feature work; they require extra security review.\n5. If both a legacy shared path and a standalone top-level path exist, prefer the standalone\n   top-level path for new work unless maintainers say otherwise. For Python package work, use\n   `agent-governance-python/` as the canonical package home. For the approved .NET standalone\n   migration, contributor guidance should point to `agent-governance-dotnet/` as the canonical\n   path.\n\n## OSS Contribution Expectations\n\n- Read the nearest `AGENTS.md` before changing code in that area.\n- Keep PRs scoped to the path described in the PR.\n- Add or update tests for behavior changes, bug fixes, security fixes, and new public API surface.\n- Attribute prior art in PR descriptions and docs when a design borrows from another project.\n- Prefer examples and docs for low-risk ecosystem additions; prefer core package changes only when\n  the project has clear adoption and the integration belongs in AGT long-term.\n- Do not add obscure dependencies to core paths just to support a single external project.\n\n## Decision Escalation\n\nAsk a maintainer before proceeding with:\n\n- new top-level packages or modules\n- cross-cutting changes across 3+ packages\n- security model changes\n- public breaking API changes\n- new framework integrations that materially expand the core surface\n- CI/CD architecture changes\n\n## Boundaries\n\n- Never commit secrets, credentials, or real tokens.\n- Never weaken security defaults, trust thresholds, or review requirements.\n- Do not mix unrelated changes into docs-only or example-only PRs.\n- Preserve honesty in docs: document shipped behavior, not aspirational behavior.\n\n## Spam / SEO Outreach Filtering\n\nClose or ignore PRs, issues, and discussions that are thinly disguised product placements or\nSEO link-building attempts. Common patterns:\n\n- Offers of \"paid collaboration\" to insert a product mention into docs, README, or blog posts\n- PRs that add a product/service link to a resources or ecosystem list with no real integration\n- Issues framed as feature requests that are actually product placements (\"Add support for X\")\n- Generic flattery about the project followed by a pitch to include an unrelated tool\n- No code contribution, no tests, no integration — just a link or brand mention\n\nAction: close with a short note (\"We don't accept sponsored content or paid placements\") or\nclose without comment. Do not modify repo content to accommodate these requests.\n\n## Version Bumps\n\nWhen bumping the monorepo version (e.g. `3.2.0` → `3.2.1`):\n\n- **DO** bump version strings in: `pyproject.toml`, `package.json`, `Cargo.toml`, `*.csproj`,\n  `__init__.py`, and `README.md` banner.\n- **DO NOT** bulk-replace version strings inside `package-lock.json` — transitive dependencies\n  may share the same version number (e.g. `import-local@3.2.0`, `istanbul-reports@3.2.0`) and\n  will get corrupted into non-existent versions. Instead, bump only `package.json`, then\n  regenerate the lockfile with `npm install --legacy-peer-deps`.\n- **DO NOT** bulk-replace inside `CHANGELOG.md` or `RELEASE_NOTES_*.md` — those are historical.\n- After bumping, verify with: `Select-String -Path package-lock.json -Pattern '\"<new-version>\"'`\n  and confirm only the SDK's own entries appear, not transitive deps.\n\n## PR Hygiene\n\nBefore opening a PR:\n\n- fix the PR title so it is semantic and consistently formatted\n- ensure commits satisfy DCO/signoff requirements\n- run the relevant docs link checks for changed docs\n- treat expected 403-prone external links as markdown-link-check exceptions, not flaky failures\n- fix spell-check issues on changed lines before requesting review\n\n## Validation\n\n- Run the narrowest existing tests for the paths you touched.\n- For bug fixes, prefer a regression test that would fail without the change.\n- For docs-only changes, make sure links, commands, and file paths are still correct.\n- For SDK changes, verify language-specific build and test commands in the scoped instructions.\n\n## PR Hygiene\n\n- Before opening a PR, proactively check the expected repository gates instead of waiting for CI feedback.\n- Use a semantic PR title in lowercase conventional-commit style such as `docs: ...`, `fix: ...`, or `feat: ...`.\n- Ensure commits are DCO-compliant by including a signoff (`git commit -s`).\n- For docs PRs, run `python scripts/docs/check_links.py` and `python scripts/docs/check_frontmatter.py` locally first.\n- Avoid markdown links to external sites that return `403` to automated link checkers. When an external source must be cited but the host blocks bots, prefer plain-text or code-formatted URLs in docs and put clickable links in the PR description instead.\n"},"files":{"AGENTS.md":"# Agent Governance Toolkit - Repository Instructions\n\n## Project Overview\n\nAgent Governance Toolkit is a multi-package OSS monorepo for runtime governance of AI agents:\npolicy enforcement, zero-trust identity, execution sandboxing, SRE, compliance, examples,\ndocs, demos, SDKs, and publishing pipelines.\n\nUse this file for repository-wide routing. When you enter a subdirectory that has its own\n`AGENTS.md`, that narrower file takes precedence.\n\n## Repository Layout Status\n\nThis routing reflects the repo **as it exists today** while reserving room for approved language\nSDK migrations. Language SDKs may live in **standalone top-level directories** at the repository\nroot. For contributor routing, treat `agent-governance-dotnet/`, `agent-governance-golang/`, and\n`agent-governance-rust/` as the canonical standalone language homes.\n\nTreat current paths as a **point-in-time representation**, not a permanent architecture promise.\nWhen a standalone top-level implementation exists for a language, changes for that language should\ngo there rather than into the repo root or an older shared SDK path.\n\n## Where Changes Belong\n\n| Area | Path | Use it for |\n|------|------|------------|\n| Published Python packages | `agent-governance-python/` | First-party reusable Python packages and SDK surfaces meant for direct external consumption |\n| Python runtime and product code | `*/` | Runtime code, applications, policy engines, trust, SRE, compliance, and other Python product surfaces that have not moved into the standalone package home |\n| Current shared SDK paths | `agent-governance-python/agent-mesh/sdks/` | Public SDK APIs and language-specific packaging that still live in the shared layout today |\n| Standalone language implementations | `agent-governance-python/`, `agent-governance-dotnet/`, `agent-governance-golang/`, `agent-governance-rust/`, and other `agent-governance-*` siblings | Top-level language-specific implementations at the repository root; use these as the canonical contributor-facing paths |\n| Docs site | `docs/` | Reference docs, tutorials, architecture, package pages |\n| Runnable examples | `examples/` | Self-contained integrations and worked examples |\n| Interactive demos | `examples/demos/` | Live demos, dashboards, real-service walkthroughs |\n| Release automation | `.github/workflows/` | GitHub Actions release, packaging, SBOM, provenance, and publishing automation |\n| GitHub automation | `.github/` | CI, PR automation, issue templates, policy workflows |\n\n## Routing Rules\n\n1. Prefer the smallest correct scope for a change.\n2. Put third-party integrations in `examples/` or `agent-governance-python/agentmesh-integrations/` before\n   expanding core packages.\n3. Put marketing or ecosystem references in docs only after the integration is real, attributable,\n   and useful to users.\n4. Keep `.github/` changes separate from feature work; they require extra security review.\n5. If both a legacy shared path and a standalone top-level path exist, prefer the standalone\n   top-level path for new work unless maintainers say otherwise. For Python package work, use\n   `agent-governance-python/` as the canonical package home. For the approved .NET standalone\n   migration, contributor guidance should point to `agent-governance-dotnet/` as the canonical\n   path.\n\n## OSS Contribution Expectations\n\n- Read the nearest `AGENTS.md` before changing code in that area.\n- Keep PRs scoped to the path described in the PR.\n- Add or update tests for behavior changes, bug fixes, security fixes, and new public API surface.\n- Attribute prior art in PR descriptions and docs when a design borrows from another project.\n- Prefer examples and docs for low-risk ecosystem additions; prefer core package changes only when\n  the project has clear adoption and the integration belongs in AGT long-term.\n- Do not add obscure dependencies to core paths just to support a single external project.\n\n## Decision Escalation\n\nAsk a maintainer before proceeding with:\n\n- new top-level packages or modules\n- cross-cutting changes across 3+ packages\n- security model changes\n- public breaking API changes\n- new framework integrations that materially expand the core surface\n- CI/CD architecture changes\n\n## Boundaries\n\n- Never commit secrets, credentials, or real tokens.\n- Never weaken security defaults, trust thresholds, or review requirements.\n- Do not mix unrelated changes into docs-only or example-only PRs.\n- Preserve honesty in docs: document shipped behavior, not aspirational behavior.\n\n## Spam / SEO Outreach Filtering\n\nClose or ignore PRs, issues, and discussions that are thinly disguised product placements or\nSEO link-building attempts. Common patterns:\n\n- Offers of \"paid collaboration\" to insert a product mention into docs, README, or blog posts\n- PRs that add a product/service link to a resources or ecosystem list with no real integration\n- Issues framed as feature requests that are actually product placements (\"Add support for X\")\n- Generic flattery about the project followed by a pitch to include an unrelated tool\n- No code contribution, no tests, no integration — just a link or brand mention\n\nAction: close with a short note (\"We don't accept sponsored content or paid placements\") or\nclose without comment. Do not modify repo content to accommodate these requests.\n\n## Version Bumps\n\nWhen bumping the monorepo version (e.g. `3.2.0` → `3.2.1`):\n\n- **DO** bump version strings in: `pyproject.toml`, `package.json`, `Cargo.toml`, `*.csproj`,\n  `__init__.py`, and `README.md` banner.\n- **DO NOT** bulk-replace version strings inside `package-lock.json` — transitive dependencies\n  may share the same version number (e.g. `import-local@3.2.0`, `istanbul-reports@3.2.0`) and\n  will get corrupted into non-existent versions. Instead, bump only `package.json`, then\n  regenerate the lockfile with `npm install --legacy-peer-deps`.\n- **DO NOT** bulk-replace inside `CHANGELOG.md` or `RELEASE_NOTES_*.md` — those are historical.\n- After bumping, verify with: `Select-String -Path package-lock.json -Pattern '\"<new-version>\"'`\n  and confirm only the SDK's own entries appear, not transitive deps.\n\n## PR Hygiene\n\nBefore opening a PR:\n\n- fix the PR title so it is semantic and consistently formatted\n- ensure commits satisfy DCO/signoff requirements\n- run the relevant docs link checks for changed docs\n- treat expected 403-prone external links as markdown-link-check exceptions, not flaky failures\n- fix spell-check issues on changed lines before requesting review\n\n## Validation\n\n- Run the narrowest existing tests for the paths you touched.\n- For bug fixes, prefer a regression test that would fail without the change.\n- For docs-only changes, make sure links, commands, and file paths are still correct.\n- For SDK changes, verify language-specific build and test commands in the scoped instructions.\n\n## PR Hygiene\n\n- Before opening a PR, proactively check the expected repository gates instead of waiting for CI feedback.\n- Use a semantic PR title in lowercase conventional-commit style such as `docs: ...`, `fix: ...`, or `feat: ...`.\n- Ensure commits are DCO-compliant by including a signoff (`git commit -s`).\n- For docs PRs, run `python scripts/docs/check_links.py` and `python scripts/docs/check_frontmatter.py` locally first.\n- Avoid markdown links to external sites that return `403` to automated link checkers. When an external source must be cited but the host blocks bots, prefer plain-text or code-formatted URLs in docs and put clickable links in the PR description instead.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Agent Governance Toolkit - Repository Instructions\n\n## Project Overview\n\nAgent Governance Toolkit is a multi-package OSS monorepo for runtime governance of AI agents:\npolicy enforcement, zero-trust identity, execution sandboxing, SRE, compliance, examples,\ndocs, demos, SDKs, and publishing pipelines.\n\nUse this file for repository-wide routing. When you enter a subdirectory that has its own\n`AGENTS.md`, that narrower file takes precedence.\n\n## Repository Layout Status\n\nThis routing reflects the repo **as it exists today** while reserving room for approved language\nSDK migrations. Language SDKs may live in **standalone top-level directories** at the repository\nroot. For contributor routing, treat `agent-governance-dotnet/`, `agent-governance-golang/`, and\n`agent-governance-rust/` as the canonical standalone language homes.\n\nTreat current paths as a **point-in-time representation**, not a permanent architecture promise.\nWhen a standalone top-level implementation exists for a language, changes for that language should\ngo there rather than into the repo root or an older shared SDK path.\n\n## Where Changes Belong\n\n| Area | Path | Use it for |\n|------|------|------------|\n| Published Python packages | `agent-governance-python/` | First-party reusable Python packages and SDK surfaces meant for direct external consumption |\n| Python runtime and product code | `*/` | Runtime code, applications, policy engines, trust, SRE, compliance, and other Python product surfaces that have not moved into the standalone package home |\n| Current shared SDK paths | `agent-governance-python/agent-mesh/sdks/` | Public SDK APIs and language-specific packaging that still live in the shared layout today |\n| Standalone language implementations | `agent-governance-python/`, `agent-governance-dotnet/`, `agent-governance-golang/`, `agent-governance-rust/`, and other `agent-governance-*` siblings | Top-level language-specific implementations at the repository root; use these as the canonical contributor-facing paths |\n| Docs site | `docs/` | Reference docs, tutorials, architecture, package pages |\n| Runnable examples | `examples/` | Self-contained integrations and worked examples |\n| Interactive demos | `examples/demos/` | Live demos, dashboards, real-service walkthroughs |\n| Release automation | `.github/workflows/` | GitHub Actions release, packaging, SBOM, provenance, and publishing automation |\n| GitHub automation | `.github/` | CI, PR automation, issue templates, policy workflows |\n\n## Routing Rules\n\n1. Prefer the smallest correct scope for a change.\n2. Put third-party integrations in `examples/` or `agent-governance-python/agentmesh-integrations/` before\n   expanding core packages.\n3. Put marketing or ecosystem references in docs only after the integration is real, attributable,\n   and useful to users.\n4. Keep `.github/` changes separate from feature work; they require extra security review.\n5. If both a legacy shared path and a standalone top-level path exist, prefer the standalone\n   top-level path for new work unless maintainers say otherwise. For Python package work, use\n   `agent-governance-python/` as the canonical package home. For the approved .NET standalone\n   migration, contributor guidance should point to `agent-governance-dotnet/` as the canonical\n   path.\n\n## OSS Contribution Expectations\n\n- Read the nearest `AGENTS.md` before changing code in that area.\n- Keep PRs scoped to the path described in the PR.\n- Add or update tests for behavior changes, bug fixes, security fixes, and new public API surface.\n- Attribute prior art in PR descriptions and docs when a design borrows from another project.\n- Prefer examples and docs for low-risk ecosystem additions; prefer core package changes only when\n  the project has clear adoption and the integration belongs in AGT long-term.\n- Do not add obscure dependencies to core paths just to support a single external project.\n\n## Decision Escalation\n\nAsk a maintainer before proceeding with:\n\n- new top-level packages or modules\n- cross-cutting changes across 3+ packages\n- security model changes\n- public breaking API changes\n- new framework integrations that materially expand the core surface\n- CI/CD architecture changes\n\n## Boundaries\n\n- Never commit secrets, credentials, or real tokens.\n- Never weaken security defaults, trust thresholds, or review requirements.\n- Do not mix unrelated changes into docs-only or example-only PRs.\n- Preserve honesty in docs: document shipped behavior, not aspirational behavior.\n\n## Spam / SEO Outreach Filtering\n\nClose or ignore PRs, issues, and discussions that are thinly disguised product placements or\nSEO link-building attempts. Common patterns:\n\n- Offers of \"paid collaboration\" to insert a product mention into docs, README, or blog posts\n- PRs that add a product/service link to a resources or ecosystem list with no real integration\n- Issues framed as feature requests that are actually product placements (\"Add support for X\")\n- Generic flattery about the project followed by a pitch to include an unrelated tool\n- No code contribution, no tests, no integration — just a link or brand mention\n\nAction: close with a short note (\"We don't accept sponsored content or paid placements\") or\nclose without comment. Do not modify repo content to accommodate these requests.\n\n## Version Bumps\n\nWhen bumping the monorepo version (e.g. `3.2.0` → `3.2.1`):\n\n- **DO** bump version strings in: `pyproject.toml`, `package.json`, `Cargo.toml`, `*.csproj`,\n  `__init__.py`, and `README.md` banner.\n- **DO NOT** bulk-replace version strings inside `package-lock.json` — transitive dependencies\n  may share the same version number (e.g. `import-local@3.2.0`, `istanbul-reports@3.2.0`) and\n  will get corrupted into non-existent versions. Instead, bump only `package.json`, then\n  regenerate the lockfile with `npm install --legacy-peer-deps`.\n- **DO NOT** bulk-replace inside `CHANGELOG.md` or `RELEASE_NOTES_*.md` — those are historical.\n- After bumping, verify with: `Select-String -Path package-lock.json -Pattern '\"<new-version>\"'`\n  and confirm only the SDK's own entries appear, not transitive deps.\n\n## PR Hygiene\n\nBefore opening a PR:\n\n- fix the PR title so it is semantic and consistently formatted\n- ensure commits satisfy DCO/signoff requirements\n- run the relevant docs link checks for changed docs\n- treat expected 403-prone external links as markdown-link-check exceptions, not flaky failures\n- fix spell-check issues on changed lines before requesting review\n\n## Validation\n\n- Run the narrowest existing tests for the paths you touched.\n- For bug fixes, prefer a regression test that would fail without the change.\n- For docs-only changes, make sure links, commands, and file paths are still correct.\n- For SDK changes, verify language-specific build and test commands in the scoped instructions.\n\n## PR Hygiene\n\n- Before opening a PR, proactively check the expected repository gates instead of waiting for CI feedback.\n- Use a semantic PR title in lowercase conventional-commit style such as `docs: ...`, `fix: ...`, or `feat: ...`.\n- Ensure commits are DCO-compliant by including a signoff (`git commit -s`).\n- For docs PRs, run `python scripts/docs/check_links.py` and `python scripts/docs/check_frontmatter.py` locally first.\n- Avoid markdown links to external sites that return `403` to automated link checkers. When an external source must be cited but the host blocks bots, prefer plain-text or code-formatted URLs in docs and put clickable links in the PR description instead.\n","category":"root","tokens":1881}]}