Security controls

What an organization admin can actually enforce, what is enforced for you by default, and where the gaps are.

One page for the question a security reviewer asks: what can we enforce, and what are we trusting?

It is deliberately explicit about what is not available. A control you believe you have and do not is worse than knowing you lack it.

What you can enforce

Control	Where
Which external services your people may connect	Connection policies
Turning a connected service off for the organization, and locking that choice so an individual cannot re-enable it	Connection policies
Permitting or blocking individual third-party tools	Connection policies
Which skills people may browse, install or build	Skill policies
Default Autonomy posture per resource, and whether users may loosen it — the Autonomy Matrix	Supervision
Reviewing every administrative change	Audit logs

Settings resolve from the top down: platform, then organization, then team, then the individual. A tier can tighten what the tier above set. It cannot loosen it. That direction is enforced, not conventional.

Two defaults worth checking rather than assuming

People may add their own third-party connections unless you change it. The default is permissive. If your posture requires an allow-list, set it explicitly — do not assume the restrictive default.

Connection controls decide whether a service is available, not what happens per call. Switching a third-party service off is a real control and it holds for new use. It does not retroactively stop a skill that is already installed from being called inside a running task. If you need a service genuinely gone, remove the installation as well as the permission.

What is enforced for you, without configuration

These apply to every organization and cannot be switched off:

Isolation between customers, enforced on the paths that read data.
No direct send. Assistants have no ability to send outside the approval path; the capability does not exist rather than being discouraged.
No self-approval, and no self-loosening. An assistant cannot approve its own work or change its own Autonomy or Supervision settings, whatever it is told.
Sender authentication on inbound mail, before anything reaches an assistant.
Access ends when a role does. When someone's assignment changes, their assistant's access to them ends across every channel at once.
An account-wide stop, releasable only by the account holder.
Administrative audit records are retained in versioned, access-restricted storage with no expiry.

Gaps — plan around these

Gap	What it means for you
Command-line and browser use sit outside the Autonomy Matrix	Where assistants can run commands or drive a browser, that behaviour is shaped by instruction, not restricted by a setting you hold. There is no tier at which you can switch it off.
No per-action approval for third-party tool calls	You control whether a service is connected. Individual calls to a connected service are not staged for review the way an email is.
No automatic flagging of unusually large actions	Bulk operations are bounded by supervision settings, not by a separate size check. Designed, not built.
Audit records cover administrative actions	They are not a per-access log of who read which record.

If any of these is a hard requirement for your organization, raise it with whoever provides your assistant before rollout rather than after — several are on the roadmap, and knowing which ones you need changes their order.