Receipts, not vibes.
Every claim says how strongly it is established. What is not known stays visible. Written for the person who signs off.
Four things it never confuses
- A scanner lead is not a confirmed defect.
- A graph path is not proven access.
- A Jank Score is not an exposure class.
- A passport is not an approval.
Evidence tiers
A path is only as strong as its weakest edge.
- verifiedAn operator inventory from outside the repository says so.
- supportedObserved in the code, or declared in configuration.
- inferredA heuristic, such as an SDK import.
- unknownNot established. Never safe, never proven dangerous.
An inventory inside the repository counts only as declared: its author controls it. What the opt-in sandbox sees is sandbox-observed, which adds to static findings and never refutes them.
Exposure classes
Qualitative, and monotone: more access can never lower the class.
- LowOnly local assets reached, or nothing reached in what it could inspect.
- ModeratePossible reach to a non-local system whose capability or classification is unknown.
- HighPossible write, delete or admin over production or sensitive assets, a supported read of restricted data, or sensitive data reachable alongside an outside destination.
- CriticalVerified write, delete or admin over critical or restricted data, or a verified sensitive export.
These are explainable heuristics, not probabilities. Sensitivity comes only from declarations or an operator inventory, never from a name such as payroll. With nothing inspected, the class is Unknown.
Rule outcomes
The decision is the most severe rule outcome. No averaging; a strong area never offsets a weak one.
- passThe rule did not trigger under the policy in force.
- reviewA person should look, for example at unverified authority over production data.
- insufficient-evidenceIt cannot judge. Missing evidence is not harm, and never becomes a pass.
- blockIt should not ship as it is under this policy.
Every outcome names its rule, such as P-DAT-002 or P-AI-001. Advisory unless you add --fail-on. Policy comes from defaults, then an operator file outside the repository; the repository itself can only tighten. The citizen profile turns most reviews into blocks.
Acceptance is a separate, recorded act by a person. jankhunt42 never creates it, and a block can never be accepted.
Where agent approvals matter
The Agents Rule of Two checks one agent at a time: untrusted input, sensitive data and a way to act must belong to the same agent.
| Configuration | Passport outcome |
|---|---|
| Some action runs without approval | Block, including combinations where a capability is only possible. |
| Every action needs approval; all three capabilities established | Review. A person’s approvals remain the boundary. |
| Every action needs approval; a capability is only possible | Information in the scan; no Rule of Two passport finding. |
Supervision is checked at the tools that act. Approval on an unrelated read does not protect a tool that can send or change data. The default profile reviews unsupervised combinations; the citizen profile blocks them.
A capability is only “possible” when the configuration cannot establish it, such as which private repositories a token reaches. Unknown servers contribute nothing, which limits coverage. No finding does not prove the agent is safe, and other passport rules can still block it.
No invented precision
- Not found means unknown, never absent.
- It never invents a host or guesses a secret.
- A connection string is not a grant; static evidence never proves privileges.
- It verifies no signatures: use
gh attestation verifyorcosign. - NIST AI RMF, AIGP and OWASP mappings are orientation, not compliance.
Full rules and limits: passport.md and connectivity.md. A finding wrong? Open an issue.