DEV Community: Arcade.dev

Claude Tag: How to Build Your Own Slack AI Agent with Arcade.dev

Manveer Chawla — Thu, 25 Jun 2026 20:21:44 +0000

"Today, 65% of our product team's code is created by our internal version of Claude Tag."

That's Anthropic, talking about its own engineering team. And this is not code autocomplete or a chatbot generating snippets in isolation. Claude Tag is a shared agent inside Slack that teammates mention by name to investigate bugs, pull metrics, work support tickets, and complete longer-running tasks. It reads thread context, connects to approved tools and codebases, and posts results back in the same conversation.

The question is not whether Claude Tag is impressive. It is: what would your team delegate if you had one?

You do not need to recreate Anthropic's entire product to find out. This tutorial recreates Claude Tag's core interaction pattern, not Anthropic's proprietary product. Start with one high-value Slack workflow, give the agent a small toolset, and use Arcade.dev for the action layer: tool connectivity, authorization, and controlled access to external systems.

Key takeaways: Claude Tag and building your own Slack AI agent

Claude Tag is Anthropic's shared AI agent for Slack. It lets teams mention @Claude in selected channels to complete multi-step work using conversation context, connected tools, and codebases.
Claude Tag turns Slack into the agent interface. It can remember relevant channel context, work asynchronously, use a dedicated identity, and return results in the thread where the request began.
You can recreate the core Claude Tag pattern. This tutorial builds a Claude Tag-style Slack AI agent with Python, Slack Bolt, OpenAI, and Arcade.
Arcade provides secure tool access. The example connects the agent to read-only GitHub, Datadog, and PagerDuty tools while Arcade handles authorization, credentials, tool execution, and access controls.
Start with one bounded workflow. Incident triage is a strong first use case because it crosses multiple systems, produces reviewable evidence, and does not require irreversible actions.
Production agents need explicit safeguards. Restrict the agent to approved Slack channels, use dedicated or per-user identities, require human approval for consequential writes, log its actions, and maintain a kill switch.

What is Claude Tag and why does your team want it?

Anthropic launched Claude Tag on June 23, 2026 as a beta for Enterprise and Team customers. The operating model is simple: Claude joins selected Slack channels as a teammate. Anyone in the channel can tag @Claude with a request. It breaks the task into stages, works through them using connected tools, and replies in-thread with what it produced. Once a thread is active, anyone there can steer it without re-mentioning the agent.

What makes this different from a personal chatbot is that the work happens in public. The channel is the interface, the context, and the audit trail. A single shared Claude instance serves an entire channel, building persistent memory as it follows along. It can work asynchronously, schedule its own follow-up tasks, and combine context from Slack threads, Google Drive docs, ticketing systems, and data warehouses into a single answer.

The underlying insight is not about AI capabilities. It is about where work starts. Most cross-functional tasks begin as a Slack message. Someone asks a question, flags a problem, or requests information that lives across three systems. The true value of shared agents is when it can do useful work in a place where that work already begins.

Do not build an AI employee. Pick one workflow.

The fastest way to stall an agent project is to scope it as "an AI that can do anything." Start with one workflow. Choose something that is:

Frequent. The team does it every week, ideally every day.
Cross-system. It requires pulling context from two or more tools (Slack, GitHub, a dashboard, a CRM).
Tedious to investigate manually. Someone has to copy-paste between tabs, summarize findings, and post an update.
Easy for a human to review. The agent produces a summary or recommendation, not a final irreversible action.

Some high-value starting points:

Incident triage across Slack, GitHub, and observability tools. When errors spike after a deployment, the agent pulls recent commits, queries Datadog for error rates and latency, checks PagerDuty for related incidents, and posts a structured summary with evidence links.

Support escalation summaries using your ticketing system, CRM, and internal docs. Instead of an engineer spending 15 minutes rebuilding context on an escalated ticket, the agent does it in seconds and posts the summary in the escalation channel.

Product-feedback triage that reads a Slack thread, extracts the core request, checks for duplicates in Linear or Jira, and creates a properly tagged issue with the original thread linked.

Account research that pulls together CRM data, recent email threads, product usage metrics, and internal notes before a customer call.

Start narrow. A focused agent earns trust faster than a broadly capable one.

How does a Claude Tag-style Slack agent work?

The architecture behind a Claude Tag-style agent has four layers:

Slack is the interface. Users tag the agent in a thread. Slack delivers the triggering event; your application retrieves thread context via the API and displays results.
The model is the reasoning layer. It understands the request, decides what information it needs, and synthesizes a response. Use whatever LLM and agent framework fits your stack.
Arcade is the action layer. It connects the agent to approved tools, handles authorization and token management, and enforces access policy. The model never sees credentials.
Your app handles orchestration. Task state, retries, async job processing, and posting updates back to Slack.

Each layer is independently replaceable. Swap the model, change the framework, add tools. The boundaries stay clean.

What we are building is a shared agent, not a multi-user agent. Every tool call runs under a single service identity regardless of who tagged the bot. Step 4 covers how to add per-user authorization if your use case requires it.

This prototype starts a run only when mentioned. Claude Tag's production experience supports unmentioned follow-ups within an active thread. To add that behavior, subscribe to message.channels and message.groups, track active thread IDs, and filter out bot-generated messages. That is a production extension beyond the scope of this walkthrough.

How to build a Claude Tag-style Slack agent with Arcade

This walkthrough uses Python with Slack's Bolt framework and the Arcade Python SDK. The same pattern works with any language or agent framework that supports MCP or Arcade's REST API.

Prerequisites

You need Python 3.8+, permission to create and install a Slack app, an Arcade account and API key, and an OpenAI API key. For local Slack Events API testing, also install and authenticate the ngrok CLI or another public HTTPS tunnel.

python3 -m venv .venv
source .venv/bin/activate
python -m pip install slack-bolt arcadepy openai

Step 1: Create the Slack app and event trigger

Create a Slack app at api.slack.com/apps. Under OAuth & Permissions, add the bot scopes app_mentions:read, chat:write, channels:history, and groups:history. Install the app to your workspace, then copy the Bot User OAuth Token (xoxb-...) and Signing Secret from the app settings.

You now have everything needed to set the environment variables:

export SLACK_BOT_TOKEN="xoxb-..."
export SLACK_SIGNING_SECRET="..."
export ARCADE_API_KEY="..."
export ARCADE_USER_ID="you@company.com"
export OPENAI_API_KEY="..."
export SLACK_ALLOWED_CHANNEL_IDS="C0123456789"

For ARCADE_USER_ID, use the email associated with your Arcade account. Arcade's default development verifier expects that identity. This is the single shared identity under which every tool call executes. All mentions in all approved channels resolve to this one account. It does not create GitHub or PagerDuty service accounts on its own. If the agent must act under a dedicated downstream identity, use dedicated accounts during the OAuth flows in Step 2.

Replace C0123456789 with your actual Slack channel ID. Open the channel in Slack's web or desktop app and copy the C... portion of its URL (https://app.slack.com/client/T.../C...). See Slack's guide to locating IDs for details.

SLACK_ALLOWED_CHANNEL_IDS restricts the agent to specific channels, enforcing the per-channel scoping that Claude Tag uses. Comma-separate multiple channel IDs. If different channels need different permissions or toolsets, you will need a channel_id-to-identity mapping or separate deployments.

Slack's three-second rule is the critical implementation detail. Your endpoint must return HTTP 200 within three seconds or Slack marks delivery as failed and retries up to three times. Bolt handles acknowledgement automatically when you use the standard decorator pattern. For production workloads where agent processing takes longer, offload work to a task queue. Deduplicate on Slack's top-level event_id before enqueueing work, otherwise retries can execute the same tools twice.

Save this as app.py:

import logging
import os

from slack_bolt import App
from agent import run_agent  # Step 3

ALLOWED_CHANNEL_IDS = {
    value.strip()
    for value in os.environ["SLACK_ALLOWED_CHANNEL_IDS"].split(",")
    if value.strip()
}

app = App(
    token=os.environ["SLACK_BOT_TOKEN"],
    signing_secret=os.environ["SLACK_SIGNING_SECRET"],
)


@app.event("app_mention")
def handle_mention(event, client, say, context, logger):
    if event["channel"] not in ALLOWED_CHANNEL_IDS:
        logger.warning("Ignoring mention from unauthorized channel %s", event["channel"])
        return

    # Ignore messages from bots (including this one) to prevent loops
    if event.get("bot_id"):
        return

    thread_ts = event.get("thread_ts") or event["ts"]

    try:
        # Retrieve up to 50 messages of thread context.
        # Production implementations should follow
        # response_metadata.next_cursor for longer threads.
        replies = client.conversations_replies(
            channel=event["channel"],
            ts=thread_ts,
            limit=50,
        )
        bot_user_id = context.get("bot_user_id")
        transcript = []
        for message in replies.get("messages", []):
            text = message.get("text", "")
            if bot_user_id:
                text = text.replace(f"<@{bot_user_id}>", "").strip()
            if text:
                speaker = message.get("user") or message.get("bot_id", "unknown")
                transcript.append(f"{speaker}: {text}")

        say("On it. Gathering context...", thread_ts=thread_ts)

        result = run_agent(
            os.environ["ARCADE_USER_ID"],
            "\n".join(transcript),
        )
        # Slack recommends keeping messages under 4,000 characters.
        # Truncate or chunk longer responses in production.
        say(result, thread_ts=thread_ts)
    except Exception:
        logger.exception("Agent failed")
        say(
            "I couldn't complete that investigation. Check the application logs.",
            thread_ts=thread_ts,
        )


if __name__ == "__main__":
    logging.basicConfig(level=logging.INFO)
    # This is Bolt's built-in development server. For production,
    # deploy through a supported web-framework adapter (e.g. Flask + Gunicorn).
    app.start(port=int(os.environ.get("PORT", "3000")))

A few things to note. Bolt handles signing-secret verification automatically when you pass signing_secret to the App constructor. The channel allowlist on the first check enforces per-channel scoping so the agent only responds in channels you have explicitly approved. The conversations_replies call retrieves up to one page of thread context so the agent sees more than just the triggering message. Slack's Events API delivers only the triggering event, not the thread history, so your app must fetch it. And the event.get("bot_id") guard prevents the agent from responding to its own messages and creating an infinite loop.

Step 2: Connect GitHub, Datadog, and PagerDuty with Arcade

Arcade connects your agent to external systems through a curated set of tools. For incident triage, you need read-only tools from GitHub, Datadog, and PagerDuty. Select specific tools rather than loading entire toolkits. Toolkits include write operations that contradict a read-only agent's scope, and a narrower tool list helps the model pick the right tool more reliably.

These tool names match Arcade's current GitHub, Datadog, and PagerDuty catalogs:

TOOL_NAMES = [
    "Github.ListRepositoryActivities",
    "Github.GetPullRequest",
    "Datadog.AggregateEvents",
    "Datadog.SearchLogs",
    "Pagerduty.ListIncidents",
    "Pagerduty.ListLogEntries",
]

Authorize tools before first use. GitHub and PagerDuty require OAuth authorization. Datadog requires API credentials configured as Arcade secrets (DATADOG_API_KEY, DATADOG_APPLICATION_KEY, and DATADOG_SITE). Configure the Datadog secrets in the Arcade secrets dashboard, then save the following as authorize.py and run it once to complete the OAuth flows:

from arcadepy import Arcade
import os

arcade = Arcade()
user_id = os.environ["ARCADE_USER_ID"]

OAUTH_TOOLS = [
    "Github.ListRepositoryActivities",
    "Github.GetPullRequest",
    "Pagerduty.ListIncidents",
    "Pagerduty.ListLogEntries",
]

for tool_name in OAUTH_TOOLS:
    auth = arcade.tools.authorize(tool_name=tool_name, user_id=user_id)
    if auth.status != "completed":
        print(f"Authorize {tool_name}: {auth.url}")
        arcade.auth.wait_for_completion(auth.id)

print("All OAuth-backed tools authorized.")

Open each URL and complete the OAuth consent. Arcade stores the tokens and refreshes them automatically. Subsequent calls reuse the authorization until it expires, is revoked, or a tool requires additional permissions. See Arcade's authorization guide for the full setup flow.

If your agent framework supports MCP natively, you can alternatively create an Arcade MCP Gateway that federates these tools behind a single Streamable-HTTP endpoint. The gateway serves tool definitions over MCP, so your agent discovers exactly the tools you curated. The direct SDK approach shown here works with any framework.

Tool selection is both a technical and product decision. The fewer tools the agent sees, the more reliably it picks the right one.

Step 3: Build the tool-calling agent loop

This is the piece that connects the Slack trigger to the tools. Your agent runtime sits between Slack and Arcade: it receives the thread transcript, uses an LLM to decide what tools to call, and executes them through Arcade.

Arcade is framework-agnostic. It works with LangGraph, the OpenAI Agents SDK, CrewAI, Mastra, Pydantic AI, Google ADK, or any MCP-compatible client. The integration has two touchpoints, both through the arcadepy SDK: tools.formatted.get to load tool definitions, and tools.execute to run them.

Save the following as agent.py. This is the run_agent function imported in Step 1, using the OpenAI Chat Completions API directly:

import json
import os

from arcadepy import Arcade
from openai import OpenAI

arcade = Arcade()   # reads ARCADE_API_KEY from env
llm = OpenAI()      # reads OPENAI_API_KEY from env

# Load tools once at startup, not on every request
TOOL_NAMES = [
    "Github.ListRepositoryActivities",
    "Github.GetPullRequest",
    "Datadog.AggregateEvents",
    "Datadog.SearchLogs",
    "Pagerduty.ListIncidents",
    "Pagerduty.ListLogEntries",
]

OPENAI_TOOLS = []
ARCADE_NAME_BY_FUNCTION = {}

for arcade_name in TOOL_NAMES:
    definition = arcade.tools.formatted.get(
        name=arcade_name,
        format="openai",
    )
    OPENAI_TOOLS.append(definition)
    ARCADE_NAME_BY_FUNCTION[definition["function"]["name"]] = arcade_name

SYSTEM_PROMPT = (
    "You investigate production incidents using only the supplied read-only "
    "tools. Return a concise summary, evidence with source identifiers or "
    "links, a recommended next step, and an Actions taken section. Never "
    "claim a query succeeded unless its tool result confirms success."
)

MAX_TOOL_ROUNDS = 8


def run_agent(user_id: str, query: str) -> str:
    messages = [
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": query},
    ]

    for _ in range(MAX_TOOL_ROUNDS):
        response = llm.chat.completions.create(
            model=os.getenv("OPENAI_MODEL", "gpt-4.1"),
            messages=messages,
            tools=OPENAI_TOOLS,
            store=False,
        )
        msg = response.choices[0].message
        messages.append(msg)

        if not msg.tool_calls:
            return msg.content or "No response was produced."

        for tc in msg.tool_calls:
            arcade_name = ARCADE_NAME_BY_FUNCTION[tc.function.name]
            result = arcade.tools.execute(
                tool_name=arcade_name,
                input=json.loads(tc.function.arguments),
                user_id=user_id,
            )

            if result.success and result.output:
                value = result.output.value
            else:
                error = (
                    result.output.error.message
                    if result.output and result.output.error
                    else "Unknown tool error"
                )
                value = {"error": error}

            messages.append({
                "role": "tool",
                "tool_call_id": tc.id,
                "content": json.dumps(value, default=str),
            })

    raise RuntimeError("Agent exceeded the maximum number of tool rounds")

A few things worth noting. Tools are loaded once at module level using formatted.get for each specific tool, which avoids pulling in unwanted write operations and eliminates per-request overhead. The ARCADE_NAME_BY_FUNCTION mapping handles the translation between OpenAI's function names and Arcade's tool names. The loop caps at MAX_TOOL_ROUNDS to prevent runaway execution. Structured tool failures returned by Arcade are fed back to the model as tool results, so it can report issues in its summary rather than crashing silently. Network and SDK exceptions still bubble to the outer Slack handler. And store=False disables storage of the Chat Completion as application state. It does not itself enable Zero Data Retention; API requests may still generate abuse-monitoring logs according to your organization's data-control settings.

Arcade documents formatted.get, formatted.list, and the OpenAI format here. Chat Completions remains supported, and GPT-4.1 supports function calling. OpenAI recommends the Responses API for new projects, but the pattern above is valid. For a complete Slack-to-Arcade reference implementation using LangGraph, see ArcadeAI/SlackAgent. For other frameworks, see Arcade's framework-specific setup guides.

Step 4: Run and test the agent

With all three files saved:

Run python authorize.py once to complete the OAuth flows.
Run python app.py to start the Bolt development server.
In another terminal, run ngrok http 3000 to expose the server.
In your Slack app settings, set the Request URL to https://<your-ngrok-host>/slack/events, subscribe to app_mention, and reinstall the app if Slack prompts you.
Invite the bot to your test channel with /invite @YourBot and try a mention.

Step 5: Configure identity and secure tool access

