Gateway Patterns and Actions Runtime for Enterprise Agentic AI Deployment

arcade.dev · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: enterprise agent action governance

Arcade argues that enterprise agents need an actions runtime between the reasoning layer and downstream systems so agents can safely take real actions across CRM, ERP, email, Workday, and other business systems without relying on agent self-enforcement or over-scoped service accounts.

Constraints:

• agents that manipulate systems can create security, compliance, and business blast radius if tool selection or parameters are wrong
• non-human identity and service-account patterns can create authorization bypass vulnerabilities when an over-scoped agent is exposed to lower-privileged users
• user-credential delegation avoids some permission escalation but creates multi-user, cloud, mobile, and excessive-action-risk problems
• agents are probabilistic and cannot be trusted to enforce their own policies on every action
• enterprises already have identity, policy, logging, and business-system permission models that should be reused rather than duplicated in each agent

Architecture

Arcade positions its actions runtime as an MCP gateway and control-plane layer in front of enterprise action systems. Agents call centrally curated MCP tools and skills through a gateway; the runtime separates agent identity, user identity, and downstream service authorization, checks the intersection on every request, routes to the right MCP server or business system, and records audit trails. Policy definitions remain in systems such as Entra, SailPoint, Gmail, Salesforce, or the services themselves, while the actions runtime acts as the enforcement, routing, tool-quality, and observability layer.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  enterprise-agents["Enterprise agents"] --> actions-runtime-gateway["Actions runtime gateway"]
  user-identity["User identity"] --> actions-runtime-gateway
  actions-runtime-gateway --> tool-catalog["Tool catalog"]
  tool-catalog --> tool-quality-evaluation["Tool quality evaluation"]
  actions-runtime-gateway --> authorization-enforcement["Authorization enforcement"]
  authorization-enforcement --> enterprise-policy-systems["Enterprise policy systems"]
  actions-runtime-gateway --> mcp-servers["MCP servers"]
  mcp-servers --> downstream-business-systems["Downstream business systems"]
  actions-runtime-gateway --> audit-and-observability["Audit and observability"]

Components

Data flow

An enterprise agent sends an MCP action request to an Arcade gateway. The runtime identifies the agent, the user, and the downstream service token; verifies whether this agent on behalf of this user can perform the requested action on the target resource; routes the request to the relevant MCP server such as Gmail; and records the action with user, agent, service, and context for auditability. If authorization is missing, the runtime initiates an authorization flow rather than letting the agent execute the action.

Why this architecture

Arcade favors an action-layer runtime because governance failures happen when reasoning turns into execution. Centralizing identity separation, tool curation, authorization, and audit trails lets enterprises reuse existing security systems while preventing each agent from inventing its own OAuth flows, Salesforce connectors, tool quality checks, and logs.

Models used: MCP · Arcade actions runtime · MCP gateway · OAuth 2.1 · Claude · Cursor · Gmail MCP server · Okta · Ping Identity · Active Directory · Entra · SailPoint · Salesforce · Microsoft Dynamics · AWS · Azure · GCP · Toolbench

Scale

• The talk frames enterprise readiness around four MCP topics: gateway patterns, audit trails, configuration portability, and enterprise authentication.
  “there are four major topics here. Gateway patterns, audit trails, config portability, enterprise auth.”transcript, stated
• The authorization model is applied on every request, event, and transaction rather than once at login.
  “Authorization is being applied and then on every single request, on every single event, every single transaction, there's an audit trail that the organization can manage.”transcript, stated
• Arcade describes thousands of preconfigured tools and MCP servers in its tool catalog.
  “there's thousands upon thousands of pre-configured tools and MCP servers. We ourselves have built most of these ourselves for the purpose of quality”transcript, stated
• Toolbench is described as reviewing every public MCP server against security, MCP adherence, and LLM usability.
  “We have ranked and reviewed every public MCP server out there based on security, based on adherence to the MCP spec, and based on what we consider to be tool patterns”transcript, stated
• The control plane supports many gateways with different policies for different agent environments.
  “I have Claude and I have Cursor. They both have different policies. My Claude cannot access any of my coding environments. And my Cursor environment can't access any of my business systems.”transcript, stated

Alternatives considered (roads not taken)

Give the agent its own non-human identity or service account

Rejected because: The talk says this over-scopes the agent and creates an authorization bypass where lower-privileged users can access capabilities granted to the service account.

Run agents with the user's raw credentials

Rejected because: User credentials avoid some permission escalation but create laptop/local-agent, multi-user, cloud, mobile, and over-permission risks.

Use a service mesh or generic API gateway as the MCP gateway

Rejected because: The talk argues this only solves networking and leaves the enterprise with the hard bespoke identity-enforcement system still to build.

Let each agent manage its own authorization, tool connections, and logging

Rejected because: The result would be fragmented OAuth flows, connectors, and logs across agents rather than a governable enterprise control plane.

Make the actions runtime the policy definition system

Rejected because: Arcade explicitly positions the runtime as policy enforcement that integrates with existing policy and identity stores to avoid creating another policy-data silo.

Expose raw API wrappers instead of agent-designed tools and skills

Rejected because: The talk says agents need curated tools and procedural skills because raw connectors do not teach the agent how to complete multi-step workflows safely.

Patterns

tool-use-orchestration (agent infrastructure)

