Approvals & autonomy

A Clone’s autonomy should be configurable, from conversation-only assistance to broader operational work. Your company determines the permitted boundary. Personal preferences and approvals cannot override a company prohibition.

The permission model needs an Allow, Ask or Deny decision for each category below. These are categories to configure, not default grants of access.

• Read data
• Change data
• Communicate
• Install connectors
• Create accounts
• Delegate work
• Run code
• Spend money

Allow

The action may proceed without individual approval only within its effective scope, company policy and information restrictions.

Ask

The action needs approval from a person authorized to approve it, before execution.

Deny

The action is prohibited. A personal preference or approval cannot make it permitted.

An approval must identify what will happen, the target or destination and the relevant content or transaction details. The first-build contract binds it to the exact action, the approver, an expiry and a single use.

A changed action needs reevaluation. An expired approval or one already used is not permission to execute again. Payment approval design must include the merchant, amount, currency and whether the charge is recurring; payments remain planned.

Permission to read does not imply permission to share. The security direction is for restrictions to follow sensitive information into summaries, files, results and delegated work. Reading restricted material may limit later actions and destinations, even when the action category would otherwise be allowed.