Name
Imran Siddique
GitHub Handle
@imran-siddique
Tell us about yourself
I'm a Principal Group Engineering Manager at Microsoft and the creator/lead maintainer of the Agent Governance Toolkit (AGT), an open-source project (MIT, 1,450+ stars, 280+ forks, 30+ contributors) that provides governance, security, and trust primitives for AI agents. Before AGT, I spent years maintaining internal and external OSS projects at Microsoft. I want to share the real, unglamorous side of maintaining a fast-growing OSS project in the AI space: the spam, the social engineering, the CI chaos, and the tools we built to fight back.
Project Name
Agent Governance Toolkit (AGT)
Project Repo Link
https://github.com/microsoft/agent-governance-toolkit
Topic: Governing Your Own Open-Source Project: Real Maintainer War Stories from AGT
The pitch: Everyone talks about governing AI agents. Nobody talks about governing the open-source projects that build them. As AGT grew from 0 to 1,450+ stars in months, we hit every maintainer nightmare in the book, and we built actual tools and processes to deal with them. This is a talk about real problems with real examples, not theory.
What I'll cover (all factual, all from our repo):
1. Spam PRs and paid-link schemes targeting popular repos
We received issues like #1760, a Bitcoin-denominated advertising pitch ("3k sats/7-day") disguised as a feature request. Another (#1705) was a "complementary governance layer" pitch that was really a product placement for an external API. We built contributor reputation heuristics into our CI (scripts/contributor_check.py) that flag accounts with patterns like: new account + fork burst + promotional content.
2. The false-positive trap: when your anti-spam tools block real contributors
Our fork-burst heuristic flagged legitimate contributors who forked several awesome-lists to submit PRs, the only GitHub workflow available for contributing to lists you don't own. Issue #1692 forced us to recalibrate. Lesson: anti-abuse tooling needs the same governance as the code itself.
3. Security regressions hiding in plain sight
We ran our own exploit-hunter assessment against AGT and found 7 real vulnerabilities (PR #1666): a WebSocket relay with zero authentication (CVSS 9.4), a sandbox provider accepting arbitrary commands (CVSS 7.8), wildcard CORS on multiple servers (CVSS 7.6), and a plugin sandbox exposing dangerous Python builtins (CVSS 7.1). All in our own governance toolkit. If you're not red-teaming your own OSS project, nobody else is doing it for you.
4. AI-generated contributions: the new maintainer headache
We added explicit policies for AI-assisted contributions in our CONTRIBUTING.md: humans must review and understand AI-generated code, autonomous bot submissions are discouraged, and we require attribution for prior art. We've seen PRs that are clearly LLM-generated with no human review, and some that "borrow" from other projects without credit.
5. CI as a governance layer, not just a test runner
Our CI runs DCO sign-off verification, contributor reputation checks, spell checking on docs, markdown link validation, and automated security scanning, not just unit tests. When your repo gets 280+ forks, CI becomes your first line of defense against low-quality or malicious contributions. We learned this the hard way after broken benchmark paths (#1826), stale links across 50+ tutorials, and dependency bumps that silently changed behavior.
6. Building community trust signals that actually work
We created 35 "good first issues" (#1618-#1653) with size labels, clear descriptions, and explicit scope boundaries. We added an ADOPTERS.md for production users. We have a multi-language SDK (Python, .NET, TypeScript, Rust, Go) which means contributor PRs can touch any stack, so our review process has to be language-aware. Real community building is operational work, not just slapping a "contributions welcome" badge on your README.
Why this matters now:
AI agent projects are the fastest-growing category on GitHub. Every maintainer of these projects will face the exact problems we faced. The tooling and processes we built for AGT are reusable patterns any OSS maintainer can adopt.
Stream Date
not yet
Dates
Flexible on dates. Happy to work with your schedule.
Twitter URL
https://x.com/mosiddi
LinkedIn URL
https://www.linkedin.com/in/imransiddique1986/
Additional Info
I can do a live demo of our contributor_check.py catching a suspicious PR in real-time, and walk through our CI pipeline showing how each check acts as a governance layer. Happy to adjust the format to whatever works best for the show, whether that's a conversation, demo-heavy walkthrough, or a mix. Looking forward to it!
cc @kecrosby
Name
Imran Siddique
GitHub Handle
@imran-siddique
Tell us about yourself
I'm a Principal Group Engineering Manager at Microsoft and the creator/lead maintainer of the Agent Governance Toolkit (AGT), an open-source project (MIT, 1,450+ stars, 280+ forks, 30+ contributors) that provides governance, security, and trust primitives for AI agents. Before AGT, I spent years maintaining internal and external OSS projects at Microsoft. I want to share the real, unglamorous side of maintaining a fast-growing OSS project in the AI space: the spam, the social engineering, the CI chaos, and the tools we built to fight back.
Project Name
Agent Governance Toolkit (AGT)
Project Repo Link
https://github.com/microsoft/agent-governance-toolkit
Topic: Governing Your Own Open-Source Project: Real Maintainer War Stories from AGT
The pitch: Everyone talks about governing AI agents. Nobody talks about governing the open-source projects that build them. As AGT grew from 0 to 1,450+ stars in months, we hit every maintainer nightmare in the book, and we built actual tools and processes to deal with them. This is a talk about real problems with real examples, not theory.
What I'll cover (all factual, all from our repo):
1. Spam PRs and paid-link schemes targeting popular repos
We received issues like #1760, a Bitcoin-denominated advertising pitch ("3k sats/7-day") disguised as a feature request. Another (#1705) was a "complementary governance layer" pitch that was really a product placement for an external API. We built contributor reputation heuristics into our CI (scripts/contributor_check.py) that flag accounts with patterns like: new account + fork burst + promotional content.
2. The false-positive trap: when your anti-spam tools block real contributors
Our fork-burst heuristic flagged legitimate contributors who forked several awesome-lists to submit PRs, the only GitHub workflow available for contributing to lists you don't own. Issue #1692 forced us to recalibrate. Lesson: anti-abuse tooling needs the same governance as the code itself.
3. Security regressions hiding in plain sight
We ran our own exploit-hunter assessment against AGT and found 7 real vulnerabilities (PR #1666): a WebSocket relay with zero authentication (CVSS 9.4), a sandbox provider accepting arbitrary commands (CVSS 7.8), wildcard CORS on multiple servers (CVSS 7.6), and a plugin sandbox exposing dangerous Python builtins (CVSS 7.1). All in our own governance toolkit. If you're not red-teaming your own OSS project, nobody else is doing it for you.
4. AI-generated contributions: the new maintainer headache
We added explicit policies for AI-assisted contributions in our CONTRIBUTING.md: humans must review and understand AI-generated code, autonomous bot submissions are discouraged, and we require attribution for prior art. We've seen PRs that are clearly LLM-generated with no human review, and some that "borrow" from other projects without credit.
5. CI as a governance layer, not just a test runner
Our CI runs DCO sign-off verification, contributor reputation checks, spell checking on docs, markdown link validation, and automated security scanning, not just unit tests. When your repo gets 280+ forks, CI becomes your first line of defense against low-quality or malicious contributions. We learned this the hard way after broken benchmark paths (#1826), stale links across 50+ tutorials, and dependency bumps that silently changed behavior.
6. Building community trust signals that actually work
We created 35 "good first issues" (#1618-#1653) with size labels, clear descriptions, and explicit scope boundaries. We added an ADOPTERS.md for production users. We have a multi-language SDK (Python, .NET, TypeScript, Rust, Go) which means contributor PRs can touch any stack, so our review process has to be language-aware. Real community building is operational work, not just slapping a "contributions welcome" badge on your README.
Why this matters now:
AI agent projects are the fastest-growing category on GitHub. Every maintainer of these projects will face the exact problems we faced. The tooling and processes we built for AGT are reusable patterns any OSS maintainer can adopt.
Stream Date
not yet
Dates
Flexible on dates. Happy to work with your schedule.
Twitter URL
https://x.com/mosiddi
LinkedIn URL
https://www.linkedin.com/in/imransiddique1986/
Additional Info
I can do a live demo of our contributor_check.py catching a suspicious PR in real-time, and walk through our CI pipeline showing how each check acts as a governance layer. Happy to adjust the format to whatever works best for the show, whether that's a conversation, demo-heavy walkthrough, or a mix. Looking forward to it!
cc @kecrosby