> ## Documentation Index > Fetch the complete documentation index at: https://docs.runlayer.com/llms.txt > Use this file to discover all available pages before exploring further. # Agent Platforms > Connect agents on third-party platforms with shared identity, policy, audit, and session monitoring where supported Route third-party agent tool calls through Runlayer to apply identity, policy, scanning, approvals, and audit. Add hooks when you also need prompts, reasoning, local tools, and responses in Runlayer Sessions. ```mermaid theme={null} flowchart LR Caller["User or autonomous trigger"] --> Runtime["Third-party agent runtime"] Runtime --> Identity["Identity
M2M, OBO, or user OAuth"] Identity --> Connection["Connections
Runlayer MCP"] Connection --> Policies["Policies
access, ToolGuard, approvals"] Policies --> Systems["Enterprise systems"] Connection --> Audit["Monitoring
Audit Logs"] Runtime -. "native hook or Hooks SDK" .-> Sessions["Monitoring
Sessions and AgentGuard"] ``` ## Configure identity Create a Runlayer [Agent Account](/platform-agent-accounts) for code-first and autonomous agents. Use an M2M token for autonomous work. When an agent acts for a user, map the authenticated caller to a Runlayer user with an active delegation and mint an OBO token. Interactive platform integrations may establish the Runlayer user directly through OAuth instead. A vendor identity, service account, or user token does not automatically become a Runlayer identity. Perform that mapping in the application unless Runlayer recognizes the user token directly. ## Connect tools Configure the runtime's remote Streamable HTTP MCP client with the [Runlayer Plugin](/runlayer-plugin) endpoint or an individual connector endpoint. Pass the short-lived token as `Authorization: Bearer `. Prefer an individual connector endpoint plus [resource-scoped tokens](/platform-agent-accounts#resource-scoping-enforcement) for narrowly privileged agents. Use Runlayer Plugin when the agent needs a broader, policy-filtered connector catalog. Resource-scoped tokens cannot be used with aggregate or plugin endpoints. ## Apply policies Grant each Runlayer principal access to only the required connectors and tools with [access rules](/platform-policies). Calls through Runlayer MCP inherit those policies plus ToolGuard scanning, approval rules, and audit logging. For OBO calls, Runlayer applies the intersection of the agent's and user's access. Platform-native browser, shell, code, function, and direct HTTP tools do not cross Runlayer merely because the agent also uses Runlayer MCP. Disable overlapping capabilities, route them through MCP, or wrap them with Runlayer where supported. ## Monitor activity Every proxied call appears in Runlayer Audit Logs. When the runtime supports custom headers, send its stable conversation or run identifier as `x-runlayer-session-id`; allowlist that header in any intermediary gateway. Add a native Runlayer adapter or the [Hooks SDK](/runlayer-hooks-sdk) to capture prompts, reasoning, responses, and tools that do not pass through MCP. Before sending hook events, enable the matching client under **Settings → Agent session monitoring → Full session scanning APIs**. ## Compare platform coverage Every platform can route MCP calls through Runlayer for identity, policy, ToolGuard, approvals, and Audit Logs. The table compares its connection and additional session options. | Platform | Identity | Tool connection | Session coverage | | ------------------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------- | -------------------------------------------------------------- | | [AWS Bedrock AgentCore](#aws-bedrock-agentcore) | Agent Account M2M or OBO | Direct remote MCP or Runlayer target behind AgentCore Gateway | Custom Hooks SDK events in Runtime code | | [Claude Managed Agents](#claude-managed-agents) | Native user OAuth or Agent Account M2M/OBO in a Claude Vault | Native remote MCP | Hooks SDK events for application-executed custom tools | | [Cloudflare Agents](#cloudflare-agents) | Native user OAuth or Agent Account M2M/OBO | Agents SDK remote MCP client | Stable conversation correlation in Audit Logs | | [Google Vertex AI Agent Engine](#google-vertex-ai-agent-engine) | Agent Account M2M or OBO from Agent Registry | ADK `McpToolset` on Agent Runtime | Custom Hooks SDK events from ADK callbacks | | [LangSmith Deployment / LangGraph](#langsmith-langgraph) | Agent Account M2M or per-caller OBO | `langchain-mcp-adapters` inside the deployed graph | Custom Hooks SDK events from graph middleware or code | | [Microsoft Foundry Agent Service](#microsoft-foundry-agent-service) | Agent Account M2M or per-request OBO | Streamable HTTP MCP from the hosted container | Custom Python Agent Framework middleware | | [OpenAI Agents](#openai-agents) | Plugin OAuth or Agent Account M2M/OBO | Workspace Agent app, Agents SDK, or Responses remote MCP | Compliance import for ChatGPT; Hooks SDK for code-first agents | | [Vercel Eve](#vercel-eve) | Agent Account M2M or per-user OBO | Generated Eve MCP connection | Native Runlayer Eve hook | Runlayer MCP is the inline enforcement point in every row. A custom or native session integration expands visibility; it does not make unwrapped vendor tools pass through the gateway. ## Platform guides [Amazon Bedrock AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html) is a set of modular services. Harness provides a managed loop, Runtime hosts custom agents, Gateway aggregates MCP targets, and Identity supplies outbound credentials. ### Configure identity Create a Runlayer [Agent Account](/platform-agent-accounts). Keep its client credentials in AgentCore's secret store and mint short-lived tokens at runtime. Use M2M for autonomous work or map the caller to a delegated Runlayer user for OBO access. AgentCore OBO requires bearer-JWT inbound authorization. Default SigV4 invocation does not carry end-user identity. For Gateway token exchange, configure the provider and target with `TOKEN_EXCHANGE`, set `actorTokenContent` to `M2M`, and set `customParameters.subject_token_type` to `urn:ietf:params:oauth:token-type:access_token`. Without that override, AgentCore labels the inbound JWT as `urn:ietf:params:oauth:token-type:jwt`, which Runlayer rejects. Pass an inbound token directly only when Runlayer recognizes it and the user has an active delegation. Otherwise map the caller to a Runlayer user and exchange the token in application code. ### Connect tools From Runtime, point the agent's remote MCP client directly at the Runlayer endpoint. From managed Harness, prefer a Runlayer external MCP target behind AgentCore Gateway and Identity. Direct Harness MCP accepts request headers, but the caller must replace an expiring bearer itself. For Gateway, configure a custom OAuth provider and enter Runlayer's token endpoint manually; AgentCore's automatic discovery expects OIDC metadata. Select `DYNAMIC` Gateway tool discovery when Runlayer tool visibility varies by caller. `DYNAMIC` is incompatible with semantic search and outbound 3LO. ### Apply policies If Gateway discovery is not `DYNAMIC`, call `SynchronizeGatewayTargets` after connector or policy-driven tool-visibility changes. Runlayer still evaluates every call at execution time. Use a Harness `allowedTools` allowlist and, where practical, a dedicated Gateway whose only target is Runlayer. If other targets must remain, use AgentCore Policy and IAM as complementary controls. Restrict direct remote MCP, Browser, Code Interpreter, inline functions, `shell`, and `file_operations` when they overlap with governed tools. `allowedTools` does not constrain `InvokeAgentRuntimeCommand`; deny that IAM action when direct Runtime commands would bypass Runlayer. ### Monitor activity Every proxied call appears in Runlayer Audit Logs. In Runtime or another custom MCP client, send the stable AgentCore session or run ID as `x-runlayer-session-id`. When using Gateway, allowlist it in the target's `metadataConfiguration.allowedRequestHeaders` before setting it in the client or interceptor. Managed Harness does not document injecting its `runtimeSessionId` into Gateway MCP calls. Only claim session correlation when an application-specific path obtains and injects a trustworthy ID. For deeper Runlayer Sessions, enable the matching [Hooks SDK](/runlayer-hooks-sdk#getting-started) session monitoring client, then add the SDK to Runtime code and emit the lifecycle events you need. There is no native Strands or managed Harness adapter. Exporting a Harness agent to Strands and deploying it on Runtime makes custom instrumentation possible; it does not add it automatically. Keep AgentCore observability and CloudWatch enabled for model, memory, shell, and runtime activity that does not pass through Runlayer. ### Learn more * [External MCP targets](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-MCPservers.html) * [Forwarded headers](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-headers.html) * [Custom OAuth providers](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-add-oauth-client-custom.html) * [OBO token exchange](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/on-behalf-of-token-exchange.html) * [AgentCore Policy](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html) * [Harness tools](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-tools.html) * [Harness export](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-export.html) * [Harness observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-operations.html) [Claude Managed Agents](https://platform.claude.com/docs/en/managed-agents/overview) is Anthropic's beta managed harness for long-running, stateful work. An agent defines its model, instructions, tools, MCP servers, and skills; each session runs in a cloud or self-hosted environment. Anthropic persists Managed Agents session history and state server-side. The product is not currently eligible for Zero Data Retention or HIPAA BAA coverage. Runlayer governance does not change that retention boundary. ### Configure identity For user-facing agents that only need the Runlayer user's identity, prefer a Claude Vault `mcp_oauth` credential. Anthropic completes the Runlayer OAuth flow and refreshes the credential automatically. For autonomous work, create a Runlayer [Agent Account](/platform-agent-accounts) and use M2M. Keep its client credentials in your service, mint and refresh the bearer outside Anthropic, and update the attached Vault before it expires. Claude Vaults do not perform Runlayer's client-credentials exchange. Use OBO when the agent must act with both agent and end-user identity. Create one workspace Vault per Runlayer user and authorize the user-to-Vault mapping on your server. Vault IDs are workspace-visible, and anyone with a workspace API key can attach one. In a multiagent session, the attached Vault credentials propagate to every thread. In Runlayer's [Agent Account](/platform-agent-accounts) setup guide, selecting **Claude Managed Agents** generates a renewable OBO credential. It exchanges the current user's Runlayer access token for an OBO token with `offline_access`, then stores the refresh token and Agent Account client credentials in the `mcp_oauth` Vault credential so Anthropic can refresh it. The Runlayer user must have an active delegation. ### Connect tools Store the Runlayer credential in a Claude Vault: use `mcp_oauth` for native user OAuth or generated OBO, or a static bearer that your service updates for M2M. Add the Runlayer endpoint to the agent's `mcp_servers`, enable its `mcp_toolset`, and attach the correct Vault when creating the session. A session's Vault IDs cannot change, so one shared session cannot safely switch users between turns. Credential rotation within an attached Vault propagates to running sessions. ### Apply policies The generated test sample uses unrestricted networking and `always_allow` for MCP. In production, use `limited` networking and allow only the Runlayer endpoint and other required hosts. Set MCP approval behavior explicitly, and omit Bash, write, and other built-in tools unless the agent needs them. Disable overlapping built-ins where actions must pass through Runlayer, including `web_fetch` and `web_search`. Claude's environment network allowlist does not constrain those two tools. Claude custom tools execute in your application. Wrap sensitive executors with the Hooks SDK's `run_tool` path when they need Runlayer policy and scanning. Claude does not validate MCP connectivity when creating a session and can continue after an MCP server fails. When governed tools are required, treat `mcp_connection_failed_error` and `mcp_authentication_failed_error` as blocking errors and stop the workflow. ### Monitor activity Runlayer records the Agent Account, delegated user when configured, tool call, policy result, and outcome in Audit Logs. For application-executed custom tools, enable the matching [Hooks SDK](/runlayer-hooks-sdk#getting-started) session monitoring client before sending tool events. Claude Managed Agents does not expose a per-session dynamic MCP header for `x-runlayer-session-id`, and Runlayer does not ingest its managed-session event stream into Sessions. Monitor Claude `session.error` events for failed MCP connections and its credential refresh-failure webhook for `mcp_oauth` renewal failures. ### Learn more * [MCP connector](https://platform.claude.com/docs/en/managed-agents/mcp-connector) * [Vaults](https://platform.claude.com/docs/en/managed-agents/vaults) * [Environments](https://platform.claude.com/docs/en/managed-agents/environments) * [Tools](https://platform.claude.com/docs/en/managed-agents/tools) * [Permission policies](https://platform.claude.com/docs/en/managed-agents/permission-policies) [Cloudflare Agents](https://developers.cloudflare.com/agents/) is a stateful agent runtime built on Workers and Durable Objects. Each agent instance can keep SQLite state, WebSocket connections, schedules, and recoverable work. ### Configure identity For a user-facing agent where Runlayer user identity is sufficient, prefer Cloudflare's native MCP OAuth flow. Runlayer supports the discovery, authorization-code, refresh, and dynamic-registration flow that Cloudflare can manage for the connection. Use a Runlayer [Agent Account](/platform-agent-accounts) when the agent also needs its own M2M or OBO identity. Bind each Durable Object and MCP connection to one principal or conversation, keep client credentials in Worker secrets, and never share a token-bearing connection across callers. ### Connect tools Add the Runlayer Streamable HTTP endpoint with `addMcpServer` and a stable server ID. For user OAuth, complete the native authorization flow; Cloudflare persists and refreshes the resulting credential. For Agent Account M2M or OBO, pass the bearer in custom headers. Cloudflare persists those headers and calling `addMcpServer` again is idempotent, so replace the connection with `removeMcpServer` and `addMcpServer` before the bearer expires. Use this path only when agent identity is worth the added rotation lifecycle. If the Agent instance name contains a user or session identifier, Cloudflare's default OAuth callback can expose it. Set `sendIdentityOnConnect: false` and use a custom `callbackPath` and callback route before enabling that OAuth path. ### Apply policies Worker tools, direct bindings, `fetch`, Browser, AI Search, Sandbox, Code Mode, and Workflows can reach systems without crossing Runlayer. Disable overlapping capabilities or route sensitive actions through Runlayer when they must be governed. ### Monitor activity Every proxied call appears in Runlayer Audit Logs. Include a stable application conversation ID or explicit Cloudflare Session API ID as `x-runlayer-session-id`. Use a Durable Object ID only when one object represents one conversation; do not use a WebSocket connection ID, which changes across reconnects. Use Cloudflare observability and Tail Workers for model, message, exception, and runtime activity beyond Runlayer's proxied calls. ### Learn more * [Agents MCP guide](https://developers.cloudflare.com/agents/tools/mcp/) * [MCP client API](https://developers.cloudflare.com/agents/model-context-protocol/apis/client-api/) * [Session API](https://developers.cloudflare.com/agents/runtime/lifecycle/sessions/) * [Runtime observability](https://developers.cloudflare.com/agents/runtime/operations/observability/) Google now documents this platform as **Gemini Enterprise Agent Platform**. It includes Agent Runtime for ADK and custom agents, Agent Studio for visual agent building, and the pre-GA Managed Agents API. Existing SDK and API resources may still use the **Vertex AI Agent Engine** and `ReasoningEngine` names. ### Configure identity Create a Runlayer [Agent Account](/platform-agent-accounts). Use `AgentRegistry.header_provider` to resolve a current M2M or OBO token for each invocation. For OBO, map the application caller to a delegated Runlayer user before minting the token. Google's generic three-legged OAuth flow does not replace Runlayer's OBO exchange. Direct `McpToolset` headers are static and suitable only for short-lived tests. In a custom runtime, construct the agent and toolset per invocation when a dynamic provider is unavailable. Dynamic or request-scoped headers prevent one caller's token from leaking into another caller's run. ### Connect tools Use Agent Runtime for the production path. In deployed ADK agents, register the Runlayer MCP endpoint with Agent Registry and expose it through `McpToolset`. This requires Application Default Credentials and `google-adk[a2a]>=1.29.0`. Other frameworks on Agent Runtime can use the same Streamable HTTP pattern. The pre-GA Managed Agents API accepts Streamable HTTP MCP with stored headers, but cannot resolve a fresh Runlayer token per call. Use it only for short-lived testing while that interface remains pre-GA. Agent Studio currently accepts only unauthenticated MCP servers, so it cannot connect to an authenticated Runlayer endpoint. ### Apply policies Use the Hooks SDK's local-tool enforcement path for function tools that should receive Runlayer policy and scanning. Configure Agent Gateway and network egress policies to allow Runlayer as the approved MCP destination when direct HTTP and alternate MCP paths should be closed. Restrict Google Search, Code Execution, and unwrapped function tools where they overlap. ### Monitor activity Have the dynamic header provider set `x-runlayer-session-id` from the stable ADK or Agent Runtime session in the current invocation context. Keep that value consistent with lifecycle events sent from ADK callbacks through the [Hooks SDK](/runlayer-hooks-sdk). Custom runtimes can set the same header when constructing a request-scoped toolset. Before sending lifecycle events, enable the matching [Hooks SDK](/runlayer-hooks-sdk#getting-started) session monitoring client. ADK callback-to-Hooks lifecycle mapping is custom instrumentation; Runlayer's ADK adapter wraps local tools but is not a lifecycle adapter. Keep Agent Runtime sessions, Cloud Observability, and Cloud Trace enabled for runtime-wide telemetry beyond Runlayer-visible activity. ### Learn more * [Gemini Enterprise Agent Platform](https://docs.cloud.google.com/gemini-enterprise-agent-platform/agents) * [Agent Runtime](https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/runtime) * [Managed Agents API](https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/managed-agents) * [ADK MCP tools](https://adk.dev/tools-custom/mcp-tools/) * [Agent Registry authentication](https://docs.cloud.google.com/agent-registry/authenticate-toolsets) * [Google ADK framework recipe](/agent-frameworks#google-adk) [LangSmith Deployment](https://docs.langchain.com/langsmith/deployment) runs LangGraph applications with durable threads, runs, streaming, persistence, and horizontal scaling in cloud, hybrid, self-hosted, or standalone topologies. ### Configure identity Create a Runlayer [Agent Account](/platform-agent-accounts). For autonomous runs, keep its client credentials in deployment secrets and mint an M2M token at runtime. For OBO, use Agent Server custom authentication to resolve the caller, then scope the token-bearing MCP client to that delegated Runlayer user. LangGraph state can outlive an individual process or run. Persist only stable identity references in graph state, then resolve and mint a current token for each invocation. Never persist a bearer in graph state. ### Connect tools Use `langchain-mcp-adapters` and `MultiServerMCPClient` to connect the deployed graph to a Runlayer Streamable HTTP endpoint. A durable run can outlive Runlayer's one-hour bearer. Refresh before each tool call or use the adapter's custom `httpx.Auth` path instead of static headers for the life of the run. ### Apply policies For LangChain `create_agent`, prefer one custom middleware with `wrap_tool_call` that sends eligible local tools through the Hooks SDK's `run_tool` path. Exclude tools already proxied by Runlayer to avoid double enforcement. For raw `StateGraph` or custom runtimes, wrap sensitive executors directly. Restrict provider-hosted tools, subprocesses, graph-node API or database calls, and other paths that overlap with governed tools. Ensure the graph cannot fall back to an ungoverned equivalent after a denial. ### Monitor activity Send the LangGraph `thread_id` as `x-runlayer-session-id`. Reuse that value for every run in the same durable conversation and for lifecycle events sent through the [Hooks SDK](/runlayer-hooks-sdk). Enable the Python [Hooks SDK](/runlayer-hooks-sdk#getting-started) session monitoring client. For `create_agent`, use the same middleware's `before_agent` and `after_agent` hooks for lifecycle events; instrument raw graphs explicitly. Runlayer does not import LangSmith traces into Sessions. ### Learn more * [LangChain MCP adapter](https://docs.langchain.com/oss/python/langchain/mcp) * [LangSmith custom authentication](https://docs.langchain.com/langsmith/custom-auth) * [LangChain middleware](https://docs.langchain.com/oss/python/langchain/middleware/custom) * [Runlayer Hooks SDK](/runlayer-hooks-sdk) The current hosted runtime is **Foundry Hosted Agents**. It deploys Python or C# containerized agents, including Agent Framework agents, on Microsoft-managed infrastructure with a dedicated Entra identity. Each agent session has a persistent filesystem, but compute deprovisions after 15 idle minutes and session state is deleted after 30 days of inactivity. The Responses protocol manages conversation history; the Invocations protocol leaves conversation state to the application. ### Configure identity Create a Runlayer [Agent Account](/platform-agent-accounts). Store its client credentials in Key Vault or another managed secret store; do not bake or log raw credentials. Mint and refresh M2M or OBO tokens in the container. For OBO on hosted-agent protocol 2.0.0, read Foundry's generated `x-agent-user-id` through Python `get_request_context()` or .NET `FoundryAgentRequestContext.Current`. Treat it as an opaque key and map it to a Runlayer user server-side; do not trust `x-client-*` headers as identity. Then perform the Runlayer token exchange per request. When a middle tier delegates a user through `x-ms-user-identity`, grant that tier the `Microsoft.CognitiveServices/accounts/AIServices/agents/endpoints/UserIdentityImpersonation/action` data action. Foundry's Entra identity and Entra OBO flow do not automatically establish Runlayer identity. ### Connect tools In a Python Agent Framework container, add the Runlayer endpoint with `MCPStreamableHTTPTool` and inject a current token with its dynamic `header_provider`. In C#, use the official MCP C# SDK, convert discovered MCP tools to `AITool` instances, and scope the client and transport headers to the current caller and run. A static Toolbox secret is a poor fit for a one-hour Runlayer token. Hosted Agents is generally available. The `agent-framework-foundry-hosting` package used by the Agent Framework hosting integration remains prerelease. ### Apply policies In Python Agent Framework agents, use Function Calling middleware to send eligible local tools through the Hooks SDK's `run_tool` path; exclude MCP calls already proxied by Runlayer. Restrict Code Interpreter, Web Search, Azure AI Search, OpenAPI, A2A, direct calls, and Toolbox MCP connections that overlap with governed tools. Route a Toolbox MCP connection to Runlayer when it should inherit Runlayer controls. ### Monitor activity Add `x-runlayer-session-id` through the Python header provider or C# transport headers. For Responses, use the stable conversation ID. For Invocations, use the application's stable session ID. `agent_session_id` identifies sandbox and filesystem continuity, not Responses conversation history. In Python containers, enable the Python [Hooks SDK](/runlayer-hooks-sdk#getting-started) session monitoring client, then use Agent Run middleware to send lifecycle events through the SDK. Runlayer has no native Foundry or Agent Framework adapter and no C# Hooks SDK. Keep Application Insights or OTLP enabled for runtime-wide telemetry. ### Learn more * [Hosted Agents concepts](https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/hosted-agents) * [Hosted-agent contract](https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/hosted-agent-contract) * [Agent Framework hosting](https://learn.microsoft.com/en-us/agent-framework/hosting/foundry-hosted-agent) * [Agent Framework middleware](https://learn.microsoft.com/en-us/agent-framework/agents/middleware/) * [Hosted-agent permissions](https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/hosted-agent-permissions) OpenAI offers several agent surfaces rather than one hosted runtime. This guide covers Workspace Agents in ChatGPT, the [Agents SDK](https://developers.openai.com/api/docs/guides/agents), and the Responses API. The three surfaces use different connection and identity paths: | Surface | Runlayer connection | Identity and session coverage | | ---------------- | ---------------------------------------- | ------------------------------------------------------------------------------------------- | | Workspace Agents | Approved Runlayer Plugin app | Plugin OAuth and Audit Logs; optional Compliance Logs import into Sessions | | Agents SDK | Hosted or application-managed MCP server | Current token per caller; Hooks SDK when the application owns the run | | Responses API | Remote MCP tool | Current `authorization` on every request; custom lifecycle events in the owning application | ### Configure identity #### Workspace Agents Use an **End-user account** connection when each invoker should retain their own Runlayer identity; Plugin OAuth establishes that user. No Agent Account is needed for this path. An **Agent-owned** connection is shared by the agent. Scheduled, Slack, and API runs act as that connection owner rather than the triggering user. Use a dedicated service user with narrowly scoped Runlayer policies when autonomous runs need this model. #### Agents SDK Create a Runlayer [Agent Account](/platform-agent-accounts). Construct M2M or OBO tool and server instances per caller instead of sharing an OBO instance. Refresh the bearer before expiry. #### Responses API Create an Agent Account and mint a current M2M or OBO bearer for each request. OpenAI does not persist the MCP authorization secret. ### Connect tools #### Workspace Agents Add [Runlayer Plugin as an approved ChatGPT app](/runlayer-plugin#openai-org-install) and enable it for the agent. #### Agents SDK Use a hosted MCP tool or an application-managed Streamable HTTP MCP server. #### Responses API Add the Runlayer endpoint as a remote MCP tool and send the current bearer in its `authorization` field on every request. ### Apply policies Plugin calls inherit the same Runlayer policies as proxied MCP calls. For hosted and Responses MCP tools, set `allowed_tools` and `require_approval` as an additional capability boundary. The TypeScript `hostedMcpTool` helper maps these to `allowedTools` and `requireApproval`. For an application-managed `MCPServerStreamableHttp`, use SDK-side `toolFilter` or `createMCPToolStaticFilter`. The TypeScript client does not document a local `requireApproval` constructor option. Wrap local tools that need Runlayer enforcement. Native tools, other Workspace apps, and unwrapped function tools do not cross Runlayer. ### Monitor activity For code-first agents, enable the matching [Hooks SDK](/runlayer-hooks-sdk#getting-started) session monitoring client before emitting lifecycle events. #### Workspace Agents Runlayer records Plugin calls in Audit Logs. For enterprise ChatGPT workspaces, optionally configure the [OpenAI Compliance Logs import](/platform-sessions#web-chat-and-compliance-imports) to add prompts and responses to Sessions. The import is delayed and monitor-only and does not include files, actions, or tool calls; use Audit Logs for governed Plugin activity. #### Agents SDK Send the stable application or agent session ID as `x-runlayer-session-id` with `hostedMcpTool` headers or `MCPServerStreamableHttp` request headers. Scope static tool or server instances to both the caller and Runlayer session, or use a custom fetch that injects current request context. Use Runlayer's OpenAI Agents tool wrappers and [Hooks SDK](/runlayer-hooks-sdk) lifecycle events to add local tools and the agent run to Sessions. #### Responses API Rebuild the remote MCP `tools` entry on every request with the current `x-runlayer-session-id`. Emit generic Hooks SDK lifecycle and tool events around the application's function execution. OpenAI Agents wrappers do not wrap direct Responses tools. Runlayer does not import OpenAI traces into Sessions. ### Learn more * [OpenAI MCP and connectors](https://developers.openai.com/api/docs/guides/tools-connectors-mcp) * [Agents SDK observability](https://developers.openai.com/api/docs/guides/agents/integrations-observability) * [OpenAI Agents SDK framework recipe](/agent-frameworks#openai-agents-sdk) * [Runlayer compliance imports](/platform-sessions#web-chat-and-compliance-imports) [Vercel Eve](https://vercel.com/blog/introducing-eve) is a filesystem-first TypeScript framework for durable agents with sandboxes, approvals, subagents, channels, schedules, and evals. Eve remains in preview. Pin the Eve version listed in the [Hooks SDK version matrix](/runlayer-hooks-sdk#getting-started) until Runlayer verifies a newer one. ### Configure identity Create a Runlayer [Agent Account](/platform-agent-accounts) and select **Vercel Eve** in its setup guide. The generated renewable auth callback is fixed-user OBO: it falls back to the Runlayer user who generated the sample. Use that unchanged only for a deployment bound to that one user. For an autonomous M2M agent, remove the generated subject and subject-type arguments from `getAccessToken`, leaving only the Agent Account client ID and secret. For a shared agent, change the generated app-scoped auth to `principalType: "user"`. Eve passes the authenticated principal to `getToken` and keys its token cache by issuer and user. Map that principal to a delegated Runlayer user and mint the OBO token inside `getToken`. The active Eve session must already have an authenticated user principal or Eve rejects the connection with `reason: "principal_required"`. Use a top-level `auth: ({ session }) => ({ ... })` resolver only when the auth provider depends on session context. Do not swap the generated fixed subject at runtime; that can reuse one user's cached token for another. ### Connect tools Add the generated `agent/connections/runlayer.ts` to the Eve application. It provides the Runlayer MCP endpoint, renewable authentication, and a header callback for the active Eve session. Give the connection a clear `description`, such as "Runlayer-governed enterprise tools and connectors," so Eve's `connection_search` can select it reliably. ### Apply policies Use Eve `tools.allow` and a connection `approval` policy as additional boundaries for sensitive or write tools. The Eve lifecycle hook is fail-open and observe-only. It records Eve-local tools but cannot block or rewrite them. Route sensitive actions through Runlayer MCP when they must fail closed. ### Monitor activity Keep the generated header callback that sends Eve's stable `session.id` as `x-runlayer-session-id`. Enable the **Vercel Eve** [session monitoring client](/runlayer-hooks-sdk#getting-started), then install the generated `agent/hooks/runlayer.ts` native hook. List every Eve MCP connection slug in the hook's `mcpConnectionNames`, including `runlayer`, so MCP tools are classified correctly. Add or re-export the hook in declared and remote subagents that need child visibility. ### Learn more * [Runlayer Eve setup](/runlayer-hooks-sdk#vercel-eve) * [Eve overview](https://eve.dev/) * [Eve MCP connections](https://github.com/vercel/eve/blob/main/docs/connections/mcp.mdx)