Arcade centralizes MCP tools and skills behind an actions runtime so many agents can call curated, permission-aware business actions instead of each agent wiring raw APIs itself.

safety-policy-enforcement (governance)

The runtime enforces whether a given agent, acting for a given user, may perform a specific action on a specific resource at execution time.

observability-tracing (operations)

Arcade treats per-action audit trails as a first-class requirement, recording which agent, user, service, and context participated in an action so security and management can understand incidents.

eval-driven-development (tool quality)

Arcade evaluates MCP tools and public MCP servers for security, MCP spec adherence, and LLM usability before exposing them as enterprise-ready tools.

multi-agent-orchestration (enterprise platform)

The same tool and skills foundation can be shared across multiple agents while the runtime gives each agent or workspace different centrally managed access.

Tradeoffs

Where to enforce policy for enterprise agent actions

Chose an external actions runtime at the action layer over agent-internal self-enforcement.

Rationale: The speaker argues enforcement matters most when reasoning becomes action and agents cannot be trusted to obey their own guardrails under goal pressure.

How to model agent authorization

Chose intersection of agent permission and user permission over agent-only service account or user-only credential delegation.

Rationale: The intersection model gives the agent only actions both the deploying organization and the user are allowed to perform, avoiding service-account overreach and raw user-credential blast radius.

Where policy definitions should live

Chose reuse existing identity, policy, and business-system authorization stores over defining policy inside the actions runtime itself.

Rationale: The runtime should enforce policy while avoiding another silo of policy data in already-complex enterprises.

How much policy differentiation to expose between agents

Chose different gateways and policies for different agents or workspaces over one undifferentiated gateway for all agent surfaces.

Rationale: Separate gateways let Claude, Cursor, coding agents, and business agents receive different access boundaries while sharing central infrastructure.

How to package business workflows for agents

Chose curated tools plus procedural skills over handing agents raw connectors and expecting them to assemble workflows from scratch.

Rationale: Tools provide deterministic building blocks, while skills teach workflow procedure; raw connectors alone leave the model to improvise error-prone implementation details.

Gotchas (what bit them)

Service-account identity can over-scope the agent.

Root cause: Treating an agent as a peer identity gives it its own broad permissions, which lower-privileged users may indirectly access.

Resolution: Evaluate action permission as the intersection of agent, user, action, and resource on each request.

Reducing all users to the lowest common denominator destroys agent value.

Root cause: When authorization cannot separate users and resources, security blocks powerful access and the agent becomes useful to neither low- nor high-privilege users.

Resolution: Use per-user and per-agent authorization checks so privileged users can safely get more valuable actions without leaking them to others.

Agents can bypass their own guardrails.

Root cause: Because agents are non-deterministic and optimize for task success, they may disable or work around safety controls that conflict with completing the task.

Resolution: Move enforcement to an external action-layer runtime that checks every request instead of trusting agent self-governance.

Local single-user agents do not translate cleanly into enterprise cloud and mobile usage.

Root cause: Delegating user credentials works most naturally for local laptop agents but leaves unresolved how multi-user agents work across cloud, mobile, and multiple devices.

Resolution: Create multi-user cloud experiences where the runtime mediates access per agent and user without leaking information.

Authorization depth is tightly coupled to downstream business logic.

Root cause: Systems that appear similar, such as Gmail versus Outlook or Salesforce versus Dynamics, have different permission models that the runtime must understand.

Resolution: Integrate with downstream authorization systems and apply their business-specific permission models instead of assuming one generic policy shape.

Raw APIs and skills can push deterministic work back into the agent.

Root cause: If a workflow such as replying to email is left as a skill over raw endpoints, the model may have to generate code or MIME manipulation for a deterministic operation.

Resolution: Package deterministic business actions as proper tools or runtime capabilities so the agent uses a reliable action instead of improvising implementation details.

Unapproved MCP servers can become a malicious or low-quality tool surface.

Root cause: If end users can spin up arbitrary MCP servers, agent tool selection can be hijacked or degraded outside central IT governance.

Resolution: Expose only blessed MCP servers and tools through a centrally governed catalog and gateway.

Evaluation

The talk describes tool quality evaluation rather than a full product evaluation harness: Arcade says its tools and public MCP servers are assessed for security, MCP-spec adherence, and LLM usability, and the demo verifies runtime authorization by revoking a token and showing the gateway initiate authorization instead of executing.

Metrics: tool security · MCP spec adherence · LLM usability/tool patterns · successful tool selection and permission-aware execution · per-request authorization pass/fail · auditability by agent, user, service, and context

Outcomes

• Arcade demonstrated a Gmail MCP action routed through the actions runtime, including token-based scope and claim checks.
• When the user's token was revoked, the runtime blocked direct execution and initiated an authorization request.
• The proposed architecture lets organizations centrally configure which agents, developers, workspaces, tools, and MCP servers are visible or executable.
• Arcade claims its tool catalog includes thousands of preconfigured tools and MCP servers that have gone through evals for quality and permission awareness.

The transcript is a product/architecture talk rather than a deployment case study with customer metrics. Its concrete scale evidence is catalog and governance scale: thousands of tools and MCP servers, every public MCP server ranked by Toolbench, every request checked for authorization, and multiple gateways/policies for different agents such as Claude and Cursor.