Personal connections. Connectors are personal on both paths: each user authorizes their own connection and Sana mirrors that user's access. An admin cannot connect on behalf of users.

Availability. Workspace owners choose whether a connector is available to everyone or only to selected users. There is no scoping by group.

Tool controls. Owners set a default for read-only and for write tools and can override individual tools. The configuration applies to everyone who has access to the connector; a tool cannot be enabled for some users and not others. See Configuring connector tools.

Approvals. Tools that make changes ask the user for approval before they run. See Human-in-the-loop approvals for actions.

Revocation. Disabling a connector in Workspace settings removes it for every user at once.

The gateway must be reachable from Sana. The endpoint must use HTTPS and resolve to a publicly reachable address. Private IP ranges and internal-only hostnames are rejected, and a gateway that is only reachable inside your corporate network cannot be connected today.

Sana sees one server with one list of tools. If the gateway aggregates twenty internal servers, the agent receives all their tools in one flat list. Two tools with the same name collide, and only the first is available. Expose curated, namespaced tool sets per use case (for example hr_get_worker, it_create_ticket) rather than the union of everything behind the gateway. Very long tool lists can also make tool selection less reliable.

Per-user identity depends on the gateway. Sana authenticates each user to the gateway with OAuth (Dynamic Client Registration, pre-registered credentials or Client ID Metadata Document) or an API key. Per-user permissions in the downstream systems hold only if the gateway forwards the user's identity to them. If the gateway substitutes a service account, every user acts with that account's permissions from that hop onward.

Sana does not detect tool changes. Teams behind the gateway can rename, remove or change tools without warning, which can silently break flows in Sana. Version your tool schemas, run contract tests on the gateway, and agree on a change notification path from server owners to your Sana workspace owner.

Use custom instructions. The connector's custom instructions field tells the agent which tools to prefer, which to avoid and how to sequence calls. At gateway scale this is the main lever for reliable behavior.

Raise the timeout only where needed. The gateway adds a network hop on every call. If a tool legitimately needs more than 60 seconds, raise the per-server timeout rather than letting calls fail.

Start read-only. Enable the connector with write tools disabled, validate the read-only flows, then enable specific write tools per use case. New tools inherit the group default, so keeping the write default off protects you from surprise write capability.

Disable what you do not need, including read-only tools. Fewer tools improve accuracy as well as security.

Keep approvals on writes. Avoid flows that depend on unattended writes.

Annotate tools correctly on custom servers. Sana treats a tool as read-only only when the server marks it as such; an unannotated tool is treated as a write tool and will ask for approval.

Treat tool output as untrusted. Any server, including an internal one, can return content that contains instructions. Prefer trusted servers and use custom instructions to constrain how the agent acts on returned content. On the gateway path, the gateway is the place to add output filtering if your security posture requires it.

Design tools for the agent. Short, unambiguous, namespaced names; descriptions that say when to use the tool and what it returns; structured, bounded results with pagination.

Test failure modes. Expired tokens, permission denied, timeouts and empty results. Confirm the agent degrades gracefully. Keep a small set of test prompts per use case and rerun them after any tool change.