The prototype above is a shared agent: one fixed service identity (ARCADE_USER_ID) handles every tool call, no matter which teammate tagged the bot. That is the right starting point for a read-only agent, but it is not the only option. A multi-user agent, where each person authorizes tools under their own identity, requires a different auth pattern. Which identity the agent uses, and whether users need to authorize tools themselves, depends on the access model you choose.

A useful architecture for recreating the Claude Tag pattern uses two identity models. Public launch material confirms Claude Tag's channel-scoped shared identity, and the DM model extends naturally from it:

In shared channels, the agent acts under its own dedicated identity, not the tagging user's. Permissions are scoped per-channel.

In DMs, the agent runs with the user's own connectors and credentials.

Replicate this with Arcade's auth patterns:

For shared-channel agents (like #eng-incidents), use a fixed service identity as shown in Steps 1 through 3. If you are connecting through an MCP Gateway instead of the direct SDK, Arcade Headers authenticates the gateway connection. An important distinction: Arcade Headers authenticates the connection to the gateway itself, but it does not bypass OAuth authorization required by individual tools like GitHub or PagerDuty. Gateway authentication and tool-level authorization are separate layers. That is why the one-time setup in Step 2 is necessary regardless of which auth mode you choose.

For personal DM agents, the tools change too. Instead of shared incident-response tools, a DM agent might access a user's own Gmail, Calendar, or Drive. Use per-user OAuth through Arcade's tools.authorize flow. When a tool requires the user's own credentials, Arcade returns an authorization URL. Your app posts that URL to the user in Slack, waits for consent, then resumes execution. The model never sees the token.

def authorize_and_execute(arcade, slack_client, channel_id, user_id):
    """Authorize a tool for a specific user and execute it."""
    auth = arcade.tools.authorize(
        tool_name="Gmail.ListEmails",
        user_id=user_id,
    )
    if auth.status != "completed":
        # In a DM, use a persistent message (no need for ephemeral)
        slack_client.chat_postMessage(
            channel=channel_id,
            text=f"Please authorize Gmail access: {auth.url}",
        )
        arcade.auth.wait_for_completion(auth.id)

    return arcade.tools.execute(
        tool_name="Gmail.ListEmails",
        user_id=user_id,
    )

Arcade stores and refreshes OAuth tokens automatically. Subsequent calls reuse the authorization until it expires, is revoked, or a tool requires additional permissions.

Note that Step 1 does not currently implement DM support. To add it, you need the bot scope im:history, the bot event message.im, and a separate @app.event("message") handler that checks event["channel_type"] == "im" and filters out bot messages. Slack does not deliver DMs as app_mention events. See Slack's message.im documentation.

For a per-user identity without requiring email scopes in Slack, Arcade accepts any consistent unique identifier. A composite Slack identity like f"{body['team_id']}:{event['user']}" works and avoids the need for users:read or users:read.email permissions.

For production multi-user agents, use Arcade's custom user verifier so end-user identity is verified against your own identity system rather than relying on Slack ID mapping alone. Note that production multi-user OAuth also requires your own provider OAuth app credentials, since Arcade's default OAuth apps use the Arcade verifier.

Step 6: Return auditable results in Slack

Trustworthy agents show their work. Structure every response so a human can verify what happened before acting on it.

Here is what a good incident-triage response looks like in Slack:

Summary: Checkout error rate increased 340% starting at 14:32 UTC, correlating with deployment v2.41.3 merged at 14:28.
Evidence:
- Datadog: p99 latency spiked from 220ms to 1,400ms at 14:32
- GitHub: PR #1847 modified the payment validation middleware
- PagerDuty: No prior incidents on checkout-service in the last 7 days
Recommended next step: Review the diff in PR #1847, specifically checkout/validation.py lines 84-112. Consider a rollback if error rate does not stabilize within 15 minutes.
Actions taken: Read-only queries to GitHub, Datadog, and PagerDuty. No writes performed.

The "actions taken" line matters. It tells the team exactly what the agent did and, just as importantly, what it did not do.

How to secure and govern a Claude Tag-style Slack agent

Governance is not a compliance afterthought. It is what lets teams deploy useful agents in the first place. Without clear controls, security teams will block the project before it ships.

Start read-only. Give the agent query access to GitHub, Datadog, and PagerDuty. Do not grant write access until the team has confidence in the agent's judgment.

Require approval before consequential writes. Opening a PR, acknowledging a PagerDuty incident, posting to a customer-facing channel: these should require a human to confirm. Arcade's Contextual Access hooks let you enforce this with pre-execution webhooks that allow, deny, or modify tool execution. Your application collects the human approval and resumes the job; Contextual Access handles the policy-enforcement layer.

Scope tool access by workflow. The incident agent should not see CRM tools. The support agent should not see deployment tooling. Separate tool sets per workflow enforce this structurally, whether you use explicit tool lists in the SDK or separate MCP Gateways.

Log what the agent did. Arcade's audit logs capture administrative actions by default. Combine these with your application-level logs and downstream SaaS audit trails so you can always answer: what did the agent do, under which identity, in which system?

Make it easy to stop. A kill switch is a feature. Revoking the agent's dedicated API key or disabling the Slack app should take seconds.

Build the Slack agent your team will actually tag

The goal is not an AI agent that can do everything. It is one dependable agent that removes friction from a workflow your team performs every week.

Pick the workflow. Define the toolset. Wire up the Slack trigger. Connect the tools through Arcade.dev. Start read-only, return inspectable results, and expand scope as trust builds.

The team that ships a useful agent in one channel next week will learn more than the team that spends a quarter designing a platform for every channel.

Start here:

[ ] Identify one recurring, cross-system workflow your team performs in Slack
[ ] Pick a small read-only toolset from Arcade's tool catalog
[ ] Authorize those tools for your service identity (python authorize.py)
[ ] Build the Slack trigger with thread context retrieval and error handling
[ ] Deploy, observe, and expand deliberately

Explore Arcade's tool catalog, authorization guides, and MCP Gateway documentation to get started. The code from this guide is on GitHub. Fork it and build something useful.

Frequently Asked Questions

What is Claude Tag?

Claude Tag is Anthropic's shared AI agent for Slack, launched on June 23, 2026 for Enterprise and Team customers. Unlike the previous Claude in Slack integration, which ran as a personal assistant under each user's own account, Claude Tag operates as a shared teammate in channels. Anyone can tag @claude, and the entire exchange is visible to the channel. It reads thread context, uses connected tools, and posts structured results in-thread.

How is Claude Tag different from Claude in Slack?

Claude in Slack gave each user a private instance that acted under their personal permissions and usage quota. Claude Tag replaces that with a single shared identity per channel, scoped by an admin. Work is visible to the whole channel, anyone can pick up a conversation where someone else left off, and Claude builds persistent context as it follows along. Anthropic will automatically migrate existing Claude in Slack workspaces to Claude Tag on August 3, 2026.

Can you build your own version of Claude Tag?

Yes. Claude Tag's core interaction pattern is reproducible: a Slack event trigger, an LLM reasoning loop, and authorized access to external tools. This tutorial builds that pattern with Python, Slack Bolt, and Arcade. Arcade handles tool connectivity and OAuth token management so you can connect to systems like GitHub, Datadog, and PagerDuty without managing credentials yourself. The result is not Anthropic's proprietary product, but a Claude Tag-style agent you fully control.

What does Arcade do in a Slack AI agent?

Arcade is the action layer between your agent and external tools. It handles three things: loading tool definitions formatted for your LLM, executing tool calls with the correct credentials injected at runtime, and managing OAuth authorization flows so the model never sees tokens or API keys. You choose which tools the agent can access, and Arcade enforces that scope on every request.

Does my Slack AI agent have access to user passwords or API keys?

No. Arcade manages all credentials on the server side. When a tool requires OAuth (like GitHub or PagerDuty), the user completes a consent flow once and Arcade stores and refreshes the token. When a tool requires API keys (like Datadog), those are configured as secrets in the Arcade dashboard. The LLM and your application code never see raw credentials. Arcade injects the right token at execution time.

Enterprise-Managed Authorization Is a Foundation, Not a Ceiling: Why Connected Agents Need Per-Action Authorization

Manveer Chawla — Tue, 23 Jun 2026 20:19:06 +0000

TL;DR

Enterprise-Managed Authorization (EMA) centralizes access provisioning and eliminates per-server consent prompts. It is the right solution for connection-time governance. It was not designed to authorize each individual tool call, and it does not.
AI workflows need per-action authorization to limit the blast radius of prompt injection, because attacks exploit the gap between "this agent is allowed to connect" and "this specific action should execute right now."
A secure authorization layer must evaluate the intersection of organization policies, user delegation, and agent capability boundaries immediately before an action executes.
Production-grade deployments use a pre-execution interceptor and credential isolation to guarantee that large language models never access raw authentication tokens directly.
High-risk production deployments need action-level runtime enforcement, implemented in-house or through an action runtime such as Arcade, without replacing existing corporate identity infrastructure, including EMA.

What Enterprise-Managed Authorization (EMA) Solves for MCP

Enterprise-Managed Authorization is now stable. The extension, adopted by Anthropic, Microsoft, Okta, and a growing number of MCP servers, solves the per-server OAuth consent tax that slowed enterprise MCP adoption.

Before EMA, every employee had to authorize every MCP server individually. Security teams had no centralized control. Work and personal accounts bled together. EMA eliminates all of this by making the organization's IdP the authoritative decision-maker for MCP server access. Administrators define policy once. Users authenticate through single sign-on and inherit every server their role permits. No per-app OAuth, nothing to configure as a one-off.

Under the hood, as part of the SSO-based authorization flow, the client obtains an identity assertion and uses it to request an Identity Assertion JWT Authorization Grant (ID-JAG), which it exchanges for access tokens from each MCP server's authorization server. Three properties follow: authorize once and inherit everywhere, centralized policy and audit for access decisions, and elimination of personal/enterprise account mixups.

This is valuable infrastructure. It is also, by design, a grant-time decision. EMA's IdP evaluates policy when tokens are issued (and may re-evaluate on renewal), but its standardized authorization visibility does not extend to individual tool calls. EMA determines who may connect to what. It has nothing to say about whether a specific tool call, proposed by a potentially compromised agent five minutes after the token was issued, should actually execute.

That gap is where the real attacks live.

How Prompt Injection Exploits Authenticated AI Agents

In early 2025, security researcher Johann Rehberger demonstrated SpAIware: a single indirect prompt injection, delivered through a malicious website, planted persistent instructions in ChatGPT's memory store. Those instructions survived logouts and browser restarts. The compromised instance then acted as a command-and-control relay, polling a public GitHub repository for attacker commands and writing exfiltrated data to Azure Blob Storage request logs. The CSA's March 2026 Promptware report generalized this into a broader class of agent C2 attacks.

The agent's built-in capabilities (web access, memory, code execution) were all legitimately available to its runtime. EMA-style centralized provisioning would not have changed the outcome. The injected instructions exploited capabilities already present in the agent's environment, not separately provisioned OAuth connections. No authorization layer distinguished a user-initiated action from an injection-initiated one. Connection-time governance was powerless because the problem was never authentication. The agent was who it claimed to be.

In mid-2026, researchers demonstrated prompt-injection attacks through GitHub comments, issue bodies, and PR titles that hijacked Claude Code, Gemini CLI, and GitHub Copilot Agent. Across the three products, the attacks exploited pre-authorized tool capabilities to exfiltrate CI secrets; some variants also induced shell-command execution. A related academic study documented similar injection vectors across 15 GitHub Actions. Anthropic's remediation was telling: they disallowed the ps tool rather than restricting broad tool access. The response was a band-aid on a connection-level wound.

These are not isolated demonstrations. F5 describes a banking scenario in which threat actors use prompt injection against an AI chatbot to initiate unauthorized financial transactions, with the bank identifying the loss only after multiple accounts are impacted. The AI Red Teaming Guide catalogs a growing body of MCP-related vulnerabilities disclosed through 2025. Simon Willison, who has tracked prompt injection since 2022, coined the "lethal trifecta" for this pattern: private data, untrusted content, and external communication converging in the same system.

The common thread across every attack: attackers induced agents to misuse capabilities already available to their runtimes. No authorization layer asked whether the specific action matched the user's intent.

Per-action authorization evaluates whether a specific tool call should proceed based on the intersection of organization policy, user delegation, and agent capability, checked at execution time, after the prompt, for every action independently. It is distinct from grant-time authorization (evaluated at token issuance, which is what EMA provides) and session-level authorization (checked once per conversation).

Per-action authorization is not itself a prompt-injection detector. It limits blast radius by denying or escalating actions that violate deterministic constraints. An injected action that remains within those constraints may still execute, so provenance controls, content isolation, and human approval remain necessary for sensitive operations.

EMA vs. Per-Action Authorization: Provisioning vs. Runtime

EMA and per-action authorization are not competing solutions. They operate at different points in the execution lifecycle and address different threat models.

Concern	EMA (Connection-Time)	Per-Action Authorization (Runtime)
Decision point	Before the agent connects to a server	Before the agent executes a specific tool call
What it answers	"Is this user/agent allowed to access this MCP server?"	"Should this specific action execute in this context?"
Policy inputs	IdP groups, roles, conditional access rules	Organization policy + user delegation + agent capability + tool arguments + trusted provenance and risk signals
Threat model	Unauthorized connections, personal/enterprise mixups, shadow IT	Prompt injection, permission abuse, lateral movement through valid connections
Evaluation frequency	At token issuance/renewal	Every tool call
Audit trail	"User X connected to Server Y at time T"	"Agent A attempted action B with parameters C, evaluated against policy D, outcome E"

EMA provides the outer gate. It ensures that only authorized users connect to approved servers through managed corporate identities. But EMA itself adds no per-tool-call semantic policy. Individual MCP servers may enforce scopes, ACLs, or rate limits on each request, but those controls are server-specific, inconsistent across the ecosystem, and unaware of whether a tool call originated from user intent or injected instructions.

The NSA's May 2026 Cybersecurity Information document on MCP security is blunt: "MCP itself cannot enforce these security principles at the protocol level." This applies equally to EMA. The extension centralizes provisioning decisions. It does not, and cannot, evaluate whether the tool call an agent is about to make was triggered by the user's intent or by a malicious instruction embedded in a GitHub comment.

Why OAuth Scopes Are Not Enough for AI Agent Authorization

OAuth scopes are space-delimited strings and are often too coarse for transaction-specific authorization. A mail.send scope grants the ability to email any recipient. It cannot encode which recipient, in what context, whether the user intended this specific email, or whether the conversation was corrupted by an injection.

RFC 9396 (Rich Authorization Requests) partially addresses this by using JSON objects to describe API access with type, locations, and actions fields. RAR can constrain later operations using transaction-specific authorization details (recipient, amount, resource), and resource servers can enforce those details. But RAR does not standardize provenance-aware evaluation of whether an agent's later action still reflects the user's current intent. When an agent makes a tool call from a potentially compromised conversation, RAR constrains the parameters but cannot determine whether the call was user-initiated or injection-initiated.

The MCP specification's auth extensions face the same structural limitation. As of June 2026, both EMA and Client Credentials operate at the transport/connection level. The ext-auth repository contains no per-action authorization extension. Final MCP SEP-2468 recommends that authorization servers include the OAuth authorization-response iss parameter and requires clients to validate it, mitigating authorization-server mix-up attacks. This is a transport-security measure, not per-action evaluation. MCP's core authorization does support runtime insufficient-scope challenges and step-up authorization, where scopes may depend on request arguments and context. These are valuable server-side controls, but they remain server-defined scope enforcement, not standardized provenance-aware authorization.

This is not an oversight in the protocol or the extension. It reflects an architectural boundary. Authentication answers "who is this?" Connection-level authorization (including EMA) answers "what can this entity access?" Per-action authorization answers "should this specific action happen right now?" Zero-touch OAuth establishes the first two. The third requires an additional application- or runtime-level mechanism.

OAuth has progressively added defenses across the authorization and token lifecycle. RFC 6749 (2012) and RFC 6750 defined bearer tokens without sender-constraining. PKCE (2015) mitigated authorization-code interception. DPoP (2023) sender-constrained tokens to reduce replay. RFC 9700 (2025) updated the entire threat model based on "practical experiences gathered since OAuth 2.0 was published." These mechanisms are not per-action authorization, but they illustrate the broader movement away from relying on bearer credentials alone. Each addition responded to real attacks that exploited assumptions about what grant-time credentials could safely cover.

The Three-Layer Authorization Model for AI Agents

Agents operate at the intersection of three distinct permission sets, not one.

AWS IAM provides a useful precedent for this model. The following table simplifies IAM's full evaluation logic (which combines identity-based and resource-based grants, then constrains them by permissions boundaries and SCPs) to illustrate the intersection principle:

IAM Layer	Agent Authorization Analog	What It Controls
Service Control Policy (Organization)	Organization policy	Maximum permissions any agent in this org can possess
Identity-based policy (User)	User delegation	What this specific user has delegated to the agent
Permission boundary (Entity)	Agent capability boundary	What this agent type is designed and permitted to do

The identity or resource policy must grant the action, while the permissions boundary and SCP must permit it. An explicit deny overrides an allow, and adding a permissions boundary can only reduce effective permissions.

EMA maps cleanly onto the first two layers at connection time. The IdP enforces organization-level policy (which servers are approved) and user-level access (which roles and groups the user belongs to). But it evaluates these layers at token issuance, not per tool call, and it does not standardize an agent-specific capability boundary. OAuth authorization servers can apply client-specific policy, but EMA itself does not define how agent capabilities should be constrained beyond what scopes and roles permit.

Suppose your organization policy says "no agent may delete production databases." A user has delegated broad access to their calendar, email, and project management tools. The agent is a triage-bot designed to label issues and assign them. The effective permission is the intersection: the triage-bot can label and assign issues in the user's projects, and nothing else. It cannot send email (outside its capability boundary), cannot delete databases (blocked by org policy), and cannot access another user's calendar (not delegated).

Oso's 2026 Least Privilege Report (analyzing 2.4 million workers and 3.6 billion permissions) found that 96% of enterprise permissions go unused over 90 days. Employees typically possess 10 times the access they actually need. Thirty-one percent of workers can modify or delete sensitive data. Thirteen percent can reach regulated data including financial and health records.

Humans often leave dormant permissions unused because of judgment, habit, and professional accountability. Agents do not share those natural constraints and can operate continuously at machine speed. When an agent inherits a human's permission set through a grant-time OAuth token (whether provisioned manually or through EMA), it may exercise capabilities the human rarely touches, turning latent over-provisioning into active attack surface.

OpenFGA (built on Google Zanzibar's principles) has formalized this by modeling agents as first-class principals, identical to human users, with explicit authorization tuples like user: agent:triage-bot, relation: member, object: project:alpha. But the intersection model must be augmented with runtime evaluation: not just "does this agent have the permission?" but "does this agent's current context justify exercising this permission?"

Zero-Touch OAuth vs. Runtime Security for AI Agents

The zero-touch reflex and the security reflex are both right, and they pull in opposite directions.

One view holds that the protocol should stay out of application-level authorization. Before EMA, users completed one authorization flow per MCP server; afterward, the client included a bearer token that the server validated on every HTTP request. EMA centralizes that initial provisioning without changing the server's responsibility to validate requests.

The opposing view holds that user-visible friction can still serve a purpose. A per-server consent prompt is not approval of each transaction, but it does show the user what access is being granted. In hosts that expose connected tools across conversations, pre-connecting a high-stakes server can make it reachable from any such conversation. That argues for separate transaction-specific controls, not for preserving per-server OAuth prompts as their substitute.

Some security teams value explicit user consent for accountability, while others prefer centrally administered access with fine-grained agent policies. Both needs can be met by combining centralized provisioning with runtime enforcement and targeted human approval.

Without a runtime enforcement layer, zero-touch provisioning can leave an action-level authorization gap. Authorization should therefore be separated from model decision-making and enforced by the harness or execution layer, whether in-process, in a sidecar, or as a remote service.

How to Implement Per-Action Authorization with a Pre-Execution Interceptor

Insert a policy evaluation point between the LLM's tool-call decision and the actual tool execution. This is the "post-prompt, pre-execution" gap that EMA and zero-touch OAuth leave open by design.

The common objection is latency. Three implementations demonstrate that per-action policy evaluation is feasible at low cost relative to typical LLM inference:

Microsoft's Agent Governance Toolkit (April 2026), which Microsoft describes as the first toolkit addressing all 10 OWASP agentic AI risks: a stateless policy engine with a ToolCallInterceptor that hooks into native framework extension points. Microsoft's own benchmarks report p99 under 0.1 milliseconds.
OPA/Rego sidecar: suitable local policies can evaluate in single-digit milliseconds, although teams should benchmark their own policy complexity and deployment topology.
Google Zanzibar: per-request authorization serving many large-scale Google services. Reported p95 under 10 milliseconds at millions of checks per second.

The minimal viable architecture has three components:

Interceptor hooking between the LLM's tool-call output and tool execution. Frameworks provide native extension points (LangChain callbacks, CrewAI middleware).
Stateless policy engine evaluating each call against organization, user, and agent policy layers. OPA, Cedar, or equivalent, running locally or as a sidecar.
Credential store isolated from the LLM. Raw tokens are never exposed to the model's context window. Credentials are injected only after policy allows execution.

The interceptor pattern in practice looks like this:

async def authorized_tool_call(tool_name, args, agent_id, delegation_chain):
    decision = await opa_evaluate({
        "tool": tool_name,
        "args": args,
        "agent_id": agent_id,
        "delegation_chain": delegation_chain
    })
    if decision["outcome"] == "allow":
        return await execute_tool(tool_name, args)
    elif decision["outcome"] == "deny":
        return {"error": decision["reason"], "code": decision["reason_code"]}
    elif decision["outcome"] == "escalate":
        return await request_human_approval(tool_name, args, decision["reason"])
    else:
        return {"error": "Unknown policy outcome", "code": "unknown_outcome"}

Production implementations should canonicalize tool arguments, bind policy decisions and human approvals to a hash of the exact tool name and arguments, and re-evaluate policy after an asynchronous approval. This prevents arguments, credentials, or policy state from changing between authorization and execution.

When Rego policies are written to return structured decisions (reason code, deciding policy rule), OPA can surface that context to the caller. A safe, user-facing reason code can be returned to the model so it can replan. Detailed policy rules and sensitive denial context should remain in internal audit logs rather than being exposed to the model.

Production implementations use RFC 8693 OAuth 2.0 Token Exchange to issue short-lived, least-privilege credentials bound to the current user and session. The LLM never sees any token; the execution layer receives the attenuated credential. This means a successful prompt injection that exfiltrates the agent's context window yields no actionable credentials. EMA's ID-JAG flow establishes the user's identity; credential isolation reduces the risk of that identity being exploited through token theft. Action-level policy and containment remain necessary to prevent the execution layer itself from being used as a confused deputy.

Different risk levels warrant different patterns:

Pattern	When to Use	Latency	Human Required?
Synchronous policy check	Read operations, low-risk tool calls	< 10ms	No
Asynchronous human-in-the-loop (HITL) approval	Financial transactions, data deletion	Minutes to hours	Yes
Deny-with-replan	Agent can choose an alternative action	< 10ms + inference	No

The asynchronous pattern draws from financial services' four-eyes principle (maker-checker): one party prepares an action, another independently reviews and approves before execution. The agent is the "maker." When a human independently reviews the agent's proposed action, this is literal maker-checker. Automated policy enforcement provides an analogous independent control but is not, by itself, the four-eyes principle.

Why Per-Action Authorization Is Inevitable for Enterprise AI

The industry has repeatedly moved from coarse upfront grants toward narrower runtime controls, and each time, it wasn't optional for long.

Android permissions. Before Android 6.0 Marshmallow (2015), apps received all requested permissions at install time. Users faced an all-or-nothing choice. Android 6.0 moved "dangerous permissions" to a contextual, just-in-time model: apps must request them at the moment of use, and users can deny or revoke specific permissions. Once granted, permissions persist until revoked, so this is not per-action authorization. But the shift from blanket install-time grants to contextual, revocable runtime grants is the same directional move. Install-time permissions are connection-time provisioning (EMA's domain).

Google BeyondCorp. After Operation Aurora (2010) demonstrated that perimeter-based trust was insufficient, Google replaced its castle-and-moat model with per-request evaluation based on device state, user identity, and context, regardless of network location. The lesson: "connected" (on the corporate network) was not an authorization decision.

OAuth's own evolution. OAuth retained bearer-token deployments while adding PKCE, DPoP, and updated security guidance to harden different stages of the flow. Neither PKCE nor DPoP is per-action authorization, but both responded to attacks that exploited assumptions about what grant-time credentials could safely cover.

AI agent authorization is the next instance. EMA represents the maturation of the connection layer, the same way centralized SSO matured enterprise web app access. The CSA, NSA, and OWASP already emphasize action-level controls, least privilege, deterministic validation, and explicit approval for consequential operations. The question is how quickly the industry will build the runtime layer that complements centralized provisioning.

Compliance pressure is accelerating the timeline. SOC 2 Trust Services Criteria map naturally to per-action controls. CC6.1 (logical and physical access controls) can be supported when audit trails capture each agent action, not just token issuance. CC6.6 (system boundary protection) is strengthened when policy enforcement operates at the tool-call level, not just the network perimeter. CC7.2 (anomaly monitoring) benefits from granular agent telemetry that reveals unusual tool-call patterns in real time. Per-tool-call logging is not a verbatim SOC 2 requirement, but it can provide useful evidence when auditors assess how agent access and actions are controlled.

On the analyst side, Gartner's Market Guide for Guardian Agents and Forrester's 2026 Technology and Security Predictions both signal that agent governance is now an enterprise category. Forrester predicts enterprises will defer 25% of planned AI spending to 2027 as financial scrutiny intensifies and organizations struggle to demonstrate ROI.

Building a Production Per-Action Authorization Architecture

A production-grade implementation requires seven components:

Connection-time provisioning (EMA, centralized IdP) controlling which users and agents access which servers.
Pre-execution interceptor between the LLM's tool-call output and execution.
Policy engine evaluating the three-layer intersection (org x user x agent) per call.
Credential isolation from the LLM, with tokens injected only after policy allows.
Deny-by-default stance with structured reason feedback for model replanning.
Human-in-the-loop (HITL) approval for high-risk actions via Slack, email, or equivalent out-of-band flow.
Per-action audit logging supporting SOC 2 Trust Services Criteria (CC6.1, CC6.6, CC7.2).

None of these components require novel technology. Microsoft AGT delivers sub-millisecond policy enforcement. OPA handles deny-with-reason in single-digit milliseconds. Zanzibar processes millions of authorization checks per second. EMA handles centralized provisioning today. The necessary building blocks exist. The gap is in connecting them: applying policies consistently across all agents as they scale to more users and systems. That is the central gap an action runtime fills. Without infrastructure for secure action, organizations often restrict agents to analysis and recommendations, keeping realized ROI incremental.

Arcade.dev evaluates agent scope and user scope together on every tool call. Its Contextual Access capability adds customer-defined organization policy through pre-execution hooks that can allow, deny, or modify tool calls. Credentials remain isolated from the LLM, and the model never receives raw tokens. Arcade's catalog includes 8,000+ agent-optimized tools designed around natural-language intent rather than raw API passthrough.

Arcade goes beyond routing. Its MCP Gateway federates multiple servers behind a single controlled endpoint. For governance, Arcade generates structured, OpenTelemetry-compatible audit events for every agent action, attributable to the requesting user and exportable to enterprise SIEM systems.

Arcade integrates with existing OAuth and IdP flows, including Microsoft Entra and Okta, rather than replacing them. It can be deployed in Arcade Cloud, in a customer VPC, on-premises, or in a fully air-gapped environment, allowing organizations to control data residency and network isolation.

Other tools in this space (OPA, Cedar, Microsoft AGT, Kontext, AuthZed) address individual pieces: policy engines, credential management, or governance overlays. Arcade provides all of these capabilities out of the box. By uniting agent authorization (policy and credentials), agent-optimized tools, and lifecycle governance into a single runtime, Arcade solves the complete execution-time security challenge. That matters because these three concerns interact at execution time.

Conclusion

EMA is the right answer to one authorization problem, but not the complete answer for agent runtime security.

The industry has repeatedly moved from coarse upfront grants toward narrower runtime controls. Each time, early adopters avoided the painful retrofit that the rest of the industry eventually endured.

The teams building continuous authorization into their agent architecture now, complementing EMA with runtime policy enforcement, make the same bet the Android, BeyondCorp, and OAuth security teams made: that "provisioned" was never the same as "authorized," and that the gap between them is where real attacks live.

FAQ

What is Enterprise-Managed Authorization (EMA) for MCP?

Enterprise-Managed Authorization is an MCP extension that allows organizations to centrally manage which MCP servers their users can access. It uses the organization's identity provider (IdP) to provision access based on groups, roles, and conditional access rules. Users authenticate once through SSO and automatically connect to all approved MCP servers without per-server consent prompts.

How does EMA relate to per-action authorization?

EMA and per-action authorization solve different problems at different points in the execution lifecycle. EMA governs who connects to what (provisioning). Per-action authorization governs whether a specific tool call should execute (runtime enforcement). EMA is the outer gate; per-action authorization is the inner gate. A complete enterprise architecture needs both centralized provisioning and runtime enforcement; EMA is one way to provide the provisioning layer.

What is per-action authorization for AI agents?

Per-action authorization is a security model that evaluates whether a specific AI agent tool call should proceed based on organization policy, user delegation, and agent capability. It checks permissions at execution time, immediately after the prompt and before the action occurs. This limits the blast radius of prompt injection by blocking policy-violating actions, even when the underlying permissions were legitimately provisioned through EMA or standard OAuth.

Why is EMA not sufficient for AI agent security?

EMA centralizes access provisioning, which is valuable. But it evaluates access at token issuance (not per tool call) and cannot detect if a specific runtime action was genuinely requested by the user or triggered by a prompt injection. Because AI agents execute tasks at machine speed, they can rapidly exercise latent over-provisioning inherent in standard OAuth scopes, even when those scopes were provisioned through a centrally managed, policy-governed flow.

How can prompt injection abuse access granted through EMA and OAuth?

Prompt injection abuses EMA- and OAuth-granted access by planting malicious instructions within untrusted content that an authenticated AI agent processes. Because the agent's connection to tools like GitHub or Azure is already authorized via valid, centrally-provisioned tokens, these calls use valid credentials and remain within granted scopes, so they can pass conventional token, scope, and ACL checks. Those checks do not establish whether the user intended the particular action.

Does per-action authorization add latency to AI agents?

Per-action authorization typically adds low latency when evaluated locally or in-process. Suitable local policies can complete in single-digit milliseconds, though results vary with policy complexity and network topology. For local policies this overhead is usually small relative to LLM inference, but remote services and complex policies should be benchmarked in the target deployment.

How do you implement per-action authorization alongside EMA?

You implement per-action authorization by inserting a pre-execution interceptor between the LLM tool call output and the actual tool execution. This interceptor uses a stateless policy engine to evaluate the requested action against organization, user, and agent policies. EMA continues to handle grant-time provisioning through the IdP. Developers can build this architecture manually or use an action runtime platform like Arcade to enforce runtime checks across their agent infrastructure while preserving their existing EMA and IdP flows.

What Does Arcade Do for AI Agent Authorization?

Arcade is an action runtime platform that provides per-action authorization, managed tools, and governance for AI agents in a single unified system. It evaluates agent and user scopes on every tool call and can enforce customer-defined organization policy through pre-execution hooks immediately before execution. Arcade integrates with existing IdP infrastructure (such as Microsoft Entra and Okta via OIDC) rather than replacing it, adding the runtime enforcement layer that grant-time provisioning cannot provide. It also isolates credentials from the LLM so that the model never sees raw tokens, reducing credential-exfiltration risk during prompt injection attacks. Action-level policy and containment remain necessary to prevent the execution layer from being used as a confused deputy.

Lessons from building 20 MCP Apps in 2 days

Teal Larson — Fri, 19 Jun 2026 21:56:10 +0000

A few weeks back, my team sat down for two days and built around twenty MCP Apps. I came out with a much better idea of what they are, what they aren't (yet), and where the duct tape is currently holding things together. Here's the brain dump.

If you haven't run into them yet: MCP Apps is the first official extension to the MCP spec. It lets a tool return a UI resource alongside its result. The host renders that UI inline as a sandboxed iframe. Tables, charts, forms, branded layouts, little interactive bits that can call back into other tools. Real, actual UI in the middle of a chat-based experience. Very cool.

They matter because some information is just better visually. A neatly grouped list of pull requests is much easier to scan than a wall of bulleted text. A chart beats a CSV. And as more of our day-to-day work shifts into chat, "bring your brand and your product surface into the conversation" stops being a nice-to-have.

OK. Lessons.

The call is coming from inside the house

MCP Apps live inside the server. This was the first thing that surprised me. An MCP App isn't a hosted URL you point your tool at or some third-party iframe you embed. It is fetched via MCP, not HTTP, so the UI code ships with the MCP server and is served via the ui:// resource scheme.

There are a number of different ways you could go about organizing this. For example, you could co-locate the files with the tools themselves:

my-mcp-server/
  tools/
    list_projects    
      list_projects.py
      project-summary.html
    list_project_patterns
      list_project_patterns.py
      pattern-card.html

Or co-locate them in a single place:

my-mcp-server/
  tools/
   list_projects.py
   list_project_patterns.py
  ui/
    pattern-card.html
    project-summary.html
    ...

We were using React because we wanted to leverage the existing internal design system components. So we landed on:

my-mcp-server/
   tools/
   ui/
     pattern-card.tsx
     project-summary.tsx
     package.json
     vite.config.mjs

A single Vite project at the root of /ui, configured to output an HTML file per TSX file at build time.

MCP Apps are enrichment-only

If a host supports MCP Apps, your user sees the rich UI. If it doesn't (Claude Code, most terminal-based clients, anything that isn't on the new extension), the _meta.ui property is silently ignored and your user just gets the text response.

So the text response is still the contract. Your MCP App is enrichment on top. If you stuff the actual answer into the UI and leave your text response empty, congratulations: you've shipped a tool that works in some clients and silently breaks in others. Always design as if half your users will never see the app.
Keep these things STUPID simple
I am going to be the first one to tell you: keep your MCP App components dumb. Pure. Boring. All data passed in as props from the tool result. No fetches from inside the app, no state machines, no calls back to your API.

The tool runs, computes its answer, hands the data to the UI as props, and the UI is just a deterministic render of that. This made our apps fast to build, easy to reason about, and very simple to test in isolation. It also kept us honest about what exactly we were sending into a sandbox we don't fully control (more on that in a sec).

Host quirks are real

There's a spec, but hosts implement it with their own opinions. Container width, padding, default typography, dark/light handling, the whole vibe varies. ChatGPT renders wide in a browser. Claude renders narrow in a chat panel. Mobile is mobile. VS Code's side panel is its own little adventure.

There's no standardized testing harness yet, so our iteration loop was: build, install in client A, eyeball it, install in client B, eyeball it, adjust, repeat. Compared to ordinary frontend dev, where you'd just spin up a Storybook or run Playwright across browsers in CI, it felt slow. Like, painfully slow.

Two things helped:

Designing layouts that gracefully reflow at narrow widths from the start, rather than fixing them after the fact.
Using a file watcher to rebuild on save, so the inner loop wasn't quite so brutal.

The tooling will catch up. For now: plan for visual QA across multiple hosts, and accept the dev loop is going to feel slow.

The host can see everything

MCP Apps run in a sandboxed iframe, but the content of that iframe is visible to the host. This has a real implication and I don't want to bury it: don't use MCP Apps to collect secrets. No API keys in form fields. No OAuth tokens. Nothing you wouldn't want logged.

If you need to collect secrets, use URL elicitation or a separate secure form outside the MCP App. You can pair that with an MCP App that polls the external endpoint for completion status. The secret itself just shouldn't live inside the rendered iframe.

TL;DR

If you're starting from zero:

Bundle your UI inside your server. Multi-page Vite, one HTML per surface, your existing design system imported directly.
Always make the text response stand on its own.
Pure components, props in, no client-side state.
Test on every host you care about, by hand, until tooling catches up.
Don't put secrets in the app.

The patterns that do still feel impossible (gathering tool inputs via UI before the call, for example) might not stay that way for long. MCP Tasks are in the experimental phase and looks like it could open that door

For now: MCP Apps are early, the spec is moving, the tooling is thin, and they're already worth shipping.

Best Composio Alternatives in 2026 for Production AI Agents

Manveer Chawla — Thu, 11 Jun 2026 19:25:27 +0000

Composio offers over 1,000 toolkits and 20,000 tools through MCP and direct APIs.

It's great for rapid prototyping, but scaling AI agents to production requires a different architecture.

This guide evaluates four production-ready alternatives, covering authorization models, governance, deployment options, and real migration complexity, for engineering teams moving beyond the prototype stage.

Key takeaways

When evaluating Composio alternatives for production, prioritize per-user delegated authorization (just-in-time user consent), agent-optimized tools with constrained schemas that reduce hallucination, and centralized governance with immutable audit logs, ideally OpenTelemetry-compatible. Deployment model (cloud, VPC, or air-gapped) is also an important consideration for enterprise environments.

Best overall for secure multi-user production: Arcade.dev
Best for AWS-native ecosystems: AWS AgentCore
Best for data-centric B2B data sync: Merge
Best for shadow AI discovery and governance: Natoma

How to evaluate Composio vs. production-ready alternatives

Composio is an MCP gateway and integration wrapper; it works well for early prototyping, single-user internal utilities, or budget-constrained projects. Its extensive integration catalog and low per-call pricing make it the fastest way to wire up a multi-app agent for a proof of concept.

Moving beyond prototypes reveals architectural limitations around identity, blast radius, observability, and multi-user AI agent authorization when routing multiple real users through agent workflows.

Evaluating a production-ready alternative comes down to three questions:

Where do my users' OAuth tokens and API keys live, and what is the blast radius if the platform is breached?
Who can register and run tool definitions, and is execution governed and versioned?
If something goes wrong, can I prove exactly what every agent did?

Adopting a runtime like Arcade or a unified data layer like Merge doesn't replace your agent orchestration loops. Teams still bring their own orchestration layers, like LangChain or Mastra, to manage reasoning and maintain contextual state. The platforms evaluated below operate as execution runtimes and gateways, securing and standardizing the tool layer that orchestration frameworks call.

When evaluating authorization and blast radius, look for delegated authorization models that evaluate the intersection of agent and user permissions for each action at runtime, scoped to that action, with credentials never exposed to the LLM. The weaker pattern, common in prototyping-first tools, is pre-authorized tokens with broad, static permissions that are fast to wire up, but widen the blast radius the moment an agent is compromised.

On May 21, 2026, an attacker gained access from internal monitoring tools into automated remediation systems, registered malicious tool definitions inside the tool-execution sandbox and executed arbitrary code. They separately abused compromised employee Gmail OAuth tokens via magic-link sign-in. Roughly 0.3% of active connections were exposed, including about 5,001 GitHub tokens, a small number of Gmail and other service tokens, and an auxiliary cache that held about 5,241 API keys during the breach window, with the full scope not yet known at the time of disclosure.

Composio responded with credential rotation and OAuth revocation across roughly 100 toolkits, and is introducing customer-key self-custody (a Zero Trust Proxy KMS), with keys visible only at creation and IP allowlisting. This incident maps directly onto the authorization, blast-radius, and governance dimensions, demonstrating that the criteria most critical to production-readiness are exactly the ones that breadth-and-price comparisons tend to ignore.

Tool reliability is another critical axis of evaluation. You need to differentiate between intent-level tools and raw API wrappers. Tools with constrained, intention-aligned schemas reduce the surface area for hallucinations and map more reliably to API calls than raw wrappers do. Raw API wrappers force the LLM to guess the exact schema structure, leading to endless retry loops and excessive token usage.

Production workloads demand strict MCP and agent governance. Composio lets teams build custom tools through its SDK, but does not support connecting external MCP servers, including official vendor-published servers. This locks teams into Composio's catalog for pre-built integrations. Look for a governed tool registration that lets teams connect external MCP servers and manage their own tool definitions alongside pre-built catalogs, with pre- and post-tool-call policy enforcement and immutable audit logs. OpenTelemetry (OTel) compliance is the emerging standard for production AI observability. Platforms must support OTel with GenAI and MCP semantic conventions, capturing exact tool execution states to provide a reliable audit substrate.

Pricing structure, deployment and self-hosting support, developer experience, and documentation quality should also guide your final platform choice.

Composio alternatives comparison table

	Arcade	AWS AgentCore	Merge	Natoma
Best for	Secure multi-user production	AWS-native ecosystems	B2B data sync	Shadow AI discovery
Pricing model	Platform + Usage based	Usage-based (Complex)	Platform / Linked accounts	Seat-based / Enterprise
MCP gateway/capability	Runtime + Gateway	Partial (BYO servers)	Gateway Only	Gateway Only
User and agent authorization	Delegated per-user auth, scoped agent permissions, runtime intersection enforcement	IAM and workload identities; end-user delegation depends on implementation	Linked account credentials for data access; limited agent-specific authorization	ABAC and role-based profiles across AI clients
Key differentiator vs Composio	Unified MCP runtime: auth + agent-optimized tools + governance	Deep AWS compliance integration	Normalized data schemas	Shadow AI discovery
Deployment options	Cloud, VPC, Air-gapped	Cloud (AWS only)	Cloud	Cloud, VPC
Audit logs support	Immutable runtime audit logs	CloudWatch/X-Ray via AWS setup	Linked-account audit trail	Tool-call and activity logs
OpenTelemetry (OTel) compliance	Yes	Yes	No	No

In-depth reviews of the best Composio alternatives

Arcade: Composio alternative for secure, multi-user production

Best for

Engineering and AI product teams deploying secure, governed, multi-user agents in production environments.

Overview

Arcade.dev is the MCP runtime for building and deploying multi-user AI agents that take real actions across enterprise systems. It unifies agent authorization, agent-optimized tools, and lifecycle governance into a single execution layer, on the principle that a runtime is the best gateway. The layer that brokers identity and routes traffic should also enforce policy and capture audit, rather than leaving teams to bolt those concerns onto a thin proxy.

This means engineering teams don't have to rebuild security plumbing, complex token management, and logging infrastructure for every new software integration.

Arcade vs. Composio: Key differences

Composio focuses on breadth with a large catalog of tools auto-generated from OpenAPI specifications. Arcade focuses on depth with tools built to agent-experience principles and validated with evals before release, and provides the full runtime stack of authorization, agent-optimized tools, and governance in a single execution layer. That architectural difference drives three major advantages:

Centralized Governance: Arcade is the central enforcement point for policies your organization has already defined in IdPs, SaaS tools, and security systems, rather than asking teams to recreate them. Unlike Composio's Tool Router, Arcade can register and govern built-in, custom, and external MCP servers via a single control plane. That control plane covers every tool, agent, and auth provider, with strict versioning, a shared registry that prevents teams from rebuilding what already exists, visibility filtering so that agents only see tools their users are permitted to invoke, and immutable, OpenTelemetry-compatible audit logs. Pre- and post-tool-call hooks let compliance teams drop in custom variables (workflow state, time windows, request volume, session context) that the runtime treats as first-class enforcement primitives. Arcade's SOC 2 Type 2 certification validates these controls through an independent audit.
Delegated Authorization: Arcade uses a multi-user, post-prompt authorization model with just-in-time permissions mapping. The runtime evaluates the exact intersection of what the agent and user are allowed to do, per action, at execution time. Tokens are managed through Arcade's automated token vault, keeping credentials isolated from the underlying language model and removing prompt injection as a direct credential-theft vector. Destructive actions can be routed through out-of-band approvals before they execute.
Intent-Level Reliability: Arcade bypasses raw API wrappers by offering a catalog of 8,000+ agent-optimized MCP tools with constrained schemas that map reliably to API calls, reducing hallucination surface area. These tools select only the fields an agent requests and flatten responses into key-value pairs, which sharply reduces token consumption. In Arcade's head-to-head Attio CRM benchmark, Composio returned roughly 100x more response tokens than Arcade across identical queries (747,083 vs. 7,426), a gap that can reach six figures in monthly token spend at enterprise scale. Built-in parallelized execution, intelligent retries with developer-defined context, and automatic failover sit alongside the catalog.

Pros: What you gain with Arcade

Arcade delivers production-grade security. Teams pass stringent enterprise security reviews by using vaulted tokens, just-in-time user consent flows, and out-of-band approvals for destructive actions, backed by SOC 2 Type 2 certification. Arcade can be deployed in the cloud, a customer VPC, on-prem, or fully air-gapped environments, which matters for regulated industries and teams running sensitive or legacy systems where the "I do not want to personally be on the hook for this" risk is highest.

Arcade also eliminates configuration sprawl. Organizations manage all custom, third-party, and built-in tools from one centralized control plane with strict versioning. Since Arcade uses specialized intent-level tools, you'll see lower token usage and fewer parameter hallucinations compared to basic API wrappers.

Cons: What you give up with Arcade

Arcade is purpose-built for multi-user production. Teams in the earliest single-user prototyping phase, where per-user authorization, governance, and audit are not yet requirements, may not need the full runtime on day one. In practice, most teams that reach Arcade start exactly there and switch once the agent meets real users.

Pricing: How Arcade is priced

Arcade uses a platform fee plus usage-based pricing on tool calls and auth events, designed for predictable scaling at enterprise volumes.

Migration considerations

For an existing Composio-backed agent, the main work is replacing Composio tool calls with Arcade's agent-optimized tools, connecting existing OAuth and IdP providers, and validating that each workflow preserves the right user consent, tool permissions, and audit trail. Because Arcade exposes a standard MCP runtime endpoint, teams can keep their orchestration layer while moving tool execution into Arcade.

AWS AgentCore: Composio alternative for AWS-native agent stacks

Best for

Enterprise engineering teams fully entrenched in the AWS ecosystem who require tight integration with the existing infrastructure and strict compliance models, and have the expertise and resources to manage the integrations themselves.

Overview

Amazon Bedrock AgentCore is a platform for building, connecting, and optimizing AI agents. Unlike standalone third-party tools, it connects agents to enterprise systems via MCP servers, internal APIs, and Lambda functions, leveraging the massive scale of AWS's broader security, identity, and networking infrastructure.

AWS AgentCore vs. Composio: Key differences

Deep AWS native integration: AgentCore inherits AWS's massive enterprise compliance halo. That gives teams access to SOC 2-, ISO-, and HIPAA-certified infrastructure, alongside resilient, multi-region availability.
AWS identity and security controls: AgentCore can use AWS Identity and Access Management (IAM) for access policies, AWS Security Token Service (STS) for short-lived role assumption, and Key Management Service (KMS) for secret encryption during tool execution. These controls are powerful, but teams must configure and connect them across the agent execution path.
AWS ecosystem evaluation tooling: AWS offers experimentation and evaluation tooling around Bedrock agent workflows, so teams can test agent variations and tool-call reliability within the AWS environment. These capabilities still require setup across the surrounding AWS services.

Pros: What you gain with AWS AgentCore

You get compliance and alignment with AWS architectures. If your organization already mandates strict VPC boundaries, private subnets, and granular IAM roles, AgentCore fits into that secure paradigm.

Combine it with AWS CloudWatch and X-Ray, and you get debugging and trace correlation for every agent action across your cloud footprint.

Cons: What you give up with AWS AgentCore

The primary tradeoff is operational assembly and management overhead. Building a secure agent environment in AgentCore requires configuring and stitching together multiple AWS services, such as IAM, CloudWatch, X-Ray, Step Functions, and Lambda, whereas a purpose-built runtime such as Arcade bundles per-user authorization, lifecycle governance, OpenTelemetry-compatible audit, and execution into a single layer that maps cleanly across clouds.

This assembly burden introduces hidden logging and compute costs that are difficult to forecast. It also creates significant ecosystem lock-in. Once you build your agent architecture tightly around AWS IAM and Bedrock routing, you lose the portability that independent, cloud-agnostic runtimes provide.

Pricing: How AWS AgentCore is priced

AgentCore relies on a complex, usage-based AWS pricing model spanning multiple underlying compute and logging services. Forecasting total costs accurately is difficult.

Migration considerations

Moving a Composio-backed agent to AWS AgentCore requires more AWS-specific implementation work. Teams need to translate integration logic into Lambda functions, AWS-hosted MCP servers, or other AWS services, then configure IAM, workload identities, logging, and tracing around those execution paths.

Merge: Composio alternative for unified APIs and B2B data sync

Best for

B2B SaaS companies focused on data-centric integration and normalizing data across hundreds of third-party platforms, like HRIS, ATS, and CRM systems.

Overview

Merge originally established itself as a leading Unified API provider, and has recently expanded to include an Agent Handler and Gateway. It connects AI tools to enterprise applications not just by routing raw requests, but by normalizing business data into standard, predictable schemas.

Merge vs. Composio: Key differences

Normalized Data Models: Instead of connecting raw APIs and returning varied JSON structures, Merge standardizes data across entire software categories. All ticket data looks the same whether it comes from Jira, Zendesk, or Salesforce. This predictable schema benefits both Retrieval-Augmented Generation (RAG) and massive B2B data-syncing operations.
Unified API focus: Merge has a stronger legacy in rigorous B2B data synchronization compared to Composio's primary focus on raw, varied action execution.

Pros: What you gain with Merge

Engineering teams get built-in data syncing capabilities that form the bedrock of contextual, data-heavy RAG pipelines.

Merge also brings a mature compliance posture for data-sync workloads, including SOC 2 Type II, HIPAA support, and GDPR alignment. Its dedicated Security Gateway can scan and redact Personally Identifiable Information (PII) before data ever reaches your underlying language models, though this is also achievable in runtime platforms like Arcade via pre- and post-tool-call hooks.

Cons: What you give up with Merge

Merge is strongest when the agent needs standardized data access across categories like HRIS, ATS, ticketing, CRM, and accounting. Compared with Composio, it is less of a broad action-execution layer for quickly calling many vendor APIs. Merge also comes from the Unified API and B2B data-sync category, so its AI capabilities are layered onto a data integration foundation rather than designed first as an agent execution runtime. Teams that need agents to perform varied actions across many apps should confirm the required actions are supported by Merge's normalized models and Agent Handler, rather than assuming the breadth of a tool-wrapper catalog.

Pricing: How Merge is priced

Merge operates on a premium B2B SaaS pricing model focused on platform usage and the total volume of active linked accounts.

Migration considerations

Moving from Composio to Merge is less about swapping an agent runtime and more about changing the integration layer. Teams need to map existing tool calls to Merge's normalized data models and adjust agent code that expects raw vendor-specific API responses.

Natoma: Composio alternative for shadow AI discovery

Best for

IT and Security teams that need to discover and govern unmanaged AI clients and rogue MCP servers across enterprise networks.

Overview

Natoma is an enterprise MCP gateway focused on discovering and governing AI tool access across fragmented clients like Claude Code, Cursor, ChatGPT, and custom internal agents. Its strongest fit is shadow AI discovery: finding unmanaged AI clients and rogue MCP servers, then applying identity-aware access controls so security teams can see and govern how agents connect to enterprise systems.

Snowflake announced a definitive agreement to acquire Natoma on May 27, 2026. Buyers should validate the standalone product roadmap, support model, and integration coverage before standardizing on it.

Natoma vs. Composio: Key differences

Policy at the tool layer: Natoma emphasizes Attribute-Based Access Control (ABAC) and bundles toolkits into strict, role-based Profiles. It focuses on rigorous policy enforcement and the integration of AWS Cedar policies rather than on basic API routing.
Shadow AI discovery: Unlike Composio, Natoma offers dedicated network-level tools to discover and govern unmanaged AI clients and rogue shadow MCP servers across an enterprise network.

Pros: What you gain with Natoma

Organizations get high visibility into exactly which AI clients are active in their enterprise environments.

You can secure existing AI coding assistants and internal agent builds without changing the underlying language models or orchestration frameworks that those tools rely on. Extensive SIEM and EDR integrations ensure your security operations center stays fully informed.

Cons: What you give up with Natoma

Natoma focuses primarily on authorization and identity mapping. Like other governance-focused overlays, it doesn't include a catalog of pre-built, agent-optimized tools.

For built-in execution-reliability features like automatic failover and intelligent retries that stabilize fragile API connections, teams typically pair it with a dedicated runtime.

Pricing: How Natoma is priced

Natoma uses a custom Enterprise SaaS pricing model requiring organizations to contact their sales team for tiered seat licensing.

Migration considerations

Moving from Composio to Natoma depends on whether the goal is replacing tool execution or adding governance over existing AI clients and MCP servers. Teams should validate supported integrations, policy coverage, and the product roadmap following Snowflake's announced intent to acquire Natoma.

Conclusion: Choosing the best Composio alternative for production

Governance determines whether you can safely scale AI agents beyond a single user, and the foundational layer you pick makes that governance enforceable rather than aspirational.

Choose Arcade for a full multi-user production runtime with built-in governance and agent-optimized tools. Choose AWS AgentCore for strict AWS-native integrations. Go for Merge if your priority is B2B data syncing and normalized schemas. Consider Natoma for shadow AI discovery across enterprise networks.

If you're transitioning from a prototype to a secure, multi-user production environment, explore Arcade.dev to see how a unified MCP runtime natively solves authorization and governance.

FAQ

What is Composio best for?

Composio works best for rapid prototyping and early-stage agents where you want quick access to a large catalog of integrations and don't need strict multi-user authorization, governance, and production-level auditability.

Is Composio production-ready for multi-user AI agents?

Composio can support limited production scenarios, but teams typically outgrow it when they need per-user delegated authorization, blast-radius controls, and standardized observability and audit logs across many users and tools.

What should I look for in a production-ready alternative to Composio?

Prioritize per-user delegated authorization with tokens kept out of model context, governance controls for tool registration and policy enforcement, and audit logs and traceability (ideally OpenTelemetry) for every tool call.

Which Composio alternative is best for secure, multi-user production agents?

Arcade is the best choice for teams that need a unified MCP runtime with just-in-time authorization and centralized governance for multi-user production deployments.

When should I choose Arcade instead of Composio?

Choose Arcade when you need a unified MCP runtime for multi-user production agents with per-user delegated authorization, centralized governance, and agent-optimized tools in a single execution layer. It fits teams moving beyond prototyping that require vaulted credentials, immutable audit logs, and flexible deployment (cloud, VPC, or air-gapped).

When should I choose AWS AgentCore instead of a standalone runtime?

Choose AWS AgentCore when you're all-in on AWS (IAM, VPC, CloudWatch/X-Ray) and have the engineering resourcing and expertise to assemble and manage multiple AWS services to meet your security, compliance, and operational requirements.

When is Merge a better choice than Composio?

Choose Merge when your primary need is B2B data integration, especially normalized schemas and data sync across categories like HRIS, ATS, and CRM, rather than governed, multi-step action execution for many end users.

What is MCP (Model Context Protocol), and why does it matter for these tools?

MCP is a standard way for agents to call tools and servers. It matters because a production setup needs consistent authorization, governance, and observability around those tool calls, especially when many users share the same agent system.

What does "delegated authorization" mean for AI agents?

Delegated authorization means the agent performs actions on behalf of a specific end user. Each tool call is evaluated against both the agent's permissions and the user's permissions at runtime, reducing the risk of shared credentials and oversized access.

Best Natoma Alternatives in 2026 After the Snowflake Acquisition

Manveer Chawla — Thu, 11 Jun 2026 19:20:22 +0000

On May 27, 2026, Snowflake announced its intent to acquire Natoma. This validates both Natoma and the enterprise Model Context Protocol governance category. Still, the acquisition prompts engineering leaders, AI platform teams, and security buyers to reassess their multi-user agent infrastructure.

When evaluating MCP runtime alternatives, you're facing a real architectural decision of whether to stay tethered to an ecosystem-native gateway or adopt an independent or vendor-neutral MCP runtime.

Key takeaways

Choose Arcade.dev if you need an independent MCP runtime with secure agent authorization via On-Behalf-Of (OBO), agent-optimized tools, agent lifecycle governance, and flexible deployment (cloud, VPC, and air-gapped).
Choose AWS AgentCore if you're all-in on AWS/Bedrock and accept AWS-only constraints.
Choose WorkOS if your main gap is enterprise SSO/directory sync (identity), not agent execution.
Choose Merge if your main need is normalized integrations and bulk data sync, not multi-step agent workflows.

Platform	Key differentiator	Deployment flexibility
Arcade	Unified auth, tools, and governance runtime	Cloud, VPC, Air-gapped
AWS AgentCore	Native AWS IAM and Bedrock integration	AWS-only
WorkOS	Developer-first human identity auth APIs	Cloud
Merge	Unified API data normalization	Cloud

What the Snowflake acquisition means for Natoma users

Snowflake's acquisition of Natoma signals that strict AI governance is now a core enterprise requirement. Natoma is a fully managed enterprise MCP gateway that enforces Cedar-based attribute access control (ABAC), shadow-AI discovery, SSO and SCIM, and SIEM/EDR integrations.

Enterprises currently discover an average of 225 unmanaged shadow AI instances per organization. That makes centralized governance an immediate security priority. But this acquisition shifts the product roadmap toward native Snowflake Intelligence and Cortex ecosystems.

Under the agreement, Snowflake will build Natoma into its governance and identity layer for AI agents and MCP tool access, using it as the centralized gateway enforcing identity, policy, and audit at the tool-call level.

This raises real questions for current and prospective Natoma users. Will Natoma remain available and supported as a standalone product, or be folded into Snowflake's stack? Will the roadmap orient toward Snowflake Intelligence, Cortex, and the broader Snowflake ecosystem?

When Natoma still makes sense after the acquisition

Natoma makes sense for enterprises already embedded in the Snowflake ecosystem, with internal role-based access control (RBAC) as their primary governance layer. It also suits platform teams that prioritize native integration with Cortex tools such as search and analyst services.

Enterprise buyers who prefer their agent governance bundled with their core data warehouse procurement will find the combined offering a natural fit.

How to evaluate Natoma alternatives in 2026

An enterprise agent setup rests on three core pillars: agent authorization, agent-optimized tool reliability, and agent lifecycle governance. Any production runtime must solve all three simultaneously, plus deployment flexibility as a cross-cutting requirement.

How agent authorization and OBO execution works

Teams either give agents their own identity with broad credentials, or they inherit the user's full access. Both approaches create an excessive blast radius. Any failure, whether from misconfiguration, hallucinated tool calls, or adversarial input, propagates across every connected system.

The runtime must enforce the exact intersection of agent and user permissions for each action, evaluating both what the agent is allowed to do and what the user is allowed to do at execution time. This process requires managing the complete OAuth token lifecycle isolated from the language model itself.

Make sure the system supports pre- and post-call policy hooks to dynamically evaluate granular access requests at runtime.

How to evaluate agent-optimized tool reliability

Most MCP servers wrap APIs designed for structured inputs, such as recipient_user_id or file_id, not for natural language like "send this to Finance." The root cause is that tool schemas are written for machine consumers rather than language models. Verbose schemas bloat the context window, and mismatched parameter names cause the model to hallucinate values.

Evaluate whether the runtime provides curated tools optimized for natural-language intent rather than rigid machine interfaces. The runtime execution layer must also support intelligent retries, automatic schema validation, and automated failover capabilities.

What agent lifecycle governance should include

Every tool execution requires immutable, OpenTelemetry-compatible audit logs tracing the agent action per user per connected service.

The runtime must enforce visibility filtering so that agents discover only the specific, approved tools permitted by the active human user session. It should also provide version control for safe upgrades and a shared registry with team-level access controls to prevent tool sprawl across projects.

How to assess deployment flexibility and vendor independence

Enterprise architecture demands deployment versatility. Can the runtime operate as a vendor-neutral layer that runs across any major cloud provider? Can you self-host it on a private network or securely deploy it in air-gapped environments?

Systems tied to a broader data warehouse or cloud provider ecosystem will dictate your downstream infrastructure choices and limit cross-platform integrations.

In-depth reviews of the best Natoma alternatives

Alternative 1: Arcade (independent action runtime)

Best for

Enterprise engineering teams needing a complete, vendor-neutral action runtime for multi-user production agents. Security-conscious organizations requiring per-user delegated authorization and air-gapped deployments.

Overview

Arcade.dev is an independent action runtime that unifies agent authorization, agent-optimized tools, and continuous lifecycle governance into a single execution layer.

While standalone gateways or specialized registries often focus primarily on routing traffic, Arcade handles the direct, parallelized execution of a catalog of over 8,000 agent-optimized MCP tools. It enforces access controls at the intersection of agent and user permissions, ensuring secure downstream actions.

Key differentiators vs. Natoma

Arcade is a full actions runtime, not only a routing gateway. It directly executes and manages the runtime reliability of the tools, whereas Natoma routes requests to your existing deployed servers.

It maintains platform independence through cloud-agnostic, flexible deployment models and provides an extensive, curated catalog of agent-optimized tools built for language-model intent. This often reduces parameter-hallucination issues found in standard interface wrappers.

Arcade co-authored the MCP auth specification alongside Microsoft and Okta/Auth0, and authored the URL Elicitation specification with Anthropic. This standards-level involvement shapes how the protocol itself handles identity and consent.

Pros (what you gain)

You get a centralized control plane for authorization, reliable tool execution, and continuous governance without stitching together multiple fragmented point solutions.

Arcade enforces a permission-intersection model in which every action is authorized at the strict intersection of the agent's permissions and the specific human user's permissions. This two-identity approach isolates credentials from the language model, preventing privilege escalation.

The runtime acquires credentials only when an action is required, requesting minimum OAuth permissions scoped to that specific tool. For irreversible actions, out-of-band approvals enforce a mandatory human approval step. You also get detailed, OpenTelemetry-compatible audit logging for every agent action executed across the runtime. Arcade holds SOC 2 Type II certification, with coverage that extends from the underlying cloud infrastructure through to every tool call an agent executes.

Cons (what you give up)

You give up the likely future advantage of Natoma being built into Snowflake Intelligence, Cortex, and Snowflake-native governance workflows. Snowflake governance policies can still be applied to workflows running through Arcade, but not natively by default. You also lose the administrative convenience of bundled procurement and unified billing if your company already purchases significant Snowflake infrastructure.

Deployment and flexibility

Arcade provides maximum environmental adaptability. It supports cloud deployments, self-hosted deployments within your own virtual private cloud, and air-gapped environments designed for regulated industries. Arcade is also agnostic to models, agent frameworks, and clients, so your team can use any combination of LLM providers and orchestration tools without runtime constraints. Post-acquisition, Natoma will likely become more opinionated toward Snowflake-supported models and tooling.

Arcade brokers authorization protocols with your existing identity providers, including Okta and Microsoft Entra, enforcing existing policies rather than requiring duplication.

Alternative 2: WorkOS (enterprise identity and SSO)

Best for

SaaS application developers whose primary roadblock is managing human user identity synchronization rather than handling agent-specific tool execution.

Overview

WorkOS is a developer platform with APIs designed to make applications enterprise-ready. It offers AuthKit, single sign-on, automated directory synchronization, and standard role-based access control.

It is a foundational identity building block, not a full AI agent platform.

Key differentiators vs. Natoma

WorkOS maintains a pure focus on identity, providing robust infrastructure for human identity management.

It delivers a great developer experience through comprehensive documentation, software development kits, and integrated drop-in interface components that accelerate time-to-market for standard authentication flows.

Pros (what you gain)

You get the fastest available path to implementing enterprise single sign-on and automated directory synchronization. WorkOS provides an off-the-shelf administrative portal that empowers enterprise buyers to manage their own user provisioning.

Cons (what you give up)

WorkOS has no native understanding of AI agents, the Model Context Protocol (MCP), or tool-calling security primitives.

Your engineering team must build the agent authorization layer from scratch, mapping WorkOS identities to individual agent scope boundaries.

Alternative 3: AWS AgentCore (AWS-native agent platform)

Best for

Large enterprises committed to Amazon Web Services as their exclusive cloud provider, seeking to build native AI agents directly within Amazon Bedrock.

Overview

AgentCore is the dedicated agent platform layer within Amazon Bedrock. It connects foundation models to enterprise systems while enforcing access policies and tracing agent workflows.

It delivers a secure, scalable environment backed by existing Amazon identity and access management infrastructure and automated reasoning primitives.

Key differentiators vs. Natoma

AgentCore offers cloud-native integration with deep, structural ties to AWS-native serverless functions, isolated virtual private clouds, and existing identity infrastructure.

It also includes built-in evaluations, providing robust native tooling for experimenting with and evaluating agent behavior under high-volume production traffic.

Pros (what you gain)

You achieve strong compliance and security inheritance if your critical workloads already operate within the Amazon ecosystem.

AgentCore provides secure connectivity to other AWS-hosted services, including storage buckets, relational databases, and internal private APIs, without routing sensitive traffic over the public internet.

Cons (what you give up)

You sacrifice vendor neutrality. AgentCore locks your agent architecture into the Amazon ecosystem and Bedrock execution paradigms.

This architecture is difficult to deploy across multi-cloud environments or hybrid on-premise setups outside the prescribed footprint. And requires a heavy engineering burden to manage the separate services.

Alternative 4: Merge (unified API for data sync)

Best for

Engineering teams building products requiring standardized data synchronization across common software categories rather than executing multi-step agent operations.

Overview

Merge is a unified API for normalized business data, providing a single integration point for hundreds of third-party tools. It's the most narrowly scoped option in this list, but the right fit for data-heavy use cases. Their agent handler product allows large language models to query and push structured data through these normalized interfaces.

Key differentiators vs. Natoma

Merge excels at data normalization, translating disparate external interfaces into a unified data schema. It focuses on aggregating standard integration layers rather than managing protocol-level execution governance for custom-deployed servers.

Pros (what you gain)

You get access to hundreds of standard external platforms without having to read individual technical documentation. Merge also automatically handles authentication for end-user application integrations.

Cons (what you give up)

Merge offers less granular control over per-user delegated execution policies, which are required for enterprise protocol governance.

Its integrations optimize for bulk data synchronization rather than natural-language intent, increasing the risk of token bloat during complex reasoning loops.

Conclusion: Choosing the right Natoma alternative after the acquisition

The Snowflake acquisition of Natoma pushes engineering leaders to evaluate whether their agent infrastructure solves authorization, tool reliability, and governance together, while maintaining the deployment flexibility their architecture demands.

The best alternative depends on your architectural philosophy and whether you stay tethered to a Snowflake-native gateway, piece together governance tools, or adopt an independent runtime. These choices are not mutually exclusive. A two-layer approach keeps data-proximate agents operating natively inside Snowflake for internally governed analytics while deploying an external, vendor-neutral runtime such as Arcade to handle cross-cloud tool execution.

Prioritize platforms that solve agent authorization, agent-optimized tool reliability, and lifecycle governance simultaneously. Addressing only one or two of these pillars will create gaps that slow your production rollout.

Book a demo with the Arcade.dev team today to see the permission intersection model execute in a live production environment.

Frequently Asked Questions

What changed for Natoma users after the Snowflake acquisition?

Natoma's roadmap will likely align more tightly with Snowflake's ecosystem, which can reduce cross-cloud portability. Teams should reassess whether they want Snowflake-native governance or an independent runtime for multi-cloud agent execution.

Is Natoma still a good choice after the acquisition?

Yes, if your agents primarily run in Snowflake and you want governance tightly coupled to Snowflake RBAC and Cortex workflows. If you need multi-cloud execution or non-Snowflake toolchains, an independent layer may be a better fit.

Why choose Arcade as a Natoma alternative?

Arcade is a vendor-neutral action runtime that combines per-user delegated authorization, a catalog of over 8,000 agent-optimized tools, and lifecycle governance in a single layer. It supports cloud, VPC, and air-gapped deployments, and is agnostic to models, frameworks, and clients. For teams that need cross-cloud portability and production-grade agent infrastructure without ecosystem lock-in, Arcade covers authorization, execution, and audit without requiring additional point solutions.

What's the difference between an MCP gateway and an action runtime?

A gateway routes requests and enforces access policies for tool calls. A runtime executes tools, enforces policy, and audits, handling reliability (retries, failover, validation), delegated auth flows, and telemetry during execution. For production multi-user deployments, a runtime is architecturally superior because it owns the full execution lifecycle rather than just the routing layer.

When should I choose an independent Natoma alternative instead of a Snowflake-native option?

Choose an independent option when you need multi-cloud portability, want to avoid data-cloud lock-in, or must support VPC, on-prem, and air-gapped deployments. An independent option also fits better when agents need to call many external SaaS tools outside Snowflake.

What is per-user delegated authorization and why does it matter for agents?

Per-user delegated authorization means each tool action is authorized using the intersection of the end user's permissions and the agent's allowed scope. This approach reduces the blast radius compared with shared service accounts and improves auditability for enterprise security reviews.

Which alternative is best if I already have an agent execution stack and only need governance?

A governance overlay fits best. Focus on registry, threat detection, and audit controls layered on top of your existing runtime rather than replacing execution.

Which option is best if my company is all-in on AWS?

If your agents run on Bedrock and you rely on AWS IAM and native AWS networking controls, an AWS-native agent platform is the most straightforward choice. Keep in mind that it comes with a trade-off on multi-cloud portability.

What should I look for in an enterprise action runtime evaluation?

Prioritize per-user delegated authorization, agent-optimized tool reliability, centralized audit and governance, and deployment flexibility (cloud, VPC, and air-gapped). These criteria directly determine whether your agent infrastructure can scale securely across users, tools, and environments.

AI agent governance and runtime compliance framework for CISOs

Manveer Chawla — Tue, 09 Jun 2026 20:50:33 +0000

AI agents are now in production across healthcare, financial services, and critical SaaS systems. They mutate data, trigger workflows, and call external APIs on behalf of real users. These are autonomous actors, not the read-only recommendation engines that security teams already know how to govern. The business is shipping them, and saying no won't pause that. The CISO question is no longer whether to allow agents into production. It's how to say yes safely, fast enough that security isn't the reason the business can't ship.

The honest answer is that traditional enterprise security models don't survive contact with this workload. Governance-as-logging assembles evidence after the breach. Governance-as-spreadsheet drifts the moment code ships. Governance-as-policy-PDF answers an auditor's question about intent, not the runtime question of what an agent actually did at 03:14 on a Tuesday. None of these are governance. They are documentation. And building bespoke security infrastructure to close the gap is the same mistake in engineering form: months of plumbing while the actual governance gap stays open.

Governance is a runtime contract enforced at the exact millisecond of every tool call, paired with an immutable audit trail that an auditor can replay end-to-end. Every agent action must be attributable, policy-governed, immutably audit-replayable, and revocable across user, agent, tenant, and task. Enforced at runtime, provable after the fact.

What follows is a CISO-grade rubric organized around the four concerns CISOs surface in the field, with the six runtime capabilities that address them. Hand it to your AI/ML team. Hand it to the security architects and IAM leads pulled into the project. Both audiences should be able to verify against it before any agent reaches production.

TL;DR

A CISO-grade rubric for AI agent governance organizes around the four concerns every CISO surfaces in the field. The 6 capabilities that address them sit beneath each:

1. Identity and attribution: the service account problem.

Capability 1: Agent and tool registry under version control
Capability 2: Delegated agent authorization with scoped, just-in-time credentials

2. Active prevention at the tool call: saying yes safely.

Capability 3: Centralized policy enforcement at runtime
Capability 4: Action-layer guardrails (parameter validation, rate limits, output filtering, prompt injection interception, step-up authorization for high-impact actions)

3. Observability your SIEM can use: after the fact.

Capability 5: Immutable, replayable audit trail

4. Continuous audit-readiness: the verification rubric itself.

Capability 6: Compliance attestation at the agent and action layer

No patchwork of SIEMs, policy engines, GRC platforms, identity providers, or MCP gateways answers all four concerns end-to-end. A unified MCP runtime does.

Mapping AI agent governance to NIST, ISO/IEC 42001, and the EU AI Act

The policy layer of enterprise AI governance is defined by a small set of converging international frameworks: ISO/IEC 42001, the NIST AI Risk Management Framework, ISO/IEC 42005, the EU AI Act, and the CSA/NIST Agentic Profile, which extends them for autonomous systems. Technical controls need to anchor here.

ISO/IEC 42001 sets the foundational requirements for an enterprise AI Management System. It demands continuous system monitoring, strict event logging, and traceable data provenance.

The NIST AI Risk Management Framework, extended by the GenAI Profile, provides a risk operating model that emphasizes continuous testing, evaluation, verification, and validation throughout the agent lifecycle.

ISO/IEC 42005 builds on these by mandating rigorous AI system impact assessments. You'll need documented, immutable evidence of risk treatments and architectural safeguards.

The EU AI Act is what's actually driving urgency. Its phased timeline doesn't just turn best practices into legally binding requirements. It turns the gap between policy and runtime into a legal liability that the security team is responsible for.

Prohibited practices and AI literacy obligations became applicable on February 2, 2025. Strict obligations for General Purpose AI providers took effect on August 2, 2025, requiring detailed technical documentation and systemic risk monitoring. By August 2, 2026, the broad applicability phase requires that every high-risk AI system implement automatic, immutable logging and strict human oversight.

These are not deadlines on the security team's roadmap. They are legal exposure that attaches whenever an agent in a regulated workload acts without governance evidence the runtime can produce on demand. "We're planning to address this" is not a defensible position when an auditor asks why the agent that processed yesterday's PHI access can't be replayed.

The Cloud Security Alliance and NIST Agentic Profile bridge the gap between broad regulatory mandates and technical implementation. This profile explicitly extends the NIST AI RMF to address threats specific to autonomous systems.

It introduces autonomy-tier classification, tool-use risk modeling, and continuous delegation-chain monitoring, giving you the vocabulary to assess multi-agent interactions.

Standards define what. A runtime defines how.

These standards are rigorous about the policy layer. They are silent about execution. NIST AI RMF tells you to monitor; it doesn't intercept a prompt injection. ISO/IEC 42001 tells you to log; it doesn't block an undesired API call. The EU AI Act requires human oversight; it doesn't mandate cryptographic approval for a specific tool-call payload.

Closing the gap between legal requirement and technical reality is a runtime problem, not a documentation problem. The control point is the action layer (the moment an agent tries to call a tool), not the infrastructure boundary, the network perimeter, or a policy document. Runtime enforcement is what turns the standards into active security controls at the place the action actually happens.

Classifying AI agent autonomy tiers (1–4)

Governance strictness has to scale with agent autonomy. A structured classification gives you the vocabulary to do that.

The CSA / NIST AI RMF Agentic Profile defines a four-tier classification aligned with the operational characteristics that drive governance requirements. Data sensitivity, action reversibility, and potential legal or customer impact should dictate the maximum acceptable tier for any workload.

Agent autonomy-tier classification (CSA / NIST Agentic Profile)

Autonomy tier	Description	Governance requirement
Tier 1: fully supervised	Agent generates outputs that require human approval before any action is taken.	Governance structures equivalent to non-agentic generative AI.
Tier 2: constrained autonomy	Agent executes pre-approved action types within a predefined scope. Actions outside that scope require human escalation.	Formal action scope documentation, approval authority delegation policies, defined escalation triggers, action-consequence mapping.
Tier 3: broad autonomy within boundaries	Agent operates with broad autonomy within a defined operational boundary. Bounded by hard constraints on resource access, action scope, and time horizon, and subject to continuous monitoring.	Continuous behavioral monitoring, defined response playbooks, real-time agent registries integrated with IAM.
Tier 4: full autonomy within constrained environment	Agent operates at full autonomy within a constrained environment, capable of spawning sub-agents, acquiring new tool capabilities, and executing long-horizon plans with minimal human interaction.	All Tier 3 requirements plus formal oversight board review at defined intervals.

Tier 1 is the starting point for high-stakes workflows where you can't easily reverse an action; every output is gated by human approval before it executes. Tier 2 is the practical default for most current enterprise deployments. Agents act autonomously within pre-approved scopes and escalate anything outside them. Tier 3 introduces broad autonomy within a defined operational boundary and is appropriate where continuous monitoring and well-bounded behavioral envelopes are in place. Tier 4 introduces sub-agent orchestration and long-horizon planning. It requires formal oversight board review and is rarely appropriate outside controlled research environments or specialized workloads.

Action-layer risk taxonomy for AI agents (tool calls, identity, and delegation)

Relying on generic vulnerability lists, such as the OWASP Top 10, isn't enough to secure autonomous systems.

Prompt injections and training data poisoning are real concerns. But when you deploy agents, focus on the action layer. When an AI system can mutate data, trigger workflows, and interact with external APIs, the threat model changes.

Once an agent can act, the threat model collapses into a set of operational questions: which tool, with which parameters, on whose behalf, under which policy version, with what approval, and for how long that authority holds. The last one, time-bounded authority, is the dimension most often missed. A token issued for a session must expire when the session ends, not linger for hours or days as a residual credential that outlives the workflow that produced it. Just-in-time issuance and tight TTLs are part of the threat model, not part of the infrastructure details.

An action-layer risk taxonomy maps specific agentic threats directly to architectural mitigations in the runtime, moving security teams from theoretical vulnerabilities to deterministic system design.

Threat-to-mitigation mapping for tool calls

Action-layer threat-to-mitigation mapping

Threat vector	Description	Primary mitigation (from 6-capability framework)
Tool-call hijacking	Malicious input manipulates the agent into calling a tool with malicious or manipulated parameters.	Capability 4: action-layer guardrails (parameter validation)
Delegated prompt injection	An agent is compromised by malicious data it retrieves from an external source, leading to undesired actions within its authorized scope.	Capability 2: delegated agent authorization (scoped credentials limit blast radius)
Credential exfiltration	An agent with overly broad permissions leaks or misuses sensitive credentials to which it has access.	Capability 2: delegated agent authorization (per-agent identity, rapid revocation)
Shadow tool execution	Developers connect unauthorized tools or external APIs to an agent without centralized security oversight.	Capability 1: agent and tool registry under version control
Unattributable automation	An agent executes a destructive action, but security teams cannot definitively prove which user or policy authorized it.	Capability 5: immutable, replayable audit trail
Context window poisoning	Sensitive information reaches the agent's context when it shouldn't: secrets or PII in tool outputs, retrieved data, or memory shared across user sessions.	Capability 4: action-layer guardrails (output filtering and redaction)

Categorizing risks by tool invocation and identity lets security leaders build active defenses that intercept malicious intent before it reaches the resource server.

This taxonomy shows that defending an agentic system requires structural controls at the exact moment a tool is called. Legacy approaches that rely solely on model-level alignment or generic network firewalls don't cut it.

Service accounts: the universal failure mode

Every CISO has been burned by shared service accounts. They break attribution. They block revocation. They're how a single misconfigured credential ends up holding access to half the data lake six months after the engineer who provisioned it left the company. Every agent project that ships on a service account repeats that mistake faster.

The failure modes are predictable. Give the agent its own identity with broad permissions, and any user behind that agent (including an intern) can bypass their own access controls. Lock those permissions down to be safe, and the agent can't do anything useful, which is how most agent projects stall before reaching production. Let the agent inherit the user's full permissions instead, and one prompt injection cascades through every system that user can touch. Three patterns, all breaking least privilege the moment an agent acts on behalf of more than one person.

The fix is not better service account hygiene. It's per-agent identity tied to the requesting user, scoped to the specific tool and action, acquired just-in-time, and revocable in isolation when that user is offboarded or compromised. This is the foundation every other governance capability rests on. The rest of the rubric assumes you've fixed this problem first.

The 6-capability rubric for AI agent governance at runtime

Neutralizing those risks requires an architecture that controls the full lifecycle of an agent action. Fragmented observability tools don't get you there. You need a unified MCP runtime that addresses all four CISO concerns through six specific capabilities.

This is the rubric a CISO hands to their AI/ML team to verify before any agent is deployed to production. Skipping any capability creates a gap that an auditor or attacker will find. Arcade.dev is the reference implementation.

The 6-capability rubric, organized by CISO concern

CISO concern	Capabilities
Identity and attribution: the service account problem	1. Agent and tool registry under version control 2. Delegated agent authorization with scoped, just-in-time credentials
Active prevention at the tool call: saying yes safely	3. Centralized policy enforcement at runtime 4. Action-layer guardrails (parameter validation, rate limits, output filtering, prompt injection interception, step-up authorization for high-impact actions)
Observability your SIEM can use: after the fact	5. Immutable, replayable audit trail
Continuous audit-readiness: the verification rubric itself	6. Compliance attestation at the agent and tool plane

Identity and attribution: the service account problem

If service accounts are the universal failure mode, this concern is the resolution. The registry establishes which agents and tools exist; delegated authorization with scoped credentials binds every action to the specific user, tool, and scope that authorized it.

Capability 1: Agent and tool registry under version control

A centralized agent and tool registry under strict version control is the foundation of any governance stack. The registry ensures agents can only discover and invoke vetted, approved tools, preventing shadow servers and duplicated effort across teams.

Every agent, every tool, and every connected MCP server should appear in the registry with their owners, purposes, model versions, autonomy tiers, and approved user populations. If you can't produce this list on demand, your governance posture is already drifting.

Capability 2: Delegated agent authorization with scoped, just-in-time credentials

Treating the agent as a distinct security principal is the architectural commitment that resolves the service account problem. That means per-agent identity, scoped credentials acquired just-in-time, and a credential scope bound to a specific user, tool, and action context. Identity answers who the agent is acting as. It does not, on its own, decide whether any particular request is safe to execute. That decision is the job of policy and enforcement, which come next.

Static API keys and shared service accounts break attribution and force you into all-or-nothing access decisions. Per-user, per-tool, just-in-time scoped tokens preserve least privilege without bottlenecking the agent. They also let security teams revoke access rapidly, isolating and ending a compromised agent's access instantly without impacting the broader system or shared service accounts.

Active prevention at the tool call: saying yes safely

Identity is necessary but not sufficient. The CISO needs assurance that even a correctly identified action will be blocked if it falls outside policy or requires human authorization. This concern is the active defense layer between the agent's intent and the resource server.

Capability 3: Centralized policy enforcement at runtime

Identity says what the agent's credentials permit. Policy says what the organization permits. Different decisions, same tool call.

An agent might have valid credentials to call the trade API (Cap 2) but still be blocked by a policy that requires human approval for trades over $10K, denies trades for restricted instruments, or restricts production changes outside business hours. Centralized policy-as-code, evaluated at every tool call, keeps these business rules consistent across teams.

Each decision records the exact policy version that authorized it. Without strict version pinning, you get silent compliance breaks when authorization rules are modified or rolled back. An auditor investigating an action three months after the fact must be able to replay the exact decision matrix that authorized it.

Capability 4: Action-layer guardrails

Identity tells you who the agent is. Policy tells you whether the action is allowed. Enforcement is what actually intercepts the request and either blocks it, modifies it, escalates it to a human, or otherwise transforms it. This is the layer that catches what identity and policy don't.

Pre-tool-call enforcement validates parameters and applies rate limits before the request reaches the resource server. Post-tool-call enforcement filters and redact outputs before they re-enter the agent's context window. This is where threats like tool-call hijacking and context window poisoning are caught at the exact moment a tool is called.

For irreversible or high-impact actions, enforcement should escalate the request out of band for human approval. The list of actions that trigger step-up authorization includes sending external email, modifying production data, executing code, transferring money, changing permissions, deleting records, and any decision affecting employment, credit, health, or legal status. Approval thresholds scale with the agent's autonomy tier, with stricter requirements at Tier 2 and above.

Relying on an agent to request permission in a chat interface is deeply flawed. Prompt injections can easily bypass these in-band checks. Process approvals out-of-band using standard protocols like JSON Web Signatures, cryptographically linking the human approval to the specific tool-call's hash and context. You're proving mathematically that a human authorized the exact payload the agent intends to send.

Observability your SIEM can use: after the fact

Even with prevention in place, incidents happen. The CISO comes in after the fact and needs an audit trail that their existing SIEM can query and replay, plus a detection layer that surfaces drift before it becomes the next incident.

Capability 5: Immutable, replayable audit trail

Governance requires tamper-proof, replayable evidence. You need immutable audit logs that support full replay of any agent interaction.

The minimum for attribution is five fields: Agent ID, User ID, Tool Call, Target System, and Timestamp. With those, you can prove who triggered which action, against which system, when. Full replay (which an auditor will ask for) requires the runtime to capture in addition to the above: Tenant, Task, Prompt Hash, Retrieved-Context References, Model Version, Policy Version, Decision, Approval, and Output Hash. All stored immutably.

This stream should follow the OpenTelemetry GenAI semantic conventions for export to an enterprise SIEM. Include key attributes, such as the operation name and requested model, to ensure interoperability.

Continuous audit-readiness: the verification rubric itself

The first three concerns address what the runtime does. This one addresses how you continuously prove it, without manual evidence assembly at audit time.

Capability 6: Compliance attestation at the agent and tool plane

Compliance attestation becomes native to the runtime. Because every action is authenticated, evaluated, and immutably logged, the system continuously generates the exact evidence required for SOC 2 Type II attestation at the agent and tool plane.

The same audit stream maps to ISO/IEC 42001 management-system controls, NIST AI RMF risk functions, ISO/IEC 42005 impact assessments, EU AI Act jurisdictional obligations, OWASP LLM Top 10 risk categories, and CSA Agentic Profile autonomy classification.

Governance requires an integrated runtime. Security treated as an afterthought in observability won't survive a regulator's first replay request.

Observability and SIEM integration

A runtime governance layer doesn't sit parallel to your security stack. It extends the SIEM, IAM, and DLP investments you've already made. The "I already have too many tools" objection is the right one for a CISO to lead with. The answer is that the runtime is not another tool. It's a layer that extends the ones you have into the place and enforces the policies where agents actually act. Flexible, not parallel.

Every agent action emits a structured event that follows the OpenTelemetry GenAI semantic conventions. Your security operations team queries these events in the same SIEM they already use (Datadog, Splunk, New Relic, Sumo Logic), using the same query syntax and dashboards. Identity flows from the same IdP that handles human login. Sensitive-payload detection is built on the same DLP that classifies your file shares. Nothing parallel; everything already familiar to the security team.

That distinction matters at audit time. Auditors don't ask for a binder of policies and screenshots. They query the audit log for the exact action, time window, or policy version they are interested in. A runtime that emits OpenTelemetry GenAI events lets your security operations team answer that query in the tools they already use to query everything else.

It also closes a compliance gap most programs hit at audit time. SOC 2 Type II or HIPAA attestation on the underlying cloud doesn't extend to the agent or tool plane unless the runtime layer is explicitly in scope. The agent plane is where the action actually happens: every tool call, every credential resolution, every policy decision. Compliance evidence has to follow the action, not stop at the infrastructure boundary. A governance runtime that ships SOC 2 Type II coverage at the agent and tool plane closes that gap directly.

10 AI agent governance anti-patterns that break runtime compliance

The right architecture matters, but knowing what breaks it matters as much. These ten traps are the patterns that render compliance efforts useless at audit time or during incident response.

1. AI governance by spreadsheet

Treating compliance as static documentation rather than a dynamic byproduct of runtime execution guarantees your security posture will drift from reality the moment code is deployed. Security controls must be expressed as code and enforced automatically, not verified manually through periodic spreadsheet updates.

2. Mutable application logs

Storing audit trails in standard, editable relational databases exposes you to massive compliance risks. Regulators and auditors demand immutable, replayable ledgers that prove an audit trail hasn't been tampered with to hide a rogue agent's actions or a developer's mistake.

3. Identity collapse and shadow MCP servers

Using a single shared API key for all users interacting with an agent breaks attribution. When a breach occurs, you can't tell which user triggered the action. Without centralized identity, shadow servers proliferate without oversight, creating invisible, ungoverned attack surfaces.

4. Credentials exposed to the agent

Storing API keys in the agent's system prompt, passing OAuth tokens as parameters the LLM can see, or letting credentials touch the agent's context window at any point creates a leak vector that no audit log can fix. A prompt injection that exfiltrates the credential is no different from one that exfiltrates user data. Credentials must be brokered by the runtime, scoped to the specific tool call, and never enter the agent's context.

5. In-band chat approvals

Delivering human-in-the-loop approval prompts within the agent's own chat interface creates a critical vulnerability. Adversarial prompt injections can forge these interfaces or trick the model into bypassing approval logic, authorizing destructive actions without genuine user consent.

6. Agent-side policy enforcement

Trusting the agent to enforce its own policy is like trusting a process to enforce its own permissions. LLMs can be prompt-injected to override their own guardrails, are non-deterministic about when they apply them, and produce no audit trail of what they decided or why. Policy enforcement must sit outside the agent, deterministic and auditable. The agent calls; the runtime decides.

7. Decentralized policy enforcement

When policy is enforced in multiple places (the agent's system prompt, ad-hoc rules in tool wrappers, separate policy engines per team), there's no single source of truth. Each enforcement point drifts. Each runs its own version. Auditors can't replay decisions consistently, because no one can prove which policy authorized an action three months ago. Centralized, version-pinned policy enforcement at runtime is the only way to keep agent behavior consistent across teams and to make it replayable across audits.

8. No autonomy-tier classification

Treating every agent identically, regardless of risk, forces overinvestment in low-stakes workloads while underprotecting high-impact ones. Without a clear tier classification mapped to data sensitivity and action reversibility, governance strictness can't scale with operational risk. Your security posture stays uniform when it should be proportional.

9. No revoke-and-rotate workflow

When an employee is offboarded or a credential is suspected to be compromised, you need to instantly rotate that user's tokens and revoke their delegated agent access without disrupting the rest of the user base. Architectures built on shared service accounts can't selectively revoke a single user's access, forcing security teams to choose between all-or-nothing breakage.

10. Compliance attestation that covers the cloud but not the agent

A SOC 2 or HIPAA certificate on your cloud provider is not a certificate on your agent fleet. Many programs only discover this gap mid-audit, when the auditor asks for evidence of agent actions, policy decisions, and approvals, and the answer is "our cloud is certified," which doesn't address the question. The agent plane needs its own attestation scope, or it will remain inadmissible no matter how many infrastructure-layer reports you produce.

Implementation patterns for AI agent governance in regulated industries

Those are the failure modes. The flip side is what running the framework actually looks like in production, across highly regulated environments with distinct autonomy requirements.

Healthcare (HIPAA): Tier 1 approval and PHI logging

Consider a Tier 1 clinical note-summarization agent deployed under HIPAA. The contractual layer (Business Associate Agreements between covered entities and processors) sits outside the runtime, but the obligations it creates live within it: strict data boundaries, demonstrable PHI access controls, and an audit trail that proves who accessed what, when, and under whose authority.

Before any summarized note is committed back to an electronic health record system, the framework requires human-in-the-loop approval. The runtime logs the physician's cryptographic signature alongside the exact prompt hash, the retrieved patient context, and the output hash. Every instance of access to Protected Health Information is immutably logged.

This pattern exercises three CISO concerns simultaneously: identity and attribution (the physician is the security principal), active prevention at the tool call (no PHI write without signed approval), and observability that the SIEM can use (every access is replayable). The contract still has to be signed, but the evidence to demonstrate it is generated automatically.

Financial services: Tier 2 bounded trade execution

Consider a Tier 2 bounded agent for compliant trade execution. The agent operates autonomously, but only within the pre-approved scope defined by policy-as-code.

A trader might ask the agent to rebalance a portfolio based on specific market signals. When the agent attempts the tool call to the trading API, the runtime intercepts the request and evaluates it against trading limits and risk parameters. The system records the exact policy version used to make the decision. If an auditor or regulator questions a trade later, you can replay the exact decision matrix, from the initial user prompt hash through the policy evaluation to the final output hash.

This pattern leans hardest on active prevention at the tool call (policy-as-code enforcement, version-pinned) and continuous audit-readiness (replayable decision matrices). Identity is the trader; attribution is the policy version. A regulator asking "why was this trade allowed?" has a deterministic answer.

Cross-industry: enterprise offboarding (Tier 1–2)

For large enterprises and public sector deployments running Tier 1 to Tier 2 agents, strict data residency and identity lifecycle management are most important.

Consider an employee undergoing an unexpected HR offboarding event. In a traditional setup with shared API keys, revoking access without breaking the agent for other users is nearly impossible. With an integrated runtime treating the agent as a distinct security principal tied to the user's identity, the offboarding event automatically triggers token rotation. The system revokes that specific user's delegated agent access instantly, ending in-flight operations and neutralizing the credential risk. No disruption to the rest of the organization.

This pattern is the clearest demonstration of identity and attribution doing their jobs. The service account problem is the failure mode that this prevents; per-agent identity tied to the requesting user is the resolution. If your runtime can't pass an offboarding fire drill in under a minute, the rest of the rubric doesn't matter.

Where each vendor category fits the agent governance rubric

The AI security market is highly fragmented. Enterprise architects end up stitching together disparate tools that were never designed for autonomous agents. The vendor landscape sorts into categories that Arcade integrates with, displaces at the agent action layer, or treats as out of scope. The difference matters.

Vendor categories and their relationship to Arcade

Architectural layer	Example vendors	Relationship to Arcade	Why
SIEM and observability platforms	Datadog, Splunk, New Relic, Sumo Logic	Feed	Arcade exports OpenTelemetry GenAI events. Your security operations team queries them in the same SIEM they already use, with the same query syntax. The SIEM stays; the runtime sends it the agent-action layer it currently can't see.
Policy engines and FGA platforms	Open Policy Agent, Cedar, OpenFGA, Oso (Polar DSL), WorkOS FGA	Complement	Define and evaluate fine-grained authorization rules. The runtime integrates with your policy engine and enforces those rules at the agent action layer, applying them in the per-user, per-tool, per-action context where agents actually act.
GRC platforms	Vanta, Drata, Secureframe	Complement	Map theoretical controls and automate attestation paperwork. Don't govern the actual API tool calls an agent makes. Arcade integrates with your GRC platform and enforces those controls on every tool call. GRC declares; Arcade enforces.
Identity providers	Okta, Auth0, WorkOS, Clerk	Complement	Authenticate the human user. Stop at the human login boundary. Arcade brokers delegated agent tokens against the same IdP and extend identity into the agent action plane.
MCP gateways and integration wrappers	Composio	Displaces	Connect language models to tools for rapid prototyping. Lacks enterprise-grade identity isolation, just-in-time consent, out-of-band approval routing, and immutable audit at the agent plane.
Agent frameworks	LangChain, Mastra	Complement	Operate at the reasoning layer (deciding what the agent should do). Arcade governs the underlying action layer, decoupled from the framework. Pick a framework for reasoning and a runtime for action. They combine.
MCP runtimes	Arcade.dev	The unifying layer	Ships the complete 6-capability rubric natively. SOC 2 Type II coverage extends from the underlying cloud through to every tool call an agent makes.

Relying on a patchwork of these vendor classes leaves significant security gaps and integration liabilities. A unified MCP runtime brings agent registration, per-user authorization, policy-as-code enforcement, immutable audit, and runtime attestation under a single, cohesive operating model. It extends the SIEM, IdP, and DLP investments your security team already runs.

Next steps to migrate to an MCP runtime for agent governance

Closing the gap between governance policy and runtime enforcement is a concrete engineering exercise. Four moves get you most of the way:

Audit your current agent and tool registry. Inventory every agent, every connected tool, every shadow MCP server, and every shared service account. If you can't produce an authoritative list with owner, purpose, model version, autonomy tier, and approved users in under a day, your governance posture is already drifting.

Stop building bespoke audit infrastructure. Custom event-bus schemas, mutable application logs masquerading as audit trails, hand-rolled OpenTelemetry pipelines for agent traces. This is undifferentiated technical debt. Your engineers should ship governed agents, not maintain compliance plumbing.

Test revoke-and-rotate aggressively. Run an offboarding fire drill with a real test user. Verify that a single offboarding event rotates that user's tokens, terminates in-flight agent operations on their behalf, and leaves every other user's workflow undisturbed. If the workflow can't do this in under a minute, your runtime can't survive a real credential incident.

Evaluate an MCP runtime. Look for a runtime that ships the six governance capabilities natively, with SOC 2 Type II attestation that covers the agent and tool plane, not just the underlying cloud.

Stitching together passive observability tools and standalone policy engines can't satisfy this requirement. Arcade.dev is the first MCP runtime to ship the complete agent governance rubric natively (runtime enforcement plus immutable, replayable audit), with SOC 2 Type II that extends from the underlying cloud to every tool call an agent makes.

Frequently asked questions (FAQ)

What is AI agent governance, and how is it different from LLM governance?

AI agent governance controls and proves what an agent can do, especially tool/API calls, using runtime policy enforcement, identity, and immutable audit trails. LLM governance often focuses on model behavior and outputs rather than execution-layer actions.

Why isn't logging enough for AI agent compliance?

Logs are passive and occur after the fact. They can't stop an undesired tool call or prompt-injection-driven action. Regulated environments require deterministic, pre-execution enforcement plus tamper-proof, replayable evidence.

Does an MCP runtime replace our SIEM?

No. It extends it. Every agent action emits an OpenTelemetry GenAI event into the same SIEM your security operations team already queries (Datadog, Splunk, New Relic, Sumo Logic). The runtime extends your SIEM into the agent action plane; it doesn't displace it. The same model applies to your IdP (Okta, Entra, etc.) and DLP. The runtime extends those investments rather than running parallel to them.

Does this lock us into a specific agent framework?

No. A runtime governance layer is decoupled from the agent framework. LangChain, Mastra, your own in-house framework: whichever your AI/ML team picks for agent reasoning, the runtime governs the action layer underneath it the same way. Frameworks decide what the agent should do; the runtime governs whether and how it gets to do it.

What does "runtime enforcement at the tool-call boundary" mean?

Every tool/API request is intercepted, evaluated against policy-as-code, and either blocked, modified (e.g., redacted), or allowed before it reaches the resource server. Then it's logged with the decision and policy version.

How do I choose the right autonomy tier for an agent?

Classify autonomy by data sensitivity, reversibility of actions, and potential legal/customer impact. Use Tier 1 (fully supervised, human approval per action) for high-stakes irreversible workloads. Tier 2 (constrained autonomy within pre-approved scope) is the default for the enterprise.

What are the minimum audit log fields required for agent governance?

See the canonical schema in Capability 5 above: Agent ID, User ID, Tool Call, System, and Timestamp at minimum. Stored immutably. Richer fields (prompt hash, retrieved-context references, policy version, output hash) enable full replay.

What is "policy version pinning" and why does it matter?

Policy version pinning records the exact policy version that authorized a specific action at that time. It prevents "silent compliance breaks" when policies change and enables auditors to accurately replay historical decisions.

Why are in-chat human approvals unsafe for agents?

In-band chat approvals can be spoofed or bypassed via prompt injection. Use out-of-band approvals (e.g., signed approvals bound to the tool-call hash) to cryptographically prove a human authorized the exact payload.

What does "agent-as-a-security-principal" mean?

Each agent gets its own identity and scoped credentials tied to the requesting user and tenant. This enables least privilege, clear attribution, and rapid revocation without relying on shared API keys.

Can we just use a service account per agent?

No. Shared or pooled service accounts break attribution (you can't tell which user triggered an action), block selective revocation (you can't rotate one user's access without breaking everyone's), and force all-or-nothing access decisions. The category requires per-agent identity tied to the requesting user, scoped to specific tools and actions, acquired just-in-time, and revocable in isolation.

How does this map to the EU AI Act, NIST AI RMF, and ISO 42001?

Those frameworks require traceability, monitoring, risk controls, and oversight. The runtime governance stack implements them operationally via identity, policy-as-code, immutable logs, HITL, and continuous assurance.

Our cloud provider is SOC 2 Type II certified. Isn't that enough?

No. Cloud attestation doesn't extend to the agent and tool plane unless the runtime layer is explicitly in scope. Auditors will ask for evidence of every agent action, every policy decision, and every approval. If your stack only attests at the infrastructure layer, the agent plane is unattested and inadmissible, regardless of your cloud provider's certificate.

What are the most common anti-patterns in agent governance?

Ten patterns break runtime compliance: spreadsheet governance, mutable logs, identity collapse with shadow MCP servers, credentials exposed to the agent, in-band chat approvals, agent-side policy enforcement, decentralized policies, no autonomy-tier classification, no revoke-and-rotate workflow, and compliance attestation that covers the cloud but not the agent or tool plane. Each one breaks auditability or allows unauthorized actions to slip through.

6 Signs Your In-House AI Agents Need an MCP Runtime

Manveer Chawla — Tue, 09 Jun 2026 20:44:55 +0000

Someone on your revenue operations team got tired of nagging account executives about CRM hygiene. So they wired up an agent. Salesforce has an MCP server, the model can call tools, and the workflow is obvious: take the meeting transcript, pull out the next steps, update the opportunity, log the activity, push a follow-up task. An afternoon of work, one API token in a .env file, and the thing runs.

It works. AEs stop complaining. The demo gets passed around. Within a week, two other teams want the same thing for Zendesk and Jira, and you have quietly become the owner of production Agentic AI inside the company.

Then it stops being an afternoon project. Not because the agent got worse, but because the moment it acts on behalf of other people, every shortcut that made the prototype fast turns into a question you cannot answer with a print() statement.

TL;DR

You need an MCP runtime for your AI Agents when auth, permissions, audit logs, integrations, reuse, or risk ownership start moving out of the prototype phase.
MCP standardizes tool connections, but it does not, by itself, solve production governance.
An MCP runtime centralizes identity, policy, tool execution, and evidence so that you do not need to rebuild those layers from scratch for deploying AI agents in production

The wall is predictable, not a failure

You built the right thing. The prototype-first path is the correct first move. Prototypes are cheap to assemble once a model can call tools and an MCP server can expose capabilities, and a small team can tolerate a narrow happy path. Every team now running agents at scale started exactly where you are, with one workflow, one tenant, light usage, and a forgiving risk posture.

The first version works because it quietly cheats. The engineer who built it is the security boundary. They know which records the agent can touch, they wrote the prompt, and they hold the token. There is no question of "what should this agent be allowed to do," because the answer is "whatever I, the builder, can do." That assumption holds right up until the agent is doing things for people who are not you.

Six signs separate a working prototype from something that needs real infrastructure. None is exotic. You will recognize your own repo in most of them.

Sign 1: You're writing more auth and login plumbing than agent logic

The identity layer: proving who is actually calling the tools.

You've crossed it when: your auth/ directory is bigger than your tools/ directory.

Look at your repository. The tools/ directory grew a sibling auth/ directory, and auth/ is now bigger. Standups have shifted from "how do we improve the agent" to "why did this user's refresh token fail" and "which account is the agent using." A new engineer's first ticket is "add Slack," and it takes two weeks.

Why it happens

Acting agents sit in the hard middle between a user and a downstream API, which forces you to own multi-user AI agent authentication and authorization mechanics you used to get for free, and enterprise APIs do not share an identity standard. Slack rotates access tokens every 12 hours; GitHub expires installation tokens in an hour and refresh tokens in six months; Microsoft Graph splits delegated from app-only access with its own consent model. Implementing one is a week. Implementing five, with refresh, rotation, revocation, and per-user storage, is a sustained quarter. Get the concurrency wrong and two threads refresh the same single-use token at once, the provider reads it as a replay attack, and the user is locked out.

How it plays out

Trace it through the Salesforce agent. The first version runs on one static admin token. Then the sales director wants updates recorded under the rep who was on the call, so you build per-user OAuth with a background worker to store, encrypt, and refresh tokens (Salesforce access tokens expire in two hours). Then security asks what happens when an AE leaves, so revocation has to tie into your IdP's deprovisioning. Each request is reasonable. Together, they are an IAM client you never set out to build.

Bottom line: the prototype needed a login; the production agent needs an identity model, especially once enterprise teams expect SSO for AI agents to work like the rest of their software stack.

Sign 2: Your permissions are a growing pile of hand-maintained if-then rules

The policy layer: deciding what they're allowed to do.

You've crossed it when: nobody can say what the agent is allowed to do without reading the code.

Sign 1 was authentication: proving who is asking. This is authorization, the harder half: deciding what they are allowed to do, and in production, agents usually mean a delegated authorization stack that evaluates the user, the agent, and the action together. It starts with one clean check, updates the record only if the signed-in rep can edit it, and then the rules multiply. Update Stage, but only with the "Pipeline Manager" permission set. Closed-won updates need manager approval. EMEA is exempt. SDRs can edit notes but not the advanced stages. Each is a defensible business need. Together, they are configuration hell, accreting in one file: permissions.py fills with branches and comments like # do NOT remove, breaks renewals team, and new permission requests take a sprint.

Why it happens

The problem is structural: authorization depends on subject, object, and context, and inline conditionals collapse those dimensions into procedural mush. NIST's ABAC guidance exists for exactly this reason, and tools like Open Policy Agent externalize policy to keep it out of application code.

How it plays out

Salesforce is the cautionary tale. Its permission model, profiles, permission sets, sharing rules, field-level security, and more, is two decades of mature hand-maintained authorization. An agent re-implementing a slice of that in Python is starting the same journey with a fraction of the staff.

Bottom line: at first, if-statements are the fastest way to encode context; later, they are an undocumented policy system, and a single wrong branch has blast radius across every tenant the agent touches.

Sign 3: You need agent audit logs for every tool call

The evidence layer: reconstructing what actually happened.

You've crossed it when: you can't reconstruct who did what after the fact.

Suppose the permission rules are right. You still cannot prove they were followed. The clearest version of this sign is a Slack thread:

"Hey, did the bot just close that opp?"
"I think so?"
"Can you check?"
"The logs rolled over."

That conversation is the finding. When something looks wrong, you need to answer fast: which run did it, who authorized it, what was the input, what changed downstream, and was there an approval? If you cannot, you do not have guardrails. You have an opinionated wrapper.

Why it happens

An auditable action comprises at least five facets that must be recorded together: the requesting user, the agent identity, the authorization decision, the input, and the resulting change. Ad-hoc logging captures one or two, and they live in different systems. Salesforce Field History has the state change but not the reasoning; the LLM trace has the reasoning but not the change; nothing correlates them. Guardrails are point-in-time controls; audit trails are durable evidence, and acting systems need both. Slack's Audit Logs API gives you actor, action, entity, and context, but explicitly will not tell you whether the action was appropriate.

How it plays out

When finance flags a deal at quarter close because the amount was moved after the close date, you can see the new value but cannot determine who changed it, on whose behalf, or based on what input. And the moment the agent mutates regulated data the question stops being internal: HIPAA at 45 CFR §164.312(b) requires systems handling ePHI to record and examine activity.

Bottom line: "we have the LLM transcript" is not an answer an auditor accepts. What they need instead is audit logs and telemetry for every tool call: who requested it, which tool ran, what changed, and how the action was authorized.

Sign 4: Every new system multiplies the work instead of adding to it

The integration layer: running one action across many systems.

You've crossed it when: the fifth connector costs more than the first, not less.

Everything so far has been one agent against essentially one system. Then the roadmap arrives: "add Gmail, Calendar, Zendesk, Jira, Slack, and Salesforce." You budget for six connectors and price them roughly equal. Instead you get six different auth models, scope vocabularies, rate-limit behaviors, schemas, pagination styles, and audit surfaces. Adding Slack should have been easier than adding Salesforce. It was not. The first integration took two weeks; the fifth took five.

Why it happens

You did not add six tools, you added six governance surfaces, and each one drags the earlier signs in behind it: another identity model to wire (Sign 1), another permission surface to encode (Sign 2), another audit stream to correlate (Sign 3). Every tool you bolt on imports a full instance of each. It gets worse when an agent composes across systems, because a single logical action (read from Calendar, look up in Salesforce, post to Slack) has to reconcile three identity propagations, three permission checks, three rate limits, and three failure modes within a single operation. This is the connector-count fallacy, and it is exactly the problem the MCP gateway pattern is meant to avoid.

How it plays out

The rate limits alone will stop a roadmap. Microsoft Graph caps you at four concurrent requests per mailbox, a ceiling that bites harder once Exchange Web Services retires on October 1, 2026 and its far roomier limit (27 connections) goes with it. Add Outlook so the agent can schedule follow-ups, and the first time it reads inbox threads while booking a meeting it trips that limit and starts collecting 429s. The roadmap stops while you build a centralized queue and rate limiter the prototype never needed.

Bottom line: one more tool is not additive; it multiplies against everything already connected.

Sign 5: Each new team rebuilds the same infrastructure

The reuse layer: amortizing the work across agents and teams.

You've crossed it when: the next team forks nothing and starts from zero.

Sign 4 was the cost of adding tools to one agent. This is the cost of adding agents to the company, the same multiplication seen from the other axis. The sales ops agent ships, after months of security clearance, token storage code, and custom audit logging. A month later the support team wants an agent that pulls Salesforce records when a Zendesk ticket opens. They look at the sales team's repo and start over. The auth is entangled with one queueing model, one set of scopes, one audit sink. Their logging assumes Salesforce. Nothing lifts cleanly, so both teams now maintain parallel auth code, and the security team has reviewed two patterns for the same risk.

Why it happens

By the third agent (customer success wants a renewal-risk updater, finance wants an invoice assistant), you have three implementations of the same core layers (identity, policy, integration, evidence) and three separately approved patterns for the same risk. Put formally, you are solving an N × M problem by hand: N agents, each rebuilt against M systems. None of those layers is agent-specific, but in every repo they were written application-specific, so there is no interface to extract. A shared layer collapses the problem to N + M, where each connector is built once and every agent inherits it.

How it plays out

This is the canonical platform-engineering trigger, and the industry has run the play before. Spotify built Backstage because its engineers were drowning in fragmented tooling, and Netflix calls this same idea the "paved road." An MCP runtime acts as this exact shared substrate for AI agents. By providing a centralized control plane and a shared registry for team-level access, the runtime ensures that identity, policy, evidence, and integrations are built once. Every new agent simply connects to the runtime and inherits this infrastructure, making the safe path the easy one.

Bottom line: copying the first agent feels faster, right up until every copy inherits a private auth stack, permission model, and audit story. A centralized MCP runtime collapses this into a single integration point that every new team and agent can safely reuse.

Sign 6: Sensitive or legacy systems are entering scope, and nobody wants to personally own the risk

The ownership layer: deciding who carries the risk.

You've crossed it when: the pull request to a sensitive system sits open because no one will approve it.

This sign is psychological before it is technical, and that is the point. You were fine letting the agent draft notes and update low-risk CRM fields. You are not fine pointing the same stack at payroll, refunds, or the ERP. A pull request to give it write access to NetSuite or Workday sits open. Reviewers comment but will not approve. The engineer asks security for sign-off; security asks the engineer. Nothing ships.

Why it happens

That hesitation is correct, and notice what it is not about. The earlier signs were about building the mechanics, and by now you have most of them. This one is about who answers for the outcome when those mechanics touch something irreversible. A Salesforce note is recoverable in minutes; a journal entry in NetSuite hits the general ledger. These systems carry formal control expectations: Dynamics 365 ties segregation of duties to SOX, IFRS, and FDA controls. "The agent probably did the right thing" is not part of the operating model there. Legacy systems sharpen it further, since they often lack what makes a bad write survivable: no fine-grained permissions, no auditable API, no transactional undo.

How it plays out

When the lead architect is asked to point the agent at a legacy financial database, the question is not "can I build the connection?" It is "if a malicious email steers this agent into the wrong write, the damage cannot be undone, and the name on the change is mine." Blocking that deploy is a rational refusal to personally absorb an institutional risk. This is where an MCP runtime steps in. By providing features like mandatory out-of-band human approvals ("read, draft, and commit"), contextual access policy hooks, and immutable OpenTelemetry-compatible audit logs, the runtime shifts the burden of trust from the developer to secure, verifiable infrastructure.

Bottom line: when accountability exceeds what one person can absorb, the work requires institutional ownership through an MCP runtime. With versioned policy, retained audit logs, routed approvals, and credentials kept entirely out of the LLM execution environment, the engineer's name is on the code, not on the risk of the decision.

The pattern behind the signs

These are not six unrelated problems. They are one problem wearing six masks. You set out to build an agent and ended up hand-building a runtime, one feature at a time, without the architecture to hold it together. The auth daemon, the growing permissions.py, the scattered logs, the per-connector rate limiter, the copy-pasted glue, the deploy nobody will approve: each is a piece of execution infrastructure that should exist once and apply to every agent, reinvented inside a single application instead. Identity, policy, evidence, integration, reuse, ownership: six names for the same missing layer.

An MCP runtime is that missing layer. Not a framework for building agents, and not a platform that hosts them. It is the standard execution layer agents act through, where those six concerns live once, as infrastructure, the same way a language runtime or a container runtime is not something application code opts into so much as the substrate it cannot act without. The agent proposes; the runtime authenticates the call, enforces policy, executes the tool, and records what happened.

Adopt one and your effort moves from building security boundaries to designing what the agent should actually do. The six concerns become properties of the layer rather than per-agent plumbing, and the next team inherits the safe path rather than rebuilding it. Arcade.dev, the MCP runtime, is built for exactly this. It delivers per-action authorization that evaluates the intersection of agent and user permissions at the moment of the call (with credentials kept out of the model), a catalog of 8,000+ agent-optimized MCP tools that translate intent into safe API calls instead of letting the model hallucinate parameters, and centralized lifecycle governance with an OpenTelemetry-compatible audit record per user per service. How you get a runtime, build or buy, is its own conversation.

Quick checklist: Have you outgrown the prototype?

You do not need a runtime the first time an agent works. You need one when the agent becomes important enough that the surrounding questions matter as much as the prompt.

Run the checklist against the agent you already have:

It acts on behalf of more than one user.
It uses per-user OAuth instead of one developer-owned token.
It can write to systems of record, not just read from them.
Permissions depend on role, team, region, record owner, approval state, or business context.
You cannot reconstruct every tool call from request to downstream change.
Adding a new connector means rebuilding auth, scopes, rate limits, retries, and audit behavior.
A second team is copying the first agent rather than reusing the shared infrastructure.
Sensitive systems such as payroll, refunds, ERP, finance, healthcare, and customer data are coming into scope.
Security, legal, or compliance has started asking who approved the action, not just whether the code works.
A pull request is stalled because everyone agrees the agent is useful, but nobody wants to personally own the risk.

If you checked one or two, you may still be in prototype territory. If you checked three or more, the agent is probably no longer the hard part. The missing layer around it is.

Bottom line: once the questions are about identity, permission, evidence, reuse, and ownership, you are no longer debugging an agent. You are discovering the runtime it needs.

You've crossed the threshold

If these signs sound like your standups, your repo, and your stalled pull requests, the conclusion is simple: you have outgrown the DIY approach. Not because you built it wrong, but because you built it well enough to hit the same wall that web apps hit before centralized identity, that deployments hit before CI/CD, and that infrastructure hit before container orchestration. The artifact that resolved each of those was the same shape every time: extract the execution layer. You are not late. You are exactly on time for the transition; every infrastructure category before this one has already been made.

How you get that runtime, whether you build or buy an MCP runtime, and how to evaluate the options, is the next conversation.

Frequently Asked Questions

What is an MCP runtime?

An MCP runtime is the governed execution layer for agents that use Model Context Protocol tools. It sits between the agent and the MCP servers it calls, handling identity, authorization, tool execution, credential isolation, policy enforcement, and audit logging.

Why do AI agents need a runtime?

AI agents need a runtime when they move from prototypes to production. MCP helps agents connect to tools, but teams still need a governed layer to decide who the agent is acting for, what it is allowed to do, how credentials are protected, and how each action is recorded.

Is MCP itself a runtime?

No. MCP standardizes how agents connect to tools and context. An MCP runtime governs what happens when those tools are used, including authorization, credential handling, policy checks, approvals, retries, rate limits, and audit trails.

When should a team use an MCP runtime?

A team should use an MCP runtime when an agent acts on behalf of multiple users, connects to sensitive systems, writes to systems of record, requires per-user OAuth, needs audit logs, or is being reused across multiple teams and workflows.

How is an MCP runtime different from an MCP server?

An MCP server exposes tools, resources, or prompts to an agent. An MCP runtime governs the execution of those tools in production. The server defines what is available. The runtime controls who can use it, under what policy, with which credentials, and with what audit record.

How is an MCP runtime different from an MCP gateway?

An MCP gateway primarily federates tools from multiple MCP servers into a single endpoint for simplified routing and single-URL configuration. While useful for connectivity, a gateway just routes requests. An MCP runtime is a complete execution layer that goes beyond routing to include delegated multi-user authorization, intent-level tool execution, contextual policy enforcement, and immutable audit logging. A gateway routes; a runtime executes, enforces, and audits.

How does an MCP runtime improve security?

An MCP runtime improves security by separating the agent from raw credentials, enforcing per-user and per-action authorization, limiting tool access, routing sensitive actions through policy checks, and recording what happened for every tool call.

Should companies build or buy an MCP runtime?

Build an MCP runtime only if your agent is single-user, your APIs are fully internal, or your agent infrastructure is your core product. For multi-user production agents that need OAuth, credential vaulting, permissions, audit logs, or SaaS integrations, buying a runtime usually lets the team ship faster while avoiding the need to own permanent infrastructure.

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.