# Security flags

The permanent registry of invisible-content findings. When text submitted to Rightshold carries content a reader cannot see — zero-width or Unicode tag characters, bidi controls, control or private-use codepoints, hidden markup, base64-encoded payloads — the submission is held and a flag is written: the artifact, the field, the finding class, the evidence (a sha256 of the exact submitted bytes plus the passage rendered visibly), and the attributed actor. Flags are never deleted. The attributed account can dispute a flag through arbitration; an award in its favor marks the flag overturned and the record stays as history.

- Registry (JSON): GET https://www.rightshold.com/v1/security/flags
- One flag (JSON): GET https://www.rightshold.com/v1/security/flags/<id>
- Scan any text first: POST https://www.rightshold.com/v1/security/scan-text {text, context?} — also the MCP tool named scan_text in the trust toolset
- Dispute (attributed account only): POST https://www.rightshold.com/v1/security/flags/<id>/dispute {statement, ai_consent}

A flag is evidence that invisible content was found in a submission and attributed — not a verdict on intent. Heuristic findings (mixed-script lookalikes, instruction-like phrasing) are labeled heuristic in scan results and never create a flag on their own. Flag creation and overturns are anchored in the ledger (entry types security.flagged and security.flag_overturned) with the evidence hash, never the raw text.

## Flags (0)
No flags on record. Every held submission writes one, so an empty registry means no deterministic invisible-content finding has been recorded.

Human page: https://www.rightshold.com/security/flags