Configure Shared and Private Connections
Connections are the trust boundary between Siesta AI and external systems. A connection can be a model provider, OAuth account, API key, REST endpoint, MCP server, storage system, CRM, ticketing system, calendar, email account, or search/scraping provider.
Connection Review Flow
- Open Connections and check whether the integration already exists.
- Add the provider or custom REST/MCP connection.
- Name the connection with owner, system, environment, and purpose.
- Confirm credentials are scoped to the minimum useful permission.
- Review whether the connection is shared, private, or system-managed.
- Review organization connection governance: provider enabled/disabled and function-level access.
- Configure token limits for model connections where volume matters.
- Test one read action and one write action before assigning it to a production agent or workflow.
Shared vs Private
| Type | Use when | Admin risk |
|---|---|---|
| Shared connection | A team should use the same service account, CRM account, Jira project, Slack app, model provider, storage account, REST API, or MCP server | One credential may affect many users and agents |
| Private connection | The action should happen under the current user's mailbox, calendar, Drive, or personal OAuth grant | Agent behavior depends on each user's authorization |
| System-managed Connection | A built-in Platform Tool needs a Siesta-managed backend Connection | Admins must understand which agent has that Platform Tool enabled |
Do not connect a personal account as a shared production connection unless the external system has no service-account option and the business owner accepts the operational risk.
Function Governance
Organization connection governance can disable a connection type or force specific functions into confirmation mode. The effective function access uses the strictest setting between organization policy and connection-level configuration.
Use this baseline:
| Function behavior | Default posture |
|---|---|
| Search, list, read, summarize | Enable when the agent audience is allowed to see the data |
| Draft, preview, validate | Enable when the user can review before acting |
| Create, update, send, post, move | Require confirmation unless the business process explicitly allows direct execution |
| Delete, publish, permission changes, financial/customer updates | Require confirmation and narrow team access |
| Unknown REST/MCP function | Require confirmation until tested and documented |
For REST tools, confirm path parameters, query parameters, body fields, and static headers. For MCP tools, confirm server URL, custom headers, function names, schemas, and ownership.
Token Limits For Model Connections
Model connections can have organization, team, and user token limits. Use these when a shared model connection powers high-volume agents or workflows. A team or user can also be disabled on a connection when temporary containment is needed.
For Azure AI Foundry model router connections, review the Azure deployment type, routing mode, and model subset before sharing the connection. The deployment type answers data-residency questions, the routing mode controls the cost-quality posture, and the subset defines which underlying models are allowed.
Practical examples:
- Set organization limits for general model usage.
- Set team limits for research-heavy or automation-heavy teams.
- Set user limits for pilots, contractors, or unusually high-volume accounts.
- Disable a user or team on a model connection during an incident instead of deleting the connection.
Credential Rotation
Rotate credentials when:
- the owner changes,
- a test integration becomes production,
- a provider reports suspicious activity,
- a shared workflow is retired,
- a contractor or temporary admin leaves,
- a key was copied into a prompt, browser, client app, or ticket.
After rotation, test the connection and review Tool Executions for failures.
Production Acceptance Checklist
- The connection has a business owner.
- The credential scope is documented.
- The provider is allowed in organization governance.
- Write functions have confirmation where needed.
- Model token limits are set where needed.
- The connection is shared only with the right teams.
- A test agent or workflow has produced a successful entry in Tool Executions.
- Failure behavior is understood before the connection is used by a team.
After the credential and sharing boundary is accepted, set up the tools, APIs, and MCP access that the connection exposes.