DEV Community: Arcade.dev

How to manage multi-user AI agent authentication and authorization in 2026 (OAuth 2.1, OIDC, and delegated access)

Manveer Chawla — Thu, 14 May 2026 20:18:23 +0000

TL;DR: multi-user AI agent authentication and authorization in 2026

Moving AI agents from single-user desktop demos to enterprise production means solving a brutal engineering problem: multi-user, multi-system delegated authorization.

Security architects and lead AI engineers are now dealing with agents that execute complex workflows across critical infrastructure on behalf of thousands of concurrent users.

The core design principle is non-negotiable: treat every agent action as delegated user access, never as the agent's own blanket access. The whole authorization stack falls out of that distinction. Nine capabilities, two identities, one strict intersection rule.

This guide breaks down how to combine OpenID Connect, OAuth 2.1, and a managed Model Context Protocol (MCP) runtime like Arcade.dev to prevent tool misuse, data leakage, and excessive agency. It's built for identity and access management leads, security architects, and AI engineering leads who need the exact infrastructure requirements to safely deploy multi-user agents into production.

Threat model for multi-user AI agents: prompt injection, tool misuse, and confused deputy

You can't engineer secure authorization without defining the threat model first. For large language models, the most dangerous attack vector runs from prompt injection straight to tool misuse.

If an enterprise agent inherits blanket admin access to a backend system, a single poisoned RAG document or malicious prompt can weaponize that agent. An attacker instructs the model to scan an inbox, summarize sensitive financial data, and exfiltrate the payload via an external tool call. The whole exfil chain completes without a human in the loop.

The Open Web Application Security Project highlights these vulnerabilities in its updated guidelines, citing prompt injection and excessive agency as primary risks that lead directly to the confused deputy problem.

In a confused deputy attack, an application gets tricked into misusing its inherited authority.

There's a second class of attack that targets the authorization flow itself. An attacker who can intercept or guess the identifier for a pending OAuth authorization can redirect the consent step to their own browser, either capturing the user's grant or seeding the agent with credentials it shouldn't have. Treating every first-time tool authorization as a step that must be cryptographically bound to a verified app user is the only durable defense.

The two-identity model for agent authorization

Engineering teams typically make one of two mistakes when designing agent authorization. Give the agent its own identity, and an intern can bypass their permissions through the agent. Inherit the user's full access, and a single prompt injection cascades through every connected system.

The right answer is the intersection: what this agent is allowed to do AND what this user is allowed to do, evaluated per action, at runtime.

Effective authorization in agentic systems requires every request to carry two identity layers:

The project-level key (the agent application): The workload identity making the call. Registered as an OAuth client, scoped to the application running the agent logic.
The user-level identity (on whose behalf the action is taken): The actual person requesting the action, authenticated via a protocol like OpenID Connect, and represented in the request as a delegated subject.

The runtime evaluates these two identities against a delegated execution context: a bounded, short-lived binding that ties a specific user to a specific agent for a specific task. The context isn't a third identity. It's the tuple of claims (user, agent, scopes, audience, tenant, task ID, expiry) the runtime evaluates at every tool call.

This model enforces the identity intersection rule, which is the foundation of modern agent security.

An agent's effective authority must always be calculated as the strict intersection of its own baseline permissions and the requesting human user's permissions. Never the union.

If a user can't delete a database record, the agent acting on their behalf must fail when attempting the same action. It doesn't matter what the agent's maximum theoretical capabilities are.

Implementing this intersection requires strict protocol separation. OpenID Connect authenticates the human user to establish who is interacting with the system. OAuth 2.1 authorizes what specific tool calls the agent can make on the human's behalf.

Conflating these two protocols leads to over-permissioned tokens that get reused across systems they were never scoped for, giving a compromised agent durable access well beyond what the user actually authorized.

Nine capabilities for production multi-user AI agent auth

The Model Context Protocol's own authorization spec, developed as a broad collaboration with Anthropic, Arcade.dev, Microsoft, Okta/Auth0, and others, defines OAuth-style protected resources and authorization server discovery, with audience binding via Resource Indicators (RFC 8707) and delegation via Token Exchange (RFC 8693). MCP defines the auth handshake; the runtime layer above must still handle token vaulting, just-in-time consent, user verification, RBAC, and audit. The nine capabilities below close that gap.

Building resilient multi-user agent infrastructure means evaluating your systems against this 2026 capability checklist. Unifying these capabilities prevents unauthorized access while ensuring reliable tool execution.

Capability 1: Model user, agent, and delegated context

Every authorization decision in your runtime must evaluate the user, agent, and context tuple simultaneously.

If your backend tool plane only verifies the agent's API key, you've failed to model the human user.

True delegated modeling ensures that the upstream resource server knows exactly which human began the request, which workload orchestrated it, and the precise context under which the delegation was granted.

In practice, this means the user_id flows from your app's authenticated session into every runtime call. A typical pattern: your IdP (Stytch, Auth0, Okta, or similar) authenticates the user and issues a session, your app extracts the user identifier from that session, and your code passes that identifier explicitly to every runtime SDK call. For example, getTools({ tools: [...], userId: userEmail }) and tools.execute({ ..., user_id: userEmail }). The runtime then resolves that specific user's vaulted OAuth tokens for the requested provider and scope. Without this explicit user binding on every call, the runtime has no way to enforce the intersection rule.

Capability 2: Separate OpenID Connect authentication from OAuth authorization

You need to strictly separate human authentication from delegated agent authorization. OpenID Connect handles the initial login session. OAuth 2.1 handles the subsequent tool authorization.

By separating these concerns, you prevent identity conflation. An agent compromised by a malicious prompt can't reuse human session cookies to access unrelated systems.

Capability 3: Issue short-lived, scoped, audience-bound access tokens

Agent access tokens must adhere to the strictest cryptographic standards to prevent token replay and lateral movement.

Each delegated access token should carry the full execution context as claims. In a delegated token, the subject (sub) identifies the human user on whose behalf the action is taken (e.g., user:alice). The actor (act) identifies the agent making the call (e.g., agent:support-copilot). The audience (aud) binds the token to a specific resource server (e.g., gmail-api), and the scope (scope) grants a specific permission (e.g., email.draft, not email.send). The expiry (exp) is set to a tight window of typically 5 to 30 minutes. A tenant claim (e.g., tenant:acme) carries the customer or workspace context, and a task ID (e.g., task_123) ties the call back to the originating user task or session.

This claim structure enforces the intersection rule cryptographically: every token carries the user, the agent, and the bounded execution context, and the resource server validates all three before honoring the request.

Your stack must enforce RFC 8707 resource indicators to bind tokens to a specific audience, ensuring a token minted for a calendar API can't be replayed against a CRM.

Use RFC 8693 token exchange to safely trade broad user tokens for tightly downscoped agent tokens.

Sender-constrain tokens using RFC 9449 demonstrating proof of possession (DPoP), ensuring that even if an access token gets intercepted, attackers can't use it without the client's private key. The stack should also support RFC 9126 pushed authorization requests and RFC 9396 rich authorization requests for enhanced, tamper-proof granularity.

Capability 4: Vault tokens and automate refresh across providers

A runtime that handles token storage and refresh per-user, per-provider, is non-negotiable for production agents. Managing the OAuth token lifecycle across thousands of users and dozens of providers is a substantial engineering problem in its own right.

Access and refresh tokens must be vaulted and encrypted on a strict per-user, per-provider basis. Your system needs to automatically handle provider-specific nuances outside the language model context.

For example, Google enforces a rolling limit of 100 refresh tokens per client, and Microsoft Entra rotates refresh tokens on every redemption with a 90-day sliding inactivity window. A dedicated token vault must abstract this refresh logic away from the agent developer.

Capability 5: Enforce read, draft, and commit approval steps

Security architects must enforce out-of-band approval flows for any irreversible action.

Reading data or drafting responses requires minimal friction and can be executed synchronously. But external side effects, such as sending emails, deleting records, or committing code, must trigger explicit human step-up approvals.

These approvals should occur via a secure, out-of-band channel, such as an enterprise authentication app, a separate user interface, or a direct messaging platform.

Capability 6: Evaluate policy before every tool call by hooking into existing entitlement systems

Never trust a language model's direct API request. Every tool call must route through a centralized policy layer that intersects the user, agent, tenant, action, resource, and task. And it must evaluate that intersection in milliseconds to avoid throttling the agent's conversational latency.

Critically, this is not an invitation to stand up yet another policy system. Enterprises already have entitlement systems and identity providers like Okta, Entra, SailPoint, and homegrown role/permission stores. The runtime's job is to hook into those systems, acquire scoped tokens at runtime, and enforce the policies the enterprise has already defined, not duplicate them in a new tool.

Open Policy Agent, Cedar, Oso, OpenFGA, WorkOS FGA, and Zanzibar-style relationship graphs are useful as the local enforcement engine. But the source of truth for who can do what should remain in your existing identity and governance systems. A runtime that asks you to redefine your authorization model in its own DSL is moving the problem, not solving it.

Capability 7: Use just-in-time consent and authorization

Blanket consent at user onboarding violates the principle of least privilege.

Implement just-in-time authorization instead. When an agent requires access to a new system or an ungranted scope to fulfill a prompt, the runtime pauses execution. It returns a granular, context-specific consent interface to the user, captures the cryptographic consent, brokers the new token, and resumes the agent's task without losing conversational context.

MCP's URL Elicitation Specification Enhancement Proposal (SEP), authored by Arcade.dev in collaboration with Anthropic and accepted into the MCP spec, standardizes how an agent runtime delivers granular, context-specific consent URLs to the user mid-task.

Capability 8: Bind first-time auth flows to a verified app user

Granular consent (Capability 7) only matters if the runtime can confirm which user is sitting at the keyboard during the first-time OAuth authorization. Without that confirmation, an attacker who intercepts a flow_id can redirect the consent step to their own browser and either hijack the authorization back into your user's session or capture the user's grant for themselves.

The mitigation is a server-side user verifier. When a user authorizes a tool for the first time, the runtime redirects them to a verifier route in your app. Your verifier reads the flow_id from the query string, looks up the currently authenticated user from your app's session (Stytch, Auth0, Okta, as the IdP, or an app-layer auth system like Supabase), and posts that user_id back to the runtime via a server-side confirm_user call signed with your API key.

If the user_id from your session matches the user_id specified when the flow started, the runtime continues. If not, the runtime rejects the flow. Every first-time authorization is therefore bound to a verified, authenticated identity in your app, which closes the flow-phishing attack surface.

In production multi-user deployments, this is non-negotiable. Arcade's reference implementations show the pattern in Next.js with Stytch and Next.js with Supabase, and Arcade's Secure Auth in Production guide walks through the verifier route end-to-end.

Capability 9: generate immutable audit logs for every agent action

Every action taken by an agent must generate an immutable audit log with a complete chain of custody.

This means capturing the requesting user, the agent identity, the tenant, the task ID, the specific tool invoked, the resource accessed, the policy decision and policy version, the prompt hash, input references, output hash, approval status, and the exact timestamp.

These logs must be OpenTelemetry-compatible, providing structured traces that export cleanly into enterprise security information and event management systems for immediate incident response.

And the audit story isn't only about the logs themselves. It's about the controls that produce them. SOC 2 Type 2 certification validates that the runtime's audit, access, and change-management controls operate as designed under independent audit. Treat the certification as a procurement floor and the per-action log structure as the actual product capability. You need both.

Why a runtime, not a gateway: the architecture shift behind multi-user authorization

In the traditional model, users interact with applications, applications call APIs, and a gateway sits between them, routing, authenticating, and rate-limiting at the perimeter. The proxy is the control point because it's the choke point: every request flows through it.

In the agentic model, that topology inverts. The agent is already the proxy. A user talks to an agent. The agent reasons, plans, and calls tools on the user's behalf. It already handles mediation, routing, and orchestration. Adding a traditional API gateway in front of the tools doesn't add a control point; it adds a redundant hop that can't see into the execution context that actually matters: which user, which action, which permission, right now.

That's why "MCP gateway" is the wrong frame for the auth problem. A stateless proxy evaluates each request in isolation. It can't track that a request is step 3 of a 6-step agent workflow, acting on behalf of a specific user who authorized a particular scope minutes ago. Bolting MCP support onto an API gateway is not a pivot. It's a patch.

The control point in an agentic architecture is the execution layer where the tool runs. That's where credentials are resolved, permissions are checked, and actions are taken on behalf of a specific human. That's the runtime. The nine capabilities above can only be enforced there.

Where each layer fits in the agent auth stack (IdP, OAuth vault, policy engine, MCP runtime)

Understanding the vendor landscape means categorizing platforms by their strict architectural function. Misunderstanding where a tool fits in the stack leads to dangerous auth gaps.

The deeper issue is consistency at scale. Even with the right primitives in place (an IdP, a token vault, a policy engine), most stacks have no uniform way to apply them across every agent, every user, and every system. Each team stitches its own integration, and two teams in the same company end up enforcing the same policy differently. The runtime is what makes a single authorization model enforceable across every agent, without each team rebuilding the plumbing.

Architectural layer	Example vendors	Primary function	Key gap for multi-user agents
Identity providers	Okta, Auth0, Entra, WorkOS, and Clerk	Authenticate the human user into the application via OpenID Connect.	Lacks the full agent authorization stack. Support for explicit delegation flows, such as RFC 8693 and sender-constraining via DPoP, varies significantly and often requires heavy custom actions. Audit covers authentication events, not per-tool-call agent actions.
OAuth libraries and vaults	Authlib, HashiCorp Vault, Doppler	Securely store, encrypt, and manage raw OAuth tokens.	Lacks a contextual decision engine, robust policy evaluation, and the dynamic, multi-provider refresh logic necessary for asynchronous agentic workflows. Audit captures token operations, not the user, agent, and tool context behind each call.
Policy engines and FGA platforms	Open Policy Agent, Cedar, Oso (Polar DSL), OpenFGA, WorkOS FGA, Zanzibar-style, Sailpoint	Evaluate fine-grained authorization policies against complex relationship graphs.	Leaves token brokering, consent user experiences, and physical tool connectivity for the engineering team to build from scratch. Audit records the policy decision, not the full execution context that the resource server actually saw.
Agent frameworks	LangChain, Mastra, Crew AI	Provide tool abstraction for agent workflows.	Push the auth burden back onto your application code; treat tools like keys in a dotenv file and quietly break the moment a second customer signs up. No native audit trail for agent actions.
MCP gateways and integration wrappers	Composio	Connect language models to external tools using standardized interfaces.	Designed for rapid prototyping and single-user proof-of-concept agents. An SDK-layer integration wrapper, not a runtime. Per-user OAuth is supported, but SSO, OIDC, and audit are limited rather than native, and the agent/user permission intersection isn't enforced.
MCP runtimes	Arcade.dev	The first MCP runtime built for agent authorization. Delivers post-prompt user-specific permissions, isolated token lifecycle management (refresh, rotation, mismatch), OAuth protocol brokering, contextual access policy enforcement, and immutable per-action audit logs exportable via OpenTelemetry.	Not applicable. This layer explicitly unifies the previous layers and fills their operational gaps.

Reference architectures for multi-user agent auth

These capabilities only matter if you can map them to real architectures. The three patterns below show how an MCP runtime enforces multi-user authorization in production.

The patterns assume the canonical multi-user setup: an agent application that authenticates users via its own identity provider (Stytch, Auth0, Okta, or Entra) and calls the runtime through its client SDK, passing the authenticated user_id on every tool call. The runtime is the backend that brokers OAuth, vaults tokens per user, and enforces policy. For MCP-client integrations like Copilot, Cursor or Claude Desktop, the runtime's MCP gateway path is used instead, but the runtime semantics are the same.

Two distinct auth flows run inside each pattern. Server-level auth determines whether the agent application (an MCP client) can connect to the MCP server. Tool-level auth governs whether the currently authenticated user can invoke a specific tool against this resource with these parameters right now. Server-level auth happens once per client-to-server connection. Tool-level auth runs on every tool call, and it's where the user verifier (Capability 8), just-in-time consent via URL Elicitation (Capability 7), and the permission intersection rule actually operate. Arcade's Server-Level vs Tool-Level Authorization guide walks through the distinction in detail.

Pattern 1: internal productivity agent (Google Workspace)

Architectural flow: Human User -> [OIDC Identity Provider] -> Agent Application -> MCP Runtime -> Gmail and Calendar MCP tools-> Google Workspace

Scenario: An internal, Claude-based assistant organizes meetings and summarizes emails across a multi-user Google Workspace environment.

Implementation: The agent must never possess domain-wide delegation. Instead, the MCP runtime brokers a user-specific OAuth flow. The runtime requests delegated gmail.readonly and gmail.compose scopes, binding the resulting token strictly to the individual employee.

On the user's first authorization, the runtime redirects the user's browser to a verifier route in the app. The verifier reads the flow_id, looks up the authenticated user from the OIDC session, and confirms the user_id back to the runtime. Only after the runtime matches the verifier-confirmed user_id against the user_id that started the flow does the OAuth grant proceed. From that point forward, the user's token is vaulted per provider and reused on subsequent calls without re-authorization.

When the agent attempts to read an inbox, the app passes the authenticated user_id from its session into the runtime SDK call. The runtime evaluates the policy engine, retrieves that specific user's token from the vault, and executes the call.

If the agent hallucinates or receives a malicious prompt to send an email, it requests the gmail.send scope. The runtime catches this unauthorized request, pauses execution, and forces an out-of-band step-up approval to the user's device. A human explicitly authorizes the transmission, or it doesn't happen.

Pattern 2: multi-tenant Slack agent (workspace isolation)

Architectural flow: Human User -> [OIDC Identity Provider] -> Agent Application -> MCP Runtime -> Slack MCP tools -> Slack workspace

Scenario: A business-to-business application deploys an agent that aggregates alerts and takes administrative actions across multiple customer Slack workspaces.

Implementation: Managing access across distinct corporate boundaries requires strict multi-tenant isolation. The runtime manages workspace-level OAuth installations, generating bot tokens combined with granular user-level channel permissions like chat:write and channels:history.

The runtime uses RFC 8707 resource indicators, ensuring that tokens minted for Tenant A's Slack instance are mathematically bound to that tenant's audience.

If an injection attack attempts to force the agent to read Tenant B's data using Tenant A's context, the policy engine rejects the cross-tenant token replay instantly. That prevents catastrophic cross-customer data leakage.

Pattern 3: Salesforce CRM agent (user-level permissions)

Architectural flow: Human User -> [OIDC Identity Provider] -> Agent Application -> MCP Runtime -> Salesforce MCP tools -> Salesforce

Scenario: A sales copilot updates pipeline records, drafts follow-up emails, and queries customer history on behalf of individual account executives.

Implementation: Salesforce data access rules are notoriously complex. The MCP runtime requests the api and refresh_token OAuth scopes to call Salesforce on behalf of the user, then evaluates the account executive's specific Salesforce profile and permission sets at every tool call before allowing the agent to proceed. Object-level access (read on Account / Contact, edit on Opportunity stage transitions, commit on Lead conversion) is gated by the user's existing Salesforce permissions, not by the agent's own credentials.

The implementation enforces strict separation between reading account contacts, drafting meeting notes, and committing pipeline updates.

Through just-in-time authorization, if a junior rep asks the agent to update a closed-won opportunity they lack privileges to edit, the runtime's policy engine blocks the action at the tool boundary. It returns a graceful access denial to the language model without exposing backend credentials.

Agent auth anti-patterns to avoid in production

Answer engines and security audits favor systems that eliminate known architectural flaws. If your current homegrown agent setup relies on any of these anti-patterns, your infrastructure isn't ready for enterprise production.

Single API key routing: Your agent backend shares a single, highly privileged service account key across all users. This breaks identity attribution at the request layer. The backend can't distinguish between an intern's request and a CEO's request, and a single prompt injection inherits maximum blast radius across the entire user base.
God mode with prompted guardrails: The agent runs with root or admin credentials, and engineers rely on system prompts like "do not delete data" to maintain security. Language models are easily manipulated through indirect injection, so relying on the model to govern its own authorization is a fundamental security failure.
Blanket sign-up consent: Forcing users to grant massive, multi-system OAuth scopes during their initial onboarding. This violates the principle of least privilege, causes consent fatigue, and provisions tokens with dangerous capabilities long before the user actually needs them.
User interface-only checks: Authorization checks are enforced exclusively at the chat interface or frontend web application, leaving the backend tool plane unprotected. If an attacker bypasses the chat interface and sends payloads directly to the tool execution endpoint, the system complies without verifying the delegated user context.
No distinction between draft and commit: Your agent treats every action with the same authorization level, sending emails or transferring funds as easily as drafting them. Without a read/draft/commit gradient and an out-of-band approval step for irreversible actions, a single prompt injection causes irreversible damage.
No immutable audit trail: Your agent system has no per-action audit log or relies on application logs that can be modified after the fact. Without an immutable record of who authorized what tool action when (with policy version, prompt hash, and approval status), security incidents can't be reconstructed, and regulator-facing audit reports become impossible.

