AIWG takes the integrity of its source, its release artifacts, and its deployed AI context seriously. This document describes how to report a vulnerability and what to expect when you do.
Please do not file public issues for vulnerabilities. A public issue puts users at risk before a fix is available.
Send a report to:
We accept reports in plain text, but strongly prefer encrypted reports if the finding describes an active exploit, embeds a working PoC, or references unpublished cryptographic material. See Encryption Key below.
Include in your report:
- A description of the vulnerability and the component(s) affected (e.g.,
aiwgCLI, a specific deployed agent/skill, a specific workflow file). - The version, commit SHA, or release tag the report is against.
- Steps to reproduce — minimal PoC if possible.
- The impact you have observed or believe is achievable.
- Whether you intend to disclose publicly, and if so on what timeline.
If your Gitea account can submit a private security advisory against roctinam/aiwg, that is an acceptable channel. Note: Gitea security advisories are a relatively recent feature and behavior varies by Gitea version; if your submission fails or is not acknowledged within 48 hours, fall back to email.
- Do not run automated scanners against
aiwg.ioorgit.integrolabs.netwithout prior coordination — they are small-team infrastructure and a vulnerability scan looks the same as an attack. - Do not attempt to exfiltrate, modify, or destroy data belonging to other users.
- Do not submit reports that depend on physical access to a target machine or social engineering of a maintainer — those are out of scope.
Release tags are signed by maintainer keys published in this repo. CI fails to publish any release whose tag does not verify against one of these keys (gate added per #1299, enforced by tools/ci/verify-signed-tag.sh).
Either format is accepted; both can co-exist:
| Format | Public-key location | Notes |
|---|---|---|
| GPG (ASCII-armored) | .gitea/keys/maintainers.asc |
Preferred for long-lived release keys |
| SSH (allowed-signers format) | .gitea/allowed_signers |
Acceptable; works with hardware-backed keys (YubiKey, etc.) |
GPG maintainer signing key (active) — registered 2026-05-12 Principal:
AIWG Release Signing <release@aiwg.io>Fingerprint:FE9272F0BC5781E1DE77FAAA719AB63879E84CE8Published:.gitea/keys/maintainers.asc
External reproducers should verify release tags only after importing the key above and confirming that the fingerprint reported by gpg --fingerprint release@aiwg.io matches the value in this section.
For encrypted reports, use the AIWG project security key.
Status: The project-specific key is being generated. Until it is published at
.github/keys/security.asc(PGP) or.github/keys/security.age(age), please send your report unencrypted tosecurity@integrolabs.netand we will respond from an account that can negotiate encrypted follow-up.Operator follow-up: generate a project-scoped key (not a personal maintainer key), publish the public component to a stable path in the repo, and update this section with the fingerprint and rotation policy. Tracked in #1285.
We will publish:
- Fingerprint of the public key
- The public key file under
.github/keys/ - The key rotation cadence (target: annual rotation; immediate rotation on any suspected maintainer compromise)
We commit to the following response timeline for valid reports:
| Stage | Target |
|---|---|
| Acknowledgement | within 24 hours of receipt |
| Initial assessment (severity, scope, confirmed reproducer) | within 7 calendar days |
| Coordinated disclosure window | up to 90 calendar days from initial assessment, extended only by mutual agreement |
| Public advisory + fix release | targeted to coincide with disclosure window end, or sooner if a fix is ready and the report has been validated |
If we miss any of these targets we will tell you why and propose a revised timeline. We will not silently drop a report.
For findings that are actively being exploited in the wild, we will accept an accelerated disclosure timeline — please flag this in the report.
In scope:
- The published
aiwgnpm package onnpmjs.organd the Gitea registry. - The AIWG repository contents at
https://git.integrolabs.net/roctinam/aiwgand its GitHub mirror athttps://github.com/jmagly/aiwg. - Deployed AI context (agents, skills, commands, rules, templates) shipped under
agentic/code/insofar as it could be weaponized against a user (e.g., a deployed agent that would induce a user's AI assistant to exfiltrate credentials). - Release workflows under
.gitea/workflows/and.github/workflows/insofar as they could be exploited to publish a malicious release. - The supply-chain controls themselves (e.g., a finding that the release-age gate is bypassable).
Out of scope:
- The Gitea instance hosting AIWG (
git.integrolabs.net) operationally — pen-testing the Gitea installation itself is not authorized. aiwg.ioinfrastructure pen-testing (the project website).- Theoretical vulnerabilities without a demonstrable exploit path.
- Vulnerabilities in user-installed third-party AI providers, IDE extensions, or upstream LLM APIs that AIWG only forwards to — report those to the relevant vendor.
- Issues that require local OS-level compromise to exploit.
We will not pursue legal action against researchers who:
- Make a good-faith effort to comply with this policy.
- Stop testing and notify us as soon as they identify a vulnerability.
- Do not exfiltrate data beyond what is required to demonstrate the vulnerability.
- Do not publicly disclose the vulnerability before we have had a reasonable opportunity to address it (see the disclosure window above).
We may publicly credit researchers who report valid vulnerabilities, with their consent.
AIWG is currently executing a supply-chain hardening campaign in response to the May 2026 Mini Shai-Hulud npm worm. If you discover a finding that overlaps with one of the in-progress controls (e.g., the lifecycle script removal, the release-age gate, the signed-tag verification step), please reference the relevant sub-issue number in your report so we can de-duplicate.
This policy is versioned with the repository. Material changes (response SLA, scope, key fingerprint) will be announced in the release notes for the version that introduces them.
Last updated: 2026-05-12 (initial publication; #1285).