Approvals, security, and privacy

Doozies can reach real systems and take real actions. Use explicit boundaries, least-privilege connections, and Approvals (aka human reviews, confirmations, or human-in-the-loop checks) to keep consequential decisions under human control.

Set a boundary in the request

State what the Doozy may do and what it must only prepare.

Investigate the billing discrepancy and prepare the corrected invoice. You may update internal notes. Ask before sending anything, issuing credit, changing payment details, or modifying the customer account.

Clear request-level boundaries complement workspace policies. They don’t replace them, and a request can’t weaken a stricter administrative rule.

Review an action

When an action requires approval, Doozy pauses that action and adds it to Approvals. Review:

• the requesting Doozy and linked to-do;
• the target account, recipient, file, or system;
• the exact message, command, or parameters;
• supporting evidence and assumptions;
• whether the action is reversible;
• other actions bundled into the request.

Approve, reject, or return feedback. Approval applies to the displayed action, not every similar future action, unless you deliberately create an always-allow rule.

Configure approval rules

Workspace admins can require approval for categories such as:

• external messages and publishing;
• purchases, refunds, and financial changes;
• deletion or destructive commands;
• production deployments and data writes;
• permission, identity, and account changes;
• exporting or sharing sensitive information;
• execution on a local computer.

Doozy-level rules can be stricter for a particular role. When rules conflict, Require approval wins over Allow.

Keep exceptions specific. “Allow all email actions” is difficult to review; “allow the Support Triage Doozy to add internal labels in the support inbox” has a clear target and impact.

Enter secrets yourself

Passwords, passkeys, API keys, verification codes, CAPTCHA responses, payment confirmations, and identity checks shouldn’t be sent through a conversation.

Use provider authorization flows, the secure secret interface, or human takeover in Morph. Return control after the sensitive step is complete and verify that the credential was stored in the intended workspace.

Treat Codex authentication caches and access tokens like passwords. Don’t attach or commit them.

Understand the workspace boundary

Each workspace has a separate Morph environment and set of connections. Within one workspace, its Doozies share the filesystem, browser sessions, installed tools, and command-line credentials.

Separate Doozies aren’t security boundaries. Use separate workspaces when data, credentials, clients, environments, or membership should remain isolated. Don’t rely on role instructions alone to protect one Doozy’s files from another Doozy in the same workspace.

Workspace members receive access according to their role. Review membership before connecting sensitive systems and remove departed members promptly.

Control connected apps

Prefer the minimum scopes needed for the work. Use dedicated service accounts where practical. Review provider permissions during setup rather than accepting broad access by default.

Removing a toolkit from one Doozy limits that Doozy’s normal access but doesn’t revoke the workspace connection. To remove access completely, disconnect the provider and revoke authorization at the provider when necessary.

Local computer access

Morph is separate from your physical computer. If local execution is enabled, configure whether each request is denied, approval-gated, or allowed under a narrow rule.

Review commands, directories, and affected files before approving local execution. Avoid granting broad access to home directories or credential stores.

Data and privacy

Doozy stores the workspace information needed to provide persistent Doozies, including conversations, to-dos, files, memories, connection metadata, and Morph state. Connected providers and selected model providers process data under their own terms and your configured account policies.

Don’t place regulated or highly sensitive data into a workspace unless your organization has approved the relevant Doozy plan, region, providers, retention settings, and connected services.

Remove access and working data

To decommission recurring work:

1. Pause schedules and active to-dos.
2. Remove or archive the affected Doozies.
3. Disconnect workspace apps and revoke provider grants.
4. Remove secrets and authenticated browser or CLI sessions from Morph.
5. Delete sensitive files from Doozy storage, Morph, and connected systems.
6. Remove workspace members who no longer need access.
7. Apply the workspace retention or deletion controls.

Deleting one conversation or Doozy doesn’t automatically erase copies elsewhere.

Use a least-privilege rollout

Begin with read-only research and internal drafts. Observe several successful runs, tighten skills and evidence requirements, then allow narrow internal writes. Add external or destructive actions only when the work has clear approvals and recovery paths.

Frequently Asked Questions