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, and how much access each grants (Off, Read, or Read & Write)	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 administrative and account activity, once audit logging is turned on	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 custom third-party connections unless you change it. The default is permissive. If your posture requires an allow-list, turn off Allow members to add their own custom connections explicitly — do not assume the restrictive default.

Connection controls decide whether a service is available. What happens on each write is decided by your Autonomy settings, and read-only calls are not staged. 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 securely and are available to you on request.

Gaps — plan around these

Gap	What it means for you
Read-only calls to connected third-party tools are not staged	You control whether a service is connected. Writes made through a connected app are staged according to your Connected apps Autonomy setting; read-only lookups run without review.
Audit records cover administrative and account activity	They are recorded only while audit logging is turned on, and 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.