Poppy field guide · 06
Security and data handling
A practical review model for deciding what belongs in a Poppy workflow, who can reach it, and which claims the system can safely support.
Teams that want the productivity of connected context without treating every source, account, and integration as equally safe.
Sensitive or private material enters prompts, boards, logs, exports, or third-party automations without a deliberate retention and access decision.
Data boundary
Begin with what the workflow is allowed to know.
Source-connected AI creates value by concentrating context, which also concentrates consequence. Inventory the classes of material the board may contain: public sources, internal drafts, customer information, credentials, regulated data, or other private content. The safest category is the one the workflow never receives.
Classification should change behavior. A public research board can support broad sharing and automation. A board containing private operational material may need narrower membership, fewer connected services, limited exports, and a different retention period. One generic ‘secure’ label does not make those choices.
- Prohibit passwords, private keys, tokens, and unnecessary personal data from boards and prompts.
- Use synthetic or redacted examples while designing a workflow.
- Document allowed data classes beside the board purpose and owner.
Flow map
Follow the content through every handoff, not only the primary tool.
A captured item may move from Android storage to a delivery adapter, Poppy, a chatbot, an automation platform, a writing model, a recording, an editor, and a publishing system. Each step can copy content into logs, history, caches, exports, or another account. Review the chain as one system.
The map should show identity and ownership as well as data. Which account authorizes each handoff? Who can revoke it? Can a personal account leave with an operator? Does a failed item expose content in an exception queue? These are operating questions before they are security terminology.
- List every service that receives content or metadata and the purpose of the transfer.
- Use organization-controlled identities for durable business workflows where possible.
- Remove intermediaries that do not create a necessary transformation or control.
Generated output
Prompt boundaries are instructions, not enforcement.
A chatbot instruction can ask the model to stay inside approved context, but the surrounding application still needs validation, access control, and review appropriate to the output. Generated content should not become an authorization decision, execute an irreversible side effect, or disclose private context solely because the prompt says not to.
Prompt injection is especially relevant when boards contain material collected from outside sources. Treat source text as data, not trusted instruction. Keep system behavior separate from the material being analyzed, and test inputs that attempt to redirect the bot or extract hidden context.
- Validate structured output before an application acts on it.
- Require human approval for consequential external actions.
- Test hostile and irrelevant instructions embedded in collected sources.
Governance
Every persistent workflow needs an owner and an exit path.
Name the person or role responsible for membership, source updates, integration credentials, failed-delivery review, and retirement. Without ownership, boards and bots remain available after their purpose, evidence, or audience has changed.
Plan deletion, export, and migration before the workflow becomes irreplaceable. An operator should know how to recover approved outputs, remove sensitive material, disable connected accounts, and continue essential work if an integration or product surface changes.
Continue the field guide