> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ctrlrun.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Reporting a vulnerability

> Report privately to contact@arpanghoshal.com or through GitHub's private vulnerability reporting.

Report vulnerabilities privately to **[contact@arpanghoshal.com](mailto:contact@arpanghoshal.com)**, or through GitHub's private
vulnerability reporting on the repository. Do not open a public issue for a security report.
Expect an acknowledgement within 72 hours and an assessment within seven days.

Include what makes the problem reproducible: the version, the policy file, and the sequence of
actions. A failing test is the fastest possible report.

## What counts as a vulnerability

CTRLRun sits in the execution path of consequential actions, so anything that breaks one of
these is a security issue rather than a bug:

* An action executes that the policy should have denied.
* An approval authorizes an action other than the exact one a human saw.
* A consumed, expired or mismatched approval is accepted.
* The same logical effect is reserved twice, in any interleaving, across threads, processes or
  hosts.
* An unknown execution outcome is recorded as `failed`.
* A principal acts outside its grant, or a delegation widens one.
* A receipt does not reflect what happened.

## What is a documented limit

These are stated in the [threat model](/THREAT_MODEL) and are not vulnerabilities, though if you
think one is stated too generously, say so:

* A compromised process, host or Python environment.
* A malicious administrator with write access to the policy file or the store.
* A remote that lies about what it did.
* A compromised approver: CTRLRun proves what was approved, not that the human was right.
* An executor that raises `NotExecuted` after the remote acted.
* Code that bypasses the decorator entirely.
* Data exfiltration through reads the policy allows.

## What happens to a report

An assessment, then a fix with a test that fails before it and passes after, then a release. If
a fix is warranted you are credited in the release notes unless you ask not to be. Where the
finding is about a claim rather than the code, the claim changes: a sentence that promised more
than the code does is a defect in this project's terms, and
[how this is built](/how-this-is-built) explains why.

## Supported versions

CTRLRun is pre-1.0 and only the latest release receives fixes.

## Next

* [Threat model](/THREAT_MODEL) · [The receipt chain](/security/receipt-chain).
* [How this is built](/how-this-is-built): what has and has not been reviewed.
* [Get started](/get-started/quickstart) · [Why](/why).


## Related topics

- [Threat model](/THREAT_MODEL.md)
- [CTRLRun and agent oversight toolkits](/compare/governance-toolkits.md)
- [Fail closed](/concepts/fail-closed.md)
- [OWASP Top 10 for Agentic Applications](/OWASP-AGENTIC-TOP10.md)
- [ctrlrun verify](/verify.md)