Security
FalseGreen is built to reduce what you have to trust.
Human intent is frozen outside the builder loop. The coding agent can produce software and evidence, but it cannot mint FalseGreen acceptance. Results stay bound to the exact source that earned them.
Separate intelligence, evidence, and authority
Trusting the acceptance system
The human-readable requirement remains authoritative. FalseGreen freezes the definition of done before the implementation is judged, so the coding agent cannot silently redefine success after seeing the result.
Builder
Coding agents can write code, run tests, review their work, and produce evidence. Those are powerful builder-side controls. They do not automatically constitute FalseGreen acceptance.
The builder can produce evidence. The builder cannot mint acceptance.
Acceptance authority
FalseGreen independently evaluates the finished result against the frozen requirements. Failed assumptions can drive repair, but the builder does not get to weaken the target to make the work pass.
Scoped execution
Customer code and toolchains are treated as untrusted inputs.
Engineering agents may need compilers, test runners, formal provers, infrastructure tools, and other powerful commands. FalseGreen constrains that work around the applicable Task, workspace, source identity, and authority boundary.
No single sandbox is treated as the entire security boundary.
Conceptual authority envelope
Exact-source authority
Acceptance belongs to the exact source state that earned it. A changed PR head does not inherit an earlier ACCEPT, and organization authentication does not become organization-wide acceptance authority.
Tasks, Jobs, frozen requirements, source identities, and reports stay scoped to the applicable work. One Job or report cannot stand in for a different repository, workspace, Task, or source state.
head A
FalseGreen ACCEPTED
↓ exact source matches
PR Gate will report ACCEPTED
new commit → head B
head A ACCEPT does not match
PR Gate will report BLOCKED
Fail-closed enforcement
When PR Gate is enabled and FalseGreen acceptance is required, it is designed to block if it cannot safely establish authority for the applicable source. A different revision, invalid or revoked Gate credential, ambiguous source identity, or integrity or service failure will not silently become green.
PR Gate is designed to report ACCEPTED, NOT REQUIRED, or BLOCKED according to the repository’s authority state. Enabling Gate will not make every pull request a FalseGreen Job.
A narrow credential
PR Gate will be separate from MCP and will use a dedicated, read-only, organization-scoped credential. It will not create or consume Jobs, change contracts, run verification, manufacture reports, or mint ACCEPT.
Inspectable evidence
A FalseGreen report makes a bounded claim inspectable: what was verified, against which source, what evidence supports the result, and what was not established.
Trusting FalseGreen with your organization
Customers retain ownership of content submitted to FalseGreen. The public Terms grant FalseGreen only the limited rights needed to host, process, transmit, and use that content to provide, secure, maintain, troubleshoot, and improve the Services.
Submitted content
FalseGreen receives a limited license to handle submitted content as necessary for the Services and as described in the Privacy Policy.
Data minimization
The Privacy Policy tells customers not to submit secrets, credentials, or personal information that is not necessary for a verification request.
Safeguards and rights
FalseGreen uses commercially reasonable safeguards, but no transmission or storage method is completely secure. Privacy rights may include access, correction, deletion, or a copy of personal information, depending on where you live.
Read the current terms and privacy policy. Found a security issue or have a security-review question?Contact us.
Explicit limits
Read the boundary