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

1. Open Connections and check whether the integration already exists.
2. Add the provider or custom REST/MCP connection.
3. Name the connection with owner, system, environment, and purpose.
4. Confirm credentials are scoped to the minimum useful permission.
5. Review whether the connection is shared, private, or system-managed.
6. Review organization connection governance: provider enabled/disabled and function-level access.
7. Configure token limits for model connections where volume matters.
8. 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.

Own and rotate MCP credentials

Choose the external MCP server's authentication mode before deciding whether its connection can be shared. Keep a personal OAuth grant or user-specific header private. Use Shared access only when the credential represents an approved team or service identity and its provider-side scope matches every intended user.

Record a credential owner for every shared MCP connection. That owner must be able to repeat consent, rotate static headers, and investigate provider-side revocation. Only the connection owner can complete reauthorization. Reauthorizing a Shared connection changes the credential used by all authorized consumers; reauthorizing a Private connection affects only its owner. Test the connection again after either operation.

Step 6: Set Token Limits For Model Connections

Model connections can have daily and weekly Organization, Team, and User defaults, plus defaults and subject overrides for a specific model. Use these when a shared connection powers high-volume agents or workflows. The Disabled column disables an override record and restores its applicable default; it does not block the subject from the connection. Use access policy or connection governance when temporary containment requires denying use.

Apply limits from broad to specific:

1. Set all-model connection defaults for the normal Organization, Team, and User budget.
2. Add model defaults when a particular model needs a different operating envelope.
3. Add User or Team overrides only for a justified exception.
4. Review both all-model and model-specific utilization in Analytics > Limits.

For example, set an Organization cap that protects the whole shared connection, add a normal daily and weekly User default, and set a lower model-specific default for a higher-cost model. Add a larger Team or User model override only for an approved exception. Every request must still satisfy the all-model connection budget, the effective model-specific budget, every applicable Team budget, and the Organization budget. See Token Limits in Connections Management for exact precedence.

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 an obsolete override to return that subject to defaults; change access or governance when the incident response must block use.

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.

For OAuth connections, use Check Connection Health and Reauthorize to separate an invalid refresh credential from endpoint, scope, network, and individual-function failures. The credential owner performs reauthorization; an administrator should then verify a safe read and, where required, one bounded confirmed write in the target system.

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 model connection, credential ownership, and initial limits are accepted, create and test the private pilot agent. Add live tools only after the data-only or read-only pilot shows that they are needed.