Security & Data
An operational ledger for provenance, privacy, and review
This compact reference describes the controls a team should inspect when RB2B research is connected to external providers. Availability and behavior remain configuration-dependent; confirm them in the package prompt, provider terms, runtime logs, and your own test.
Control matrix
| Control | Expected record | Review cadence | Status boundary |
|---|---|---|---|
| Source provenance | Provider, source context, observation date, transformed field | Every accepted claim | Depends on connected source |
| Refresh policy | Freshness window, expiry behavior, last checked date | Before reuse | Team-defined policy |
| Secret handling | Runtime store, minimum scope, rotation owner | At setup and rotation | Never place keys in prompts |
| Privacy controls | Purpose, access, correction, suppression, deletion | Before production | Jurisdiction and provider dependent |
| Human review | Accepted evidence, rejected alternative, decision, reviewer | Before downstream action | Required operating gate |
| Failure handling | Error state, retry rule, partial output, destination | Every release test | Inspect locally |
Evidence checklist
- Package review: inspect the displayed package, permissions, version, and completion output before configuration.
- Network review: document every service the task may call and the minimum credential scope it requires.
- Data review: keep unknown and conflicting values visible; never treat a populated field as proof of freshness or lawful use.
- Destination review: determine where intermediate records, logs, caches, and exports are written and when they are deleted.
- Outreach review: verify professional relevance, suppression, opt-out language, and applicable regional requirements before sending.
- Claim review: do not present unverified SOC 2, ISO, GDPR, coverage, accuracy, or uptime statements as certifications or guarantees.
Run a security-aware first test
Use non-sensitive known companies, a minimum-scope test credential, and a written deletion plan. Installation success confirms execution—not research accuracy, permission, or outreach readiness.
Keep the test date, package version, configuration owner, sanitized output, and reviewer decision beside the result. This record lets another operator reproduce the assessment, identify changed provider behavior, and distinguish a runtime regression from a revised source or policy.
npx -y @okki-global/okki-go-taroball