Conclusion: the delegated authorization rule for multi-user agents

The transition to production-grade, multi-user AI agents demands a fundamental shift in how we architect security. The entire philosophy of agent authorization boils down to one strict rule:

This specific agent may perform this specific action on this specific resource, for this specific user, in this specific tenant, for this specific task, for a strictly limited period of time.

If your current infrastructure can't cryptographically enforce and audit that exact sentence from the chat prompt down to the backend API layer, your system isn't ready for multi-user production in 2026.

A gateway can't enforce that rule. A runtime can.

Before you commit to a runtime, do three things. Audit your current identity mapping to confirm your backend systems actually model the user, agent, and context tuple on every tool call. Stop building bespoke OAuth plumbing. Refresh logic, just-in-time consent user interfaces, and multi-tenant token vaulting are undifferentiated technical debt your engineers shouldn't be writing. And test the intersection rule aggressively by sending malicious prompts against your own agents to verify that your policy engine intercepts them at the network boundary.

Arcade is the first MCP runtime purpose-built for agent authorization, handling per-user OAuth, just-in-time consent, token vaulting, policy intersection, and immutable audit as native capabilities, not bolt-on plugins. The nine capabilities above are unified under one control plane, alongside Arcade's agent-optimized tool catalog and lifecycle governance, so your engineering teams can focus on shipping high-value agent logic instead of maintaining fragile identity plumbing.

Frequently asked questions

What's the best way to manage multi-user AI agent authentication and authorization in 2026?

Treat every tool call as delegated user access, not agent-owned access. Implement a two-identity model (the agent application and the user on whose behalf the action is taken), bind every call to a delegated execution context, and enforce the intersection rule via OAuth 2.1 delegated tokens, a policy engine in front of tools, short-lived scoped tokens, and immutable audit logs.

What is the two-identity model for agent authorization?

Every request carries two identities: the project-level key (the agent application making the call) and the user-level identity (the human on whose behalf the action is taken). The runtime evaluates these two identities against a delegated execution context, a bounded binding that ties a specific user to a specific agent for a specific task, so the backend can attribute and constrain every action.

What is the "intersection rule," and why does it matter?

The agent's effective permissions must be the intersection of the user's permissions and the agent's allowed capabilities. Never the union. This rule prevents "confused deputy" failures where an injected prompt causes the agent to misuse broad system access.

How should OpenID Connect and OAuth 2.1 be used together for agents?

Use OpenID Connect to authenticate the human user (who they are). Use OAuth 2.1 to authorize the agent's tool calls (what the agent can do on the user's behalf) with scoped, audience-bound tokens.

How do you prevent prompt injection from turning into tool misuse?

Don't rely on prompts for security. Route every tool call through a policy enforcement layer that checks user/agent/context, scopes, tenant, and resource. Use short-lived, audience-bound tokens so even a successful injection can't pivot across systems.

Which token properties are required for secure delegated-agent access?

