Chat and workflows are just the start — tables, files, and knowledge all live in the same workspace, in the browser or on your desktop.
diff --git a/apps/docs/content/docs/introduction/index.mdx b/apps/docs/content/docs/introduction/index.mdx index 6935e392a95..78c208e0151 100644 --- a/apps/docs/content/docs/introduction/index.mdx +++ b/apps/docs/content/docs/introduction/index.mdx @@ -59,6 +59,8 @@ The core source is available on [GitHub](https://github.com/simstudioai/sim) und Sim is SOC 2 Type II compliant. Find reports and security details in the [trust center](https://trust.sim.ai/). +Enterprise organizations can sign in through [SSO](/platform/enterprise/sso) with SAML 2.0 or OIDC, including Microsoft Entra ID, Okta, and Google Workspace. They can also sync members from Entra ID or Okta with [SCIM](/platform/enterprise/scim), review [audit logs](/platform/enterprise/audit-logs), and restrict models, blocks, and tools with [permission groups](/platform/enterprise/access-control). + ## Related docs - [Getting started](/getting-started): Build and run a simple summarizer. diff --git a/apps/docs/content/docs/workflows/blocks/agent.mdx b/apps/docs/content/docs/workflows/blocks/agent.mdx index b94b4fa818b..966f822339c 100644 --- a/apps/docs/content/docs/workflows/blocks/agent.mdx +++ b/apps/docs/content/docs/workflows/blocks/agent.mdx @@ -187,7 +187,7 @@ Live tool-call chips stream for **OpenAI, Anthropic, Azure Anthropic, Google, Ve | Provider | Streamed thinking | Models | |----------|-------------------|--------| | OpenAI | Summaries only — Requires OpenAI organization verification; falls back to no summaries. | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6.1-terra`, `gpt-6-sol`, `gpt-6-luna`, `gpt-5.6-sol`, `gpt-5.6-terra`, `gpt-5.6-luna`, `gpt-5.5-pro`, `gpt-5.5`, `gpt-5.4-pro`, `gpt-5.4`, `gpt-5.4-mini`, `gpt-5.4-nano`, `gpt-5.3-codex`, `gpt-5.2-pro`, `gpt-5.2`, `gpt-5.1`, `gpt-5-pro`, `gpt-5`, `gpt-5-mini`, `gpt-5-nano`, `o4-mini`, `o3`, `o3-mini`, `o1` | -| Anthropic | Summaries only — These generations omit full thinking; Sim requests summarized thinking on streaming runs. | `claude-fable-5-1`, `claude-fable-5`, `claude-sonnet-5-5`, `claude-sonnet-5`, `claude-opus-5-5`, `claude-opus-5`, `claude-opus-4-8`, `claude-opus-4-7`, `claude-opus-4-6`, `claude-sonnet-4-6`, `claude-opus-4-5`, `claude-sonnet-4-5`, `claude-haiku-5-5`, `claude-haiku-4-5` | +| Anthropic | Summaries only — These generations omit full thinking; Sim requests summarized thinking on streaming runs. | `claude-fable-5-2`, `claude-fable-5-1`, `claude-fable-5`, `claude-sonnet-5-5`, `claude-sonnet-5`, `claude-opus-5-5`, `claude-opus-5`, `claude-opus-4-8`, `claude-opus-4-7`, `claude-opus-4-6`, `claude-sonnet-4-6`, `claude-opus-4-5`, `claude-sonnet-4-5`, `claude-haiku-5-5`, `claude-haiku-4-5` | | Azure OpenAI | Summaries only — Requires OpenAI organization verification; falls back to no summaries. | `azure/gpt-6.1-sol`, `azure/gpt-6-sol`, `azure/gpt-6-luna`, `azure/gpt-6-astra`, `azure/gpt-5.6-sol`, `azure/gpt-5.6-terra`, `azure/gpt-5.6-luna`, `azure/gpt-5.5`, `azure/gpt-5.4-pro`, `azure/gpt-5.4`, `azure/gpt-5.4-mini`, `azure/gpt-5.4-nano`, `azure/gpt-5.2`, `azure/gpt-5.1`, `azure/gpt-5.1-codex`, `azure/gpt-5`, `azure/gpt-5-mini`, `azure/gpt-5-nano`, `azure/o3`, `azure/o4-mini` | | Azure Anthropic | Summaries only — These generations omit full thinking; Sim requests summarized thinking on streaming runs. | `azure-anthropic/claude-fable-5-1`, `azure-anthropic/claude-opus-5-5`, `azure-anthropic/claude-sonnet-5-5`, `azure-anthropic/claude-haiku-5-5`, `azure-anthropic/claude-opus-5`, `azure-anthropic/claude-opus-4-8`, `azure-anthropic/claude-opus-4-7`, `azure-anthropic/claude-opus-4-6`, `azure-anthropic/claude-opus-4-5`, `azure-anthropic/claude-sonnet-5`, `azure-anthropic/claude-sonnet-4-6`, `azure-anthropic/claude-sonnet-4-5`, `azure-anthropic/claude-opus-4-1`, `azure-anthropic/claude-haiku-4-5` | | Google | Summaries only | `gemini-4-argon`, `gemini-3.8-flash`, `gemini-3.7-flash`, `gemini-3.6-flash`, `gemini-3.5-flash-lite`, `gemini-3.5-flash`, `gemini-3.1-pro-preview`, `gemini-3.1-flash-lite`, `gemini-3-flash-preview`, `gemini-2.5-pro`, `gemini-2.5-flash`, `gemini-2.5-flash-lite` | diff --git a/apps/sim/app/llms-full.txt/route.ts b/apps/sim/app/llms-full.txt/route.ts index f1ed68e438a..815e2f84a3d 100644 --- a/apps/sim/app/llms-full.txt/route.ts +++ b/apps/sim/app/llms-full.txt/route.ts @@ -22,6 +22,7 @@ import { linkLine, markdownResponse, navMenuLines, + SECURITY_LINES, SOLUTION_LINES, section, toLlmsMarkdown, @@ -172,6 +173,7 @@ export async function GET() { `- ${max.name}: $${max.dollars} per user per month, ${max.credits.toLocaleString('en-US')} credits.`, '- Enterprise: custom limits, infrastructure, and governance for large organizations.', ]), + section('Security and governance', SECURITY_LINES), section('Solutions', SOLUTION_LINES), section( 'Customer stories', diff --git a/apps/sim/app/llms.txt/llms.ts b/apps/sim/app/llms.txt/llms.ts index ddd8aad98f4..3b374e78bc5 100644 --- a/apps/sim/app/llms.txt/llms.ts +++ b/apps/sim/app/llms.txt/llms.ts @@ -54,6 +54,37 @@ export const SITEMAP_LINE = linkLine( /** One llms.txt entry per `/solutions/*` page. */ export const SOLUTION_LINES = SOLUTIONS.map((s) => linkLine(s.title, s.path, s.description)) +/** Compliance and enterprise identity controls, which buyers check before shortlisting. */ +export const SECURITY_LINES = [ + linkLine( + 'Trust Center', + 'https://trust.sim.ai/', + 'SOC 2 Type II, ISO 27001, and GDPR: reports, policies, and subprocessors' + ), + linkLine( + 'Single sign-on', + `${DOCS_URL}/platform/enterprise/sso`, + 'SAML 2.0 and OIDC, with setup guides for Okta, Microsoft Entra ID, Google Workspace, and AD FS' + ), + linkLine( + 'Directory provisioning', + `${DOCS_URL}/platform/enterprise/scim`, + 'SCIM 2.0 member and group sync from Microsoft Entra ID or Okta' + ), + linkLine( + 'Audit logs', + `${DOCS_URL}/platform/enterprise/audit-logs`, + 'Actor, time, and resource for configuration and security events, with CSV export and data drains' + ), + linkLine( + 'Permission groups', + `${DOCS_URL}/platform/enterprise/access-control`, + 'Restrict features, models, blocks, and tools by workspace and member' + ), + '', + 'On Sim Cloud, single sign-on, directory provisioning, audit logs, and permission groups are part of the Enterprise plan.', +] + /** One llms.txt list entry: `- [title](url): description`. */ export function linkLine(title: string, href: string, description?: string): string { return `- [${title}](${toSiteUrl(href)})${description ? `: ${description}` : ''}` diff --git a/apps/sim/app/llms.txt/route.ts b/apps/sim/app/llms.txt/route.ts index e67c3ad6228..fe89fdc6bc5 100644 --- a/apps/sim/app/llms.txt/route.ts +++ b/apps/sim/app/llms.txt/route.ts @@ -21,6 +21,7 @@ import { markdownResponse, navMenuLines, PRICING_LINE, + SECURITY_LINES, SITEMAP_LINE, SOLUTION_LINES, section, @@ -52,6 +53,7 @@ export async function GET() { ...navMenuLines(PLATFORM_MENU), PRICING_LINE, ]), + section('Security and governance', SECURITY_LINES), section('Solutions', SOLUTION_LINES), section( 'Customers', diff --git a/apps/sim/content/library/ai-agent-platforms-own-fine-tuned-models/index.mdx b/apps/sim/content/library/ai-agent-platforms-own-fine-tuned-models/index.mdx new file mode 100644 index 00000000000..b4ad9a15548 --- /dev/null +++ b/apps/sim/content/library/ai-agent-platforms-own-fine-tuned-models/index.mdx @@ -0,0 +1,172 @@ +--- +slug: ai-agent-platforms-own-fine-tuned-models +title: 'AI Agent Platforms for Running Your Own Fine Tuned Models Compared' +seoTitle: 'AI Agent Platforms for Fine Tuned Models' +description: 'Compare AI agent platforms for connecting fine tuned models through hosted providers, OpenAI compatible endpoints, and local model runtimes.' +date: 2026-11-09 +updated: 2026-11-09 +authors: + - andrew +readingTime: 8 +tags: [AI Agents, Fine Tuned Models, Self Hosting, Sim] +ogImage: /library/ai-agent-platforms-own-fine-tuned-models/cover.jpg +draft: false +faq: + - q: "Which AI agent platforms support fine tuning custom models?" + a: "Sim, n8n, Dify, and the archived Flowise project can call fine tuned or custom models through provider identifiers, deployment configurations, compatible endpoints, or local runtimes, but they generally do not train the model." + - q: "What are the top AI agent builders that let us plug in our own fine tuned model?" + a: "Sim fits self hosted fine tuned model endpoints, n8n fits broader automation, Dify fits provider plugins, and the archived Flowise project offered visual LangChain components." + - q: "Can I use a fine tuned model in an AI agent?" + a: "Sim can use a fine tuned model when the model is deployed through a supported provider or reachable self hosted endpoint and the selected model supports the capabilities the agent needs." + - q: "What is a custom model AI agent builder?" + a: "A custom model AI agent builder connects agent instructions, tools, memory, and workflow logic to a model selected by identifier, deployment, or endpoint." + - q: "Do AI agent platforms fine tune models?" + a: "The platforms in this comparison orchestrate agents around deployed models rather than providing the underlying fine tuning process." + - q: "Can Sim run a self hosted fine tuned model?" + a: "Sim can run agents against a fine tuned model served through Ollama, vLLM, LM Studio, or LiteLLM when Sim is self hosted and can reach the endpoint." + - q: "Can Sim Cloud connect to a local Ollama or vLLM model?" + a: "Sim documents Ollama, vLLM, LM Studio, and LiteLLM as self hosting capabilities, so teams should use a self hosted Sim deployment for those local endpoint paths." + - q: "Does Sim require Enterprise for local models?" + a: "Sim does not require Enterprise for Ollama, vLLM, LM Studio, or LiteLLM on a self hosted deployment." + - q: "Does Sim support BYOK for hosted fine tuned models?" + a: "Sim supports workspace BYOK on every Sim Cloud plan, but using a specific hosted fine tune still depends on the provider integration exposing that model." + - q: "Is BYOK the same as bringing your own model?" + a: "Sim BYOK is not the same as bringing your own model because BYOK supplies provider credentials while a custom model also needs an addressable model identifier, deployment, or endpoint." + - q: "Can n8n run custom models?" + a: "n8n can call custom models through documented model nodes such as Microsoft Foundry and Ollama or through a direct authenticated API request." + - q: "Does n8n train fine tuned models?" + a: "n8n orchestrates calls to a model that a provider or model runtime already serves rather than training the fine tuned model." + - q: "Is n8n open source?" + a: "n8n is source available under the Sustainable Use License, which is based on the fair-code model rather than an OSI-approved open source license." + - q: "Can Dify use an OpenAI compatible custom endpoint?" + a: "Dify supports model provider configuration in which users can supply a model name and base URL for an OpenAI compatible service." + - q: "Can Flowise use a local custom model?" + a: "The archived Flowise project can connect visual flows to local model services through integrations such as Ollama when the deployment can reach the runtime." + - q: "Do these AI agent platforms support Azure OpenAI deployments?" + a: "n8n and the archived Flowise project document Azure OpenAI model integrations, while support should be checked against the exact deployment, API version, authentication method, and model capability required." + - q: "What is the best AI agent platform for a vLLM endpoint?" + a: "Sim fits teams that need a visual builder and a documented base URL configuration for vLLM-compatible model access on a self hosted deployment." + - q: "What is the best AI agent platform for Ollama?" + a: "Sim fits teams building visual agents around Ollama on self hosted infrastructure, while n8n and Dify offer different orchestration approaches." + - q: "Is Sim open source?" + a: "Sim has separate core and enterprise licenses, and production use of enterprise features requires an active Sim Enterprise subscription." + - q: "Is Sim free to self host with a custom model?" + a: "Core custom-model capabilities do not require Enterprise, while production use of enterprise features requires an active Sim Enterprise subscription." + - q: "Is Sim a good n8n alternative for custom models?" + a: "Sim fits teams that want a visual agent workspace and documented self hosted support for Ollama, vLLM, LM Studio, and LiteLLM." + - q: "Is Sim a good Zapier alternative for custom model agents?" + a: "Sim fits custom model agent teams when self hosting and direct control over the model endpoint matter more than conventional application automation alone." + - q: "What should I test before using a fine tuned model in production?" + a: "Test model quality, tool calling, structured outputs, context limits, timeouts, concurrency, endpoint failures, and data handling before sending production traffic to a fine tuned model." +--- + +## TL;DR + +Sim, n8n, and Dify can connect agents to custom models through different routes. Sim fits teams that want a visual workspace with documented support for Ollama, vLLM, LM Studio, and LiteLLM on self hosted infrastructure. n8n fits general automation around model calls, while Dify fits applications organized around model provider plugins. Flowise previously offered composable LangChain-based model flows, but its maintainers [announced the project's wind-down](https://flowiseai.com/sunset) and archived the repository in August 2026, so teams should not select it for a new deployment. + +These platforms generally do not train a model. They orchestrate agents around a fine tuned model that is already available through a provider model identifier, an Azure OpenAI deployment, an OpenAI-compatible endpoint, or a local model runtime. + +As of November 2026, the documented connection options make Sim a fit for self hosted custom model endpoints, n8n a fit for general automation around model calls, and Dify a fit for model provider plugins. + +## Which AI agent platforms support fine tuning custom models? + +Sim, n8n, Dify, and the archived Flowise project can call custom or fine tuned models, although the connection method depends on where the model is hosted. + +| Platform | Fit | Documented connection paths | +| --- | --- | --- | +| Sim | Visual agents using self hosted custom endpoints | [Ollama, vLLM, LM Studio, and LiteLLM](https://docs.sim.ai/platform/self-hosting/environment-variables) on self hosted Sim, plus [provider keys for supported hosted models](https://docs.sim.ai/platform/costs#bring-your-own-key-byok) | +| n8n | Automation surrounding custom model calls | [Microsoft Foundry or Azure OpenAI](https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.lmchatazureopenai/), [Ollama](https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.lmchatollama/), and direct API requests | +| Dify | LLM applications using model provider plugins | [Provider plugins and user-supplied OpenAI-compatible endpoints](https://docs.dify.ai/en/develop-plugin/features-and-specs/plugin-types/model-designing-rules), plus [local model services](https://docs.dify.ai/en/self-host/use-dify/nodes/llm) | +| [Flowise (archived)](https://flowiseai.com/sunset) | Existing composable flows built with LangChain components | Azure ChatOpenAI, ChatOpenAI custom base URLs, and Ollama | + +A hosted fine tune is usually selected through the model identifier exposed by its provider. An Azure OpenAI model is selected through its deployment configuration. A model served by vLLM, Ollama, LM Studio, or LiteLLM is reached through a runtime endpoint available to the agent platform. + +This comparison evaluates the custom model connection path rather than the broader platform category. For that broader decision, see [AI agent platforms and builders compared](https://www.sim.ai/library/best-ai-agent-platforms-2026). + +## What AI agent builders let us plug in our own fine tuned model? + +The useful distinction is not a ranking. Teams should match each platform's documented endpoint options, deployment controls, and orchestration model to their requirements. + +### When does Sim fit a self hosted custom model? + +A self hosted Sim deployment can connect to Ollama through `OLLAMA_URL` and to vLLM, LM Studio, or LiteLLM through the [documented environment variables](https://docs.sim.ai/platform/self-hosting/environment-variables). The [Sim self hosting documentation](https://docs.sim.ai/platform/self-hosting) explains the deployment model, and the [Docker documentation](https://docs.sim.ai/platform/self-hosting/docker) covers the production Compose stack. + +This setup lets a team serve a proprietary fine tune from infrastructure it controls and use that model inside Sim's visual builder. Local model support is a self-hosting capability and does not require Sim Enterprise. + +Workspace BYOK credentials work on every Sim Cloud plan for supported hosted model providers. Organization-level keys require Pro for Teams, Max for Teams, or Enterprise, as described in the [Sim BYOK documentation](https://docs.sim.ai/platform/costs#bring-your-own-key-byok). BYOK is useful when a fine tune remains hosted by a supported provider, but it does not turn a provider model into a self hosted model. + +### When does n8n fit a custom model agent? + +n8n fits when the main requirement is automating applications and data flows around a custom model call. + +n8n documents an [Ollama Chat Model node](https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.lmchatollama/) and a [Microsoft Foundry Chat Model node](https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.lmchatazureopenai/) that connects to Microsoft Foundry or Azure OpenAI resources. Its [HTTP Request node](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/) can also call an authenticated REST API directly. That flexibility can suit a team already using n8n for deterministic automation that wants to insert inference into a larger process. + +Direct API calls can require more manual request, response, and tool orchestration than a model integration designed around the endpoint. + +### When does Dify fit a custom model agent? + +Dify fits teams that want an LLM application environment organized around model provider plugins and reusable model configuration. + +Dify's [model provider documentation](https://docs.dify.ai/en/self-host/use-dify/workspace/model-providers) describes provider installation, workspace-wide keys, and custom endpoint fields. Its [model plugin specification](https://docs.dify.ai/en/develop-plugin/features-and-specs/plugin-types/model-designing-rules) documents user-supplied model names and base URLs for OpenAI-compatible endpoints. Teams can also [deploy Dify with Docker Compose](https://docs.dify.ai/en/self-host/deploy/quick-start/docker-compose). + +This approach can suit teams that want to register a custom inference service and reuse it across application configurations. + +### What should existing Flowise users know? + +Flowise offered visual LangChain components for custom model calls. Its documentation covers [Ollama chat models](https://docs.flowiseai.com/integrations/langchain/chat-models/chatollama), [Azure ChatOpenAI](https://docs.flowiseai.com/integrations/langchain/chat-models/azure-chatopenai-1), and [custom base URLs for ChatOpenAI](https://docs.flowiseai.com/integrations/langchain/chat-models/azure-chatopenai). + +However, Flowise's maintainers announced that they were winding down operations and archived the repository in August 2026. Existing users can evaluate migration needs, but teams choosing a platform for a new project should use an actively maintained option. + +## What are the key facts about custom model support at a glance? + +Sim, n8n, Dify, and Flowise separate agent orchestration from model training, but their licenses, deployment models, and inference billing paths differ. + +1. Sim's core is Apache 2.0, while `apps/sim/ee` uses the separate [Sim Enterprise License](https://github.com/simstudioai/sim/blob/main/apps/sim/ee/LICENSE); under that licensing split, Sim's core can be self hosted, and custom model inference is paid through the selected provider or infrastructure running the endpoint. + +2. n8n uses the source-available [Sustainable Use License](https://github.com/n8n-io/n8n/blob/master/LICENSE.md). n8n supports [cloud and self hosted deployment options](https://docs.n8n.io/choose-how-to-use-n8n/), while model calls made with a team's own provider credentials are billed by that provider. + +3. Dify uses the [Dify Open Source License](https://github.com/langgenius/dify/blob/main/LICENSE), a modified Apache 2.0 license with additional conditions. Dify can be self hosted, and custom provider inference is paid through the provider or the team's own infrastructure. + +4. Flowise is no longer an active option for a new deployment because its repository is archived and its maintainers announced a wind-down. + +These facts are current as of November 2026. They describe software licensing, maintenance status, and model inference responsibility, not a guarantee that every hosted plan exposes every connection method. + +## How do you use a fine tuned model in an AI agent? + +Sim can use a fine tuned model after the model is deployed behind a supported provider or self hosted inference endpoint and made reachable from the Sim deployment. + +1. Deploy the fine tuned model through its original provider, Azure OpenAI, or a runtime such as vLLM, Ollama, LM Studio, or LiteLLM. +2. Record the model identifier, deployment name, base URL, authentication method, context limit, and expected request format. +3. Choose an agent platform with a documented connection path for that hosting method. +4. Configure credentials and endpoint settings without placing secrets inside prompts or workflow inputs. +5. Select the model in the agent or workflow and connect only the tools the agent is allowed to use. +6. Test ordinary requests, malformed inputs, timeouts, tool calls, structured outputs, and context limit failures. +7. Compare the agent against a baseline model using the same evaluation set before moving production traffic. + +For self hosted Sim, use `OLLAMA_URL` for Ollama or the documented `VLLM_BASE_URL` and `LITELLM_BASE_URL` paths for compatible runtimes. Network access still matters because the Sim deployment must be able to reach the inference endpoint. + +## What is the difference between BYOK and bringing your own fine tuned model? + +Sim BYOK supplies credentials for a supported hosted model provider, while bringing a fine tuned model also requires the platform to address the specific model identifier, deployment, or custom endpoint. + +A provider key proves that the agent platform may call the provider. It does not specify which fine tune to use, expose a private endpoint, or make a local runtime reachable. + +For more context, read [how Sim's BYOK model works](https://www.sim.ai/library/byok-multi-model-ai-agent-builder) and the comparison of [agent builders for Claude, Gemini, GPT, and open models](https://www.sim.ai/library/ai-agent-builders-claude-gemini-gpt-open-models). + +## How should you choose a custom model AI agent builder? + +Sim fits a team that prioritizes a visual builder, self hosting, and documented local or OpenAI-compatible runtime paths. Choose n8n when the model call is one step inside a broader automation system. Choose Dify when model provider plugins and LLM application management are the central requirements. Do not start a new deployment on Flowise because the project has been wound down and archived. + +Before choosing a platform, confirm these requirements: + +1. The exact endpoint protocol and authentication method used by the deployed model. +2. Support for the model identifier or Azure deployment name. +3. Network connectivity from the agent runtime to the inference endpoint. +4. Tool calling and structured output compatibility for the selected model. +5. Context limits, timeout behavior, concurrency, and streaming support. +6. Logging rules for prompts, outputs, credentials, and proprietary data. +7. A fallback path when the custom model is unavailable or fails an evaluation. + +## Where can I compare related AI agent platform choices? + +Different comparisons answer different requirements. Read the broader [AI agent platform comparison](https://www.sim.ai/library/best-ai-agent-platforms-2026), the guide to [Claude, Gemini, GPT, and open model builders](https://www.sim.ai/library/ai-agent-builders-claude-gemini-gpt-open-models), the explanation of [BYOK for multi-model agents](https://www.sim.ai/library/byok-multi-model-ai-agent-builder), or the comparison of [self hosted AI workflow automation platforms](https://www.sim.ai/library/best-self-hosted-ai-workflow-automation-platforms-2026). diff --git a/apps/sim/content/library/moving-ai-agent-prototypes-into-production/index.mdx b/apps/sim/content/library/moving-ai-agent-prototypes-into-production/index.mdx new file mode 100644 index 00000000000..16e30a198c7 --- /dev/null +++ b/apps/sim/content/library/moving-ai-agent-prototypes-into-production/index.mdx @@ -0,0 +1,219 @@ +--- +slug: moving-ai-agent-prototypes-into-production +title: 'Moving AI Agent Prototypes Into Production: A Practical Guide' +seoTitle: 'AI Agent Prototypes to Production Guide' +description: 'Move an AI agent prototype into production with a practical checklist for deployment, evaluation, approvals, security, costs, and rollback.' +date: 2026-11-09 +updated: 2026-11-09 +authors: + - andrew +readingTime: 10 +tags: [AI Agents, Deployment, AI Governance, Sim] +ogImage: /library/moving-ai-agent-prototypes-into-production/cover.jpg +draft: false +faq: + - q: "What is the fastest way to move from a prototype to a production AI agent?" + a: "The fastest way to move an AI agent prototype into production is to preserve its validated prompts, tools, models, and business logic while adding deployment, versioning, rollback, logs, cost controls, approvals, access controls, secrets, and evaluation." + - q: "what ai agent tools do people actually use in production" + a: "Production teams use combinations of code frameworks such as LangChain or LangGraph, AI workspaces such as Sim, automation products such as n8n, Zapier, or Make, and dedicated observability or evaluation tools." + - q: "we outgrew our langchain prototype and need something production ready without rebuilding from scratch, what platforms should we evaluate" + a: "Teams that outgrow a LangChain prototype should evaluate Sim, code based orchestration products, integration automation products, and cloud specific agent services according to how much existing logic each option can preserve." + - q: "What should you keep when moving an AI agent prototype into production?" + a: "An AI agent team should keep validated prompts, model settings, tool definitions, output schemas, business rules, working integrations, and representative test cases from the prototype." + - q: "What must a production AI agent platform provide?" + a: "A production AI agent platform must provide repeatable deployment, versioning, rollback, logging, tracing, cost controls, access controls, secret management, failure handling, approvals, and evaluation support appropriate to the use case." + - q: "Should you rewrite an AI agent prototype before deploying it?" + a: "An AI agent prototype should not be rewritten by default because an incremental migration preserves validated behavior and makes regressions easier to isolate." + - q: "How do you evaluate an AI agent before production deployment?" + a: "An AI agent should be evaluated against representative normal, ambiguous, malformed, adversarial, and dependency failure cases with predefined thresholds for quality, safety, latency, and cost." + - q: "Do production AI agents need human approval?" + a: "Production AI agents need human approval when they can take consequential actions that are sensitive, expensive, regulated, or difficult to reverse." + - q: "Can an AI agent prototype be deployed as an API?" + a: "An AI agent prototype can be deployed as an API when the team defines stable inputs, outputs, authentication, timeout behavior, errors, versioning, and operational limits." + - q: "Can an AI agent prototype be deployed as Chat?" + a: "An AI agent prototype can be deployed as Chat when people need an interactive interface and the team defines identity, conversation boundaries, permissions, escalation, and data handling." + - q: "When should a team use Sim instead of staying in LangChain?" + a: "Sim is a strong fit when a team wants a shared visual environment for building, deploying, and managing agents, while LangChain remains appropriate when engineers need extensive code level control over custom behavior." + - q: "When should a team use Sim instead of n8n?" + a: "Sim is a strong fit when models, agent behavior, and human collaboration are central to the system, while n8n is worth evaluating when application integration and deterministic automation dominate the use case." + - q: "Can Sim use local models in a self hosted deployment?" + a: "Sim can use Ollama, vLLM, LM Studio, or LiteLLM on any self hosted Sim deployment, and local model support does not require Sim Enterprise." + - q: "What is the difference between a prototype and a production AI agent?" + a: "A prototype proves that an AI agent can perform a task, while a production AI agent adds repeatable deployment, governance, security, monitoring, evaluation, ownership, and recovery." + - q: "Who should own an AI agent in production?" + a: "A production AI agent should have one accountable business or technical owner with authority over access, releases, evaluation thresholds, incident response, costs, and retirement." + - q: "What is the biggest mistake teams make when moving AI agents into production?" + a: "AI agent teams make their biggest mistake when they treat deployment as the finish line and omit the controls needed to change, evaluate, investigate, stop, and recover the agent safely." +--- + +## TL;DR + +The fastest way to move an AI agent prototype into production is to preserve the validated prompts, models, tools, and business logic while moving execution into an environment that adds deployment, versioning, logs, cost controls, approvals, access controls, secrets, and evaluation. + +A prototype proves that an agent can complete a task under favorable conditions. A production agent must complete that task safely and predictably for real users, real systems, and real budgets. + +## What is the fastest way to move from a prototype to a production AI agent? + +The fastest prototype to production path keeps the agent logic that already works and replaces the fragile operating layer around it. + +Do not begin with a complete rewrite. First capture the current prompts, model settings, tool definitions, data sources, expected outputs, and representative test cases. Then place that behavior inside a production environment with a stable deployment interface and explicit operational controls. + +The shortest practical sequence is: + +1. Define one production use case and one owner. +2. Preserve the working prompts, tools, and model configuration. +3. Create a repeatable evaluation set from successful and failed prototype runs. +4. Deploy the agent through the interface its users need, such as an API endpoint or Chat. +5. Add versioning, rollback, logs, cost limits, approvals, access controls, and secret management. +6. Release the agent to a small user group before expanding access. +7. Review failures and costs against explicit acceptance thresholds. + +A team should postpone architecture changes that do not address a measured production risk. Replacing every component at once makes it harder to determine whether a regression came from the model, prompt, tool integration, data, or deployment environment. + +## What prototype to production checklist should AI and IT leaders use? + +A production AI agent is ready for deployment only when its behavior, ownership, access, costs, and recovery process are explicit. + +### 1. How will users or systems invoke the agent? + +The production agent needs one defined invocation contract before the team adds more features. + +Choose the interface that matches the job. An API is appropriate when another application or service invokes the agent. Chat is appropriate when people need an interactive experience. Scheduled, webhook, and event based triggers fit work that begins from a time or system event. + +Document the accepted inputs, returned outputs, authentication method, timeout behavior, and error response. If the prototype accepts arbitrary notebook variables, convert them into a stable input schema. + +### 2. How will the team version and roll back the agent? + +The production agent needs an identifiable version and a tested rollback path for every deployment. + +Version the prompt, model configuration, tools, routing logic, output schema, and environment dependencies together. Record which version handled each run so that an incident can be reproduced. + +Rollback should restore the last known good configuration without requiring the team to reconstruct it from memory. The detailed process and platform criteria are covered in [AI Agent Version Control and Rollback: Platforms, Process, and Enterprise Checklist](https://www.sim.ai/library/ai-agent-version-control-rollback-platforms). + +### 3. What logging and tracing must the agent capture? + +The production agent needs enough run data to explain what happened without exposing unnecessary sensitive information. + +Capture the request identifier, agent version, model, tool calls, latency, status, token or usage data, and final outcome. Record failures at the step where they occurred rather than treating every unsuccessful run as one generic error. + +Logging answers what happened. Tracing shows the sequence that produced the result. Evaluation determines whether the result was good. [What Is AI Agent Observability? Traces, Metrics, and Evals Explained](https://www.sim.ai/library/ai-agent-observability) explains how these layers differ. + +### 4. How will the team control model and tool costs? + +The production agent needs budget controls at both the run level and the team level. + +Set limits for model usage, iteration count, tool calls, and expensive branches. Use less expensive models where tests show that they meet the required quality threshold. Assign cost ownership so that a growing bill has a responsible reviewer. + +Track cost per successful outcome, not only cost per model call. An inexpensive run that repeatedly fails or creates manual cleanup can cost more than a higher quality run. See [How Do You Control AI Agent Spend Across Teams?](https://www.sim.ai/library/control-ai-agent-spend-across-teams) for a broader governance framework. + +### 5. Where does the agent require human approval? + +The production agent needs human approval before actions whose mistakes are difficult, sensitive, or expensive to reverse. + +Typical approval points include sending external communications, changing customer records, issuing payments, deleting data, granting access, and making regulated decisions. The approval request should show the proposed action, relevant evidence, and the fields the reviewer must complete. + +In Sim, the Human in the Loop block pauses a run and resumes it with submitted form fields. If approval or rejection determines the next action, a downstream Condition must check that field and route the run accordingly. [What Is Human-in-the-Loop in AI Agents?](https://www.sim.ai/library/what-is-human-in-the-loop-in-ai-agents) covers the design pattern in more detail. + +### 6. How will access control and secrets work? + +The production agent needs least privilege access and centrally managed secrets rather than credentials embedded in prompts or code. + +Give the agent access only to the systems, records, and actions required for its job. Separate development and production credentials. Define who can view, change, deploy, and run the agent, and remove sensitive values from logs and evaluation data. + +For regulated or sensitive deployments, map these controls to the requirements in [Enterprise AI Agent Compliance and Deployment Guide: HIPAA, GDPR, Data Residency, On-Prem, and VPC](https://www.sim.ai/library/enterprise-ai-agent-compliance-deployment-guide). + +### 7. How will the team evaluate the agent before release? + +The production agent needs a repeatable evaluation set with pass criteria tied to the business task. + +Turn prototype examples into test cases that include normal inputs, ambiguous requests, malformed data, tool failures, permission failures, and adversarial instructions. Evaluate the final outcome as well as intermediate tool choices. + +Define acceptance thresholds before testing. Useful measures can include task completion, factual correctness, structured output validity, tool selection, policy compliance, latency, and cost per successful result. Averages alone are insufficient when one severe failure can cause material harm. + +### 8. What happens when a model, tool, or dependency fails? + +The production agent needs an explicit failure policy for every external dependency. + +Decide which operations can be retried, which can use a fallback, and which must stop for review. Prevent repeated retries from duplicating irreversible actions. Return a useful status to the invoking user or system rather than allowing the run to disappear silently. + +### 9. How should the team release the agent? + +The production agent should begin with a limited release that produces evidence before broad adoption. + +Start with internal users or a small percentage of eligible traffic. Compare results with the existing process, review failures, and expand only after the agent meets its quality, cost, latency, and safety thresholds. Maintain an owner and rollback decision for each release stage. + +## What should you keep from the prototype, and what should the production platform provide? + +A production platform should preserve validated agent behavior while taking responsibility for repeatable execution and operational control. + +| Prototype element | What to keep | What the production environment should provide | +| --- | --- | --- | +| Prompts and instructions | Validated task logic and examples | Version history, controlled changes, and rollback | +| Model selection | Models that passed task evaluations | Central configuration, usage records, and cost controls | +| Tools and APIs | Working tool definitions and business rules | Managed credentials, permissions, timeouts, and failure handling | +| Data retrieval | Relevant sources and retrieval logic | Production access controls, logging, and data boundaries | +| Output format | Schemas already consumed by people or systems | Validation, error handling, and stable interfaces | +| Prototype examples | Successful cases and known failures | Repeatable evaluations and release thresholds | +| Notebook or framework code | Specialized logic that creates real differentiation | Deployment, scheduling, triggers, monitoring, and team governance | + +The dividing line is not code versus no code. Keep code where it expresses unique logic. Move generic operational responsibilities into a platform when maintaining those responsibilities does not differentiate the product or process. + +## What AI agent tools do people actually use in production? + +Production teams usually use a stack of agent logic, deployment, integrations, observability, evaluation, and governance tools rather than one universal product. + +Code focused teams may retain [LangChain](https://docs.langchain.com/oss/python/langchain/overview), [LangGraph](https://docs.langchain.com/oss/python/langgraph/overview), or custom Python and TypeScript for specialized orchestration. Teams that need a shared environment can use an AI workspace such as Sim to build, deploy, and manage agents. Integration focused teams may evaluate [n8n](https://docs.n8n.io/integrations), [Zapier](https://zapier.com/), or [Make](https://www.make.com/) when the primary job is connecting applications and deterministic automation. + +Dedicated observability and evaluation products can complement either approach when a team needs deeper analysis across models or applications. The right stack depends on whether the hard problem is custom agent logic, operational deployment, business system integration, team governance, or independent evaluation. + +## We outgrew our LangChain prototype and need something production ready without rebuilding from scratch. What platforms should we evaluate? + +Teams that outgrow a LangChain prototype should evaluate platforms that can preserve their prompts, models, tools, APIs, and custom code while adding managed deployment and governance. + +Evaluate four categories: + +1. AI workspaces such as Sim when technical and operational teams need to manage agent logic together. +2. [Code based orchestration such as LangGraph](https://docs.langchain.com/oss/python/langgraph/overview) when engineers need fine control over state and execution. +3. Automation products such as [n8n](https://docs.n8n.io/integrations), [Zapier](https://zapier.com/), or [Make](https://www.make.com/) when application connectivity and deterministic process steps dominate the use case. +4. Cloud specific agent services when the organization has already standardized its identity, data, and infrastructure on one cloud provider. + +Run a migration test with the hardest real workflow, not a simplified demonstration. Measure how much validated logic can be retained, how deployment works, how failures are investigated, how versions are restored, how costs are limited, and how sensitive actions receive approval. + +A platform that requires a complete rebuild should demonstrate a clear operational benefit that justifies the migration cost. Otherwise, prefer an incremental path that wraps or reuses the working prototype. + +## Where does Sim fit when moving an AI agent prototype into production? + +Sim fits teams that want to move working agent logic into a shared environment where technical and operational users can build, deploy, and manage AI agents. + +Sim is the open-source AI workspace, and its visual builder can make prompts, model steps, tool calls, conditions, and approval points easier for a wider team to inspect and change. Sim fits especially well when the production challenge is no longer proving that the model works, but making the complete process deployable, understandable, and governable. + +Sim should not force a team to discard valuable custom logic. Keep specialized services or code where they provide a real advantage, then connect them to the managed workflow through defined interfaces. + +For teams that [self-host Sim](https://docs.sim.ai/platform/self-hosting), local models can run through Ollama, vLLM, LM Studio, or LiteLLM. Local model support is a self-hosting capability and does not require Sim Enterprise. Model choice should still be validated against the same production evaluation set used for hosted models. + +## When should you stay in code instead of moving to a workspace? + +Code remains the better primary environment when the agent depends on novel algorithms, complex state, unusual runtime behavior, or engineering controls that a workspace cannot represent cleanly. + +Stay in code when most changes require software engineers, the agent is part of a larger application release, or custom execution is itself a product advantage. Use a workspace when the larger problem is coordinating models, tools, business systems, approvals, schedules, and ownership across a team. + +A hybrid architecture is often practical. A coded service can retain specialized logic while Sim coordinates the broader process, deployment interface, and human steps. The team should choose the boundary that minimizes duplicated operational work without hiding important behavior. + +## What should AI and IT leaders decide before approving production deployment? + +AI and IT leaders should approve a production agent only when one accountable owner can explain its purpose, access, limits, evidence, and recovery process. + +The approval record should answer these questions: + +1. What business outcome does the agent own? +2. Who owns the agent after deployment? +3. Which users and systems can invoke it? +4. Which data and credentials can it access? +5. Which actions require human approval? +6. Which version is running? +7. What evaluation evidence supports release? +8. What are the quality, cost, and latency thresholds? +9. How will failures be detected and investigated? +10. How will the team stop or roll back the agent? + +An agent is not production ready because it completed one impressive demonstration. It is production ready when the organization can operate it through normal changes, failures, audits, and ownership transitions. diff --git a/apps/sim/content/library/self-hosted-ai-agent-use-cases-engineering-teams/index.mdx b/apps/sim/content/library/self-hosted-ai-agent-use-cases-engineering-teams/index.mdx new file mode 100644 index 00000000000..729214128be --- /dev/null +++ b/apps/sim/content/library/self-hosted-ai-agent-use-cases-engineering-teams/index.mdx @@ -0,0 +1,249 @@ +--- +slug: self-hosted-ai-agent-use-cases-engineering-teams +title: '10 Self Hosted AI Agent Use Cases for Engineering Teams' +seoTitle: '10 Self Hosted AI Agent Use Cases' +description: 'Explore 10 self hosted AI agent use cases for engineering teams, from incident triage and CI diagnosis to deployment checks and status reports.' +date: 2026-11-09 +updated: 2026-11-09 +authors: + - andrew +readingTime: 10 +tags: [AI Agents, Self Hosting, Engineering, Open Source, Sim] +ogImage: /library/self-hosted-ai-agent-use-cases-engineering-teams/cover.jpg +draft: false +faq: + - q: "What are common AI agent use cases for development teams that want to run everything on open source infrastructure?" + a: "Sim can support incident triage, pull request summaries, release notes, on call handoffs, documentation search, security alert routing, CI failure analysis, issue triage, deployment checks, and engineering reports on self hosted infrastructure." + - q: "Our dev team wants to build internal automation agents without vendor lock in, what open source AI agent frameworks are best suited for that?" + a: "Sim fits teams that want an Apache 2.0 core, a visual workflow builder, self hosting, and portable model connections, while LangGraph and CrewAI suit teams that prefer code first orchestration or multiagent experimentation." + - q: "We're a small engineering team evaluating open source AI agent frameworks that let us self host and avoid per task pricing. What should we choose?" + a: "Sim is a strong choice for a small engineering team that wants to self host its agent workspace and replace hosted per task charges with infrastructure, maintenance, and model costs it can control." + - q: "Is Sim fully Apache 2.0 licensed?" + a: "Sim's core is Apache 2.0, but apps/sim/ee is governed by the separate Sim Enterprise License and requires an active Sim Enterprise subscription for production use." + - q: "Is n8n open source?" + a: "n8n is source available under the Sustainable Use License, not open source under an OSI approved license, as of November 2026." + - q: "Can Sim run local models on a self hosted deployment?" + a: "Sim can use Ollama, vLLM, LM Studio, or LiteLLM on any self hosted Sim deployment without requiring Sim Enterprise." + - q: "Can a self hosted AI agent avoid per task pricing?" + a: "A self hosted Sim deployment can avoid a hosted platform's per task billing model, but the team still pays for infrastructure, model inference, storage, observability, and maintenance." + - q: "What is the safest first AI agent use case for an engineering team?" + a: "Sim should first automate a read heavy task such as pull request summarization, on call handoff preparation, or internal documentation search because the output is easy for an engineer to review before action." + - q: "Should an AI agent be allowed to deploy code automatically?" + a: "Sim should not receive unrestricted deployment authority until the workflow has deterministic policy checks, reliable evaluations, complete logs, and an explicit human approval step for consequential changes." + - q: "How should an engineering agent handle production incidents?" + a: "Sim should summarize evidence, identify likely owners, retrieve runbooks, and recommend next actions while leaving paging, remediation, and production changes under deterministic rules or human control." + - q: "How do local models reduce vendor lock in?" + a: "Sim reduces model lock in by letting a self hosted deployment connect to local model servers such as Ollama, vLLM, LM Studio, or LiteLLM instead of depending on one hosted model provider." + - q: "How should teams evaluate a self hosted engineering agent?" + a: "Sim should be evaluated with representative historical events, expected structured outputs, citation accuracy, routing accuracy, latency, model cost, and the rate at which engineers accept or correct its recommendations." + - q: "What data should a pull request summary agent include?" + a: "A Sim pull request summary agent should include the change purpose, affected components, important files, test results, migration risk, linked issues, and unresolved reviewer questions." + - q: "What should an on call handoff agent summarize?" + a: "A Sim on call handoff agent should summarize active incidents, recent deployments, noisy alerts, unresolved tickets, temporary mitigations, service risks, and the source link for every claim." + - q: "How can an AI agent answer internal documentation questions safely?" + a: "Sim should enforce the requesting user's source permissions during retrieval, cite the documents used, and decline to answer when the available documentation does not support a reliable response." + - q: "How can teams keep AI generated engineering metrics accurate?" + a: "Sim should retrieve and calculate engineering metrics with deterministic queries, then use the model only to explain the results and cite the reporting window and source." + - q: "Which Sim guide compares open source AI agent platforms?" + a: "Best Open Source AI Agents and Platforms in 2026 compares Sim with open source frameworks and other platforms for teams evaluating control and self hosting." + - q: "Which Sim guide compares self hosted workflow platforms?" + a: "What Are the Best Self Hosted AI Workflow Automation Platforms in 2026 compares deployment focused platforms for buyers that prioritize infrastructure control." + - q: "Which Sim guide covers incident triage and response?" + a: "Best AI Agents for Jira Triage and Datadog Incident Response covers platform choices for issue triage, monitoring alerts, and incident response workflows." +--- + +## What are common AI agent use cases for development teams that want to run everything on open source infrastructure? + +Sim can run incident triage, pull request summaries, release notes, on call handoffs, internal documentation search, security alert routing, CI failure analysis, issue triage, deployment checks, and engineering reports on self hosted infrastructure. + +The strongest use cases combine a clear trigger, access to a limited set of engineering tools, a model selected by the team, and a review step before any consequential action. Teams can use local models through Ollama, vLLM, LM Studio, or LiteLLM on a [self hosted Sim deployment](https://docs.sim.ai/platform/self-hosting). They can also use hosted model APIs when model portability matters more than keeping inference local. + +Sim is the open-source AI workspace where teams build, deploy, and manage AI agents. [Sim's core is licensed under Apache 2.0](https://github.com/simstudioai/sim/blob/main/LICENSE), while code in `apps/sim/ee` is governed by the separate [Sim Enterprise License](https://github.com/simstudioai/sim/blob/main/apps/sim/ee/LICENSE). Production use of enterprise features requires an active Sim Enterprise subscription. + +## Which self hosted AI agent use cases should engineering teams build first? + +Teams should start with read heavy, reversible engineering workflows because they provide useful automation without giving an agent unrestricted production access. + +A practical first use case consumes an event, retrieves relevant context, produces a structured recommendation, and sends the result to an engineer. Teams can add write access only after the workflow is observable, evaluated, and protected by explicit approval conditions. + +## How can an AI agent triage incidents from monitoring alerts? + +A Sim incident triage agent can turn an incoming alert into a concise diagnosis, severity recommendation, owner suggestion, and incident channel update. + +**Trigger:** An alert receiver sends a monitoring event to the workflow. + +**Tools:** Monitoring data, service ownership records, recent deployment records, runbooks, an issue tracker, and a team messaging system. + +**Model option:** A local model through Ollama, vLLM, LM Studio, or LiteLLM can keep alert context inside the [self hosted environment](https://docs.sim.ai/platform/self-hosting). A hosted model can be used when the team accepts external inference. + +**Build note:** Give the agent read access first, require structured fields for severity and evidence, and put a human decision before paging another team or changing production systems. + +For a focused platform comparison, read [Best AI Agents for Jira Triage and Datadog Incident Response](https://www.sim.ai/library/best-ai-agents-jira-triage-datadog-incident-response). + +## How can an AI agent summarize pull requests for reviewers? + +A Sim pull request agent can summarize the purpose, affected components, test coverage, migration risk, and unresolved reviewer questions for each pull request. + +**Trigger:** The source control system reports that a pull request was opened or updated. + +**Tools:** The pull request diff, repository documentation, ownership files, test results, and linked issues. + +**Model option:** A local code model can process repository context without sending source code to an external model provider. A hosted model can be selected for repositories whose security policy permits it. + +**Build note:** Ask the agent to cite file paths and changed functions, separate observed changes from inferred risk, and post a summary rather than an approval decision. + +## How can an AI agent generate release notes? + +A Sim release notes agent can convert merged changes, issue records, and deployment metadata into internal and customer facing release summaries. + +**Trigger:** A release branch is cut, a version tag is created, or a deployment completes. + +**Tools:** Commit history, pull requests, issue records, deployment metadata, and the documentation repository. + +**Model option:** A local general purpose model is usually sufficient when the workflow retrieves clean change metadata. A hosted model can help when the input is large or inconsistent. + +**Build note:** Generate separate engineering and customer versions, exclude internal security details, and require a release owner to approve the final text. + +## How can an AI agent prepare on call handoffs? + +A Sim on call handoff agent can assemble active incidents, noisy alerts, recent deployments, unresolved tickets, and known risks into one shift summary. + +**Trigger:** A schedule starts the workflow before an on call rotation changes. + +**Tools:** The incident tracker, monitoring system, deployment log, issue tracker, runbooks, and team messaging system. + +**Model option:** A local model can summarize operational records inside the team's network. A hosted model remains an option when the records are approved for external processing. + +**Build note:** Preserve links and timestamps for every claim so the incoming engineer can inspect the original evidence instead of trusting an unsupported summary. + +## How can an AI agent answer questions from internal engineering documentation? + +A Sim documentation agent can answer engineering questions by retrieving relevant runbooks, architecture decisions, service documentation, and post incident reviews before generating a cited response. + +**Trigger:** An engineer asks a question through an approved chat or internal interface. + +**Tools:** A document index, repository documentation, access control metadata, and the team's chat interface. + +**Model option:** Local embeddings and a local model can keep document retrieval and generation inside self hosted infrastructure. A hosted model can be substituted without redesigning the workflow when the model interface remains portable. + +**Build note:** Enforce source permissions during retrieval, return citations with every answer, and allow the agent to say that the available documentation does not support an answer. + +For a deeper comparison of this use case, read [Best AI Agents for Internal Knowledge Search Across Docs and Tools](https://www.sim.ai/library/best-ai-agents-internal-knowledge-search). + +## How can an AI agent route dependency and security alerts? + +A Sim security routing agent can enrich a dependency or vulnerability alert with ownership, exposure, repository activity, and remediation context before assigning it to the right team. + +**Trigger:** A dependency scanner, vulnerability scanner, or repository service emits a new alert. + +**Tools:** The alert payload, software inventory, ownership records, repository metadata, issue tracker, and messaging system. + +**Model option:** A local model is appropriate when vulnerability details and source context must stay inside the environment. Hosted inference can be used when policy permits it. + +**Build note:** Let deterministic rules control severity thresholds and escalation, while the model summarizes evidence and proposes remediation steps. + +## How can an AI agent diagnose CI failures? + +A Sim CI diagnosis agent can classify a failed build, identify likely causes, retrieve similar failures, and suggest the next debugging action. + +**Trigger:** The continuous integration system reports a failed job. + +**Tools:** Build logs, test output, recent commits, historical failure records, repository documentation, and issue search. + +**Model option:** A local code model can analyze logs and source context without exporting them. A hosted model can be used for approved repositories or especially large contexts. + +**Build note:** Require the agent to quote the relevant log lines, label its diagnosis as a hypothesis, and avoid automatically changing code until the team has evaluated its accuracy. + +## How can an AI agent triage engineering issues and bug reports? + +A Sim issue triage agent can classify a new report, detect likely duplicates, request missing reproduction details, and recommend an owner and priority. + +**Trigger:** A user or internal system creates an issue. + +**Tools:** Issue history, ownership records, product documentation, recent release notes, and repository metadata. + +**Model option:** A smaller local model can handle classification and field extraction, while a larger local or hosted model can compare longer issue histories. + +**Build note:** Return structured fields for component, severity, duplicate candidate, missing information, and confidence so routing remains inspectable. + +## How can an AI agent check deployment risk before a release? + +A Sim deployment risk agent can compare a proposed release with test results, recent incidents, dependency changes, ownership data, and change window policy before recommending proceed, review, or stop. + +**Trigger:** A deployment candidate reaches a defined preproduction stage. + +**Tools:** Deployment metadata, test results, incident history, dependency records, service ownership, and policy documents. + +**Model option:** A local model can keep operational context private. A hosted model can be used if the organization permits the relevant metadata to leave its environment. + +**Build note:** Keep the final deployment gate deterministic and require an explicit human decision when the recommendation is review or stop. + +## How can an AI agent produce engineering status reports? + +A Sim engineering reporting agent can turn issue movement, deployments, incidents, and service metrics into a concise weekly report with links to evidence. + +**Trigger:** A weekly schedule or reporting request starts the workflow. + +**Tools:** Issue trackers, deployment logs, incident records, service metrics, and the reporting destination. + +**Model option:** A local model can summarize internal operational data, while a hosted model can be selected when data policy allows it. + +**Build note:** Calculate metrics with deterministic queries, use the model only for synthesis, and include the reporting window and source for every number. + +## Which open source AI agent frameworks fit internal engineering automation? + +Sim fits engineering teams that want a visual workspace, self hosting, portable model connections, and inspectable workflows without adopting a code only orchestration framework. This fit applies to Sim's Apache 2.0 core, with the enterprise exception described in the [Sim Enterprise License](https://github.com/simstudioai/sim/blob/main/apps/sim/ee/LICENSE). + +[LangGraph is a code first option](https://docs.langchain.com/oss/python/langgraph/overview) for teams that want explicit state management inside an application. [CrewAI supports agents defined around roles, goals, tools, and collaboration](https://docs.crewai.com/v1.15.34/en/concepts/agents), which can suit multiagent experiments. Sim fits teams that want to connect triggers, tools, models, conditions, and approvals in one visual workflow builder. + +n8n is another automation product that buyers evaluate for this job, but its current licenses are based on the fair-code model rather than an OSI-approved open-source license. As of November 2026, n8n documents its main repository under the [Sustainable Use License with stated exceptions](https://docs.n8n.io/n8n-community-license). Teams that need an OSI-approved core license should distinguish n8n's licensing model from Sim's Apache 2.0 core. + +For a complete framework and platform comparison, read [Best Open Source AI Agents and Platforms in 2026](https://www.sim.ai/library/open-source-ai-agent-platforms). + +## What facts should teams compare before choosing Sim or n8n? + +Sim and n8n differ most clearly in licensing, agent building focus, and how teams evaluate long term portability. + +As of November 2026, Sim's core uses the OSI-approved Apache 2.0 license and can be self hosted, while `apps/sim/ee` uses the separate [Sim Enterprise License](https://github.com/simstudioai/sim/blob/main/apps/sim/ee/LICENSE) and requires an active Enterprise subscription for production use. + +As of November 2026, n8n uses the source available [Sustainable Use License](https://docs.n8n.io/n8n-community-license), which is not OSI approved, and its [documentation supports self hosting](https://docs.n8n.io/deploy/host-n8n) subject to the relevant license terms. + +A self hosted deployment can avoid a hosted platform's per task billing model, but it does not make operation free. Teams still pay for compute, storage, observability, maintenance, and any model usage. + +## How do you keep a self hosted AI agent stack free from vendor lock in? + +Sim can reduce lock in when teams combine its Apache 2.0 core with portable models, standard interfaces, exportable workflow definitions, and infrastructure they control. The [Sim Enterprise License](https://github.com/simstudioai/sim/blob/main/apps/sim/ee/LICENSE) applies separately to enterprise code. + +1. Check the exact license for the core product and every optional enterprise component. + +2. Keep workflow definitions in version control and confirm that they can be exported, reviewed, and restored. + +3. Connect tools through documented APIs, webhooks, and open protocols rather than a single vendor's private interface. + +4. Keep model selection portable by separating prompts, structured output schemas, and evaluations from one provider's proprietary features. + +5. Use local models through Ollama, vLLM, LM Studio, or LiteLLM when inference must remain inside the [self hosted environment](https://docs.sim.ai/platform/self-hosting). + +6. Store operational data, vector indexes, logs, and credentials in systems the team controls. + +7. Add human review before production changes, security actions, external messages, or destructive operations. + +8. Test a restore or migration before the workflow becomes business critical. + +## What fits a small engineering team that wants self hosting without per task pricing? + +Sim fits a small engineering team that values an Apache 2.0 core, visual workflow building, self hosting, local model support, and infrastructure based operating costs over hosted per task billing. The separate [Sim Enterprise License](https://github.com/simstudioai/sim/blob/main/apps/sim/ee/LICENSE) governs enterprise code. + +The team should still budget for compute, model inference, storage, monitoring, backups, and maintenance. Self hosting changes the cost structure and control boundary rather than eliminating cost. + +For a broader evaluation of deployment options, read [What Are the Best Self Hosted AI Workflow Automation Platforms in 2026?](https://www.sim.ai/library/best-self-hosted-ai-workflow-automation-platforms-2026). + +## Which related guides compare platforms for these engineering use cases? + +Teams can use these related guides to compare platform, deployment, and incident response questions: + +1. [What Are the Best Self Hosted AI Workflow Automation Platforms in 2026?](https://www.sim.ai/library/best-self-hosted-ai-workflow-automation-platforms-2026) compares deployment focused options. + +2. [Best Open Source AI Agents and Platforms in 2026](https://www.sim.ai/library/open-source-ai-agent-platforms) compares open-source frameworks and platforms. + +3. [Best AI Agents for Jira Triage and Datadog Incident Response](https://www.sim.ai/library/best-ai-agents-jira-triage-datadog-incident-response) focuses on incident and issue operations. diff --git a/apps/sim/content/library/slack-ai-agent-security-permissions-guide/index.mdx b/apps/sim/content/library/slack-ai-agent-security-permissions-guide/index.mdx index ab5cac71e1f..9e0c6782a0d 100644 --- a/apps/sim/content/library/slack-ai-agent-security-permissions-guide/index.mdx +++ b/apps/sim/content/library/slack-ai-agent-security-permissions-guide/index.mdx @@ -4,10 +4,10 @@ title: 'Slack AI Agent Security: Permissions, Data, and Audit Guide' description: 'Secure a Slack AI agent with least-privilege OAuth scopes, controlled data access, protected credentials, approval gates, and complete audit evidence.' seoTitle: 'Slack AI Agent Security: Permissions and Audit Guide' date: 2026-10-03 -updated: 2026-10-24 +updated: 2026-11-09 authors: - andrew -readingTime: 15 +readingTime: 22 tags: [AI Agents, Security, Slack, Governance, Sim] ogImage: /library/slack-ai-agent-security-permissions-guide/cover.jpg draft: false @@ -57,20 +57,34 @@ faq: - q: "Is n8n open source?" a: "n8n is source-available under the Sustainable Use License rather than an OSI-approved open-source license. Organizations can self-host n8n subject to that license's conditions and restrictions." - q: "Is Sim or n8n better for a secure Slack AI agent?" - a: "Sim is the stronger choice when a team prioritizes an Apache 2.0 core, visual agent control, conditional approval paths, and optional enterprise governance features, while n8n remains a capable incumbent for teams already operating its workflow ecosystem. Security still depends on how either platform's Slack scopes, credentials, tools, approvals, and logs are configured." + a: "Sim fits teams that prioritize an Apache 2.0 core, visual agent control, conditional approval paths, and optional enterprise governance features, while n8n fits teams already operating its workflow ecosystem. Security still depends on how either platform's Slack scopes, credentials, tools, approvals, and logs are configured." - q: "What is the best AI agent platform for Slack?" a: "Sim is a strong AI agent platform for Slack when teams need controlled multi-step workflows, human approval, self-hosting options, and explicit routing around model and tool decisions. Best AI Agents for Slack provides the focused product comparison, while Best AI Agent Platforms and Builders in 2026 covers the broader platform market." - q: "What should be tested before a Slack AI agent goes live?" a: "A Slack AI agent should be tested for unauthorized installation, excessive scopes, forbidden channel access, secret leakage, direct and indirect prompt injection, unsafe tool arguments, approval bypass, replayed requests, incomplete logs, revocation, and rollback." + - q: "Can we require human approval in Teams or Slack before an AI agent acts on a security alert?" + a: "Slack and Microsoft Teams can require human approval by pausing the workflow, recording an authorized reviewer's decision, and allowing the action only when a deterministic condition confirms approval. In Sim, Human in the Loop collects the decision, and a downstream Condition must route the approved and rejected outcomes." + - q: "How do you build interactive security agents in Slack or Teams that trigger processes and approve actions?" + a: "Sim builds interactive security agents by separating message intake, decision support, authorization, approval, and execution into distinct workflow stages. Privileged credentials should be available only after identity and approval conditions pass." + - q: "What is Slack AI security?" + a: "Slack AI security is the set of identity, OAuth, data access, approval, logging, and retention controls that govern how an AI system reads Slack data and performs actions. Slack permissions alone are not sufficient because the workflow must also authorize the person requesting each action." + - q: "How do I implement RBAC and least privilege for agent tools like email Slack and Jira?" + a: "Sim workflows should implement RBAC and least privilege by checking the requester's identity, limiting each connection to required resources and actions, and placing sensitive tools after deterministic approval conditions. The connected service must remain the final enforcement point for the credential's permissions." + - q: "How can a team share one AI agent in Slack while each person keeps their own tool permissions?" + a: "Sim personal credentials resolve only under an authorized personal identity and the execution identity determined by the trigger, so a Slack requester does not automatically select that person's credential. A secure design must map the requester to an authenticated Sim identity and eligible personal connection, reject missing mappings, and never fall back to a more privileged shared credential." + - q: "How can I securely connect Slack to my AI agent?" + a: "Slack can be connected securely to an AI agent by using OAuth, granting only necessary scopes, validating signed requests, protecting tokens, mapping Slack users to authorized identities, and requiring approval for privileged actions." --- ## TL;DR +Slack and Microsoft Teams can require human approval before an AI agent acts on a security alert by pausing the workflow, recording an authorized reviewer's decision, and continuing only when a deterministic condition confirms approval. In Sim, Human in the Loop collects the decision, while a downstream Condition routes on the submitted field. + A secure Slack AI agent uses least-privilege OAuth scopes, restricted installation and channel access, controlled data retention, protected credentials, approval gates for consequential actions, and end-to-end audit evidence. Slack agents operate inside conversations that may contain customer data, source code, credentials, legal discussions, personnel information, and instructions from people the agent was never designed to trust. Security therefore depends on more than the model: teams must control what the Slack app can read, what the agent can do, where data flows, and how every sensitive action is reviewed. -As of October 2026, Slack documents these controls across its official guidance for [OAuth scopes](https://docs.slack.dev/reference/scopes/), [app management settings](https://slack.com/help/articles/222386767-Manage-app-approval-for-your-workspace), [request verification](https://docs.slack.dev/authentication/verifying-requests-from-slack), and the [Audit Logs API](https://docs.slack.dev/admins/audit-logs-api). +As of November 2026, Slack documents these controls across its official guidance for [OAuth scopes](https://docs.slack.dev/reference/scopes/), [app management settings](https://slack.com/help/articles/222386767-Manage-app-approval-for-your-workspace), [request verification](https://docs.slack.dev/authentication/verifying-requests-from-slack), and the [Audit Logs API](https://docs.slack.dev/admins/audit-logs-api). ## How do you secure an AI agent in Slack? @@ -87,6 +101,18 @@ A practical security model has six layers: The strongest design assumes that a malicious instruction can reach the agent. The controls surrounding the model must keep that instruction from becoming an unauthorized action. +## What are the key Slack AI agent security controls? + +Slack AI agent security depends on narrow OAuth scopes, identity-aware credentials, explicit approval for high-impact actions, deterministic authorization checks, and complete execution evidence. + +1. Give the Slack app only the scopes required for its defined use case. +2. Keep read permissions separate from write permissions. +3. Use personal credentials only when the execution identity and integration support them. +4. Require approval before destructive, privileged, external, or costly actions. +5. Check approval results with deterministic workflow conditions. +6. Record the requester, proposed action, reviewer, decision, target system, and final result. +7. Revoke unused tokens and review scopes after every material workflow change. + ## What should be included in a Slack AI agent threat model? A Slack AI agent threat model should cover unauthorized installation, excessive scopes, unintended channel access, data leakage, prompt injection, credential theft, unsafe tool calls, approval bypass, and incomplete audit evidence. @@ -111,6 +137,23 @@ A Slack AI agent should request only the Slack OAuth scopes needed for named fea Slack uses [granular scopes](https://docs.slack.dev/reference/scopes/) to authorize API capabilities. Common examples include `app_mentions:read` for receiving mentions, `chat:write` for posting messages, `channels:history` for public-channel history, `groups:history` for private-channel history, `im:history` for direct-message history, `files:read` for files, and `commands` for slash commands. A scope should not be added merely because it might be useful later. +### What Slack OAuth scopes does an AI agent actually need? + +As of November 2026, Slack documents bot token scopes individually in its [OAuth scope reference](https://docs.slack.dev/reference/scopes/). Add scopes incrementally rather than copying a broad manifest. + +| Agent requirement | Slack bot scope | When it is needed | When to omit it | +|---|---|---|---| +| Send messages as the app | `chat:write` | The agent posts replies, alerts, or approval requests | The agent never posts to Slack | +| Receive slash commands | `commands` | A custom Slack app exposes a slash command | The workflow uses no slash commands | +| Read app mentions | `app_mentions:read` | The agent responds when users mention the app | The agent uses only commands or another trigger | +| Read public channel messages | `channels:history` | The use case requires public channel history | Mentions or explicit message payloads provide enough context | +| Read private channel messages | `groups:history` | The app must read private channel history and has been added to that channel | The use case does not require private channel history | +| Read direct messages | `im:history` | The agent must process direct message history | Direct message history is unnecessary | +| Read group direct messages | `mpim:history` | The agent must process group direct message history | Group direct messages are outside the use case | +| Read basic user information | `users:read` | The workflow must map Slack users to an authorization rule | The workflow does not need user directory data | + +Slack scope names and behavior can change. The authoritative sources are Slack's scope reference and its [app manifest documentation](https://docs.slack.dev/app-manifests/). A scope permits the app to request an operation, but the workflow must still authorize the requester. + Use this review process: 1. Start with the exact user journeys the agent must support. @@ -179,7 +222,7 @@ Slack retention settings do not automatically delete copies held by an agent, mo Slack bot tokens, Slack signing secrets, model keys, and downstream API credentials should be stored in a managed secret system and injected only into the component that needs them. -A Slack signing secret verifies that an inbound request came from Slack; it is not an API token and should not be reused as one. As of October 2026, Slack's official [request-verification guidance](https://docs.slack.dev/authentication/verifying-requests-from-slack) requires validating the signature and timestamp over the raw request body and rejecting stale requests to reduce replay risk. +A Slack signing secret verifies that an inbound request came from Slack; it is not an API token and should not be reused as one. As of November 2026, Slack's official [request-verification guidance](https://docs.slack.dev/authentication/verifying-requests-from-slack) requires validating the signature and timestamp over the raw request body and rejecting stale requests to reduce replay risk. Apply these controls: @@ -193,6 +236,23 @@ Apply these controls: Teams should track where credentials are introduced and used during execution so an incident review can identify every affected system. +### How can I securely connect Slack to my AI agent? + +Use this implementation sequence: + +1. Create or select the Slack app used for the integration. +2. Define the smallest set of bot scopes required by the use case. +3. Install the app through Slack OAuth rather than copying user tokens into prompts or workflow inputs. +4. Validate Slack signatures and request timestamps for commands and interactive requests. +5. Store the signing secret, client secret, and access tokens in managed credential storage. +6. Map Slack users to application identities and allowed roles. +7. Put write actions behind explicit conditions and approvals. +8. Log the requester, workflow version, tool call, reviewer, decision, and outcome. +9. Revoke credentials when ownership or access requirements change. +10. Reassess scopes whenever the workflow gains a new tool or action. + +Slack's [request verification documentation](https://docs.slack.dev/authentication/verifying-requests-from-slack) describes the signed request process. As of November 2026, it specifies validating the signature and timestamp before processing an incoming request. + ## How should a Slack AI agent control external actions? A Slack AI agent should authorize every external action against the requesting identity, approved use case, target resource, and action risk instead of trusting the model's decision alone. @@ -210,12 +270,53 @@ Classify actions by impact: Tool arguments should be validated against schemas and policy. The executor should reject unexpected destinations, identifiers, commands, file paths, and URLs even when the model produced syntactically valid output. +## How do you build interactive security agents in Slack or Teams that trigger processes and approve actions? + +An interactive security agent should separate conversation, decision support, authorization, and execution into distinct workflow stages. + +| Layer | Responsibility | Security rule | +|---|---|---| +| Conversation | Receive a command, mention, alert, or approval response | Treat all message content as untrusted input | +| Decision support | Collect context and propose a response | Do not grant this stage privileged credentials | +| Authorization | Confirm identity, role, target, and approval | Use deterministic conditions rather than model judgment | +| Execution | Call Slack, Jira, GitHub, AWS, or another system | Expose only the exact action and credential required | + +For Slack slash commands, Sim requires a custom Slack bot with its own signing secret. The native Sim Slack app cannot deploy slash command triggers. Verify Slack request signatures, reject stale requests, and authorize the requester before starting a privileged workflow. + +For Microsoft Teams, apply the same separation of duties: authenticate the requester, constrain the proposed action, collect approval from an authorized reviewer, and execute only through the approved branch. + +## How do I implement RBAC and least privilege for agent tools like email, Slack, and Jira? + +Role based access control for AI agents should constrain who may invoke the agent, which tools it may call, which records those tools may access, and which actions require approval. + +| System | Least privilege checklist | +|---|---| +| Slack | Separate read and write scopes. Restrict channel membership. Avoid message history scopes unless the use case requires them. Validate request signatures. Map the requesting Slack identity to an allowed role. | +| Jira | Use a dedicated integration identity or an authorized personal connection. Restrict project permissions. Separate issue reading from creation, editing, transition, and deletion. Require approval for bulk changes or sensitive projects. | +| GitHub | Prefer repository-specific installation access. Grant contents, issues, pull requests, or actions permissions only when required. Keep administrative permissions out of general agent workflows. Protect production branches independently of the agent. | +| AWS | Use a dedicated IAM role with explicit actions and resources. Prefer temporary credentials. Add conditions for account, region, resource tags, and request context. Require approval for destructive or privilege-changing operations. | +| Email | Separate reading, drafting, and sending permissions. Require approval for external recipients, bulk sends, sensitive attachments, and mailbox rule changes. Limit mailbox access to the accounts required. | + +The model should never be the final RBAC enforcement point. Authorization belongs in the identity provider, connected service, workflow conditions, credential boundary, and approval policy. + ## When should a Slack AI agent require human approval? A Slack AI agent should require human approval whenever an action is difficult to reverse, affects an external party, changes access, moves money, exposes sensitive data, or crosses a defined risk threshold. Approval must be meaningful rather than ceremonial. The approver should see the requester, proposed action, destination, relevant inputs, expected effect, and any sensitive data involved. Approval records should capture the approver's identity, decision, timestamp, and the exact action that was authorized. +### Can we require human approval in Teams or Slack before an AI agent acts on a security alert? + +A secure approval sequence is: + +1. The monitoring system sends the alert and supporting evidence to the agent. +2. The agent proposes a bounded response, such as disabling a user session or opening an incident. +3. The workflow presents the proposal to an authorized reviewer in Slack or Teams. +4. The workflow records the reviewer identity, decision, time, and optional reason. +5. A deterministic Condition checks whether the result is approved. +6. Only the approved branch receives credentials capable of performing the action. +7. The workflow records the final action and result for review. + Sim's Human in the Loop block pauses a run and resumes it with submitted form fields. Approve or reject is represented as a field, so a downstream Condition must inspect that field before the workflow takes the approved or rejected path. The [human-in-the-loop guide](https://www.sim.ai/library/what-is-human-in-the-loop-in-ai-agents) explains the broader control pattern. Sim's Wait block should not be used as an approval mechanism because it resumes only after a set time and does not resume in response to an external event. Sim's Guardrails block reports whether a check passed or failed; a downstream Condition must route on that result if the workflow should stop or take a safer path. @@ -238,6 +339,22 @@ At minimum, record: - Errors, retries, cancellations, and timeouts. - A correlation identifier shared across Slack, the agent runtime, and downstream systems. +### How should teams audit a Slack AI agent? + +Capture enough evidence for a reviewer to reconstruct who requested an action, what the agent proposed, who approved it, which credential class executed it, and what changed. + +| Evidence | Why it matters | +|---|---| +| Requester identity | Establishes who initiated the workflow | +| Slack workspace and channel | Establishes the collaboration context | +| Workflow version | Shows which logic and tools were active | +| Input and supporting evidence | Explains why the action was proposed | +| Proposed action and target | Defines the exact intended change | +| Reviewer identity and decision | Proves whether required approval occurred | +| Credential class | Distinguishes a personal connection from a shared service identity | +| Tool request and response | Shows what the connected system accepted or rejected | +| Final status | Confirms whether the action completed, failed, or was denied | + Avoid placing raw secrets or unnecessary message content in audit records. Logs must be useful for attribution and investigation without becoming a second uncontrolled copy of sensitive Slack data. The guide to [AI agent observability](https://www.sim.ai/library/ai-agent-observability) explains how traces, metrics, and evaluations complement this audit evidence. Slack's [Audit Logs API](https://docs.slack.dev/admins/audit-logs-api) provides supported workspace-level administrative events for Enterprise organizations, while the agent runtime's execution records must capture model, workflow, approval, and tool behavior. @@ -267,28 +384,44 @@ A guardrail can improve detection, but authorization must still be enforced by d Sim supports secure Slack agent design through visual workflow control, conditional routing, human review, self-hosting options, and enterprise governance capabilities. -Sim is the open-source AI workspace where teams build, deploy, and manage AI agents. Sim's core is licensed under Apache 2.0, while code in `apps/sim/ee`—including SSO, SCIM, access control, access requests, audit logs, data retention, data drains, session policies, and credential groups—is covered by the separate [Sim Enterprise License](https://github.com/simstudioai/sim/blob/main/apps/sim/ee/LICENSE). Production use of that enterprise code requires an active Sim Enterprise subscription. +Sim is the open-source AI workspace where teams build, deploy, and manage AI agents. Sim's core is licensed under Apache 2.0, while code in `apps/sim/ee` (including SSO, SCIM, access control, access requests, audit logs, data retention, data drains, session policies, and credential groups) is covered by the separate [Sim Enterprise License](https://github.com/simstudioai/sim/blob/main/apps/sim/ee/LICENSE). Production use of that enterprise code requires an active Sim Enterprise subscription. -Any self-hosted Sim deployment can use Ollama, vLLM, LM Studio, or LiteLLM-compatible local models through the documented [self-hosting environment settings](https://docs.sim.ai/platform/self-hosting/environment-variables); local-model support does not require Sim Enterprise. [Workspace BYOK keys work on every Sim Cloud plan](https://docs.sim.ai/platform/costs), while organization-level keys require Pro for Teams, Max for Teams, or Enterprise as of October 2026. +Any self-hosted Sim deployment can use Ollama, vLLM, LM Studio, or LiteLLM-compatible local models through the documented [self-hosting environment settings](https://docs.sim.ai/platform/self-hosting/environment-variables); local-model support does not require Sim Enterprise. [Workspace BYOK keys work on every Sim Cloud plan](https://docs.sim.ai/platform/costs), while organization-level keys require Pro for Teams, Max for Teams, or Enterprise as of November 2026. For Slack slash commands, Sim requires a custom Slack bot with its own signing secret because the native Sim Slack app cannot deploy slash-command triggers. Teams should verify Slack signatures at the request boundary and apply the same scope, channel, and installation controls described in this guide. +## How can a team share one AI agent in Slack while each person keeps their own tool permissions? + +Sim supports personal secrets and account connections, but runtime resolution follows an authorized Sim execution identity rather than automatically inheriting the Slack requester's account. The [Sim Secrets documentation](https://docs.sim.ai/platform/credentials) states that personal secrets belong to their owner and that the personal namespace depends on the trigger. For example, a webhook or deployed chat uses the workflow owner's personal namespace, while an authenticated manual run uses the person running it. + +Preserving each person's tool permissions therefore requires an execution path that maps the Slack requester to the expected authenticated Sim identity and an eligible personal connection. Reject a run when that mapping or connection is absent, and never silently fall back to a more privileged shared credential. + +Shared credentials fit tightly bounded machine actions, such as creating tickets in one queue. Restrict which workflows may use them, and place privileged actions after deterministic authorization and approval checks. + +Sim's core is Apache 2.0, while access control, access requests, audit logs, session policies, and credential groups are governed by the separate [Sim Enterprise License](https://github.com/simstudioai/sim/blob/main/apps/sim/ee/LICENSE). Production use of that enterprise code requires an active Sim Enterprise subscription. + The implementation guide [How do you build an AI Slackbot without code?](https://www.sim.ai/library/how-to-build-ai-slackbot-without-code) covers construction, while [Best AI Agents for Slack](https://www.sim.ai/library/best-ai-agents-for-slack) covers product-selection intent. This guide owns the security and permissions review that should happen before deployment. ## How does n8n fit into Slack agent security reviews? n8n remains an important incumbent for Slack automation through its documented [Slack node](https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.slack), but an n8n Slack workflow still requires independent review of scopes, credentials, data flows, tool permissions, approvals, and audit evidence. -As of October 2026, n8n is self-hostable under its [Sustainable Use License](https://github.com/n8n-io/n8n/blob/master/LICENSE.md), a source-available license that does not appear in the [OSI's approved-license list](https://opensource.org/licenses). Connecting a workflow to Slack does not determine whether a particular deployment follows least privilege. +### How do Sim and n8n differ for Slack agent security? + +Sim fits teams that want an open-source AI workspace with explicit workflow stages for human decisions and deterministic Conditions for authorization. n8n fits teams that already operate its workflow ecosystem and are prepared to review how credentials, projects, roles, logs, and approval steps work in their selected deployment. + +As of November 2026, n8n is self-hostable under its [Sustainable Use License](https://github.com/n8n-io/n8n/blob/master/LICENSE.md), a source-available license that does not appear in the [OSI's approved-license list](https://opensource.org/licenses). Connecting a workflow to Slack does not determine whether a particular deployment follows least privilege. + +As of November 2026, n8n documents API access tokens for its Slack Trigger and recommends OAuth2 for its Slack action node in the [Slack credentials documentation](https://docs.n8n.io/integrations/builtin/credentials/slack). Security teams should verify how their selected n8n deployment and plan handle projects, roles, credentials, logs, and approval workflows. -Technical buyers comparing the two should separate platform licensing from deployment security. Sim's core uses the OSI-approved Apache 2.0 license, with enterprise features under the separate Sim Enterprise License; n8n uses its fair-code Sustainable Use License. Either platform still needs an enforceable Slack security boundary. +Technical buyers comparing the two should separate platform licensing from deployment security. Sim's core uses the OSI-approved Apache 2.0 license, with enterprise features under the separate [Sim Enterprise License](https://github.com/simstudioai/sim/blob/main/apps/sim/ee/LICENSE); n8n uses its fair-code Sustainable Use License. Either platform still needs an enforceable Slack security boundary. ## What are the key platform facts for a Slack AI agent security review? Sim and n8n differ in licensing and governance packaging, but either platform must be configured around Slack's permission boundary and the organization's own action policies. -- **Sim:** Sim's core is Apache 2.0 and can be self-hosted, `apps/sim/ee` uses the separate Sim Enterprise License, workspace BYOK is available on every Sim Cloud plan, and [hosted model usage is recorded at the applicable Sim rate](https://docs.sim.ai/platform/costs) as of October 2026. -- **n8n:** n8n is self-hostable under the source-available Sustainable Use License rather than an OSI-approved open-source license, and n8n Cloud describes usage in workflow executions on its [official pricing page](https://n8n.io/pricing/) as of October 2026. +- **Sim:** Sim's core is Apache 2.0 and can be self-hosted, while `apps/sim/ee` uses the separate [Sim Enterprise License](https://github.com/simstudioai/sim/blob/main/apps/sim/ee/LICENSE). Workspace BYOK is available on every Sim Cloud plan, and [hosted model usage is recorded at the applicable Sim rate](https://docs.sim.ai/platform/costs) as of November 2026. +- **n8n:** n8n is self-hostable under the source-available Sustainable Use License rather than an OSI-approved open-source license, and n8n Cloud describes usage in workflow executions on its [official pricing page](https://n8n.io/pricing/) as of November 2026. - **Slack:** Slack is the identity, conversation, installation, and OAuth boundary for the agent, while model usage and agent-platform execution are billed and governed separately from Slack workspace access. Platform selection does not replace threat modeling. The deployment is secure only when the Slack app, agent runtime, models, credentials, tools, approvals, and logs form one enforceable control system. diff --git a/apps/sim/lib/api/contracts/knowledge/mcp.ts b/apps/sim/lib/api/contracts/knowledge/mcp.ts index f06b87c0843..b5d6571bbb7 100644 --- a/apps/sim/lib/api/contracts/knowledge/mcp.ts +++ b/apps/sim/lib/api/contracts/knowledge/mcp.ts @@ -78,6 +78,9 @@ const MAX_MCP_READ_DOCUMENTS = 10 export const readLiveDocumentMcpSchema = readDocumentInputSchema .extend({ documentId: readDocumentInputSchema.shape.documentId.optional(), + startChunkIndex: readDocumentInputSchema.shape.startChunkIndex.describe( + 'Copy next.startChunkIndex from a prior read to continue it; live documents always use 0.' + ), documentIds: z .array(readDocumentInputSchema.shape.documentId) .min(1) diff --git a/apps/sim/lib/knowledge/mcp/route-handler.protocol.test.ts b/apps/sim/lib/knowledge/mcp/route-handler.protocol.test.ts new file mode 100644 index 00000000000..a6be8a5ee7a --- /dev/null +++ b/apps/sim/lib/knowledge/mcp/route-handler.protocol.test.ts @@ -0,0 +1,196 @@ +import { member } from '@sim/db/schema' +import { queueTableRows, resetDbChainMock } from '@sim/testing' +import { createPersonalApiKeyPrincipal } from '@sim/testing/factories/principal.factory' +import { createRouteContext } from '@sim/testing/helpers/http' +import { credentialGroupsServiceMock } from '@sim/testing/mocks/credential-groups-service.mock' +import { + knowledgeAvailabilityMock, + knowledgeAvailabilityMockFns, +} from '@sim/testing/mocks/knowledge-availability.mock' +import { knowledgeBaseUseCasesMock } from '@sim/testing/mocks/knowledge-base-use-cases.mock' +import { knowledgeContextsMock } from '@sim/testing/mocks/knowledge-contexts.mock' +import { knowledgeEmbeddingsMock } from '@sim/testing/mocks/knowledge-embeddings.mock' +import { knowledgeServiceMock } from '@sim/testing/mocks/knowledge-service.mock' +import { + permissionGroupsResolveMock, + permissionGroupsResolveMockFns, +} from '@sim/testing/mocks/permission-groups-resolve.mock' +import { rateLimiterMock } from '@sim/testing/mocks/rate-limiter.mock' +import { createMockRequest } from '@sim/testing/mocks/request.mock' +import { simSearchConnectorsMock } from '@sim/testing/mocks/sim-search-connectors.mock' +import { urlsMockFns } from '@sim/testing/mocks/urls.mock' +import { v2ApiKeyAuthModuleMock, v2RouteMocks } from '@sim/testing/mocks/v2-route.mock' +import { beforeEach, describe, expect, it, vi } from 'vitest' + +const mocks = vi.hoisted(() => ({ index: vi.fn(), liveSearch: vi.fn() })) +vi.mock('@/lib/api/server/routes/v2-api-key-auth', () => v2ApiKeyAuthModuleMock) +vi.mock('@/lib/core/rate-limiter', () => rateLimiterMock) +vi.mock('@/lib/core/utils/after-response', () => ({ afterResponse: vi.fn() })) +vi.mock('@/lib/knowledge/mcp/activity', () => ({ recordOrganizationSearchMcpActivity: vi.fn() })) +vi.mock('@/lib/knowledge/application/contexts', () => knowledgeContextsMock) +vi.mock('@/lib/knowledge/application/billing', () => ({ + resolveKnowledgeAttributedUserId: (principal: { userId: string }) => principal.userId, +})) +vi.mock('@/lib/knowledge/search/search-index', () => ({ findSearchIndex: mocks.index })) +vi.mock('@/lib/permission-groups/resolve.server', () => permissionGroupsResolveMock) +vi.mock('@/lib/credential-groups/service', () => credentialGroupsServiceMock) +vi.mock('@/lib/knowledge/service', () => knowledgeServiceMock) +vi.mock('@/lib/knowledge/embeddings', () => knowledgeEmbeddingsMock) +vi.mock('@/lib/knowledge/application/knowledge-bases', () => knowledgeBaseUseCasesMock) +vi.mock('@/lib/knowledge/application/connectors', () => ({ + createKnowledgeConnector: { execute: vi.fn() }, +})) +vi.mock('@/lib/knowledge/application/connector-access', () => ({ + startKnowledgeConnectorMemberEnrollment: { execute: vi.fn() }, +})) +vi.mock('@/lib/knowledge/access/availability', () => knowledgeAvailabilityMock) +vi.mock('@/connectors/registry', () => ({ CONNECTOR_META_REGISTRY: {} })) +vi.mock('@/lib/sim-search/connectors', () => simSearchConnectorsMock) +vi.mock('@/lib/sim-search/live/application', async (importOriginal) => ({ + ...(await importOriginal