Please do not open a public GitHub issue for security vulnerabilities.

Report them privately to security@vengtoo.com. Include:

• A description of the issue and its impact
• Steps to reproduce (a minimal policy file / request sequence is ideal)
• The agent version or commit hash

We will acknowledge your report within 3 business days and keep you updated as we work on a fix. We ask that you give us a reasonable window to release a patch before public disclosure, and we will credit you in the release notes unless you prefer otherwise.

The Vengtoo Agent is an authorization decision point, so we treat the following classes of issues as high severity:

• Decision integrity — any input (policy file, bundle, or request) that causes an ALLOW where the policy semantics say DENY. The engine is designed to fail closed: malformed conditions, unknown condition keys, unknown operators, and invalid patterns must all deny, never allow.
• Bundle supply chain — bypassing Ed25519 bundle signature verification, or getting the agent to trust a verification key served by the bundle origin rather than the pinned trust anchor.
• Authentication — bypassing the VENGTOO_CLIENT_SECRET check on the decision endpoints.

Denial-of-service against the agent's own HTTP endpoints, and issues that require an attacker to already control the agent's host or config, are generally lower severity but still welcome reports.

For production deployments:

• Set BUNDLE_SIGNATURE_REQUIRED=true and pin the cloud's signing key via VENGTOO_BUNDLE_TRUSTED_KEYS or vengtoo-agent trust-key. The agent refuses to start in this mode if no key is pinned.
• Set VENGTOO_CLIENT_SECRET so only your services can query decisions.
• Do not expose the agent's listen address beyond your service network; /healthz and /readyz are unauthenticated by design for probes.

Security fixes are applied to the latest minor release. Older releases receive fixes on a best-effort basis.