Low-code workflow
You host the engine, so its credential store holds the keys to everything it touches.Data flow
- 1Workflows start from webhooks, schedules or forms. Those paths must be public and the input is untrusted, so patch within days and put a WAF in front.
- 2Builders reach the editor only through SSO (paid tiers) or a private-access proxy. Never expose it to the internet.
- 3LLM nodes call a Track A model, ideally the AI gateway for keys and logs.
- 4The same workflow then acts on CRM, email, Slack, cloud and ticketing APIs.
- 5Every connected app's OAuth token sits in one credential store. In n8n, a vault integration is Enterprise-only, so protect the encryption key and database.
- 6Execution history holds prompts and data. In n8n, native log streaming is Enterprise-only, so export it on a schedule.
Low-code workflow: build or buy
Buy + glueWhat you can buy for each box in the diagram, the open source option, and the part you still build yourself.
| Component | Buy | Open source | You build | Maturity |
|---|---|---|---|---|
| Triggers (webhooks, forms) | Cloudflare WAF or another WAF on public trigger paths. | Caddy, nginx path routing | Split public webhook and form paths from the editor. | GA |
| SSO or private access | n8n Business or Enterprise for native SSO. Dify Enterprise. Cloudflare Access, Tailscale. | oauth2-proxy, Pomerium | Reverse proxy in front of the editor on free editions. | GA |
| Workflow engine | n8n Business or Enterprise, Dify Enterprise. | n8n Community, Dify, Langflow, Flowise | Patch pipeline with a short SLA for critical fixes. | GA |
| Execution history | n8n Enterprise log streaming. | n8n public API, Postgres export | Scheduled export to a bucket or SIEM, plus pruning and retention. | GA |
| Credential store | n8n Enterprise external secrets with Vault, AWS Secrets Manager or Infisical. | HashiCorp Vault, Infisical | Protect the n8n encryption key, encrypt and lock down the database. | GA |
| Model access | Provider keys with spend caps, or your AI gateway. | LiteLLM | Per-instance or per-workflow keys. | GA |
| CRM, email, Slack, cloud and ticket APIs | Already owned. | · | Least-privilege service accounts per integration, not builders' personal admin accounts. | GA |
Rollout steps
| # | Step | Who | Effort |
|---|---|---|---|
| 1 | Deploy on a private host with Postgres, editor behind private access, only webhook and form paths public behind a WAF | Platform engineer | 3-5 days |
| 2 | Pin the version, subscribe to security advisories and set a patch SLA of days, not weeks | Platform engineer | 1 day, then ongoing |
| 3 | Move integrations to dedicated service accounts and protect the encryption key and database | Platform or security engineer | 1 week |
| 4 | Export execution and audit logs daily to a bucket or SIEM and set pruning | Security engineer | 3-5 days |
| 5 | Issue a capped model key, then move to the AI gateway later | Platform engineer | 1 day |
| 6 | Onboard builders with a connector review checklist | Security engineer | 2-3 days |
What you still build
- Reverse-proxy split of the editor from public webhook and form routes
- Execution log export job on non-Enterprise tiers
- Encryption key handling and database hardening on non-Enterprise tiers
- Per-integration service accounts and a scope review checklist
Gotchas
- Webhook and form endpoints have to be public. The 2026 critical n8n flaws, including the unauthenticated Ni8mare bug, were in that code.
- External secrets and log streaming are n8n Enterprise only. On lower tiers, credentials sit in the n8n database, and the key sits on the host.
- Native SSO needs n8n Business or above, or Dify Enterprise. Free editions need a proxy.
- Langflow had an unauthenticated code execution flaw in CISA's known exploited list. Never expose it to the internet.
- Owning the instance means owning every connected app's token.
Custom agents
Data flow
- 1A signed-in user asks the agent to do something. The user's identity travels with the request.
- 2The agent plans with a Track A model, reached through the AI gateway.
- 3Generated code runs in an ephemeral sandbox with no network and no secrets.
- 4Every tool call goes to the MCP gateway, never directly to a system.
- 5The policy engine allows or denies per user, agent, tool and action.
- 6External, financial, destructive and regulated-data actions pause for human approval. Internal writes run on their own and are logged.
- 7The gateway gets a short-lived, narrowly scoped token for the user (on-behalf-of for internal APIs, stored per-user tokens for most SaaS, STS for cloud), calls the tool, and flags likely injected instructions in the result.
- 8Every call, argument and result is logged to the SIEM.
- 9Before each release, automated red teaming and evals test the agent for injection, data leaks and unsafe actions.
- 10A kill switch revokes the agent's tokens at once. A runtime monitor that flags anomalies can come later.
Custom agents: build or buy
Buy + glueWhat you can buy for each box in the diagram, the open source option, and the part you still build yourself.
| Component | Buy | Open source | You build | Maturity |
|---|---|---|---|---|
| IdP (user + agent identity) | Okta Agent SSO (core Okta SSO), Okta for AI Agents, Microsoft Entra Agent ID, Auth0 for AI Agents add-on, Aembit | Keycloak | Give each agent a named owner and an allowed tool set | GA |
| Red team and evals | Promptfoo Enterprise, Mindgard, Straiker Ascend | Promptfoo, garak, PyRIT | Test cases for your own tools, data and destructive actions | GA |
| Code sandbox | E2B Pro or Enterprise, Daytona, Modal Team | E2B self-hosted, gVisor, Firecracker | Block egress, keep secrets out of the image, clean up after runs | GA |
| Human approval | Auth0 asynchronous authorization (CIBA), AI Agents add-on or Enterprise | · | Per-action approval card showing exact arguments, deny on timeout, decision logged | GA |
| MCP gateway | Runlayer, Obot Enterprise, Prisma AIRS AI Gateway (ex-Portkey), Kong AI Gateway Enterprise (MCP plugin in Tech Preview) | agentgateway, Obot, Portkey gateway, Docker MCP Gateway, ToolHive | Approved-server registry, pinned tool descriptions, per-agent allowlist, kill-switch flag | GA |
| On-behalf-of tokens | Auth0 Auth for MCP (token exchange), Entra Agent ID agent OBO flow, Okta Cross App Access, Aembit | Keycloak token exchange, agentgateway | Map each tool to scopes, broker per-user SaaS tokens in a vault | GA |
| Policy engine | Amazon Verified Permissions (Cedar) | OPA, Cedar | The rules: user, agent, tool, action and data class, with tests | GA |
| Tool result scanning | Prisma AIRS, Check Point AI Guardrails (formerly Lakera), Zenity, Noma | LLM Guard, mcp-scan | Wire it into the response path, scan nested JSON, tune false positives | GA |
| Tool audit to SIEM | Your existing SIEM plus gateway logs | OpenTelemetry | Redact secrets and regulated fields, link user, agent and run ID | GA |
| Kill switch | Gateway deny rule plus IdP agent disable | · | One flag that blocks an agent's tool calls and revokes its tokens | GA |
| Runtime anomaly monitor | Zenity, Noma, Straiker, Geordie (all quote only) | · | Connect monitor alerts to automatic token revocation | Preview |
Rollout steps
| # | Step | Who | Effort |
|---|---|---|---|
| 1 | Classify every tool action as read, internal write, external, destructive, financial or regulated | Security engineer | 1 week |
| 2 | Register the agent in your existing IdP with a named owner | Platform engineer | 1 week |
| 3 | Put all tools behind an MCP gateway, remove the agent's direct credentials and add a kill switch | Platform engineer | 2-4 weeks |
| 4 | Set up token exchange for internal APIs, a vault for SaaS tokens and STS roles for cloud APIs | Identity or platform engineer | 2-4 weeks |
| 5 | Start with a static tool allowlist per agent, then move to OPA or Cedar rules with tests | Security engineer | 3-4 weeks |
| 6 | Build approval for external and destructive actions, denied by default on timeout | Application engineer | 2-3 weeks |
| 7 | Run generated code in an ephemeral sandbox with no network and no secrets | Application engineer | 1 week |
| 8 | Log redacted calls to a bucket, then forward to the SIEM with alerts | Security engineer | 1-2 weeks |
| 9 | Add a red-team suite to CI that includes injection through tool results | Security engineer | 2 weeks |
| 10 | Add a tool result scanner that flags likely injection | Platform engineer | 1-2 weeks |
| 11 | Later, add a runtime anomaly monitor that can revoke tokens | Security engineer | 2-4 weeks |
What you still build
- Policy rules covering user, agent, tool, action and data class, with unit tests
- An approval screen that shows the exact action and arguments and records who approved
- A classification of every tool action by risk
- Per-user token brokering for SaaS apps that won't accept your IdP's tokens
- Result-scanner integration and what happens on a hit
- Kill-switch wiring across the gateway and the IdP
- Red-team test cases written for your own tools
Gotchas
- True on-behalf-of exchange works for your internal APIs and apps that support Cross App Access. Most SaaS needs stored per-user OAuth tokens, scoped only as narrowly as the SaaS allows.
- Result scanning flags likely injection but misses plenty. Treat narrow scopes and human approval as the real controls.
- Cloudflare MCP Server Portals expect a human browser login and don't support device auth, so they don't fit headless agents.
- Kong's MCP OAuth2 plugin is Enterprise-only and still in Tech Preview.
- Build the kill switch now. It takes days. Defer only the anomaly monitor.
- Too many approval prompts train people to click yes. Only ask for external, destructive, financial or regulated actions.
- Logging full tool results can copy regulated data into your SIEM. Decide on redaction first.
Common use cases
- Lead enrichment and alert triage workflows
- Onboarding and scheduled reporting
- Customer-facing support agents
- Ops and SRE runbook automation
Key risks
- One credential store holding tokens for everything
- Internet-exposed, under-patched workflow editors
- Excessive agency from broad tool scopes
- Confused deputy when the agent uses its own credentials
- Prompt injection via tool results
- No way to stop an agent that goes wrong
Fast path
- KEEPSSO or private access in front of every workflow editor
- KEEPPatch within days, WAF on public trigger paths
- SIMPLIFYStatic tool allowlist per agent before OPA
- KEEPHuman approval on external and destructive actions
- KEEPShort-lived, scoped tokens per user
- KEEPKill switch that revokes agent tokens
- SIMPLIFYRedacted audit to a bucket first