Instances currently have two capabilities:

• View, granted to:
  • instance members;
  • users with the "can manage instances" capability (Phacility staff);
  • members of the merchant account (Phacility staff).
• Edit, granted to:
  • members of the billing account.

You need edit permission to:

• Edit or reset configuration settings.
• Disable the instance.
• Edit the instance properties (there currently are no editable properties, so this is moot).
• Invite a user.
• Cancel an invite.
• Strip multi-factor authentication from a user.
• Change the instance billing plan.
• Restart the daemons.
• (Indirectly) Manage billing: pay bills, configure autopay.

If you have edit permission, the instance is also displayed differently on the instances home page.

Private clusters (T11230) will introduce additional options, and likely additional capabilities. However, I believe editing these will be very rare and reserving them for high-level admins is likely reasonable (most organizations won't want someone in HR managing their European subcluster device layout, I assume).

Automated export (T7148) also likely needs a separate permission.

Of these capabilities, these have billing implications:

• Invite users (up to 50 users, at least).
• Change billing plan.
• (Future) Manage clustering.
• Pay bills, configure autopay.

These have security/policy/privacy implications:

• Edit configuration (because of feed.http-hooks, although I would like to make this non-policy-violating, see T10363 / T5726).
• Strip multi-factor auth.
• (Future) Export data.
• (Future) Manage clustering (maybe).

These actions have no substantive implications and can only be mildly annoying if abused:

• Cancel invites.
• Restart daemons.
• Disable instance (maybe very annoying if abused).

We're fairly conservative about billing changes, but probably do not need to be. In particular:

• If a rogue user accidentally added a lot of users they shouldn't have, we'd likely just tell the install to disable them and issue credit for the next billing cycle, which is presumably a reasonable remedy for most installs/situations. The largest possible size of this mistake is now $1,000, which isn't a very big deal in the scheme of things.
• If a rogue user intentionally added a lot of users they shouldn't have, the need to activate them for them to get billed, and they get prorated. So they either need to add 50 users on the 1st day of the billing period, activate them, and keep them active for 30 days without anyone noticing that typeaheads are full of 50 weird new users, or add hundreds of users near the end of the month. Maximum impact is $1,000 again, and we can easily fix it and issue credit. The user could do more financial damage more quickly and less traceably by destroying one laptop.

In theory, a malicious or mistaken user could do more damage by switching billing plans in the future, but we have no plans to introduce a $5000/user bling plan or anything, and private clusters will likely need staff intervention and/or prepayment before going into effect, at least for the foreseeable future.