If you discover a security vulnerability in apcore, please report it responsibly.
Do NOT open a public issue for security vulnerabilities.
Please use GitHub's private vulnerability reporting feature:
- Go to the relevant repository's Security tab
- Click Report a vulnerability
- Fill in the details
Alternatively, email: team@aiperceivable.org
- Acknowledgment: Within 48 hours
- Initial assessment: Within 7 days
- Fix or mitigation: Depends on severity; critical issues targeted within 30 days
| Component | Supported Versions |
|---|---|
| apcore spec | Latest published version |
| apcore-python | Latest release |
| apcore-typescript | Latest release |
| apcore-rust | Latest release |
| apcore-mcp-* | Latest release |
| apcore-a2a-* | Latest release |
| apcore-cli-* | Latest release |
| apcore-toolkit-* | Latest release |
Older versions receive security fixes on a best-effort basis.
This policy covers all repositories under the aiperceivable GitHub organization that are part of the apcore standard.
apcore assumes the extensions root is at least as trusted as the host process. That is the case in the two deployments the project supports today: the root ships inside the deployed artifact and is read-only at runtime, or it is operator-managed at the host's own trust level.
A root writable by a party less trusted than the host is outside this
model, and confinement is not the control that would protect it: a writer
there can drop a module that passes every check and does whatever it likes
inside execute(). The symlink time-of-check/time-of-use window described in
Discovery TOCTOU is one
consequence of that boundary, not a defect within it, and the assessment is
accepted as written: document the boundary, do not add per-platform
mechanism to close one window in a deployment the project does not claim to
support.
Reports that assume a less-trusted extensions root are still welcome — they are evidence that the deployment should be supported, which is exactly what the assessment names as the thing that would change the decision. Please say so in the report rather than filing it as a confinement bypass.
We follow coordinated disclosure:
- Reporter submits vulnerability privately
- We confirm and assess the issue
- We develop and test a fix
- We release the fix and publish an advisory
- Reporter is credited (unless they prefer anonymity)