Draco is a security project: it brokers authentication and orchestrates authorization for AI agents. We take reports against it seriously and we appreciate the time it takes to make one.

Please do not report security vulnerabilities through public GitHub issues, discussions, or pull requests.

Use GitHub's private vulnerability reporting on this repository (Security tab, "Report a vulnerability"). Include what you can of: the affected component (a draco.core module, a reference agent, a tool backend, or a deploy manifest), a reproduction or proof of concept, the impact as you understand it, and any suggested fix.

You can expect an acknowledgment within 5 business days. We will keep you informed as we triage, fix, and disclose, and we will credit you in the advisory unless you prefer otherwise.

Draco is pre-1.0. Security fixes land on main; there are no maintained release branches yet. If you are deploying Draco, track main.

• Draco's design intentionally delegates: identity issuance to SPIRE, authorization decisions to OpenFGA, token issuance to the IdP, secret storage to OpenBao. A finding against one of those systems belongs upstream, but a finding in how Draco integrates them (token handling, audience and scope binding, trust-state handling, enforcement ordering, fail-open behavior) is exactly what we want to hear about.
• One limitation is known and documented rather than a new finding: per-tool access tokens are bearer tokens within their TTL; RFC 8705 certificate binding is designed but deferred to a dedicated slice. Mitigations in place are short TTLs, per-tool audience restriction, scope bounded to the granted operations, and cache clearing plus best-effort RFC 7009 revocation on trust degradation and shutdown.
• The committed Kubernetes manifests under deploy/ are sanitized samples with placeholder values; findings about placeholder credentials in those samples are expected, not vulnerabilities.