// prove.reviewed_workflow

Privacy and audit for AI operations

OpenOrange keeps AI work accountable with local secrets, redacted observations, request attribution, explicit policy, contextual approvals, audit history, health checks, and recovery metadata.

OpenOrange treats privacy and audit as product boundaries. Sensitive values stay local, while policy decisions, request attribution, redaction state, and audit context remain visible where needed.

01

Secret values stay in local files or secret backends.

02

The control plane stores references and audit context, not copied token values.

03

Sensitive capabilities can use local allow, ask, and deny policy while attributable audit history stays available.

04

Rollback metadata and smoke checks stay tied to the instance.

Privacy boundary

Secrets, sessions, memories, media, caches, runtime databases, overlays, and raw logs stay local by default. OpenOrange works with redacted observations and references.

Direct controls

Ordinary work stays direct. Sensitive capabilities can ask for approval or be denied by local policy, and decisions remain attributable without turning audit into a user workflow.

Audit-ready runtime operations

Request, service, policy, and action history preserve what happened, who initiated it, and which privacy or approval state applied.

// questions

Does OpenOrange need secret values?

No. OpenOrange should store secret references and audit context while token values stay local or in the chosen secret backend.

Can sensitive actions still be gated?

Yes. Local policy can allow, ask, or deny by command or plugin capability. Ask decisions wait for approval, and deny changes always require a user decision.