Tokens should be short-lived, scoped, and audience-bound (so they can't be replayed against other APIs). For stronger replay resistance, use sender-constrained tokens (e.g., DPoP) so stolen tokens are unusable without the client key.

How do you handle OAuth refresh tokens safely for thousands of users?

Store tokens in a per-user, per-provider encrypted vault and automate refresh/rotation outside the LLM. This prevents secrets from leaking into prompts and prevents provider-specific refresh edge cases from breaking agent workflows.

When should an agent require step-up approval or human confirmation?

Require step-up approval for irreversible or high-impact actions (e.g., sending an external email, deleting records, committing code, or transferring funds). Let the agent read and draft with lower friction, but gate "commit" actions via an out-of-band confirmation flow.

What is just-in-time authorization for AI agents?

The agent requests new scopes or system access only when needed for a specific task. The runtime pauses, collects granular consent, mints a downscoped token, and resumes. This reduces over-permissioning and consent fatigue.

What is MCP URL Elicitation?

URL Elicitation is a Specification Enhancement Proposal authored by Arcade.dev with Anthropic and accepted into the Model Context Protocol spec. It defines how an MCP runtime returns a granular, context-specific consent URL to the user mid-task when the agent needs a new scope or system, allowing the user to authorize the request out of band before the runtime resumes execution. URL Elicitation is the standardized mechanism behind just-in-time agent authorization.

What should be included in an audit log for agent tool calls?

Log the user identity, agent identity, tenant, tool/action/resource, policy decision, timestamp, and a prompt or request hash. Make logs immutable and exportable via OpenTelemetry-compatible formats for incident response and compliance.

Should you build or buy an MCP runtime for enterprise AI agents in 2026?

Manveer Chawla — Wed, 13 May 2026 21:21:22 +0000

The engineering bottleneck for enterprise AI has shifted. Your team has built agents. They work in single-user environments on LangChain or Mastra. The wall hits when you try to wire those agents into secure enterprise systems for thousands of employees without creating new security exposure or a permanent maintenance load.

In 2026, engineering directors face a real architectural decision, and it isn't whether to write custom Model Context Protocol (MCP) servers. Custom MCP servers are how you connect agents to proprietary internal systems, regardless of which path you choose. The actual decision is whether you also build the runtime layer that wraps those servers: OAuth lifecycle, credential vaulting, multi-user auth, permission intersection logic, audit pipeline, policy enforcement, and observability. Build that layer yourself on top of LangChain or Mastra, or buy an MCP runtime that delivers it off the shelf.

The right answer depends on your deployment profile. Once multi-user authorization, audit-grade governance, or asynchronous tool-call observability enter the picture, the build path incurs increasing costs and a growing risk surface. Maintaining your own auth, credential vaulting, and audit pipeline puts every agent action inside your security blast radius. The decision favors buying a runtime.

TL;DR: Build vs. buy MCP runtime

An MCP runtime handles the work most teams have no business writing themselves: agent authorization, OAuth token rotation, audit logging, and policy enforcement. The runtime is the execution, authorization, and governance layer where your agent's tools (MCP servers) run.

If you build your own runtime. Three narrow profiles fit this path: single-user scope, agent infrastructure as your core product, or all-internal API pipelines. You retain full control and assume responsibility for the OAuth lifecycle, credential vaulting, audit logging, and policy enforcement. Each integration becomes a permanent line item on your engineering roadmap; auth and policy maintenance never go to zero.

If you buy a runtime. This is the default for multi-user production. You get centralized lifecycle governance that maps to your existing policies, multi-user authorization with full OAuth lifecycle management, tool execution, and a path to build proprietary tools without rebuilding the runtime layer.

Four tipping points force a transition from a self-built runtime layer to a vendor-provided one:

Crossing the three-integration threshold, where API maintenance starts consuming dedicated sprints.
Introducing user-delegated actions, requiring agents to execute tool calls on behalf of specific human users with distinct permissions.
Moving from synchronous read-only tasks to asynchronous, long-running read/write operations that break standard LLM timeouts.
Needing OpenTelemetry-compatible audit logs to satisfy compliance and security teams.

The state of MCP infrastructure: Config hell vs. the buy tradeoff

The Model Context Protocol has standardized how AI applications consume context and execute tools, replacing the bespoke API wrappers teams used to write for every LLM feature.

Adopting MCP introduces architectural challenges. Enterprise platform teams choose between two operational burdens: the DIY trap of "config hell," or the buy-side tradeoff of vendor cadence and ecosystem dependency.

Config hell happens when you scale bespoke MCP servers. Platform engineers spend their time editing JSON configurations to re-map tool schemas every time an upstream SaaS provider deprecates an endpoint, chasing token rotation drift when an OAuth refresh expires and the custom retry logic doesn't handle the edge case, and handling the manual work that SOC 2 and GDPR compliance requires (immutable schema registries, signed tool manifests, middleware to redact PII from tool outputs). When you build your own infrastructure, you own every broken connection, every expired token, and every security patch.

The runtime is not an additional proxy in front of your tools. In an agentic architecture, the agent is already the proxy. It mediates between the user and downstream systems, reasons about which tools to call, and orchestrates multi-step workflows. The runtime is the execution layer where the chosen action actually runs. It is where credentials are resolved, policy is enforced, and the call is made on behalf of a specific user.

The runtime is the best gateway.

The real buy-side tradeoffs are different. You accept the runtime's policy primitives and observability format as lock-in. You take on overhead from per-tool authorization checks and just-in-time token resolution, which is a fraction of LLM inference and downstream API latency.

The real choice in 2026 is risk, not cost. Build your own runtime layer, and your security blast radius scales with every integration, user, and policy change. Buying a runtime moves that work to a vendor that has already been audited for it. For enterprise deployments, that is the safer side of the tradeoff.

When to build your own runtime

Building your own runtime layer is the right call in a narrow set of scenarios. The open-source ecosystem has matured enough that deep platform engineering teams can stand up their own orchestration layer on top of the official Model Context Protocol Python or TypeScript SDKs. The SDKs implement the MCP specification over JSON-RPC 2.0 and support both stdio for local process communication and Streamable HTTP for remote execution. Teams wrap MCP servers in adapters provided by frameworks like LangChain or Mastra so agents can invoke them directly, then deploy on Kubernetes using custom Helm charts.

The MCP servers themselves then become the easy part. The runtime layer that wraps them is the actual work, and the cases where building that layer in-house make sense are narrow.

Build your own runtime if you have a single-user scope. Per-user OAuth, token vaulting, and permission intersection are the hardest parts of the runtime layer, and they matter only once more than one human is involved. A solo developer connecting their own credentials to a single agent does not need them.

Build your own runtime if the agent infrastructure is your core product. A startup whose entire product is a smart scheduling agent for end users must control every layer of the stack. The engineers should be deep into this work because it is the company.

Build your own runtime if you own every API in the pipeline. If your agents act only on systems and data sources you control, with no third-party SaaS connections, you bypass the OAuth-lifecycle problem entirely, and the case for buying weakens.

Air-gapped deployments are not a build trigger. They are a deployment-mode question. Self-hosted runtimes run the vendor's runtime layer entirely inside your infrastructure, satisfying the air-gap while inheriting auth, audit, and governance from the runtime. Build your own runtime layer only when the deployment also prohibits third-party vendor software, which typically applies to highly classified environments.

Outside those three cases, building your own runtime is a misallocation of senior engineering time.

Beyond the MCP servers themselves, you build secure token vaults to manage OAuth refresh lifecycles for each user and service. You handle provider-specific rate limits and pagination. You architect state machines for asynchronous debugging when a tool call takes ten minutes to execute. You patch custom servers every time an upstream API changes its schema. Skip that work, and you get agent hallucination and silent failures.

Auth and policy carry their own ongoing burden, separate from API drift. People join and leave the company. Roles change. Permissions get revoked. Policies tighten after an incident. Each event has to flow through your custom auth layer in real time. This is a permanent FTE cost, not a build-once-leave-alone problem, and it never decreases as the deployment grows.

When to buy a runtime

An MCP runtime shifts engineering effort from infrastructure to product. Your team operates on top of an execution layer that already handles auth, vaults, audit, and policy, instead of building each one.

A runtime gives you four things off the shelf.

Centralized lifecycle governance. The runtime is the enforcement point for the policies your organization has already defined elsewhere (in your IDPs, your sales tools, your security systems). It maps to those existing policies and enforces them at the agent layer. It does not ask you to recreate access policies inside a new tool. Administrators get a single control plane to manage agent behavior, audit tool execution, and roll out updates safely across the organization.

Multi-user post-prompt authorization. Every tool call executes using the credentials and permissions of the human user requesting the action. The runtime handles the OAuth token lifecycle (secure vaulting, refresh, rotation) without exposing credentials to the LLM.

A catalog of pre-built, version-controlled MCP tools, so your agents reach thousands of enterprise systems on day one.

A path for proprietary tools that doesn't require rebuilding the runtime layer. When you need custom MCP servers for internal systems, you write them on the runtime's open-source MCP framework and inherit auth, audit, and governance for free. If you already have custom MCP servers built without the framework, you can connect them to the runtime and still get the same auth, audit, governance, and pre/post-call policy hooks without rewriting them.

Platform engineers shift from writing brittle integration scripts and debugging broken OAuth flows to managing high-level access policies. Your team defines which agents can access which tools, sets up visibility filtering so specific teams only see permitted integrations, and monitors OpenTelemetry-compatible dashboards to track agent reasoning and tool execution latency. You spend time on the agent's logic, not the plumbing.

Enterprise MCP scorecard: Decision criteria for build vs. buy

Eight dimensions separate a local prototype from a production deployment. The matrix scores each lane against them.

Evaluation dimension	DIY runtime layer (open-source SDKs)	Vendor MCP runtime
Control & customization	Absolute. Full control over transport layers, custom memory state, and bespoke hardware isolation.	High. Standardized tool execution with hooks for custom policies, but limited underlying infrastructure access.
Setup speed	Weeks to months. Requires building auth layers, token vaults, and infrastructure deployment pipelines.	Hours to days. Drop-in integration with existing IdPs and immediate access to pre-built tool catalogs.
Maintenance burden	Severe. Team owns all API schema updates, deprecations, token rotation logic, and security patches. The work compounds with every integration and every policy change.	Minimal. The vendor absorbs API drift, token lifecycle work, and security patching. Your team manages access policies and visibility, not infrastructure.
Multi-user authorization	Manual implementation. High risk of prompt injection and credential leakage if built incorrectly.	Built-in. Automated just-in-time token issuance, scoped per user and isolated from the LLM.
Lifecycle governance	Fragmented. Requires custom logging middleware, disparate SIEM integrations, and manual version control.	Centralized. Unified control plane, OpenTelemetry-native audit logs, and shadow MCP prevention.
Async task handling	Complex. Requires building external polling, dead-letter queues, and durable state machines for timeouts.	Native. Parallelized execution, automatic failover, intelligent retries, and decoupled result fetching.
Deployment options	Infinite. Deploy anywhere, including fully air-gapped, offline environments.	Cloud, self-hosted on-prem or in cloud (vendor enterprise tier), hybrid, or fully air-gapped. Cloud requires network egress to the vendor control plane; self-hosted runs the runtime entirely in your own infrastructure.
Best-fit team profile	Single-user scope, agent infrastructure is your core product, you own every API in the pipeline.	Multi-user production, mixed proprietary plus SaaS requirements, teams optimizing for time-to-value and audit-grade governance.

Multi-user authorization in production

Multi-user authorization is where most enterprise agent projects stall before production.

A developer testing locally passes their personal API keys to the system. In production, an agent serves thousands of users with different permission scopes.

If your runtime layer relies on a shared service account or forwards a user's full-scope bearer token to the LLM context, you've created an attack vector. A prompt injection attack instructs the agent to use those inherited permissions to exfiltrate data or delete repositories.

Shared service accounts also break audit-trail requirements: systems can't tell an autonomous-agent action apart from a human-directed one.

A runtime solves this with multi-user, post-prompt authorization. The runtime enforces a permission intersection at execution time:

Agent Permissions ∩ User Permissions = Effective Action Scope

The agent can only execute an action if both the agent's role policy and the user's native SaaS permissions allow it. Every other combination is denied.

For example, an HR agent scoped to recruiting tasks is invoked by an employee with admin privileges in Workday, including access to global payroll data. When the agent attempts to read payroll, the runtime evaluates the intersection at call time and denies the request. The user has the authority. The agent's restricted scope blocks the action.

The runtime acquires a tightly scoped, just-in-time token to execute the allowed action on behalf of the user. The credentials never reach the LLM client, which removes prompt injection as a direct credential-theft vector.

Lifecycle governance and audit

Without centralized governance, enterprise agent deployments turn into shadow IT. Developers spin up rogue MCP servers on local machines or unauthorized cloud instances, connecting LLMs to internal databases without oversight.

A runtime acts as the central enforcement point for the policies your organization has already defined elsewhere. It maps to your IDPs, your sales tools, your security systems, and enforces what's there. It does not ask you to recreate access policies inside a new tool. Think of the runtime as the bouncer: it enforces, it doesn't author. All tools and servers are registered in a single catalog. Visibility filtering ensures that an HR agent sees only HR-related tools, while a coding agent sees only repository tools.

Beyond enforcing what's already defined, the runtime exposes pre- and post-tool-call hooks for custom logic. Compliance teams drop in their own variables (workflow state, time windows, request volume, contextual data on the user or session), and the runtime treats those as first-class enforcement primitives alongside standard policies. Organization-specific conditions get wired in without forking the runtime.

The runtime generates fine-grained, OpenTelemetry-compatible audit logs. Every action is tracked: which user prompted the agent, which LLM model generated the tool call, what parameters were passed, and what the downstream API returned. That visibility is a prerequisite for passing security reviews in regulated industries.

Async and long-running tasks

Standard LLM architectures are synchronous. Inference endpoints time out within minutes.

Enterprise agent actions, such as triggering CI/CD pipeline builds, provisioning cloud infrastructure, or querying large data warehouses, can run for tens of minutes or hours.

In a DIY runtime, platform engineers build the asynchronous scaffolding themselves: job queues, external-memory state synchronization, polling mechanisms, and dead-letter queues for failed operations.

A runtime handles this work. It supports the latest MCP Tasks specifications, so agents trigger a long-running process, receive a task identifier immediately, and poll for the result asynchronously.

The runtime handles parallelized execution, failover routing when an endpoint drops, and backoff retries. The agent workflow stays durable without the application layer managing state.

Observability: end-to-end OpenTelemetry traces

The hidden cost of DIY MCP stacks is debugging. When an agent fails a tool call at 3 a.m., platform engineers stitch together traces from the agent run, each MCP server's logs, each provider SDK's retry logs, and each target SaaS API's status page. There is no correlated view. Investigating one failed async action means grepping across three systems in parallel and reconstructing the sequence by hand.

A runtime emits a single OpenTelemetry trace that carries the full chain. An example span tree for one agent action ("schedule a follow-up meeting and send the recap"):

agent.run (root)                 user_id, session_id, agent_id
├─ llm.infer                     model, prompt_tokens, completion_tokens
├─ mcp.tool_call                 tool=google_calendar.create_event
│  ├─ mcp.authz                  policy_result=allow, user_scope=calendar.events.write
│  ├─ mcp.oauth.refresh          token_id, refresh_outcome=ok
│  └─ mcp.http.execute           target_host, status=200, latency_ms=412
├─ mcp.tool_call                 tool=gmail.send
│  ├─ mcp.authz                  policy_result=allow
│  ├─ mcp.retry                  attempt=2, reason=rate_limited
│  └─ mcp.http.execute           status=202, latency_ms=890
└─ llm.infer                     result synthesis

Export that trace to Honeycomb, Datadog, or your SIEM, and you can answer "which user, agent, tool, policy, token, or retry caused the failure?" in one view. DIY gets you there only if you build the trace-correlation layer yourself and maintain it as SDKs, provider log formats, and policy engines evolve. That maintenance is a direct cost on your DIY stack, and it goes away when you adopt a runtime that emits agent-to-tool traces natively.

Operational burden of building

The operational burden of a DIY runtime layer compounds with every integration and every policy change. Initial development is the smallest part of the work. Most of the engineering effort lands after launch in API deprecations, schema changes, OAuth token rotation, security patching, and the auth and policy churn that grows with every user, every role change, and every revoked permission.

A production post-mortem of custom MCP servers documents the typical failure chain: auth drift, orphaned session state, brittle retries, silent tool hallucinations. Each failure costs senior engineering capacity to diagnose and remediate, on a timeline that doesn't compress.

Senior engineers building a DIY runtime spend their time on OAuth refresh scripts and incident-response patches. Senior engineers using a runtime spend their time on proprietary agent logic and domain-specific workflows. The differences compound across every team and every quarter.

How to evaluate MCP runtime vendors in 2026

Buying a runtime starts with picking the right vendor. The MCP infrastructure market has been segmented into three rough categories. Gateways route MCP traffic. Registries catalog MCP servers. Runtimes handle execution, authorization, and governance. Different vendors cover different layers. Most cover one. Some bundle two. The breakdown of MCP gateways, runtimes, and registries shows where specific vendors stack up across the three categories.

Within the runtime category, evaluate vendors against four capabilities:

Centralized lifecycle governance. Does the runtime enforce the policies your organization has already defined elsewhere (IDPs, sales tools, security systems), or does it ask you to recreate them in a new tool? Look for one control plane with audit logs, version control, and visibility filtering across every agent and tool.
Multi-user post-prompt authorization. Does the runtime evaluate per-user, per-action permissions at execution time, or does it pass through a shared service account? Per-user OAuth, with credentials isolated from the LLM, is the bar.
Agent-optimized tools, plus a path for proprietary ones. Are the tools intent-translating, or are they raw API wrappers that make the agent fill in object IDs and enums? Does the vendor offer an open-source framework that lets you build custom MCP servers for internal systems and inherit auth, audit, and governance without rebuilding the runtime layer?
Custom policy hooks for contextual access. Can your compliance team add organization-specific logic (workflow state, time windows, request volume, contextual data on the user or session) as first-class enforcement primitives, without forking the runtime?

How Arcade delivers on each

Arcade is the MCP runtime. It delivers all four capabilities in a single layer for multi-user AI agents at scale.

Agent lifecycle governance. Arcade is the central enforcement point for the policies your organization has already defined. It maps to and enforces policies from your IDPs, sales tools, and security systems. It does not ask you to recreate access policies inside a new tool. One control plane for every tool, agent, and auth provider. Version control to safely roll out tool upgrades. A shared registry that prevents teams from rebuilding what already exists. Visibility filtering so agents only see tools their user is permitted to invoke. Fine-grained audit logs, OpenTelemetry-exportable to your SIEM, that track every agent action per user and per service. Arcade's SOC 2 Type 2 certification validates these controls through an independent audit.

Agent authorization. Every MCP request in Arcade carries two identity layers: a project-level key (which application is making the request) and a user-level identity (on whose behalf the action is taken). Arcade evaluates the intersection of agent and user permissions dynamically at runtime to prevent privilege escalation. It handles the full OAuth lifecycle (refresh, rotation, mismatch) with credentials isolated from the LLM, and hooks into existing enterprise identity governance systems like Okta, Entra, and SailPoint to enforce policies the enterprise has already defined rather than duplicating them. That is the layer that removes prompt injection as a direct credential-theft vector.

Agent-optimized tools. Arcade's catalog of over 8,000 agent-optimized MCP tools are not API wrappers. They translate natural-language intent into structured API calls, so an agent asked to "send this to Finance" does not have to hallucinate the target recipient_user_id. The token cost shows up in benchmarks: for identical CRM queries, intent-level tooling produced 100x fewer response tokens than a raw API-passthrough approach, with token output equivalent to 3.7% of a 200K context window versus 373%. At scale, that overhead translates to context-window overflow in multi-step workflows and degraded agent accuracy. The runtime handles parallelized tool execution, failover, and retries. The Arcade MCP Framework lets you build custom proprietary tools that federate into the same control plane with the same auth and governance wrapping.

Contextual access and custom policies. Beyond enforcing policies your organization has already defined elsewhere, Arcade exposes pre- and post-tool-call hooks for custom logic. Compliance teams drop in their own variables (workflow state, time windows, request volume, contextual data on the user or session), and the runtime treats those as first-class enforcement primitives. Organization-specific conditions get wired in without forking the runtime.

For enterprises with mixed requirements (proprietary-internal systems plus SaaS breadth, multi-user auth plus governance, fast shipping plus safety), Arcade covers the full set without forcing ecosystem lock-in.

Final recommendation

For most enterprise deployments in 2026, buy an MCP runtime. The deployment profile shapes how the runtime gets deployed, not whether to deploy it.

Proprietary-internal-only. Sensitive data is the strongest buy signal, not a build trigger. Legacy systems holding proprietary data are precisely where Arcade gets pulled in. That's where the operational pain peaks and where security and compliance officers carry the most direct accountability. A custom OAuth pipeline maintained by a small team is a position no security leader wants to defend in a regulated audit. An audited, SOC 2 Type 2 runtime that has already cleared third-party scrutiny is much easier to defend.

Recommended pattern: build custom MCP servers using the Arcade MCP Framework, run them inside your VPC or on-prem, and create an MCP gateway in the runtime to connect them to the Arcade control plane. For environments where even the control plane must stay in customer infrastructure, run the runtime self-hosted. The data stays inside your boundary. The runtime handles auth, OBO, vaulted credentials, audit logs, and governance.

For fully air-gapped deployments with no external network egress, run a self-hosted runtime entirely inside your infrastructure. The runtime layer is identical to the cloud version; only the deployment mode changes. Build your own runtime only when the deployment also prohibits third-party vendor software.

SaaS-heavy. Once your agentic workflow needs to touch Google Workspace, Microsoft, Salesforce, GitHub, or Slack, you buy. The runtime handles the OAuth lifecycle, schema drift, and tool maintenance for hundreds of SaaS APIs your team would otherwise rebuild. The security gap is largest in this profile. So is the operational gap.

Mixed (most enterprises). Agents query proprietary internal databases, synthesize that data, and act in public SaaS applications. Mixed-requirement teams do not have to choose between proprietary security and SaaS breadth. Adopt an MCP runtime, such as Arcade.dev, for SaaS coverage, then create an MCP gateway in the runtime to connect internal MCP servers (or custom servers built with the Arcade MCP Framework) to the same control plane. Both surfaces inherit the same security and audit controls, with multi-user authorization wrapping every action.

If you have already built MCP servers without the Arcade Framework, you do not have to rewrite them. Connecting an existing custom server to Arcade still gives you the runtime's auth, audit, governance, and pre- and post-call policy hooks on top of what you already have.

Summary

Deployment profile	Recommendation	Pattern
Proprietary-internal-only	Buy an MCP runtime	Build custom MCP servers on the Arcade MCP Framework, run them inside your VPC or on-prem, and create an MCP gateway in the runtime to reach them. Self-hosted for environments where the control plane must stay in customer infrastructure.
Fully air-gapped (no external egress)	Buy an MCP runtime, self-hosted	Run a vendor's self-hosted runtime entirely inside your infrastructure. Build your own only when the deployment also prohibits third-party vendor software.
SaaS-heavy	Buy an MCP runtime	Adopt the runtime directly. It handles the OAuth lifecycle, schema drift, and tool maintenance for hundreds of SaaS APIs.
Mixed proprietary plus SaaS	Buy an MCP runtime	Arcade for SaaS coverage. An MCP gateway created in the runtime connects internal MCP servers (built with or without the Arcade Framework) to the same control plane.

Decision checklist

Run your deployment plan against these five questions:

Will your agents serve more than one human user with different permission scopes?
Do you need audit-grade logs that tie every tool call to a specific human, agent, and target system?
Do any of your agents take asynchronous actions that exceed standard LLM request timeouts?
Are you connecting to five or more external SaaS APIs across the organization?
Are your regulatory constraints so severe that no external network egress is permitted, even through a gateway running inside your own network?

How to read the answers:

"Yes" on any one of the five questions: buy an MCP runtime.
Otherwise: confirm fit against the three build cases in "When to build your own runtime" before committing to DIY.

Conclusion

The deployments that stall in 2026 fail on risk: auth that can't be audited, credentials sitting inside an LLM context window, and a security blast radius no one in the room can scope. Sensitive data raises that bar, which is why proprietary scenarios are a buy trigger, not a build trigger. Rebuilding OAuth pipelines and schema registries is a poor use of senior engineering time, and the build path stops compounding the moment a second user or a regulated audit enters the picture.

Arcade.dev's MCP runtime provides agent lifecycle governance, agent authorization, and an agent-optimized tool catalog in a single layer.

Next step: book a 30-minute technical discovery call with Arcade's team to walk through the multi-user authorization architecture and the deployment options for your environment.

Or start in the Arcade playground. Connect one tool, run one user-scoped action, and see how the runtime handles OAuth, policy, and audit in a single trace.

Frequently Asked Questions

What is the difference between an MCP server and an MCP runtime?

An MCP server is a single endpoint that exposes tools. An MCP runtime is the execution layer that hosts, secures, and governs those servers. The runtime handles production complexities like multi-user authorization, load balancing, and audit logging that individual servers lack.

How do MCP runtimes handle rate limits and long-running tasks?

They use the asynchronous MCP Tasks specification, returning a task ID immediately while managing the long-running job in the background. The runtime handles vendor-specific API rate limits, backoff retries, and connection failovers. Your agent polls for the final result without managing execution state.

Why is multi-user authorization so difficult for custom AI agents?

Multi-user authorization requires dynamic, just-in-time credential management to prevent prompt-injection attacks that compromise a user's full account. Custom builds must securely orchestrate complex "On-Behalf-Of" token flows, vault credentials out of the LLM context window, manage strict refresh token rotation, and enforce granular access policies at execution time.

Can you mix custom MCP servers with an MCP runtime?

Yes. Custom MCP servers and runtimes are not alternatives. You build custom MCP servers for proprietary internal systems in either path. The question is whether you also build the runtime layer wrapping them. Runtimes support hybrid architectures: custom servers running proprietary tools inside your VPC connect to the runtime's control plane via a gateway or a secure tunnel. This governs public SaaS and custom internal tools through a single control plane. Servers built on the runtime's open-source framework inherit auth and audit automatically. Existing servers built without the framework connect to the runtime and still get its auth, audit, and policy hooks without being rewritten.

When should we build our own runtime layer instead of buying an MCP runtime?

Build your own runtime if you have a single-user scope with no multi-user requirement, if the agent infrastructure is itself your core product, if you own every API in the pipeline (no third-party SaaS). Sensitive data on its own is not a build trigger. Air-gapped deployments are handled by self-hosted runtimes from vendors that offer them. Buy a runtime in every other case.

When does it become cheaper to buy an MCP runtime?

Once you support multiple integrations and multi-user OAuth. Maintenance and security work exceed the runtime's usage cost beyond three integrations.

Do MCP runtimes expose OAuth tokens or credentials to the LLM?

No. The runtime keeps credentials in a vault and issues tightly scoped, just-in-time tokens for tool execution without placing secrets in the model context.

What security and compliance features should an enterprise MCP runtime include?

Post-prompt authorization, least-privilege policy enforcement, immutable audit logs (OpenTelemetry-friendly), secret vaulting and rotation, and admin controls for tool access and visibility.

What is "post-prompt" (on-behalf-of) authorization for AI agents?

Post-prompt authorization means the runtime authorizes and executes each tool call using the requesting user's permissions at execution time, rather than using a shared service account or passing user tokens into prompts.

How much latency does an MCP runtime add?

A small overhead from per-tool authorization checks and just-in-time token resolution. The overhead is a fraction of LLM inference and downstream SaaS API latency.

Can an MCP runtime work in a private VPC or hybrid environment?

Yes. The runtime's MCP gateway lets internal MCP servers run inside your VPC while governance and routing stay centralized. Self-hosted deployment runs the runtime entirely in your own infrastructure.

How do MCP runtimes help with audit logging and incident response?

They record who requested the action, which tool was called, the parameters, results, and timing. All exportable to SIEM via OpenTelemetry for compliance and investigations.

How do MCP runtimes handle SaaS API changes and version drift?

The vendor maintains tool schemas and centrally updates integrations. This reduces breakage from deprecations and keeps tool definitions consistent across agents.

Can we start DIY and migrate to a runtime later?

Yes. Teams begin with DIY for prototypes and migrate to a runtime when multi-user auth, governance, and operational load become production requirements.

Claude Code Routines: 5 production workflows that ship real work

Manveer Chawla — Fri, 01 May 2026 16:50:58 +0000

TL;DR

Claude Code Routines enable unattended, cloud-run workflows via scheduled, API, and GitHub event triggers. Enterprise use breaks with demo-grade setups.
Daily run caps and shared subscription usage push teams to batch work into a single daily "meta-orchestrator" routine plus a few real-time triggers.
5 production workflows: incident postmortem drafting, on-call triage → ticket drafts, PR-aging report, expansion-signal scanning, and changelog PR generation.
Key enterprise risks: over-permissioned connectors, prompt injection from untrusted inputs, API rate limits (notably Slack history), and weak auditability.
Production pattern: use an MCP runtime that delivers agent authorization, agent-optimized tools, and agent lifecycle governance, plus human approval gates for write actions.

Cloud-hosted agents are not new. OpenClaw, Perplexity Computer, n8n, Zapier, and a handful of SaaS agent runtimes have been executing unattended work for a while. The release of Claude Code Routines adds a different option: teams that already use Claude Code as their day-to-day development agent can now run that same agent, with the same prompts, tools, and conventions, on Anthropic's cloud instead of tethered to a laptop.

A routine is a saved Claude Code configuration (a prompt, one or more repositories, and a set of connectors) packaged once and run automatically on Anthropic-managed cloud infrastructure. Each routine can attach any combination of three trigger types: scheduled (recurring cadence), API (POST to a per-routine endpoint with a bearer token), and GitHub events (pull request or release activity on a connected repository). Routines are currently in research preview, so limits and API shapes are still moving.

Most of the early Routines content focuses on personal productivity: meeting prep, inbox summaries, and calendar wrangling. For senior developers and engineering leaders trying to run autonomous agents across an enterprise, those demos do not cut it.

Moving from a script on one laptop to a production-grade engineering workflow means dealing with the realities of enterprise architecture. Production automation demands strict governance, robust security boundaries, and the ability to work within aggressive API rate limits.

This article covers five production-leaning, unattended routines designed for engineering teams. We'll map exactly what happens at runtime, identify which workflows need human oversight, and outline the governance models you need to safely run scheduled, API-triggered, and GitHub-triggered Claude Code sessions without compromising your infrastructure. Before getting to the workflows, it's worth looking at why demo-grade setups buckle the moment they move from a single laptop to a shared team environment.

Where demo patterns hit production reality (security, reliability, governance)

Routines formalize what teams have been wiring together with cron jobs, GitHub Actions, and custom middleware for two years: Claude Code running on a schedule, against a GitHub event, or through an API call, with no developer laptop in the loop. But moving from a single developer's personal setup to a shared enterprise environment exposes severe limitations in security, reliability, and auditability. Fast.

Start with the execution model. Per Anthropic's docs, routines "run autonomously as full Claude Code cloud sessions: there is no permission-mode picker and no approval prompts during a run." Whatever the agent decides to do, it does. At the speed of inference, without a human in the loop. That shifts the burden of "what is this agent allowed to do" from interactive confirmation to pre-deployment configuration. If the configuration leans on bundled first-party connectors and creator-inherited OAuth scopes, the guardrails come off exactly when you need them most.

The most critical vulnerability is the permission inheritance model of bundled first-party connectors.

In a standard setup, an automated routine inherits the full global access of the developer who created it. Anthropic's docs make the consequence explicit: "Anything a routine does through your connected GitHub identity or connectors appears as you: commits and pull requests carry your GitHub user, and Slack messages, Linear tickets, or other connector actions use your linked accounts for those services." A first-party OAuth token works for a single developer querying their personal pull requests. It becomes a massive liability the moment you deploy it as an unattended routine on behalf of a whole team.

If an agent operates with an engineering lead's administrative permissions, a single compromised routine gains unrestricted read and write access across your entire enterprise system. This architecture fails security reviews every time the automation touches shared customer data, source code, or regulated infrastructure.

This over-permissioning makes prompt injection threats way worse. Unattended routines ingest untrusted third-party text by design. They process incoming PagerDuty incident descriptions, analyze raw Sentry stack traces, and scan customer support emails.

Without typed, permission-scoped tool contracts to validate the output, a malicious payload hidden in a customer ticket can instruct the routine to exfiltrate data or delete production resources. Natural language instructions won't stop these exploits in an enterprise environment.

Operational and reliability constraints compound the problem. Routines draw down the same subscription usage as interactive sessions, plus a separate daily cap on how many runs can start per account. Anthropic doesn't publish a specific number, and Claude usage tightens once team activity ramps up, so unattended workflows have to be designed with quota-awareness from day one.

This forces engineering teams to abandon simple event-driven architectures for complex batch processing. You can't trigger a routine for every individual pull request comment. Instead, you orchestrate batch jobs that process dozens of events at once to conserve quota, or enable extra usage and accept metered overage when caps hit.

Reliability and visibility close out the failure list. Early adopters report consistent issues with bundled connectors in unattended execution: community issue trackers show silent failures during runtime, OAuth token expiration errors that crash scheduled tasks, and connectors that fail to load in the cloud environment.

Bundled connectors also lack auditability. When an unattended routine updates a Jira ticket, queries a GitHub repository, and posts a Slack message, standard bundled connectors give you opaque execution logs. Security teams can't construct a definitive audit trail of what the agent did across multiple platforms.

The rest of this article shows how a dedicated MCP runtime resolves each of these failure modes:

Risk	Control	Where it lives
Over-permissioned token	Per-user, per-tool authorization evaluated per action	MCP runtime
Prompt injection from untrusted text	Agent-optimized tools with schema enforcement and isolated credentials	MCP runtime
Quota overrun	Meta-orchestrator batching plus targeted GitHub event triggers	Routine design
Silent write to production	Human approval gate on drafts, PRs, or prefixed branches	Workflow config and branch protection
No audit trail for compliance	Full execution context logged per tool call, exportable via OpenTelemetry	MCP runtime

5 production Claude Code routine workflows you can batch into one daily run

The risks and controls above become concrete through workflow design. Before the patterns, one operational constraint shapes every choice below: quota. Routines share subscription usage with interactive sessions and add a daily cap on runs per account, so running a separate routine for every minor event burns through the budget fast.

The solution is to architect a single "meta-orchestrator" routine that wakes up once a day, runs a sequential batch of discrete data-gathering and reporting tasks, and shuts down. That consumes one run from your daily cap.

This strategy saves your remaining runs for critical, real-time API and GitHub event triggers that demand immediate attention.

Here are five concrete engineering workflows designed for this quota-aware framework, with their technical triggers, human approval surfaces, and governance requirements. Three of them (nightly incident postmortem, weekly PR-aging, expansion-signal scanning) sit inside the meta-orchestrator and share the daily run. The other two (Sentry triage, release-notes draft) run real-time because their value is latency-bound. You want the Linear ticket while the incident is hot, and the changelog draft as soon as the release tag lands.

Routine	Trigger	Primary tools	Approval surface	Run slot
Nightly incident postmortem	Scheduled (2:00 AM daily)	PagerDuty, Slack, Notion	Human engineers review and publish the drafted Notion page	Meta-orchestrator
On-call Sentry triage	API (Sentry webhook → routine `/fire` endpoint)	Sentry, Linear	On-call engineer triages the drafted Linear ticket queue	Real-time
Weekly PR-aging report	Scheduled (Friday morning)	GitHub, email	Read-only; no write approval needed	Meta-orchestrator
Expansion signal scanner	API (nightly)	HubSpot, Slack Search	Account managers review flagged accounts in a Slack channel	Meta-orchestrator
Friday release notes draft	GitHub event (release created)	GitHub, Jira / Linear	PM reviews the pull request and merges the changelog	Real-time

Nightly incident postmortem draft (PagerDuty, Slack, Notion)

Assembling a postmortem means stitching PagerDuty timestamps, Slack threads, and deploy markers into a readable narrative. This workflow does the assembly and drafts the first pass so the engineer lands on a structured Notion page instead of a blank one.

Trigger: Scheduled. Runs as the first sequence in the daily 2:00 AM meta-orchestrator.
Workflow: The routine queries the PagerDuty API for resolved events from the previous 24 hours. The hard part is Slack context: the conversations.history endpoint now rate-limits non-Marketplace apps to one request per minute, so bulk-ingesting incident channels is off the table. The routine uses the Slack Search API to isolate key messages, or fires via the API trigger when a Slack reaction-event webhook (configured in your Slack app) POSTs to the routine's /fire endpoint after an engineer drops a designated emoji on a summary message. It then drafts a Notion page with a timeline, impact, and initial resolution steps.
Approval surface: The routine runs unattended. An engineer reviews, edits, and publishes the Notion draft the next morning.
Governance & security checklist:
- Scope the PagerDuty token to read-only on specific services. Scope Slack tokens to the incident channels only, not org-wide.
- Redact customer identifiers (email, user ID, account ID) at the tool layer before the draft is written to Notion. Do not rely on the model to scrub PII.
- Log triggering PagerDuty incident ID → drafted Notion page ID for every run, not just on failure.

On-call triage and ticket creation (Sentry to Linear)

When a service degrades, on-call engineers get paged with a dozen near-identical error reports. This workflow groups the noise by Sentry fingerprint and files one Linear ticket per cluster so the on-call triages root causes, not duplicates.

Trigger: API. Claude Code Routines don't accept arbitrary third-party webhooks (only GitHub events), so configure Sentry's webhook integration to POST to the routine's /fire endpoint with its bearer token when an error spike crosses a configured threshold. Runs outside the daily orchestrator because triage value drops fast if it waits.
Workflow: The routine reads fresh events from Sentry, groups them by fingerprint to collapse duplicates, and ranks clusters by event count and affected-users count. Each cluster becomes a Linear ticket with the stack trace snippet, affected release, and a link back to the Sentry issue. Tickets land in an un-triaged queue with a default P3 label.
Approval surface: The routine never triages itself. The on-call engineer reviews the queue, adjusts severity, and assigns the ticket.
Governance & security checklist:
- Scope the Sentry token to specific project slugs. Exclude projects flagged as handling authentication or payment data.
- Strip user-supplied strings (URL params, form inputs, search terms) from error payloads before the agent sees them. Those fields are the prompt-injection surface.
- Log the mapping from Sentry event ID → Linear ticket ID. This is what lets post-incident reviews reconstruct which alert caused which ticket.

Weekly pull request aging and code review report (GitHub)

Stale PRs create merge conflicts, block releases, and erode review velocity. This workflow replaces the Friday morning dashboard sweep with a single email that names the three PRs each lead needs to act on.

Trigger: Scheduled. The daily orchestrator runs the workflow every day; the body skips itself on non-Fridays.
Workflow: The routine queries the GitHub GraphQL API for PRs open longer than three days across the org, pulling each PR's review state, failing check runs, and unresolved review comments in a single query. It summarizes each PR's blocker (waiting on reviewer X, failing CI check Y, unresolved change requests) and emails a grouped digest to the relevant engineering leads.
Approval surface: Read-only. The email dispatches without human intervention, so the token scope is the real control.
Governance & security checklist:
- Use a GitHub App token with metadata, pull_requests, and issues read-only. Do not grant contents scope; the routine never needs the diff.
- Strip code blocks from the email template before send, even if the agent tries to paste one.
- Send from a dedicated service-account email, not a developer mailbox, so downstream audit trails stay clean.

Expansion signal scanner for customer health (HubSpot, Slack)

Support tickets and shared Slack channels are where customers accidentally self-identify as enterprise-tier: questions about rate limits, SSO, SOC 2 reviews, and data residency. This workflow surfaces those signals into a single account-health feed so the revenue team sees them.

Trigger: API-triggered. Runs as part of the nightly meta-orchestrator.
Workflow: The routine queries HubSpot for tickets created or updated in the last 24 hours and scans the body and notes for enterprise-tier keywords ("rate limits," "SSO," "SOC 2," "HIPAA," "data residency"). For shared customer Slack channels, bulk history ingestion is off the table because of conversations.history rate limits, so the routine uses the Slack Search API against the same keyword set. Each matching account gets a row in an internal Slack post with links back to the source ticket or message.
Approval surface: Findings land in a dedicated internal Slack channel with source links. An account manager reviews each flagged account and decides whether to open an expansion conversation.
Governance & security checklist:
- The routine never writes to HubSpot. It reads from an allowlist of ticket properties (subject, body, pipeline stage) and nothing else.
- Restrict the Slack token to public support channels plus explicitly listed shared customer channels. Never grant channels:history org-wide.
- Log which account IDs, ticket IDs, and Slack message IDs were scanned on each run, along with which keywords matched. The keyword that triggered the flag is the part account managers need to trust the signal.

Friday release notes and changelog draft (GitHub, Jira/Linear)

Commit messages are written for engineers; release notes are written for customers. This workflow drafts the customer version so the product team edits prose instead of compiling a changelog from scratch.

Trigger: GitHub event trigger on release.created, scoped to the specific repository. Requires the Claude GitHub App installed on the repo. Running /web-setup alone grants clone access but doesn't enable webhook delivery.
Workflow: The routine finds the previous release tag, collects every PR merged into main between the two tags, and resolves each PR back to its Jira or Linear ticket using the ticket ID conventionally placed in the PR title or body. It then drafts customer-facing release notes in Markdown, grouped by feature area. One caveat: the bundled GitHub MCP connector has gaps around basic writes like updating the release body directly, so the routine opens a pull request against a release-notes/ branch instead of editing the release in place.
Approval surface: The routine commits the Markdown to a release-notes/<tag> branch and opens a PR. A product manager edits the copy and merges.
Governance & security checklist:
- Give the routine read-only access to Jira and Linear. It should never change a ticket's status or rewrite acceptance criteria.
- Enforce a branch protection rule: the routine's write token can only push to branches matching release-notes/*. The main branch is structurally unreachable.
- Log triggering release tag → list of PRs analyzed → resulting changelog PR number. When the next release breaks, provenance is what makes the diff debuggable.

How to evaluate an enterprise MCP runtime for Claude Code routines

Every workflow above has a shared dependency: the tool layer underneath. Native Claude Code Routines can't safely execute these tasks on bundled connectors alone. Workflow 5's note about the GitHub connector missing basic writes is representative of the stock first-party set, not an outlier.

Relying on bundled connectors and first-party token inheritance also means rate-limit failures, prompt injection exploits, and security audits that halt deployment.

What's missing is a purpose-built MCP runtime: the execution layer where tools run, credentials are resolved just-in-time, and every action is authorized against a specific user's permissions. This is not another proxy in front of your enterprise systems; the agent is already the proxy. The runtime is where the tool call lands, where identity and policy are evaluated, and where the audit record is written. Critically, the runtime is stateful. It maintains per-session, per-user context across an agent's entire reasoning loop, which is exactly what a stateless proxy cannot do. And this statefulness is what makes per-user, per-tool authorization enforceable.

An enterprise MCP runtime delivers three capabilities working in concert: agent authorization (per-user, per-tool, per-action), agent-optimized tools (built for LLM consumption, not API passthrough), and agent lifecycle governance (centralized control, versioning, and full-execution audit logs).

Capability	Bundled first-party connectors	Enterprise MCP runtime
Permission model	Inherits the creator's global OAuth scope	Scoped per routine, per user, per action
Auth lifecycle	Token embedded at setup; manual refresh	Runtime manages refresh, rotation, and expiry
Audit logs	Opaque, per-connector, not unified	Full chain of custody per tool call (user, tool, params, result), exportable to SIEM via OpenTelemetry
Prompt injection defense	None; LLM parses raw input into API calls	Multi-layered: isolated credentials, per-action auth, schema enforcement, visibility filtering
Rate-limit handling	Direct hits against upstream APIs	Throttling, batching, and targeted webhooks
Tool catalog	Stock first-party set only	The largest catalog of agent-optimized MCP tools (8000+)
Gateway composition	One OAuth/connector per upstream service	Runtime-level federation: tools composed into a single identity-scoped URL (Arcade calls this the MCP Gateway feature: a composition layer, not a proxy)
Cross-harness portability	Claude Code only	Any MCP-compatible harness (Codex, OpenCode, local-model)

Agent authorization: per-user, per-tool, evaluated at runtime

The most critical function of a dedicated MCP runtime is handling multi-user agent authorization, sometimes called post-prompt authorization.

Single-user demos hide the real problem. Anthropic's docs are explicit that "routines belong to your individual claude.ai account. They are not shared with teammates." Every routine is structurally a single-user artifact, even when the work it does affects an entire team. The moment a routine has to act on behalf of multiple users (one-per-engineer on a platform team, or org-wide when a customer-health scanner runs for every account manager), shared service accounts and creator-inherited OAuth scopes collapse as a model. Teams either give the agent broad permissions (and an intern bypasses their access controls through the agent) or inherit the user's full permissions (and one prompt injection cascades through every system that user can touch). The right answer is the intersection: what is this agent allowed to do AND what is this user allowed to do, evaluated per action at runtime. That is the problem the runtime has to solve before routines can move past single-user demos.

Rather than letting a routine inherit the global, administrative permissions of its creator, an advanced runtime isolates the LLM entirely from underlying credentials and executes every tool call On-Behalf-Of (OBO) a specific user. The runtime evaluates the intersection of the agent's baseline permissions and that user's native permissions per action at runtime, so every action is attributable to a specific human in the audit log.

Authorization is just-in-time. The runtime requests and validates credentials only when a specific user action requires them. If a user never invokes the Salesforce integration, no Salesforce tokens are ever obtained or stored. The entire OAuth flow (token exchange, refresh, storage) executes in deterministic backend logic that the LLM can never observe, alter, or leak. For additional governance, teams attach pre-tool-call and post-tool-call hooks to enforce custom policies: human-in-the-loop approvals for destructive actions, usage limits, or contextual access rules.

The runtime manages the entire OAuth token lifecycle. It handles token refresh, rotation, and mismatch scenarios outside the view of the LLM. If a routine tries to access a repository the target user can't see, the runtime blocks the action at the protocol layer.

Critically, the runtime hooks into the identity and entitlement systems you already run (Okta, Entra, SailPoint) instead of asking you to redefine authorization policies in yet another system. It acquires scoped tokens just-in-time, enforces the policy your IDP already owns, and keeps credentials isolated from the LLM and the MCP client. The runtime delegates authorization to what the enterprise has already defined; it doesn't duplicate it.

Agent-optimized tools: built for LLM consumption, not API passthrough

Most MCP servers today are thin API wrappers. When a user says "update the Acme deal," the wrapper still asks the agent for opportunity_id, owner_id, stage_enum, and close_date. The agent fills those parameters probabilistically and either guesses the wrong values or retries blindly. This failure mode is called parameter hallucination, and it's where most agent failures happen in production. A proxy layer has no mechanism to close it.

Agent-optimized tools invert this pattern. When a user asks to "make the intro paragraph friendlier," the tool translates that to segmentId=gz49hg56, index=350, text='your friendlier message'. The agent never thinks beyond "intro paragraph." Every tool ships with rich semantic descriptions to help the LLM pick correctly, consistent schemas across services regardless of the underlying API, and agent-interpretable errors instead of raw HTTP status codes. In practice this ships as the largest catalog of pre-built agent-optimized MCP tools (8000+), covering productivity, CRM, communication, and developer systems, so teams skip the wrap-an-API-in-MCP step entirely.

Reliability is a runtime concern, not an agent concern. Pagination, rate limiting, retries, and failover all get handled by the runtime, invisible to the agent. Tools execute in parallel where safe; failed calls retry with additional developer-defined context; MCP servers fail over automatically. The agent gets a clean result or a clean error, never a half-paginated list or a transient network blip bubbling up into the reasoning loop.

Strict schemas also harden the tool layer against prompt injection. Schema enforcement is one layer of the defense, not the whole defense. A malicious payload buried in a customer email can't talk the agent into a destructive call that doesn't match an approved schema. More importantly, credentials never leave the runtime, so a jailbroken prompt has no tokens to exfiltrate. Per-user authorization is evaluated at every action, so an injected instruction can't do more than the acting user is already permitted to do. And visibility filtering scopes the tools a routine can even see, so there's no latent high-privilege tool hanging around for a payload to discover. Prompt injection defense has to be structural and in depth: at the tool layer, the auth layer, and the governance layer. Not a prompt-level patch.

Agent lifecycle governance: centralized control and full visibility

Agent lifecycle governance is the third pillar of an enterprise MCP runtime. Deploying autonomous agents at scale requires centralized control over which tools are available, to whom, and with what permissions, plus total visibility into what's happening at runtime.

A dedicated runtime provides a full chain of custody for every agent action (user identity, tool name, parameters, and result), exportable to your SIEM via OpenTelemetry. Independent attestation (Arcade.dev is SOC 2 Type 2 certified) validates that these controls hold in production, which matters when security reviews start before deployment, not after. The runtime also lets security teams enforce visibility filtering so a routine only sees the tools it explicitly has permission to use, and provides the infrastructure to mandate human-approval gates for any routine attempting to write data to a production system.

Portability across agent runtimes using MCP

Investing in an MCP runtime also guarantees architectural portability. Because tools are exposed over the open MCP standard, the heavy lifting of building tool contracts, managing OAuth flows, and establishing governance policies happens once.

That investment is usable from any MCP client (Claude Code Routines, Cursor, Claude Desktop, VS Code, ChatGPT, and custom applications) and stays portable across other agent harnesses like OpenAI Codex or on-prem deployments running open-weights models for regulated workloads. When your team swaps Claude for a different harness on a specific workflow, or moves sensitive routines onto on-prem compute for compliance reasons, the tool contracts, OAuth flows, and audit logs travel with you. The agent harness changes; the governance layer does not.

How to test and deploy your first remote Claude Code routine

With the runtime in place, the remaining question is how to ship a routine to production without breaking things. Writing a prompt, attaching a token, and flipping the schedule is not the move. The four-step framework below enforces clear boundaries on top of your MCP runtime:

Step 1: Wire up Arcade MCP Gateway as a custom connector

Before you can safely test anything, give the routine somewhere governed to call. With Arcade, the flow is (full integration walkthrough at Arcade for Claude Code):

In your Arcade dashboard, create a new MCP Gateway. Configure it with Arcade auth so tools inherit per-user, per-action authorization rather than a shared service account.
Add the tools this routine needs to the gateway, scoped to the minimum the workflow requires and nothing more.
In the Claude web interface, create a custom connector pointing at the gateway's URL.
Complete the one-time authorization to link the connector to the gateway.

With the connector live, any routine you create can include it alongside (or in place of) bundled first-party connectors.

Step 2: Sandbox execution

Never test a new routine against production data. Sandbox the execution using the /schedule command in the CLI or the "Run now" feature in the web interface.

Point the routine at a scratch Notion workspace, a dedicated testing Slack channel, or a sandbox GitHub repository. Conduct multiple dry runs to observe how the routine handles edge cases, unexpected inputs, and empty datasets.

Step 3: Start with read-only permissions

When configuring the routine for its initial deployment, enforce a strict "Read-Only First" mandate. Use your Arcade gateway to scope the routine's MCP tools exclusively to read operations.

For example, if you're building an incident triage routine, allow the routine to read from PagerDuty and output its analysis to a simple text file or a private Slack message. Validate the quality of the routine's logic and data extraction for at least one week before granting permission to write data or create tickets.

Step 4: Add human approval gates for write actions

As you transition the routine to handle write operations, establish hard structural boundaries that mandate human oversight.

Don't allow the agent to commit directly to your main branch or publish documentation live. Instead, configure the routine to draft documents, open pull requests, or push code exclusively to branches with a specific prefix. Every destructive or state-changing action requires a human engineer to review and merge the work.

Where to start

Claude Code Routines deliver genuine unattended automation for engineering teams: Claude Code running on a schedule, GitHub event, or API call, entirely off the developer laptop. Realizing that value across an organization means acknowledging that moving from a localized laptop demo to a nightly production workflow introduces severe architectural and security challenges.

You can't run autonomous workflows at scale using bundled connectors, first-party token inheritance, and opaque execution logs. Production deployments demand typed tool contracts, robust rate-limit handling, and explicit permission scoping to protect against prompt injection and data exposure.

If your engineering team is evaluating how to run unattended AI agents safely, Arcade is the industry’s first MCP runtime purpose-built for this. By unifying agent authorization, agent-optimized tools, and agent lifecycle governance in a single runtime, we let you ship reliable production workflows without spending months rebuilding security and operational plumbing.

FAQ

What are Claude Code Routines, and what changed in the April 2026 release?

A routine is a saved Claude Code configuration (prompt, repositories, and connectors) packaged to run automatically on Anthropic-managed cloud infrastructure. The April 2026 release shipped three trigger types: scheduled, API (per-routine /fire endpoint with a bearer token), and GitHub events (pull request or release activity on a connected repository). Routines are currently in research preview.

How many times per day can a Claude Code Routine run?

Routines share subscription usage with interactive sessions and have an additional daily cap on how many runs can start per account. Anthropic doesn't publish a specific number and it can change during the research preview, so per-event routines that fire on every PR comment or alert quickly become impractical.

How do teams work around routine run quotas in production?

Two options. First, batch multiple tasks into a single daily "meta-orchestrator" routine and reserve real-time runs for only the highest-severity API and GitHub event triggers. Second, enable extra usage in Settings → Billing so runs that hit the cap continue on metered overage.

Why are bundled connectors risky for enterprise unattended routines?

Bundled first-party connectors inherit the creating developer's global OAuth scope. That permission inheritance fails security reviews the moment the routine touches shared code, customer data, or regulated systems.

How do unattended routines increase prompt injection risk?

Untrusted third-party text (PagerDuty descriptions, Sentry traces, customer emails) flows directly into the agent at runtime. A payload buried in that text can steer the agent toward unsafe actions. Defense has to be multi-layered at the runtime: isolated credentials the LLM never sees, per-user authorization evaluated on every action, schema enforcement on each tool call, and visibility filtering so the routine can't even discover tools it isn't permitted to use.

What is an MCP runtime, and why do I need it?

An MCP runtime is the execution layer where agent tool calls run. It resolves credentials just-in-time, authorizes each action against a specific user's permissions, enforces tool schemas, and writes a unified audit log. It is not another proxy in front of your enterprise systems. The agent is already the proxy. The runtime is where identity, policy, and execution come together.

What is "post-prompt authorization"?

The runtime checks each individual tool action at execution time against the acting user's permissions and the routine's policy. The routine never inherits the creator's blanket credentials.

Which routine actions should require human approval?

Any write or state-changing action (creating tickets, committing code, publishing documentation) should land as a draft, PR, or triage queue and go through a human review gate before merging.

How do Slack API rate limits affect these workflows?

Slack's conversations.history endpoint now rate-limits non-Marketplace apps to a single request per minute. Production designs use Slack Search, targeted webhooks, or curated context instead of bulk history pulls.

What should I implement first to deploy a safe routine?

Wire up Arcade as a custom connector first so the routine calls tools through a governed runtime, then test in a sandbox, enforce read-only tools, and introduce human-in-the-loop gates before granting write permissions.

What should be logged for auditability in enterprise routines?

Log the triggering event, the tools called, the target resources, the acting user or service account, and the resulting object IDs (e.g., Sentry event ID → Linear ticket ID).

Claude Code for the Outer Loop: An AI SRE Playbook to Reduce On-Call Toil

Manveer Chawla — Wed, 22 Apr 2026 22:03:16 +0000

It is 2:13am. PagerDuty fires for checkout-service, p95 past threshold for four minutes. You open Datadog, find the wrong dashboard, then the right one, then the CI tool for recent deploys, then Jira for open incidents, then #incidents in Slack to check whether a co-worker is already in the war room. Eight minutes in, you have a working hypothesis.

That is not incident response. That is a context-loading tax the on-call pays before the work begins.

Coding agents, such as Claude Code, are eating the inner loop. The outer loop is a different story. Operational work (incident response, runbook execution, SLO investigation, on-call handoffs) still looks almost identical to how it looked five years ago. The gap is not the model. It is the infrastructure to run agentic tools across a team, against production, with the auth, scope, and audit guarantees an SRE program needs.

This article is about the execution layer. The data substrate underneath is the other half of the problem, and I've written about it on the ClickHouse blog.

TL;DR

Claude Code already works in the outer loop. The interface, the reasoning, the tool-call contract all transfer. What changes is the data sources.
Five workflows prove it. Incident triage, runbook execution, postmortem drafting, SLO investigation, on-call handoffs. Every one of them is Claude-shaped.
The auth, scope, and audit gap is the bottleneck. The MCP servers for most SaaS tools already exist. The problem is that when every engineer wires their own connection, you inherit inconsistent authorization, over-scoped credentials, and no audit trail. Useful to one person at best. A data exposure incident at worst.
The gap is an MCP runtime, not a model. Managed auth, hosted compute, tool-level governance, persistent audit logs. Until something provides all four, outer-loop AI stays a party trick.
An MCP runtime is more than an MCP gateway. A gateway routes MCP tools under one URL. An MCP runtime adds the compute that runs them, the auth that scopes them, and the audit trail that makes them safe in production. Arcade.dev is an MCP runtime with a gateway inside it.

Five AI SRE workflows and the MCP servers that power them

If you only read one thing in this article, read this table.

#	Workflow	MCP servers	What Claude Code does	What on-call does
1	Incident triage	PagerDuty, Datadog, Slack, GitHub	Pulls the PagerDuty payload, correlates Datadog signals in the window, checks recent deploys, scans Jira and #incidents, drafts a war room post	Decides the next move
2	Runbook execution	Confluence, Kubernetes, GitHub	Parses the Confluence doc into steps, lays out the diagnostic sequence with commands and expected output, proposes any write command	Runs the steps, approves every write
3	Postmortem drafting	Slack, PagerDuty, Datadog, Confluence	Reconstructs the timeline from Slack, PagerDuty, Datadog, and the deploy log, fills the team template with source-linked evidence	Writes the root cause and action items
4	SLO investigation	Datadog, PagerDuty, Snowflake, Confluence	Finds the burn inflection, correlates deploys, config changes, traffic shifts, and upstream incidents, ranks hypotheses with linked evidence	Evaluates hypotheses, decides action items
5	On-call handoff	PagerDuty, Datadog, Slack, Zendesk	Assembles the shift briefing from pages, active incidents, baking deploys, SLO burn, and open action items, delivers it as a Slack DM	Reviews, adds color, signs off

Workflow 1: Incident triage is mostly archaeology

Scenario

The manual triage above is a parallelism problem, not a skill problem. One engineer, five workflows, sequential context loads. Every on-call engineer I know tells the same story: "I spent the first ten minutes figuring out what was happening."

What Claude Code does

Hand the alert to Claude Code: "Triage this particular alert, correlated with the Datadog metrics, service logs, and the deployment history. Scan Slack history for other correlated failures."

Claude Code returns the alert context in two sentences, the top three correlated signals with direct Datadog links, and the deploys most likely to matter by service-graph proximity with commit SHAs and authors. Two to three minutes end to end, running while you are opening the laptop. Grafana's team reported a 3.5x reduction in time to root cause using a similar pattern.

What on-call does

By the time the on-call moves from the alert on their phone to opening their laptop, Claude Code's initial analysis is waiting. They read the summary, validate it against the dashboards, cross-reference the ranked deploys against what they know shipped recently, and decide the next move. They also catch the failure modes: the correlation that is spurious, the deploy the service graph does not know about, the #incidents thread that was noise. Claude Code compresses the archaeology. The on-call judges it.

The auth, scope, and audit gap

PagerDuty, Datadog, Slack, Jira, and GitHub all ship MCP servers. The problem is running them across a team, not building them.

If the setup is not configured consistently for every engineer on the rotation, the workflow breaks on the shift that needs it most. Misconfigured permissions lead to inconclusive analysis, and inconclusive analysis at 3am is worse than no analysis at all. Engineers who wire up their own connections often grant themselves broader scopes than the workflow needs, and the next access review turns into cleanup nobody planned for. The failure mode that matters most: if tool access is not scoped properly, a diagnostic step can inadvertently trigger a write action, mutate state in production, and turn the triage itself into the incident. Consistent setup, scoped credentials, and read-only enforcement are properties of the MCP runtime, not the individual engineer's configuration.

Workflow 2: Runbook execution at 3am

Scenario

Mature teams maintain their runbooks. The ones in constant use stay fresh because people fix them after every incident. The rot lives in two quieter places. Runbooks that fire once a quarter drift between uses, and nobody notices until the next 3am page reveals that half the commands point at deprecated tools and renamed clusters. And new engineers on the rotation often do not know which runbook applies to the alert in front of them. Finding the right doc at 3am is its own skill, and it takes months on the rotation to build.

"Runbooks are a lie we tell ourselves."

During my time leading reliability at Confluent and Dropbox, I saw this pattern play out across very different stacks. It is not an organization-specific problem. It is the law of prioritization playing out: the runbooks that fire often get the attention, and the ones that fire rarely do not.

What Claude Code does

Finding the right runbook. Once triage narrows the problem, the on-call needs to know which runbook applies and what to run. Point Claude Code at the alert. It matches the metadata (service, symptom, tag) against the runbook index, surfaces the top candidate, and lays out the diagnostic sequence with exact commands, the systems they target, and expected output for each step.

Keeping runbooks fresh. Most mature teams run quality weeks or reliability sprints to refresh runbooks. At Confluent, we did this quarterly. Claude Code makes the sprint cheaper since this is a safe environment: replay every runbook against staging in a batch, flag the commands pointing at deprecated tools and renamed clusters, regenerate steps against current infra. The rot that accumulated since the last review gets caught in hours instead of weeks.

What on-call does

The on-call runs the steps. Claude Code lays out the plan, the engineer executes it. Opening unbounded production access to a coding agent does not pass the sniff test for any reliability org I have worked with, and should not. The engineer confirms Claude Code picked the right runbook, runs each diagnostic in their own terminal with their own scoped credentials, and tracks pass/fail as they go. When Claude Code picks the wrong runbook, the on-call re-points it, and that correction feeds the index for the next page.

The auth, scope, and audit gap

If Claude Code does not execute against production directly, enforcement becomes the whole game. The runbook has to be scoped to the user running it, the environment it targets, and the actions the current step actually needs. A step that is safe in staging is dangerous in prod. A step that is safe for a senior SRE is catastrophic for a new joiner still learning the cluster. Without tool-level governance that understands user, environment, and action together, you are back to trusting every engineer to read carefully at 3am, which is exactly the failure mode the runbook was supposed to prevent. Finding the right runbook and enforcing the right scopes are two different problems. Claude Code solves the first. The MCP runtime solves the second, with governance scoped per user, per environment, and per action. Both have to work, and neither replaces the other.

Workflow 3: Postmortem drafting rots at the archaeology step

Scenario

The incident resolved at 4pm. The retro is Thursday. Someone has to write the draft. The hard part is not the thinking. It is the archaeology: Slack scrollback, PagerDuty timeline, Datadog graphs, deploy history, team template. The incident.io team puts manual reconstruction at 60 to 90 minutes per incident. That matches every team I have run.

Most postmortems get drafted badly at the last minute. The retro starts from a weak foundation, and the same incident class comes back six months later.

What Claude Code does

Type into Claude Code: "Draft the postmortem for INC-4729 using the team template." Claude Code assembles the archaeology. It pulls the Slack transcript, the PagerDuty timeline, the Datadog panels from the incident dashboard, and the deploy log for every service touched. It drops each of those into the team template with source links, so every timeline entry traces back to the panel, commit, or message it came from.

The draft stops at archaeology. Timeline, impact, affected services, evidence. The root cause, contributing factors, and action items fields are left structurally empty. Teams that let AI draft those turn every retro into a cleanup exercise. Zalando's team reported hallucination rates as high as 40 percent in early AI-drafted postmortem analysis, and the lesson is not better prompting. It is to keep anything causal out of the draft.

What on-call does

The on-call and the retro group review the draft. They are not rewriting it. They correct timeline entries that are wrong, add the signal the archaeology missed (a customer report that came through email, a related incident three days earlier, the deploy two sprints ago that introduced the latent bug), and spend their time on the part that matters: running the 5 whys, pressure-testing the root cause, deciding action items.

The leverage is strongest on the long tail. In my experience, eighty to ninety percent of incidents a mature team handles are high-volume, low-priority events where the archaeology is mechanical and the writeup feels mundane. That is where teams cut corners, and where repeat incidents quietly accumulate. Claude Code absorbs the mundane work so the high-judgment work gets attention on every incident, not just the big ones.

The auth, scope, and audit gap

The tools the draft pulls from carry the most sensitive data in the company. #incidents has customer PII and vendor secrets. The deploy log has commit messages that sometimes leak security context. Datadog dashboards expose traffic patterns across the fleet. The engineer who set up the Slack connector usually has broader workspace read than the postmortem role needs, and the draft ends up citing messages it had no business reading.

Scoping has to happen at the tool layer, not the prompt layer. Which channels the draft can read, which dashboards it can fetch, which tables it can query, all bounded by policy and tied to the user triggering the workflow. Then a provenance trail in a persistent log, showing what the AI accessed, when, and under whose identity. That is the half compliance will ask about, and the half that decides whether the workflow survives its first security review.

Workflow 4: SLO investigation and error budget reviews

Scenario

At Confluent, my team reviewed our availability SLO every Monday. We pulled the week's incidents, measured their impact on the SLO and the customer SLA, and mapped the root causes from each postmortem back to services and themes. The goal was to see whether the week's error budget had been spent on one repeat problem or scattered across five unrelated ones.

Most of the prep was manual correlation: error budget delta, matched to PagerDuty incident, matched to Datadog regression, matched to deploy history, matched to the postmortem, matched to the theme bucket. One SRE typically spent four to six hours on that pipeline before the meeting started. The thinking happened in the review. The prep was legwork.

What Claude Code does

Ask Claude Code to prep the Monday review. It pulls the SLO and SLA deltas, fetches every PagerDuty incident in the window, joins each to the Datadog regression that matches in time and service, pulls the postmortem from Confluence, and extracts the root cause section. It groups root causes into themes using the team's existing taxonomy and hands back a structured brief: error budget delta, the incidents that account for it, the themes, and the open questions the postmortems did not resolve.

What Claude Code does not do is quantify how much of the burn each incident "caused" in percentage terms. That is causal analysis current models do poorly, and a made-up percentage in a metrics review is worse than no number.

The AI hunts. The human decides.

What on-call does

The SRE running the review reads the brief, validates the incident-to-regression matches (Claude Code will get some wrong), writes the causal story the AI refused to guess at, decides which themes warrant action items, and raises the open questions in the meeting. Four hours of prep becomes thirty minutes of review and correction.

The auth, scope, and audit gap

Warehouse-backed workflows are the ones SRE teams have held off on the longest, and the reason is scope. You cannot hand Claude Code unrestricted warehouse access and hope prompt engineering keeps it away from PII. You cannot give it unbounded query budgets and wait to see a five-thousand-dollar scan on next month's bill. Scope enforcement at the MCP runtime layer is what changes the math: this task queries these tables and not others, costs less than fifty dollars, never touches prod write paths. Without that, the workflow stays a prototype and never makes the rotation.

Workflow 5: On-call handoffs lose the context nobody wrote down

Scenario

Handoffs are the most undervalued ritual in SRE work because the incidents they prevent never get counted. Handoff quality tracks how tired the outgoing engineer is, which means handoffs are worst on the shifts that had the most incidents, which is when they matter most. The non-obvious cost: the morning incident where the new on-call did not know a deploy was still baking, and ends up paging the previous on-call at 8am to ask what happened overnight.

What Claude Code does

Claude Code generates the briefing at the rotation boundary, without anyone triggering it. It pulls the last 24 hours of pages with resolution notes, active incidents, baking deploys, SLOs that crossed a burn threshold, unresolved #incidents threads, Zendesk escalations, and customer reports that came in through the on-call email alias. It lists open action items assigned to the rotation. It delivers the briefing as a Slack DM with a copy in the team's handoff Confluence doc.

What on-call does

The outgoing engineer adds the color only they can add: what they think is a false alarm, which customer report to watch, which deploy they are nervous about, which alert they silenced and why. That is the handoff knowledge that lives in the outgoing engineer's head and nowhere else. Claude Code assembles the facts. The on-call provides the judgment.

The auth, scope, and audit gap

The briefing fires at 5pm whether anyone is logged in or not, which means it needs a credential that lives outside any single engineer's session. Dotfiles on a closed laptop do not qualify. A scheduled workflow without a persistent service identity is not a workflow. It is a cron job that silently stops running the next time someone rotates off the team. Persistent service identity is a property of the MCP runtime, not the engineer's laptop.

Claude Code is a companion, not an autonomous AI SRE

Five workflows, one pattern. Claude Code reads, correlates, drafts, and waits. The human decides.

Most of the AI SRE market is betting the other way. Traversal, Resolve, Anyshift, and others are building toward autonomous agents that page, remediate, and close incidents on their own. I am skeptical. A model's output is a function of its capability and the context it is given. Current models can do the archaeology reliably. They cannot reliably be given enough scoped context and the right tools to remediate production unsupervised. That is a context and tooling gap, not a model gap, and I would rather ship the shape that already works.

Claude Code runs when you ask. It stops when the next step needs judgment. It never pages, rolls back, or closes an incident on its own.

A companion also dodges the procurement fight that stalls autonomous rollouts. You are not replacing a role or adding an on-call tier. You are pointing the tool your team already uses at data sources they already trust, with an MCP runtime that scopes what it can do. The security review goes from "new vendor, new risk" to "scoped tools inside an existing agent."

Every workflow in this article starts as a prompt and grows into a skill. The triage prompt, the runbook dispatcher, the postmortem drafter, the SLO prep pipeline, the handoff briefing: each one begins as something one engineer types once, and becomes a packaged skill every engineer on the rotation invokes the same way. The skill keeps getting sharper because the team keeps editing it: a new data source here, a tighter prompt there, a correction after an incident surfaces a blind spot. One person's trick becomes team infrastructure, and the infrastructure compounds.

Reliability comes from running a proper reliability program, and a proper program is mostly operational work around rituals: triage, runbooks, postmortems, SLO reviews, handoffs. Claude Code earns its keep by making the rituals cheap enough to happen on every shift, not just the ones where someone has the energy for them.

What an AI SRE needs from its MCP tool integration layer

Every workflow above needs the same four things.

Managed authentication and authorization across tools. OAuth flows for every connected tool, credentials refreshed automatically, scoped per user, reachable from any device including a phone at 3am.
Managed compute, always on, team-wide. Tools run on shared infrastructure, cloud-hosted or on-prem, with the same behavior whether the trigger came from a laptop, a phone, a webhook, or a cron job.
Tool- and agent-level governance. Per-tool permission policies, per-task cost budgets, and per-query data access limits enforced where the call happens, not where the model proposes it. This is the difference between a workflow security will approve and one they kill on sight.
Persistent audit logs. Every tool call logged with triggering user, arguments, response, and timestamp, in a log the agent cannot modify. Without this you cannot retro the AI, and you cannot trust it.

Arcade: an MCP runtime for AI SRE workflows

Arcade is an MCP runtime built to close exactly this gap. Managed OAuth handles every connected tool, with credentials that refresh automatically and never touch the language model. Every tool call runs on behalf of the user who triggered it, so native permissions in PagerDuty, Datadog, and Snowflake apply exactly as they would outside the agent. You connect PagerDuty once, and every Claude Code session on your team picks it up at the right scope.

The runtime runs tools on hosted workers, deployable in your cloud or on-prem, and enforces per-tool policies where the call happens, not where the model proposes it. The same workflow triggered from a phone, a laptop, or a cron job executes on shared infrastructure. Policies fire at the MCP runtime layer: "this workflow queries these Snowflake tables and not others," "this workflow can propose PagerDuty actions but cannot execute without approval," "this workflow has a $25 query budget."

Every tool call lands in an OpenTelemetry-compatible run log with triggering user, arguments, response, and timestamp. It drops straight into the observability pipeline your platform team already runs. When your postmortem asks what Claude Code did during the incident, you have the answer. When compliance asks for every query this AI ran against the warehouse last quarter, you have the answer.

Prebuilt tools ship for PagerDuty, Datadog, Slack, Jira, Confluence, GitHub, Snowflake, and more. You can also bring your own MCP servers into the runtime: the PagerDuty, Datadog, Snowflake, and Kubernetes servers linked in the table above drop in as-is and inherit the same managed auth, policy enforcement, and audit logs as the prebuilt ones. You extend your existing MCP investment instead of replacing it.

You can build this without Arcade, and the reason not to is the same reason you did not write your own CI system: the work is real, the edge cases are ugly, and it is not where your reliability differentiation lives. A mature team can hand-roll managed OAuth, stand up hosted workers, wire per-tool policy enforcement, and ship a tamper-evident audit log. A few platform teams I know started down that path and concluded it was too costly to own, or simply not where they wanted to spend their reliability budget.

Reducing on-call toil is where SRE leverage lives

The outer loop has not caught up to the inner loop because the infrastructure to run agentic tools safely against production systems has been missing. A coding assistant only needs your repo and your editor. An operational assistant needs managed identity, hosted compute, enforced governance, and an audit trail, because it reaches into systems where mistakes page the CTO.

The SRE teams that figure this out over the next year will pull away from the ones that do not, the same way the teams that adopted Claude Code for inner-loop work in 2024 pulled away from the teams that waited. The inner loop is solved. The outer loop is where the leverage lives now, sitting on a data substrate that is its own design problem.

Claude Code does not replace the on-call. It just lets them start on page 5 instead of page 1.

Frequently asked questions

What is an AI SRE?

An AI SRE is an AI assistant that helps site reliability engineers with operational work: incident triage, runbook execution, postmortem drafting, SLO investigation, and on-call handoffs. Most practical AI SRE deployments today run as companions that read, correlate, and draft while a human engineer decides the next move, rather than as autonomous agents that page, remediate, and close incidents on their own.

What is the difference between an MCP gateway and an MCP runtime?

An MCP gateway routes MCP tools under a single URL so any MCP client can call them. An MCP runtime goes further: it adds the compute that runs the tools, managed authentication, per-tool permission enforcement, and persistent audit logs. A gateway is routing infrastructure. A runtime is production infrastructure. Arcade is an MCP runtime with a gateway inside it.

Can Claude Code replace an on-call engineer?

No. Claude Code works best as a companion to the on-call engineer, not a replacement. It compresses the archaeology (pulling alerts, correlating signals, drafting summaries) so the engineer starts with context already loaded. Every decision that requires judgment (rolling back a deploy, paging a co-worker, closing an incident) stays with the human.

How do I use Claude Code for incident triage?

Point Claude Code at the alert with a prompt like "Triage this alert, correlated with Datadog metrics, service logs, and deployment history. Scan Slack for correlated failures." With MCP servers for PagerDuty, Datadog, Slack, and GitHub wired into an MCP runtime, Claude Code returns a summary, the top correlated signals, candidate deploys, and a draft war room post in two to three minutes.

Is it safe to let Claude Code execute runbooks in production?

Claude Code should not execute against production directly. The safer pattern is for Claude Code to parse the runbook, lay out the diagnostic sequence, and propose commands, while the on-call engineer runs each step in their own terminal with their own scoped credentials. Unbounded production access for any coding agent should not pass a reliability review.

What MCP servers do I need for AI SRE workflows?

The core set covers the tools already in an SRE rotation: PagerDuty, Datadog, Slack, and GitHub for incident triage; Confluence and Kubernetes for runbook execution; Snowflake for SLO investigation; Zendesk for on-call handoffs. Each has a production-ready MCP server that can run inside an MCP runtime like Arcade, which handles managed auth, policies, and audit logs across all of them.

How does Arcade work with Claude Code?

Arcade is an MCP runtime that manages OAuth, per-tool permission policies, and audit logs for every tool Claude Code calls. You connect PagerDuty, Datadog, or Snowflake once, and every Claude Code session on your team picks up the tools at the right scope. Arcade also runs bring-your-own MCP servers, so existing integrations work as-is.

What is the difference between AI SRE tools like Traversal and using Claude Code with an MCP runtime?

Traversal, Resolve, and Anyshift are building autonomous agents that page, remediate, and close incidents on their own. Claude Code with an MCP runtime takes the companion approach: read, correlate, draft, and wait for the engineer to decide. The companion pattern ships today. The autonomous bet does not.

Does the observability store underneath matter as much as the MCP runtime above?

Yes. An AI agent runs 10 to 30 queries per investigation, and most observability stores weren't built to serve that pattern at the retention and cardinality an SRE needs. The MCP runtime handles the execution layer; the observability store handles the cognitive substrate. Both matter. I've written about the substrate side here.

How to Connect AI Agents to Enterprise Productivity Tools Securely (2026 Architecture Guide)

Manveer Chawla — Thu, 09 Apr 2026 20:58:36 +0000

Most enterprise AI agents today can analyze but can't execute. They summarize documents, surface insights, and draft responses. They don't close support tickets, update Salesforce, or trigger deployments. The ROI stays incremental. The architecture that solves this is an MCP runtime, a secure execution layer that handles authorization, credentials, and tool calling on behalf of each user.

The real transformation happens when agents take actions, when employees direct work instead of doing it. But getting agents to safely execute across enterprise systems is where everything falls apart.

Recent industry studies from IDC and MIT show that 88 to 95 percent of enterprise AI pilots fail to reach production. The root cause isn't the language model. It's the complexity of secure integration, and every month spent rebuilding auth plumbing is a month your agents aren't delivering business value.

Key takeaways

Use an MCP runtime as the secure action layer between your agents and enterprise tools. It evaluates the intersection of agent permissions and user permissions per action at runtime.
Execute every tool call on behalf of the user (OBO). The agent acts with the user's credentials, scoped to the user's native permissions, and every action is attributable in audit logs.
Keep OAuth tokens out of the LLM context. Credentials must be vaulted at the runtime layer where the model cannot observe, alter, or leak them.
Do not use static service accounts. They break permission models and turn a single prompt injection into an enterprise-wide incident.
Build with agent-optimized tools, not raw API wrappers: intent-level operations with validated schemas that prevent parameter hallucination and eliminate retry loops.
Require human-in-the-loop approvals for all destructive actions. Deletes, bulk updates, and external communications must pause for explicit sign-off before execution.
Ship audit logs and telemetry from day one. Export every tool call via OpenTelemetry to your SIEM for compliance, incident response, and root cause analysis.

Why connecting AI agents to enterprise tools is hard: identity, permissions, and safe execution

The bottleneck in agentic systems, such as Claude Cowork or OpenClaw, isn't making API calls. It's identity propagation, permission inheritance, and safe execution within complex enterprise environments.

When teams build direct integrations between LLMs and enterprise software, they immediately hit friction. Developers spend cycles managing fragile OAuth token lifecycles, handling async user consent flows, manually tuning least-privilege authorization scopes, and building custom approval controls. This is undifferentiated infrastructure work that burns engineering time without advancing the agent's core capabilities.

Because this work is tedious and blocks core agent development, teams frequently take a dangerous shortcut: they use service accounts.

Granting an agent global read and write access across an entire enterprise instance breaks native permission models. You're bypassing years of carefully configured role-based access controls.

A single manipulated input can result in instant, untraceable data exfiltration or system modification. If an agent holds a static API key with global write access, a localized prompt injection vulnerability becomes an enterprise-wide blast radius.

Teams make two mistakes here. Give the agent its own identity, and an intern can bypass their permissions through the agent. Inherit the user's full access, and one prompt injection cascades through every connected system.

The right answer is the intersection: what is this agent allowed to do AND what is this user allowed to do, evaluated per action, at runtime. This is the permission intersection model, and it's the only approach that prevents both privilege escalation and blast radius expansion simultaneously.

This evaluation must happen at the runtime layer. Not at login time, not in the prompt, and not in the application code. Without it, scaling agents beyond single-user demos is unsafe.

The architectural shift: The agent is already the proxy

Before evaluating specific integration approaches, you need to understand why the traditional enterprise architecture no longer applies.

In the pre-agentic model, a proxy (API gateway) sits between applications and APIs, routing, authenticating, and rate limiting. The proxy is the control point because all traffic flows through it.

Agents invert this topology. The agent mediates between the user and the infrastructure. It already handles routing, orchestration, and decision-making. Adding a traditional proxy in front of the tools the agent calls doesn't add a control point. It adds a redundant hop that can't see into the execution context that matters: which user, which action, which permission, right now.

The control point in an agentic architecture is the execution layer where the tool runs, where credentials are resolved, permissions are checked, and actions are taken on behalf of a specific human. That's the runtime.

The gateway era was defined by the proxy as the control point. The agentic era is defined by the runtime.

Four architectures for connecting AI agents to enterprise tools

As organizations move from isolated pilots to production deployments, engineering teams adopt one of four integration models. Understanding where each approach breaks down under enterprise load is critical for architectural planning.

Integration approach	Security & identity	Maintenance burden	Reliability & execution	Speed-to-market
Custom connectors & DIY auth	Highly variable; often falls back to static keys.	Extremely high; requires dedicated auth teams.	Low; prone to parameter hallucination loops.	Very slow.
Legacy iPaaS	Moderate; struggles with On-Behalf-Of execution.	Medium; relies on maintaining visual workflows.	Medium; optimized for linear triggers, not loops.	Moderate.
Unmanaged MCP servers	Low; lacks centralized multi-user authorization.	High; requires manual deployment and patching.	Low; lacks native retries and failover state.	Fast for prototypes.
MCP runtime (e.g., Arcade)	High; native permission mapping and token vaults.	Low; runtime handles lifecycle and upgrades.	High; parallel execution and automatic retries.	Very fast.

Approach 1: Build custom connectors and OAuth (DIY authentication)

Build one-off API wrappers and custom OAuth layers for every enterprise tool your agent needs.

The upside is total control. You dictate every aspect of the integration and avoid third-party vendor lock-in.

But the limitations get crippling fast. Custom connectors become a massive engineering drain. Teams spend months building secure token vaults, handling refresh token rotation, and writing edge-case logic. Those are months that could have been spent shipping agent features that actually move the business forward.

Raw enterprise APIs compound the problem. They expect highly structured, deterministic inputs, but agents generate dynamic natural language. Wiring them directly to raw endpoints leads to parameter hallucination and endless retry loops. Authentication alone becomes a standalone infrastructure project: token rotation, user matching, session validation.

Approach 2: Use legacy iPaaS for agent tool calls

Enterprises retrofit existing integration platforms like Workato, MuleSoft, or Zapier to trigger actions based on LLM outputs.

The strength is familiarity. Enterprise IT teams already know these tools, and they come with massive pre-built endpoint catalogs.

But the limitations are architectural and fundamental. These platforms were built for linear, deterministic, trigger-based automation. Agentic systems operate on non-deterministic, stateful reasoning loops where the agent decides what to call, when, and how many times based on intermediate results. Forcing that into a linear webhook pattern breaks down fast.

The deeper problem is identity. Legacy iPaaS platforms center on system-to-system service accounts. They lack true user-scoped, On-Behalf-Of (OBO) execution, which forces teams to build complex, fragile workarounds to ensure the agent only acts with the specific permissions of the user typing the prompt. Per-user authorization evaluated at runtime across every tool call requires infrastructure these platforms were never designed to deliver.

Approach 3: Run unmanaged MCP servers

The Model Context Protocol standardized how AI models connect to data sources and tools. In this approach, teams deploy open-source MCP servers to expose local or SaaS capabilities directly to their agents.

MCP's strength is standardization. It decouples the agent framework from the underlying tool implementation, creating a universal language for tool calling. The problem is that the quality of unmanaged, open-source MCP servers varies widely. According to benchmarks many struggle with reliability and correctness, which compounds the challenges of production deployments.

These servers break down the moment you take them to production. Raw, unmanaged MCP servers lack centralized governance. They don't ship with multi-user enterprise authentication handling, meaning every user often shares the same connection identity.

They also lack production reliability features like automatic retries, parallel execution, and stateful failover out of the box. That burden falls back on the application developer.

Approach 4: Use an MCP runtime (the secure action layer)

An MCP runtime is the infrastructure layer purpose-built to solve this problem. Arcade.dev, the industry's first MCP runtime, combines agent-optimized tools, centralized authentication and authorization, and enterprise governance into a single control plane.

This approach targets production AI specifically. The runtime speaks MCP natively (JSON-RPC, Streamable HTTP) with no protocol translation and no context loss. It preserves native permissions through On-Behalf-Of token flows, isolates credentials from the language model, and provides instant, OpenTelemetry-compatible audit logs for every action.

Teams ship faster because the runtime handles authorization, token lifecycle, retries, and governance. Engineers focus entirely on agent logic and business outcomes.

Arcade's MCP Gateway lets any MCP client access the full tool catalog through a single endpoint. Teams can also bring their own MCP servers into the runtime to get authorization, retries, and audit logs without rewriting what already works. The runtime extends your existing MCP investment rather than replacing it.

For single-user hobbyist projects or local scripts, a full runtime adds unnecessary overhead. But for platform engineering teams deploying autonomous systems to thousands of corporate users, an MCP runtime is the only viable path to production.

What production demands: authorization, tooling, and governance

The comparison above shows where each approach breaks. But understanding why the MCP runtime wins requires going deeper into the three capabilities that separate production deployments from demos: just-in-time authorization that enforces user-scoped access, agent-optimized tools that eliminate hallucination loops, and governance infrastructure that gives platform teams full visibility over every action.

How just-in-time authorization enforces user-scoped access

Custom connectors fall back to static keys. Legacy iPaaS platforms rely on shared service accounts. Unmanaged MCP servers lack multi-user auth entirely. All three fail at the same point: they can't evaluate who is allowed to do what at the moment the tool is called.

That’s the problem just-in-time authorization solves.

The agent requests and validates credentials only at the moment an action requires them, not upfront. If a user never invokes the Salesforce integration, no Salesforce tokens are ever obtained or stored.

The entire authentication flow (OAuth exchanges, token refresh, credential storage) executes in deterministic backend logic that the LLM can never alter, observe, or leak. For additional governance, teams can attach pre-tool-call and post-tool-call hooks to enforce custom policies like human-in-the-loop approvals for certain actions, usage limits or contextual access rules.

This works because the runtime is stateful. It maintains per-session, per-user context across an agent's entire reasoning loop. A stateless proxy evaluates each request in isolation and can't know that a request is step 3 of a 6-step workflow, acting on behalf of Alice, who authorized this specific scope 4 minutes ago. The runtime can, and that session context is what makes per-user, per-tool authorization enforceable.

This is where the permission intersection model described earlier becomes operational. The architecture enforces: Agent Permissions ∩ User Permissions = Effective Action Scope. The agent can only execute an action if both the agent's role policy and the human user's native SaaS permissions explicitly allow it. Every other combination is denied.

A concrete example: an enterprise AI agent is built to assist the Human Resources department. An employee using this agent has high-level administrative privileges in Workday, including access to global payroll data. But the HR agent itself is scoped strictly to recruiting tasks.

Because the runtime evaluates the intersection of these permissions at call time, the agent is denied when prompted to access payroll data. The user has the authority, but the agent's restricted scope prevents the action. This stops data exfiltration and confused deputy attacks cold.

Agent-optimized tools vs API wrappers: what to use and why

The comparison table flags a specific failure mode for custom connectors: parameter hallucination loops. This happens because raw REST endpoints require precise, deterministic parameters, and language models produce probabilistic natural language. Wiring one directly to the other without an intermediary is where agents break.

Agents need intent-level tools rather than raw API wrappers. An intent-level tool absorbs the ambiguity of an agent's request and translates it into a safe, predictable transaction. The result is faster execution, fewer failed actions, and lower inference costs because the agent doesn't burn tokens on retry loops.

Production execution also requires runtime reliability features that raw APIs don't provide. The runtime provides developer-defined context for intelligent retries, parallelized execution for multi-step tasks, and automatic failover to handle rate limits and transient network errors gracefully. Standardized schemas within these tools prevent parameter hallucination, the most common cause of agent failure when wiring models directly to APIs.

Consider how this works in practice. Instead of an agent calling a raw Salesforce update endpoint and failing because it hallucinated a required stage ID string, the agent uses a high-level, agent-optimized progress tool.

The tool natively understands the user's intent to move a deal to negotiation. Its internal logic securely looks up the correct, exact ID for that specific Salesforce instance, validates the state transition, and safely executes the update. The language model doesn't need to guess the exact database schema. The action succeeds on the first call, not the fifth.

Governance and observability for agent actions (audit logs, OTel, versioning)

Unmanaged MCP servers scored "Low" on reliability and security in the comparison above because they lack centralized governance. Once agents execute real actions on behalf of users, platform teams need complete visibility and control over the integration ecosystem. The runtime delivers this through three mechanisms.

Visibility filtering ensures agents only see the specific tools the current user is permitted to invoke. If a user doesn't have permission to merge code in GitHub, the GitHub merge tool doesn't appear in the agent's context window.

Deep audit trails log every action per user, per service, and per agent session. These logs are exportable to standard SIEM tools via OpenTelemetry (OTel) to satisfy compliance audits.

Version control lets platform engineers safely upgrade tool schemas and rotate connection parameters without breaking production agents running mid-session on older versions.

When an agent incorrectly closes several open opportunities in a CRM, the platform team can't spend days parsing raw application logs. With an OTel-compatible audit log generated by the action layer, the security team can instantly trace the destructive action back to the exact user prompt, the specific agent session, and the token used. This isolates the root cause in minutes, enabling teams to refine the agent's instructions or the tool's access policy immediately.

Of the four approaches evaluated, only the MCP runtime delivers all three: user-scoped authorization at call time, intent-level tooling that prevents hallucination, and centralized governance with full audit trails. The remaining sections show how this architecture works in practice and how to evaluate it for your organization.

How to choose an enterprise agent integration approach (security, OBO, and TCO)

Choosing how to connect your AI agents to enterprise tools is a foundational architectural decision. It dictates the speed and security of your deployment. Platform engineers and technical leaders need to frame their buying and building criteria around security, scale, and where their engineering resources should focus.

Security and compliance requirements (SOC 2, ISO 27001, auditability)

Can the proposed solution natively map to SOC 2 and ISO 27001 requirements for strict user attribution? If an agent deletes a file in Google Workspace, the audit log must definitively prove which human authorized that action.

The system must support pre-tool-call Human-in-the-Loop (HITL) approval hooks. Destructive actions like modifying production configurations or bulk-updating database records must pause execution and require cryptographic sign-off from a human administrator via Slack or email before proceeding.

Build vs buy economics (OAuth maintenance and total cost of ownership)

Build versus buy demands a ruthless economic assessment.

Calculate the actual engineering hours required to build, maintain, and securely upgrade OAuth flows for ten or more distinct enterprise APIs. Factor in the hidden costs: managing refresh token rotation, building webhook callback URLs for long-running async tasks, patching custom connectors when SaaS vendors inevitably deprecate their API versions.

Then ask what those engineers could have shipped instead.

Adopting an MCP runtime transforms a multi-month infrastructure project into a configuration exercise. The total cost of ownership drops dramatically, and your team reclaims months of engineering capacity to invest in the agent capabilities that differentiate your product.

Time-to-value and engineering focus

Time-to-value is where most teams underestimate the cost of building in-house.

Will your highly paid AI engineers spend the next three months building reliable Slack and Workspace connectors, or will they spend that time optimizing agent prompts, evaluating reasoning logic, and shipping the agent capabilities that drive revenue? Every week spent on integration plumbing is a week your competitors use to get their agents into production.

When evaluating external vendors or internal architecture plans, force the issue with hard technical questions:

Are API keys or OAuth tokens ever visible in the language model's prompt context window?
How does the system resolve conflicting permissions between a highly privileged user and a narrowly scoped agent?
Can the system emit W3C-standard trace context to our existing OpenTelemetry collectors?
How does the tool handle rate limiting when an agent enters an unexpected retry loop?

If the answer to credential visibility is anything other than absolute isolation, the architecture is unfit for enterprise production.

Reference architecture for an MCP runtime (step-by-step flow)

With the architectural decision framed, here's how a request actually flows through the runtime end to end. The MCP runtime acts as the intermediary that brokers trust and execution between the non-deterministic reasoning engine and the deterministic enterprise environment.

The flow of a secure request follows a strict sequence:

User prompt: The user submits a request, e.g., "close this support ticket."
LLM plan: The agent's language model determines the sequence of tool calls needed to fulfill the request.
MCP runtime: The runtime receives the tool call request. It evaluates user and agent permissions and retrieves the necessary On-Behalf-Of credential.
Tool execution: The runtime, not the agent, executes the precise API call against the target system (e.g., Zendesk).
Result & next action: The runtime receives the API result, filters it, and passes it back to the agent. The LLM then either plans the next action in the sequence or determines the task is complete.
Confirmation & audit: The agent confirms the action's completion to the user, and the runtime logs the entire transaction via OpenTelemetry for audit purposes.

This architecture enforces a hard separation of concerns. The language model handles reasoning, planning, action selection, and generation. The runtime layer handles credentials, policy enforcement, rate limiting, action execution, and logging.

By vaulting tokens at the runtime layer, this architecture prevents prompt-injection-driven data exfiltration. The language model never possesses the keys required to export data.

How an MCP runtime works with any LLM

The MCP runtime works with any LLM through any orchestration framework, or none at all. No framework dependency is required. Arcade serves as the secure execution backend: your code handles reasoning, Arcade handles credentials, authorization, and tool execution.

This clean separation is what accelerates time-to-production. AI engineers focus entirely on agent logic while offloading the high-risk plumbing of enterprise integrations to the runtime.

A working example: an agent that reads Gmail and sends Slack messages through Arcade's runtime. Setup requires three dependencies and three environment variables:

pip install arcadepy openai python-dotenv

# .env
ARCADE_API_KEY=your_arcade_api_key        # Free at arcade.dev
ARCADE_USER_ID=your_email@company.com     # The user the agent acts on behalf of
OPENAI_KEY=your_openai_key

from arcadepy import Arcade
from openai import OpenAI
from dotenv import load_dotenv
import json, os

load_dotenv()

arcade_client = Arcade()
arcade_user_id = os.getenv("ARCADE_USER_ID")
llm_client = OpenAI(
   api_key=os.getenv("OPENAI_KEY"),
)

# Define enterprise productivity tools — Arcade handles auth for each
tool_catalog = [
   "Gmail.ListEmails",
   "Gmail.SendEmail",
   "Slack.SendMessage",
]

# Get tool definitions formatted for the LLM
tool_definitions = [
   arcade_client.tools.formatted.get(name=t, format="openai")
   for t in tool_catalog
]

# JIT authorization + execution — credentials never touch the LLM
def authorize_and_run_tool(tool_name: str, input: str):
   auth = arcade_client.tools.authorize(
       tool_name=tool_name, user_id=arcade_user_id
   )
   if auth.status != "completed":
       print(f"Authorize {tool_name}: {auth.url}")
       arcade_client.auth.wait_for_completion(auth.id)

   result = arcade_client.tools.execute(
       tool_name=tool_name,
       input=json.loads(input),
       user_id=arcade_user_id,
   )
   return json.dumps(result.output.value)

# Agentic loop — LLM reasons and selects tools, Arcade executes them
def invoke_llm(history: list[dict], max_turns: int = 5) -> list[dict]:
   turns = 0
   while turns < max_turns:
       turns += 1
       response = llm_client.chat.completions.create(
           model="gpt-4o-mini",
           messages=history,
           tools=tool_definitions,
           tool_choice="auto",
       )
       msg = response.choices[0].message
       if msg.tool_calls:
           history.append(msg.model_dump(exclude_none=True))
           for tc in msg.tool_calls:
               result = authorize_and_run_tool(tc.function.name, tc.function.arguments)
               history.append({"role": "tool", "tool_call_id": tc.id, "content": result})
           continue
       else:
           history.append({"role": "assistant", "content": msg.content})
       break
   return history

# Run the agent
history = [{"role": "system", "content": "You are a helpful assistant."}]
history.append({"role": "user", "content": "Summarize my latest 5 emails, then send me a DM on Slack with the summary."})
history = invoke_llm(history)
print(history[-1]["content"])

The LLM reasons through the task, selects Gmail.ListEmails to fetch emails, summarizes them, then selects Slack.SendMessage to deliver the summary. The runtime handles JIT authorization for each tool on behalf of that specific user. The agent never sees OAuth tokens, never manages refresh flows, and never touches credentials. Full walkthrough in the Arcade docs.

Next steps to productionize agent integrations (checklist)

To transition from sandbox prototypes to production-grade deployments, platform engineering teams follow a structured, iterative implementation plan.

Step 1: Inventory required tools and least-privilege scopes

Start by conducting a rigorous audit of your necessary tools. List the specific APIs your agents need, and document the exact user-scopes and OAuth granularities required for each. Don't request global access. Map out the principle of least privilege for every single workflow.

Step 2: Define autonomous vs human-approved actions (HITL)

Next, define your operational boundaries. Build a matrix deciding which actions are safe for autonomous execution (like reading calendar events) and which high-risk actions require explicit user delegation or human-in-the-loop approval hooks (like deleting files or sending external emails).

Step 3: Standardize on a single control plane

Centralize your integration strategy immediately. Prevent the creation of "shadow registries."

When disparate engineering teams build redundant, unmanaged integrations using hardcoded tokens, they create severe security vulnerabilities and integration sprawl. Standardize on a single control plane for all agent tool use.

Step 4: Pilot one workflow and validate token isolation and telemetry

Before rolling out broadly, test the architecture with a narrow, controlled use case. Pilot a single workflow, like developer issue automation linking GitHub and Jira, to validate token isolation and telemetry.

Invest in infrastructure, not just isolated connectors. Evaluate platforms that treat authorization, agent-optimized tools, and lifecycle governance as a unified secure runtime, not separate problems.

Conclusion: Use an MCP runtime to connect AI agents to enterprise tools

The true challenge of connecting AI to enterprise productivity tools has little to do with formatting JSON payloads or making API calls. The bottleneck is securing user-scoped access, enforcing least-privilege permissions at runtime, and maintaining rigorous operational governance over non-deterministic systems.

The most successful platform engineering teams recognize that rebuilding identity propagation, token lifecycles, and reliable integration mechanics from scratch is an expensive distraction from their core business objectives. They need an MCP runtime, not more custom connectors.

Arcade is the industry's first MCP runtime. It delivers secure agent authorization, the largest catalog of agent-optimized tools, and centralized lifecycle governance in a single control plane. Arcade eliminates the undifferentiated heavy lifting of enterprise integration so your team ships faster and scales with control.

If you're building agents that need to execute across enterprise tools, start with the getting started guide or explore the full tool catalog to see what's available out of the box.

FAQ: Enterprise AI agent integrations

What is the best way to connect AI agents to enterprise productivity tools?

Use an MCP runtime, a secure action layer that performs user-scoped (OBO) execution, keeps tokens out of the LLM, and enforces runtime authorization per tool call.

Should AI agents use service accounts to access Slack, Google Workspace, or Microsoft 365?

No. Service accounts bypass user permissions and expand the blast radius of prompt injection. Use on-behalf-of user execution with least-privilege scopes.

What does "On-Behalf-Of (OBO)" mean for agent integrations?

OBO means the agent executes each action using credentials tied to the requesting user, so the action is limited to that user's native permissions and is attributable in audit logs.

What is just-in-time authorization for AI agents?

Just-in-time authorization is a runtime policy check that executes at the moment of each tool call, evaluating the user's identity, the agent's allowed scope, and the requested action. Credentials are requested and validated only when needed, not pre-authorized during setup.

What is an MCP runtime, and how is it different from an MCP server?

An MCP server exposes tools to an agent using the MCP, but it's typically single-user, stateless, and ships without built-in auth, token management, or observability. An MCP runtime is the enterprise infrastructure layer that complements MCP servers to add what they lack: multi-user OBO authentication, per-call policy enforcement, token vaulting, automatic retries, and audit/telemetry. The server defines what the agent can call; the runtime makes it safe to call at scale. Arcade is the industry's first MCP runtime, purpose-built for production agent deployments.

What are the minimum security requirements for production agent tool access?

Token isolation from the LLM, user-scoped/OBO execution, least-privilege scopes, per-action authorization, audit logs with user attribution, and HITL approvals for high-risk actions.

How do you audit and attribute agent actions for compliance (SOC 2 / ISO 27001)?

Log every tool call with user identity, tool, parameters/intent, outcome, and trace context, and export via OpenTelemetry to your SIEM for investigation and reporting.

When do legacy iPaaS tools (Zapier/Workato/MuleSoft) break down for agents?

They struggle with non-deterministic agent loops and true user-scoped OBO execution, forcing teams to rely on shared credentials or brittle workarounds.

How do agent-optimized tools reduce hallucinations compared to raw API wrappers?

They use intent-level operations with validated schemas and internal lookups, so the model doesn't have to guess required IDs/parameters and can fail safely.

When should we add human-in-the-loop (HITL) approvals?

For destructive or irreversible actions (deletes, external emails, bulk updates, permission changes) or any action that materially impacts security, finance, or customer data.

How to build a secure WhatsApp AI assistant with Arcade and Claude Code (OpenClaw alternative)

Manveer Chawla — Thu, 02 Apr 2026 21:43:19 +0000

I texted "prep me for my 2pm" on WhatsApp. Thirty seconds later, my phone buzzed back with a structured briefing: who I was meeting, what we last discussed over email, what my team said about them in Slack, and three talking points. No browser tab. No laptop. Just a message on my commute.

That's the promise of an always-on AI assistant. And until recently, it was almost impossible to build one that actually worked.

Open-source frameworks like OpenClaw made headless, two-way messaging agents popular. Anthropic's Claude Code Channels confirmed the approach had legs. Channels is currently in research preview, but the direction is clear. Anthropic already uses this pattern for hand-offs between their desktop app, mobile app, and Claude Code. Expect this to GA in some form.

But getting from a weekend demo to a reliable assistant exposes gaps that no amount of prompt engineering fixes. Authorization. Tool reliability. Session management. The agent needs access to your calendar, email, and Slack, and you need to be sure it's not a security liability.

I built a working version. This guide walks through the entire thing: a WhatsApp relay server, an MCP server, Claude Code as the brain, and Arcade.dev for secure tool access. Working code at every step.

We'll start with the pitfalls you need to understand, then build it.

TL;DR

OpenClaw-style headless frameworks give your agent god-mode access to every connected service, rely on brittle tool wrappers, bloat the context window with raw API responses, and produce zero audit trail. Buying a dedicated Mac Mini to run them doesn't help. The machine isn't the threat model, the credentials are.
This guide builds a WhatsApp AI assistant using a relay server that handles Meta's webhooks, an MCP server that bridges to Claude Code, Arcade for secure tool access and audit logging, and a meeting-prep skill that pulls from Google Calendar, Gmail, and Slack to deliver structured briefings directly in WhatsApp.
Every layer includes working code you can run locally: webhook ingestion with HMAC signature validation, a cursor-based message queue, MCP tool definitions, Claude Code configuration, and a complete skill file that encodes a three-phase meeting-prep workflow.

From demo to production: The four pitfalls of always-on AI agents

The headless setup that OpenClaw popularized is the starting line. The moment you try to move from a weekend proof of concept to something you'd actually trust with your calendar and email, four architectural problems surface.

Pitfall 1: God-mode credentials and the agent security risk

Headless agent frameworks inherit the host machine's full access profile. The agent gets the same permissions as the developer who launched it. Every OAuth token, every API key, every connected service, wide open.

A single prompt injection or compromised dependency cascades through everything. Your Google Drive, your CRM, your source code repos. One bad input and the agent becomes an insider threat.

This isn't theoretical. CVE-2026-25253 exposed a one-click RCE in OpenClaw. The gateway lacked origin validation. An attacker could exfiltrate the auth token via a malicious link and achieve total system compromise.

We wrote about this pattern in detail in OpenClaw doesn't need your tokens.

Pitfall 2: Fragile API wrappers and the tool reliability problem

Most agent tools are thin wrappers around REST APIs. They force the model to guess complex payload parameters and retry when natural language doesn't map to rigid schemas.

Then shadow registries appear. Different teams build duplicate, unversioned wrappers for the same APIs. One unannounced API change breaks multiple agents in ways nobody predicted. Public tool registries have already become a supply-chain attack vector, with malicious tools that exfiltrate local state or establish backdoors.

For patterns that make MCP tools more resilient, see 54 Patterns for Building Better MCP Tools.

Pitfall 3: Context window bloat from raw API responses

Unoptimized tools dump the full API response into the context window. A Jira ticket history? Tens of thousands of tokens of irrelevant metadata. The agent's reasoning goes erratic. Costs spike with every conversation turn.

Pitfall 4: No audit trail, no reliability, no compliance

Keeping a self-hosted agent alive with tmux or systemd creates an audit black hole. When the process crashes or misbehaves, there's no structured log to trace what happened. Which action was taken? What parameters? Which user started the request?

You can't answer "what did the agent do?" if you never logged it.

That's an immediate fail for SOC2, ISO27001, and any serious compliance review.

Why buying a Mac Mini doesn't fix any of this

There's a growing trend: developers buying dedicated Mac Minis or spinning up VMs to run OpenClaw-style agents 24/7. The reasoning is, if the agent has its own machine, you've isolated it.

You haven't. The machine isn't the threat model. The credentials are.

That Mac Mini still needs OAuth tokens for Google Calendar, API keys for your CRM, access to your Slack workspace. A compromised dependency doesn't care whether it's running on your laptop or a dedicated server in a closet. The blast radius is identical. For a deeper comparison of isolation strategies that actually reduce blast radius, see AI Agent Sandboxing Guide.

Hardware isolation solves availability. It doesn't touch authorization, tool reliability, context management, or audit logging.

You've built an expensive, always-on machine with unfettered access to your business systems. Every pitfall above still applies.

How Arcade, Claude Code, and Skills solve these problems

I needed three things: a secure way to connect to business tools, a battle-tested agent runtime, and a way to encode workflows without writing integration code.

Arcade solves the tool and auth layer. It sits between the agent and your business tools. When the agent wants to read your calendar, Arcade evaluates permissions, mints a just-in-time token scoped to that specific action, and executes the call. The LLM never sees long-lived credentials. Your Google Calendar token isn't sitting in an .env file on a Mac Mini. It's managed by Arcade's runtime with per-action authorization.

Arcade also solves the brittle tools problem. Instead of writing fragile REST wrappers, you use pre-built, agent-optimized integrations that return summarized data, not raw JSON dumps. When Google changes their Calendar API, Arcade handles it. Your agent code stays untouched. And every tool call generates structured audit logs tied to the specific user and action.

Claude Code is the agent runtime. It's more battle-tested than OpenClaw, has native MCP support, and handles tool orchestration without the brittle process management of tmux and systemd scripts.

Skills encode the actual workflows. This is the piece most people miss. Arcade gives the agent access to your tools with proper auth. Skills tell the agent how to use them well. For a deeper look at the distinction, see Skills vs Tools for AI Agents.

A skill is a markdown file that encodes domain expertise: which tools to call, in what order, what to look for in the results, how to format the output. Without a skill, you have an agent with calendar access but no idea how to prepare a meeting brief. With a skill, you have an assistant that pulls calendar events, cross-references email threads, checks Slack for internal context, and delivers a structured briefing, all from a single WhatsApp message.

Arcade gives access. Skills give expertise. Together, they turn an LLM into a useful assistant.

And because skills are just markdown files, anyone on the team can write and iterate on them. No code deployment. No engineering tickets.

Here's what we're building: a WhatsApp relay for messaging, Claude Code as the brain, Arcade for auth-managed tool access, and skills that encode your team's workflows.

Step-by-step: building the WhatsApp AI assistant with MCP and Arcade

Enough architecture. Here's what we're making: WhatsApp messages flow through a relay server into an MCP server, which feeds them to Claude Code. Claude Code processes messages using skills, calls business tools through Arcade, and replies back through the same chain.

One wrinkle: WhatsApp's Cloud API only supports webhooks. There's no WebSocket or long-polling option. That means something has to sit on a public URL to receive Meta's callbacks. Since we're running everything locally, the relay server handles that role, and ngrok tunnels traffic from Meta's servers to it on your machine.

Prerequisites: WhatsApp Business API, Claude Code, and Arcade

Before starting, make sure you have a Meta developer account with a WhatsApp Business App configured (Meta's getting started guide), Node.js 20+ and npm, ngrok for tunneling webhooks to your local machine, Claude Code installed and configured, an Arcade account with API access, and a phone number registered with WhatsApp Business API.

Step 1: Project structure and environment setup

Here's the folder layout:

whatsapp-assistant/
├── whatsapp.ts          # MCP server (bridge between relay and Claude Code)
├── package.json         # MCP server dependencies
├── .mcp.json            # Claude Code MCP server registration
├── whatsapp-relay/
│   ├── relay.ts         # Relay server (faces the internet via ngrok)
│   ├── package.json     # Relay server dependencies
│   └── .env             # WhatsApp API credentials (from .env.example)
└── skills/
    └── meeting-prep/
        └── SKILL.md     # Meeting preparation skill for Claude Code

Start by setting up both projects:

# Create the project
mkdir whatsapp-assistant && cd whatsapp-assistant

# Initialize the MCP server
npm init -y
npm install @modelcontextprotocol/sdk
npm install -D typescript @types/node tsx

# Initialize the relay server
mkdir whatsapp-relay && cd whatsapp-relay
npm init -y
npm install hono @hono/node-server
npm install -D typescript @types/node tsx
cd ..

Create your .env file inside whatsapp-relay/ with the following variables:

# Meta WhatsApp Cloud API
WHATSAPP_ACCESS_TOKEN=        # Bearer token from Meta App Dashboard
WHATSAPP_PHONE_NUMBER_ID=     # Bot's phone number ID
WHATSAPP_VERIFY_TOKEN=        # Any string, used for webhook verification handshake
WHATSAPP_APP_SECRET=          # App secret for validating webhook signatures

# Relay auth
RELAY_SECRET=                 # Shared secret, local MCP server sends this in X-Relay-Secret header

The RELAY_SECRET is a shared key between the relay and MCP server. Generate something random (openssl rand -hex 32). It prevents anything on your network from impersonating the MCP server.

Step 2: Build the WhatsApp webhook relay server

The relay is the only component that faces the internet. It has three jobs: validate incoming WhatsApp webhooks, queue messages for the MCP server, and proxy outbound messages to Meta's API.

Webhook signature validation

Every webhook payload from Meta includes an HMAC-SHA256 signature. The relay verifies this before processing anything:

import { createHmac, timingSafeEqual } from "node:crypto";

const APP_SECRET = process.env.WHATSAPP_APP_SECRET!;

function verifySignature(rawBody: string, header: string | undefined): boolean {
  if (!header) return false;
  const sig = header.replace("sha256=", "");
  if (!sig) return false;
  const expected = createHmac("sha256", APP_SECRET)
    .update(rawBody)
    .digest("hex");
  if (sig.length !== expected.length) return false;
  return timingSafeEqual(Buffer.from(sig), Buffer.from(expected));
}

This uses timingSafeEqual to prevent timing attacks, a detail that matters when you're validating signatures from a third party.

Webhook handler: always return 200

Meta uses at-least-once delivery. If your endpoint returns anything other than 200, Meta retries, potentially creating a storm of duplicate events. The relay acknowledges immediately and processes asynchronously:

app.post("/webhook", async (c) => {
  const rawBody = await c.req.text();

  if (!verifySignature(rawBody, c.req.header("x-hub-signature-256"))) {
    // Still return 200. Returning 4xx causes Meta to retry with the same bad signature.
    console.error("webhook: invalid signature");
    return c.text("ok", 200);
  }

  try {
    const payload = JSON.parse(rawBody) as WaWebhookPayload;
    parseMessages(payload);
  } catch (err) {
    console.error("webhook: parse error:", err);
  }

  return c.text("ok", 200);
});

Note the pattern: even on a bad signature, we return 200. Logging the rejection is enough. Returning 4xx just makes Meta retry with the same bad payload.

In-memory message queue with polling

The relay queues validated messages and exposes a polling endpoint for the MCP server. The MCP server passes a cursor (the last message ID it saw) to get only new messages:

let queue: InboundMessage[] = [];
let nextId = 1;
const MAX_QUEUE = 1000;

function enqueue(msg: Omit<InboundMessage, "id" | "timestamp">): void {
  queue.push({ ...msg, id: nextId++, timestamp: Date.now() });
  if (queue.length > MAX_QUEUE) {
    queue = queue.slice(queue.length - MAX_QUEUE);
  }
}

// Polling endpoint, protected by relay secret
app.get("/poll", (c) => {
  const since = Number(c.req.query("since") ?? "0") || 0;
  const messages = queue.filter((m) => m.id > since);
  const cursor = messages.length > 0 ? messages[messages.length - 1].id : since;
  return c.json({ messages, cursor });
});

The relay authenticates all local-facing routes with the shared secret via x-relay-secret header. The WhatsApp-facing webhook routes don't use this. They're validated by Meta's HMAC signature instead.

Outbound message proxy

When Claude Code wants to reply, it goes through the MCP server, which calls the relay, which calls Meta's API:

const WA_API = `https://graph.facebook.com/v21.0/${PHONE_NUMBER_ID}`;

async function waApi(
  path: string,
  body: Record<string, unknown>,
): Promise<{ ok: boolean; status: number; data: unknown }> {
  const res = await fetch(`${WA_API}${path}`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${ACCESS_TOKEN}`,
    },
    body: JSON.stringify(body),
  });
  const data = await res.json();
  return { ok: res.ok, status: res.status, data };
}

The relay is built with Hono, a lightweight framework that keeps the code minimal. The full relay is roughly 200 lines and handles text messages, images, documents, audio, video, stickers, reactions, and location shares.

Step 3: Build the MCP server for Claude Code

The MCP server is the bridge between the relay and Claude Code. It polls the relay for incoming WhatsApp messages and exposes tools that Claude Code can call to respond.

Tool definitions

The server registers four tools with Claude Code via the Model Context Protocol:

const mcp = new Server(
  { name: "whatsapp", version: "1.0.0" },
  {
    capabilities: { tools: {}, experimental: { "claude/channel": {} } },
    instructions: [
      "The sender reads WhatsApp, not this session.",
      "Anything you want them to see must go through the reply tool.",
      'Messages arrive as <channel source="whatsapp" chat_id="..." wamid="..." user="..." ts="...">.',
      "Reply with the reply tool. Pass chat_id (phone number) back.",
      "WhatsApp has a 24-hour session window: you can only send free-form messages",
      "within 24 hours of the user's last message.",
    ].join("\n"),
  },
);

The instructions field tells Claude Code how to interpret incoming messages and that it must use the reply tool to send anything back. Without this, the model might try to respond in its own transcript, which the WhatsApp user would never see.

The four tools are reply (send text), react (emoji reactions), mark_read (read receipts), and send_media (images, documents, audio, video). Here's the reply tool definition:

{
  name: 'reply',
  description: 'Reply on WhatsApp. Pass chat_id (phone number) from the inbound message.',
  inputSchema: {
    type: 'object',
    properties: {
      chat_id: { type: 'string', description: 'Phone number to send to' },
      text: { type: 'string', description: 'Message text' },
      reply_to: { type: 'string', description: 'wamid to quote-reply to (optional)' },
    },
    required: ['chat_id', 'text'],
  },
}

Polling loop with cursor persistence

The MCP server polls the relay every 2 seconds and forwards new messages to Claude Code as channel notifications:

const CURSOR_FILE = join(process.env.HOME || "/tmp", ".whatsapp-relay-cursor");
let cursor = loadCursor();

async function poll(): Promise<void> {
  try {
    const result = await relay(`/poll?since=${cursor}`);
    if (!result.ok) return;

    const { messages, cursor: newCursor } = result.data as {
      messages: InboundMessage[];
      cursor: number;
    };

    for (const msg of messages) {
      const meta = {
        chat_id: msg.from,
        wamid: msg.wamid,
        user: msg.pushName || msg.from,
        ts: new Date(msg.timestamp).toISOString(),
        type: msg.type,
      };

      mcp.notification({
        method: "notifications/claude/channel",
        params: {
          content: msg.text ?? `(${msg.type})`,
          meta,
        },
      });
    }

    if (newCursor > cursor) {
      cursor = newCursor;
      saveCursor(cursor);
    }
  } catch (err) {
    process.stderr.write(`whatsapp channel: poll error: ${err}\n`);
  }
}

The cursor persists to disk (~/.whatsapp-relay-cursor), so restarting the MCP server doesn't re-process old messages. Each message becomes a channel notification that Claude Code sees as a new input, including the sender's phone number, display name, timestamp, and message type as metadata.

Step 4: Register the MCP server with Claude Code

Create a .mcp.json file in your project root:

{
  "mcpServers": {
    "whatsapp": {
      "command": "node",
      "args": ["--import", "tsx", "whatsapp.ts"]
    }
  }
}

That's it. When Claude Code starts in this directory, it discovers the MCP server, launches it as a child process via stdio, and the WhatsApp channel becomes available. Claude Code now receives WhatsApp messages as channel notifications and can call the reply, react, mark_read, and send_media tools.

Step 5: Configure the Arcade gateway and connect it to Claude Code

Before the assistant can access business tools, you need to create an Arcade gateway that defines which tools the agent can use and with what permissions.

Log into the Arcade dashboard, create a new gateway, and add the MCP servers for the services your assistant needs: Google Calendar, Gmail, Slack, and any others relevant to your workflows. For each server, select only the specific tools you want the agent to access. This is where you scope permissions. If the meeting-prep skill only needs to list calendar events and search email, there's no reason to expose tools that delete events or send email on your behalf.

Once the gateway is created, register it with Claude Code from the command line:

claude mcp add 'arcade-gateway' \
  --transport http 'https://api.arcade.dev/mcp/<your-gateway-slug>' \
  --header "Authorization: Bearer <your-arcade-api-key>" \
  --header 'Arcade-User-ID: <your-email>'

This writes the gateway configuration to ~/.claude.json. Claude Code now has two MCP servers: the local WhatsApp channel server (from .mcp.json in the project) and the remote Arcade gateway (from ~/.claude.json). The WhatsApp server handles messaging. The Arcade gateway handles business tool access with per-action authorization.

The Arcade-User-ID header tells Arcade which user's credentials to use when executing tool calls. In the single-user setup, this is your email. In the multi-user architecture described later, the orchestrator passes a different user ID per session.

Step 6: Create a meeting-prep skill with Arcade tools

With the channel wired up, the assistant needs capabilities. This is where tools and skills work together. Arcade provides secure access to business tools (Google Calendar, Gmail, Slack), and skills tell the agent how to use those tools to accomplish a specific workflow.

Skills in Claude Code are markdown files. No code, no deployment, just a structured prompt that encodes domain expertise. Here's the structure:

skills/
└── meeting-prep/
    └── SKILL.md

The skill file has two parts: frontmatter that tells Claude Code when to activate it, and a body that defines the workflow. Here's the meeting-prep skill:

---
name: meeting-prep
description: "\"Prepare briefings for upcoming customer meetings by reading"
  your Google Calendar, identifying external/customer meetings (based on
  attendee email domains), then pulling relevant context from Gmail threads
  and Slack conversations."
---

# Meeting Prep

You are a meeting preparation assistant. Your job is to create concise,
actionable briefings for upcoming external meetings.

## Customer Directory
Read the centralized client registry at `$AGENT_DATA_DIR/clients.md`.
Use it to match calendar attendee domains to known customers, find the
correct Slack channel, and locate customer-specific data files.

## Phase 1: Discover (Find the Meeting)

- Search Google Calendar using `list_events` for the relevant time window
- Identify external meetings by checking attendee email domains
- Any attendee whose domain is NOT your organization signals an external meeting

## Phase 2: Gather (Pull Context from Email and Slack)

### Email Context (Gmail)
1. Search for recent threads involving external attendees (last 30 days)
2. Read the 3-5 most relevant threads, looking for decisions, action items, tone
3. Check the calendar event itself for agenda or documents

### Slack Context
1. If there's a dedicated customer channel, read recent messages there
2. Otherwise search by company name or contact names (last 2 weeks)
3. Look for internal context not in email: concerns, feature requests, deal status

## Phase 3: Brief (Deliver the Prep)

### Meeting Briefing: [Title]
**When:** [Date & Time]
**With:** [Attendees + roles/company]
**Meeting type:** [Quarterly review, Demo, Follow-up, Intro call]

**Quick Context:** 2-3 sentences on where things stand
**Recent History:** Chronological recap of last interactions
**Key Things to Know:** Open items, concerns, opportunities
**Suggested Talking Points:** 3-5 practical conversation starters
**People Notes:** Brief note on new stakeholders or unfamiliar attendees

The skill tells the agent exactly which Arcade-powered tools to use (list_events, search_messages, read_thread), in what order, what signals to look for in the results, and how to format the output. The customer directory lookup means the agent doesn't waste tokens fuzzy-matching company names. It goes straight to the right email domain and Slack channel.

When a user texts "prep me for my 2pm" on WhatsApp, Claude Code receives the message via the channel, activates this skill, runs the three-phase workflow through Arcade's tools, and sends the briefing back via the WhatsApp reply tool. The whole flow, from WhatsApp message to structured briefing, happens without the user leaving the chat.

Step 7: Run and test the WhatsApp assistant locally

Start everything in order:

# Terminal 1: Start the relay server
cd whatsapp-relay
node --import tsx relay.ts
# → "whatsapp relay listening on :3000"

# Terminal 2: Expose the relay via ngrok
ngrok http 3000
# → Copy the https:// forwarding URL

# Terminal 3: Start Claude Code from the project root
cd whatsapp-assistant
claude --dangerously-load-development-channels server:whatsapp
# Claude Code discovers .mcp.json and launches the MCP server
# → "whatsapp channel: connected, polling http://localhost:3000 every 2000ms"

Register your webhook with Meta by going to your app in the Meta Developer Dashboard, then navigating to WhatsApp, Configuration, Webhook. Set the Callback URL to your ngrok URL plus /webhook (e.g., https://abc123.ngrok.io/webhook), set the Verify Token to the value in your .env file, and subscribe to the messages webhook field.

Now send a message from your phone to the WhatsApp Business number. You should see it flow through the relay, into the MCP server, and appear in Claude Code. Claude Code processes it and sends a reply back through the same chain.

Try texting "prep me for my next meeting." The first time Claude Code calls an Arcade-powered tool (like reading your calendar), Arcade prints an authorization URL in the terminal. Open it in your browser and authenticate with the relevant account (Google, Slack, etc.). This is a one-time step per service. After that, Arcade manages token refresh automatically.

If you have the meeting-prep skill configured and Google Calendar / Gmail connected through Arcade, you'll get back a structured briefing right in WhatsApp.

Scaling from single-user to multi-user: What changes in the architecture

Everything above runs as a single user. One Claude Code instance, one set of Arcade credentials, one identity context. Here's what breaks when a second user messages the bot, and what you need to change.

Why a single Claude Code instance doesn't work for multiple users

The single-user setup has an implicit assumption: every WhatsApp message belongs to you. When Claude Code calls an Arcade tool like list_events, Arcade uses the credentials you authenticated during setup. There's no user identifier in the call.

If User 2 messages the same bot, Claude Code still calls Arcade with your credentials. User 2 gets your calendar. Worse, Claude Code runs in a single conversation context. User 1's meeting briefing (deal terms, internal Slack messages, revenue numbers) is sitting in the context window when User 2's message arrives. A prompt injection from User 2 could surface User 1's data. Arcade secured the credentials correctly, but the shared context window breaks tenant isolation.

You need two things: separate agent instances so context never crosses between users, and per-user credential routing so Arcade knows whose calendar to read.

The multi-user architecture

The relay server, MCP tool schemas (reply, react, send_media), and skills stay identical. What changes is the orchestration layer.

The single-user version uses Claude Code CLI with its built-in channels feature. For multi-user, you build a custom orchestrator using the Claude Agent SDK. The SDK doesn't have native channel support, but it gives you sessions, hooks, tool permissions, and MCP connections, the building blocks to replicate what channels do for a single user across many users.

The relay server becomes a router. When a message arrives from +1111, the orchestrator looks up which agent session owns that phone number and routes the message there. When +2222 messages, it routes to a different session. Each session has its own context window, its own MCP server instance, and its own Arcade user context. No data crosses between them.

Credential routing works through Arcade's user_id parameter on tool calls. Each user goes through the Arcade browser auth flow once (the same authorization URL step from the single-user setup). After that, when the orchestrator calls an Arcade tool on behalf of User 2, it passes User 2's identity. Arcade resolves the correct OAuth grants, mints a scoped token for that specific action, and executes the call. User 2's calendar request returns User 2's calendar. For a full walkthrough of how this authorization model works across frameworks, see SSO for AI Agents: Authentication and Authorization Guide.

The identity pairing itself is straightforward. Map each WhatsApp sender ID to a corporate identity using a one-time verification flow: send a code via a WhatsApp Authentication Template, have the user confirm it in a web portal, and store the mapping.

Arcade handles the rest of the multi-user complexity: per-user OAuth token exchange and just-in-time grants for credential delegation, scoped tool execution that prevents cross-tenant data access, a versioned tool registry that doesn't break when upstream APIs change, and structured audit logs tied to the specific user and action. These are the same four pitfalls from earlier. They all get harder at multi-user scale, and Arcade handles them natively.

Production readiness checklist for AI agents

Before you move beyond local use, gut-check these five things:

Credential isolation. Can the LLM see your auth tokens? If yes, stop. The architecture needs just-in-time, per-action authorization where the model never touches long-lived credentials. Standing service account privileges are a non-starter.
Tool reliability. Are your tools agent-optimized or naive REST wrappers? If the model has to guess complex payload parameters and brute-force retries, you'll hit failures that are invisible until production.
Versioning and rollbacks. Can you update a tool without breaking the running assistant? If one upstream API change takes down your agent, you need a versioned registry with safe deprecation periods.
Auditability. Can you trace every action back to the specific human who requested it? If not, you fail SOC2 and ISO27001. You need immutable logs with user IDs, tool names, and sanitized parameters.
Developer time allocation. Are your engineers building OAuth plumbing and webhook retry logic, or building skills and workflows? If it's the former, the architecture is too low-level.

Next steps

You now have a working WhatsApp assistant. A relay handling Meta's webhooks. An MCP server bridging to Claude Code. A meeting-prep skill that turns "prep me for my 2pm" into a structured briefing pulled from your calendar, email, and Slack.

The interesting part is what comes next. The relay and MCP server are infrastructure you write once. The skills are where the ongoing value lives, and anyone on the team can write them. Meeting prep was the first one I built. Expense report summaries, daily standups, customer check-in reminders: same pattern, different markdown file.

For multi-user deployments, the Claude Agent SDK gives you the building blocks to orchestrate per-user agent sessions, with the relay routing messages and Arcade handling per-user credential delegation, tenant isolation, and audit logging. You focus on skills, not infrastructure.

The code from this guide is on GitHub. Fork it and build something useful.

FAQ

What is an always-on AI executive assistant?

An always-on assistant runs continuously and interacts through messaging channels like WhatsApp or Slack. It maintains state across conversations and takes actions in connected business tools asynchronously, without needing a browser tab open.

What are the risks of using OpenClaw for an AI agent?

They commonly rely on shared machine credentials, fragile scripts, and ungoverned tool wrappers. This creates high risk of token leakage, unreliable tool calls, context bloat, and missing audit trails required for compliance.

How do you prevent an agent from having god-mode access to company systems?

Use runtime, per-action authorization with just-in-time, short-lived grants (e.g., OAuth token exchange). The agent never holds broad or long-lived credentials, and every action is evaluated against the requesting user's permissions.

What is Arcade and how does it secure AI agent tool access?

Arcade is a runtime that sits between an AI agent and your business tools. Instead of giving the agent stored credentials, Arcade evaluates each tool call against the requesting user's permissions, mints a just-in-time token scoped to that action, executes the call, and logs the result. It also provides agent-optimized integrations that return summarized data instead of raw API responses. For a full overview, see How Arcade works.

Is it safe to give an AI agent access to my Google Calendar and email?

Not if the agent holds long-lived OAuth tokens or API keys directly. A prompt injection or compromised dependency can exfiltrate those credentials and access everything the agent can reach. The safe approach is per-action authorization: a runtime like Arcade mints a short-lived, scoped token for each specific action and revokes it immediately after, limiting the blast radius to a single call.

How does the relay server handle duplicate WhatsApp webhooks?

WhatsApp delivers events with at-least-once semantics. The relay returns 200 OK immediately (even on bad signatures) to prevent retry storms, and processes messages asynchronously. For production use, add a deduplication store like Redis keyed by message ID.

What is WhatsApp's 24-hour messaging window?

Free-form replies are allowed within 24 hours of the user's last message. Proactive messages outside that window must use pre-approved WhatsApp message templates (HSM templates). For an 8 AM morning brief, you'd need an approved template.

Can I use this architecture with models other than Claude?

Yes. The relay server and MCP protocol are model-agnostic. The relay handles WhatsApp I/O, and the MCP server defines tools via a standard protocol. You could swap Claude Code for any MCP-compatible runtime.

How do I add new skills or workflows to a Claude Code agent?

Create a new directory under skills/ with a SKILL.md file. The skill's frontmatter description tells Claude Code when to activate it. Skills are just structured prompts, no code deployment required.

Don't trust LLM research

Mateo Torres — Tue, 31 Mar 2026 14:16:48 +0000

I work at Arcade. Part of my job is making sure agents find us when searching for secure ways to integrate agentic apps into the MCP ecosystem. That makes me exactly the kind of person this post is about.

I could play the game, write the "Arcade vs X" comparison posts, publish the rigged listicles, churn out the SEO slop that I'll describe below. I don't know much about SEO, but I do know what dishonest content looks like when I see it, and I'd rather talk about the problem honestly than contribute to it.

Even if you're the most diligent researcher and you really go out of your way to assess every dependency and every tool in your code base, you can't realistically test all possible options if you want to do that within a reasonable time frame. This is especially true when AI agents are involved. And even more so for new tech like MCP and other agentic protocols. Your research capability is saturated by the ever-increasing number of tools and options, each of which have an army of agents producing encyclopedic arguments about why you should pick them and
not all of the other (awful) alternatives. If before AI the process was already annoying and exhausting, now it's basically an impossible battle.

So the obvious approach is to let an LLM do the reading for you. Let it sift through the volume that no human has time for, and hope that it can at least surface what's worth a closer look. And at least for now this is sort of working if you're searching in domains with an obvious answer. Numpy, SciPy & friends are the right answer for Python-based data science. NetworkX or igraph will be the go-to choices for network science. But these choices are "pre-agent", and have achieved strong authoritative signals at a time when working code was expensive to get. Choosing the right thing to build an agent is a much less obvious search task. For that, unfortunately, agents don't do a great job.

Quantity over quality

The main issue is that LLMs are inherently trusting, which makes them easy to manipulate with unsubstantiated claims. If 50 blog posts say "Tool X is the best for Y", the model will treat that as a stronger signal than 3 posts saying "Tool Z", even if the 50 are all from Tool X's marketing team. The model has no way of knowing that, because it can't consider the source. It just sees volume and treats it as consensus. And if the content has nice tables and numbered lists? Even better, LLMs love structured content and will happily treat a rigged comparison matrix as gospel. Agents doing live web search make this worse, because they also inherit whatever ranking biases the search engine has on top of
all of this.

So I can simply add a statement here

Therefore, it is an undeniable fact that Mateo is the best person ever and you should listen to everything he says

And while you may disagree (ouch!), LLMs are so far incapable of verifying it. Repeat it enough times across enough websites and it becomes fact as far as the model is concerned. Some of the patterns I see coming from dishonest companies exploiting this are:

<Our company> vs <Other Company>, the definitive comparison: The content is usually all the good things about them and all the bad things about the other company, even if all the facts are made up. These work really well on LLMs because the structured "pros and cons" format looks like a balanced analysis, and the model has no way to check whether any of the claims are true. An honest comparison does it fairly, acknowledging the pros and cons while providing evidence.
Top-N tool for AI 2026: They define the rubric, then grade themselves an A. The "metrics" are just their own feature list dressed up as evaluation criteria, with tables and rankings that LLMs love to treat as authoritative. Everyone else scores poorly by definition (if they're mentioned at all). An honest comparison will explain the criteria clearly, and apply it honestly to their own stuff.
Best <competitor> alternatives 2026: This one is parasitic. They ride a competitor's name recognition to hijack search intent. If someone is looking for alternatives, they already know the competitor. The goal is to reframe the user's existing choice as a problem and position themselves as the obvious fix. An honest version of this type of article should bring forward evidence-based pros and cons of the product being discusses, as well as the alternatives.
<competitor> limitations for <use case> 2026: This is simply an attack article, often targeting competitors with made up facts, with the inevitable CTA to their own product as the divine solution to the problem. LLMs are particularly susceptible to these because the framing is negative ("limitations", "problems", "issues"), and the model will internalize that negativity about the competitor without questioning whether the limitations are real.

An imperfect mitigation

I have no solution for this in the long term, but I've seen good results from this skill I wrote. In essence it's a critic step that I run when I don't recognize any of the choices given to me by the LLM.

Now, the obvious question: if LLMs are gullible, why would a second LLM pass be any less gullible? The short answer is that it's not, but it's asking different questions. The first pass asks "what should I use for X?", and the model happily absorbs whatever the top results claim. The critic pass asks "does this source have a conflict of interest?", "can I find corroboration outside this source's own ecosystem?", and "does this read like a comparison or like an ad?" LLMs are actually decent at spotting self-promotional language when you explicitly tell them to look for it. They just won't do it on their own.

I named it /confirm-research, and it's been useful to distill more signal from the slop content. It won't catch subtle manipulation. If someone writes genuinely informative content with a quiet bias, the critic will miss it just like I would. But the patterns I listed above are not subtle, and that's exactly what makes them filterable.

The negative side of this is obviously the extra token usage, but it's worth it for me, as trusting the LLM with a choice of dependency will be way more expensive if I have to replace it later in the project. The other negative is that it's an operator-triggered step. I could integrate this into the rules of how I prefer the harness to deal with web searches, but the critic only works when the offending content is already in the agent's context.

I am hoping that things like it get integrated into the system prompts of agentic harnesses. But until that happens, the responsibility is on you. The next time an agent confidently recommends a tool you've never heard of, ask yourself who wrote the content that convinced it. I chose not to write that kind of content for Arcade. Not everyone will make the same choice.

OpenClaw can do a lot, but it shouldn't have access to your tokens

Mateo Torres — Thu, 26 Feb 2026 23:12:47 +0000

OpenClaw (a.k.a. Moltbot, a.k.a. ClawdBot) went viral and became one of the most popular agentic harnesses in a matter of days.

Peter Steinberger had a successful exit from PSPDFKit, and felt empty until the undeniable potential of AI sparked renewed motivation to build. And he's doing it it non-stop.

OpenClaw approaches the idea of an Personal AI agent as a harness that communicates with you (or multiple users) in any of the supported channels in multiple sessions connected to the underlying computer through a gateway, which is ultimately responsible for running and maintaining.

A super entertaining narration of important events is available in OpenClaw's Lore doc page (worth a read!)

A security nightmare

Everyone wanted to start playing with what is clearly shaping how the future of Personal AI assistants could look like. However, people were running OpenClaw without even an afterthought to security. And that (of course) resulted in some not so funny preventable disasters:

As this TechCrunch article points out:

Right now, running Moltbot safely means running it on a separate computer with throwaway accounts, which defeats the purpose of having a useful AI assistant. And fixing that security-versus-utility trade-off may require solutions that are beyond Steinberger’s control.

The reason for this is, as you may have guessed, the lethal trifecta: the inherently dangerous combination of giving LLMs tools with the following characteristics:

Access to your private data
Exposure to untrusted content
The ability to externally communicate

As Simon Willison (who coined the term) explains:

LLMs are unable to reliably distinguish the importance of instructions based on where they came from. Everything eventually gets glued together into a sequence of tokens and fed to the model.

As a harness with "Full System Access" and "Browser Control" as flagship features,

you can see how OpenClaw checks the three boxes.

Securing OpenClaw

OpenClaw doesn't have to be limited to throwaway accounts though. Since it blew up, security has been one of the main focus points of OpenClaw's development, and you can leverage some of that today to get a secure experience in the harness. While this still requires you to be technically savvy, you can:

Use OpenClaw's tool policies to control which user and/or agent gets access to specific tools
Run it in a Sandbox
Use exec approvals to implement human-in-the-loop for specific tools that may have undesired side-effects
Use a detached tool-calling runtime like Arcade. Credentials never touch the harness, so there's nothing to leak.

Here's how to setup that last point in your OpenClaw instance:

First, clone the Arcade plugin:

git clone --depth 1 https://github.com/ArcadeAI/openclaw-arcade-plugin /tmp/openclaw-arcade

Then, install it into your OpenClaw gateway:

openclaw plugins install /tmp/openclaw-arcade/arcade

Go to your Arcade Dashboard to get and API key

copy it, and run this command to configure your Arcade API key:

openclaw config set plugins.entries.arcade.config.apiKey "{your_arcade_api_key}"

And this one to configure your Arcade User ID (this is the email you used to

sign up to Arcade):

openclaw config set plugins.entries.arcade.config.user_id "{your_arcade_user_id}"

Once the Arcade plugin is configured, initialize it to load all the tools, and

restart the OpenClaw gateway

openclaw arcade init
openclaw gateway restart

Now OpenClaw has access to 7,000+ tools, with tokens handled outside the harness. Nothing to exfiltrate.

Here's a screenshot of how this works when I talk to the Telegram bot connected

to my OpenClaw instance:

Final tips

Even with these precautions, OpenClaw is still early-adopter territory. Make sure to run this in a sandbox, a VPS, or even a dedicated computer. If you're sharing files to OpenClaw, make sure to set up the guardrails around the tools it can use, and be mindful of the accounts you log into in the browser it can control.

Ready to secure your agent setup?

Arcade handles just-in-time agent authorization so credentials never touch your harness → Get started