Securely exposing tools to large models with stateless connector architectures
Large language models become materially more useful when they can search internal knowledge, create tickets, query business systems, trigger workflows, or operate specialized software. They also become more dangerous. A model that can invoke a tool is no longer merely generating text: it is participating in a chain of identity, authorization, data handling, and potentially irreversible action. Secure tool exposure therefore cannot be treated as a plug-in configuration task. It is an architecture and operations discipline.
A stateless connector architecture is a practical way to build that discipline. In this pattern, the protocol server does not depend on long-lived protocol-held session state to remember who the caller is or what they may do. Instead, a connector, gateway, identity broker, and policy layer establish and verify context for each meaningful interaction. This approach aligns with the Model Context Protocol (MCP) shift toward a stateless protocol layer, but it only improves security when teams deliberately move session handling, authentication, authorization, isolation, inspection, and auditing into well-designed supporting layers.
Why stateless tool exposure changes the security model
MCP is designed around a client-host-server architecture with clear security boundaries. The MCP architecture page for the 2025-06-18 specification describes those roles, while Google’s MCP overview and MCP Go SDK documentation note the move to a stateless protocol in the 2026-07-28 specification. The shift can simplify tool-serving systems because a remote server no longer needs to preserve protocol session state as its core operating model.
However, statelessness does not eliminate identity or continuity. A model may still need to make several related calls: discover available tools, retrieve a record, request approval, and execute an action. The difference is that security-relevant continuity should be carried and checked explicitly through authenticated tokens, request context, policy decisions, correlation identifiers, and controlled workflow state rather than being silently assumed from a durable server-side session.
Stateless does not mean context-free. It means that context must be explicit, verifiable, bounded, and re-evaluated instead of being inherited from an opaque long-lived connection.
This distinction matters because a persistent session can become an accidental security container. It may retain elevated credentials, stale authorization decisions, a prior tenant selection, or assumptions about the safety of an earlier tool response. In a stateless connector design, the system has a better opportunity to verify the principal, intended audience, requested scope, tenant, and policy conditions at the point of use.
What moves out of the protocol server
When the protocol layer is stateless, teams should decide exactly which surrounding component owns each responsibility. Leaving those responsibilities implicit is one of the most common ways to create a connector that appears simple but is difficult to secure.
Connector or gateway:
manages the model-facing connection, request normalization, protocol translation, rate controls, and tool routing.
Identity provider or credential broker:
issues, exchanges, or retrieves credentials appropriate to the user, workload, and target service.
Policy decision point:
evaluates whether a specific tool operation is allowed under current identity, scope, resource, and risk conditions.
Policy enforcement point:
blocks, transforms, constrains, or permits the actual request at the connector or tool boundary.
Execution environment:
isolates the code and dependencies used to invoke a tool, especially when connectors run extensions or user-configured integrations.
Audit and detection pipeline:
records the request, authorization basis, tool input, relevant output metadata, and resulting action for investigation and monitoring.
Google Cloud’s framing of remote MCP servers as enterprise-ready emphasizes governance, security, and access control. That framing is useful because it avoids treating a remote MCP server as a standalone endpoint. In an enterprise deployment, the server is part of a broader control plane and must participate in access governance even if the protocol itself is stateless.
Start with a threat model for the connector, not just the model
Tool-connected models face threats that ordinary API clients do not fully capture. The model can be influenced by untrusted text, retrieved content, tool descriptions, and tool returns. It can select among available actions probabilistically, and it may be asked to complete a broad objective rather than a narrowly coded transaction. These properties make the connector boundary a critical security control point.
Recent security research on MCP and tool-integrated agents reinforces the concern. One paper argues that MCP changes the risk profile by replacing static, developer-controlled integrations with more dynamic, user-driven agent systems. Another analysis highlights prompt-injection vulnerabilities in tool-integrated LLM agents and states that MCP had no formal security analysis at the time of that paper’s publication. The conclusion is not that tool use is impossible to secure; it is that conventional API trust assumptions are insufficient on their own.
Model the assets and trust boundaries
A useful threat model begins by listing assets that must not be disclosed, corrupted, or used without authority. Include customer data, source code, credentials, financial systems, production infrastructure, private files, business records, and the ability to send messages or alter configurations. Also identify the identities in play: the human user, the model application, the connector workload, the tool service, and any downstream service account.
Next, draw the boundaries where trust changes. A user prompt crossing into the model is one boundary. A model-generated tool request crossing into a connector is another. The connector’s call into a SaaS platform, internal API, database, or workflow system is yet another. Every boundary should have an explicit answer to three questions: who is acting, what is permitted, and what evidence will be retained?
Threats that deserve first-class controls
Prompt injection:
untrusted content attempts to redirect the model toward unauthorized instructions or unsafe tool use.
Tool-return poisoning:
a tool response contains adversarial text that induces the agent to take a harmful follow-on action.
Confused deputy behavior:
the connector uses its own broad privilege to perform an action that the requesting user should not be able to perform.
Credential replay or leakage:
a token, secret, or session artifact is exposed to the model, stored in logs, or reused outside its intended audience.
Connector substitution:
a user or administrator connects an unreviewed remote tool that has a misleading purpose, unexpected behavior, or excessive scopes.
Cross-tenant or cross-workspace access:
a request reaches data associated with a different organization, user, or environment because context was not bound and checked.
Unsafe action chaining:
individually allowed read and write operations combine into an outcome that violates a business control.
Anthropic’s Remote MCP guidance is especially relevant here. It warns that custom connectors can access and take action in services not verified by Anthropic. The guidance says suspicious tool calls may be blocked, but it still recommends isolating Claude from sensitive data. That is the right architectural posture: platform safeguards are valuable, but they do not remove the customer’s responsibility to control data access, tool privilege, and deployment boundaries.
Build an identity chain that preserves least privilege
The safest connector does not give the model a general-purpose master credential and hope its instructions remain safe. It establishes an identity chain from the requesting user or workload to the connector and then to the target tool. At each step, the system should narrow authority to the task, resource, tenant, and duration that are actually required.
Anthropic’s connector documentation describes a crucial principle: when a tool is connected, Claude can only see and do what the user can already see and do in that tool. This permission inheritance model is a strong foundation for least privilege. It reduces the chance that the model becomes a privileged deputy with access beyond the human or application that invoked it.
Use delegated access where the task is user-specific
For user-facing tools such as document repositories, issue trackers, calendars, and customer systems, delegated authorization is generally the appropriate model. The connector should obtain authority that represents the user’s permitted access, not substitute a broadly privileged shared integration account. The downstream service remains the authority on whether that user can read a file, update a case, or send a message.
Anthropic’s MCP Directory Policy requires OAuth 2.0 with recognized certificates for remote MCP servers that need authentication. That requirement supports a mature delegated-access pattern: authentication is not a custom secret exchange, and the user or organization can rely on a recognizable authorization mechanism. OAuth alone is not sufficient, but it provides a better foundation than embedding durable API keys in connector configuration.
Broker credentials at runtime
AWS Prescriptive Guidance recommends secure credential brokering, runtime credential retrieval, and isolated tool access for generative AI systems. In a stateless architecture, runtime credential retrieval is particularly natural. The connector can request a short-lived, audience-restricted credential only when it must call a target service, rather than storing a long-lived credential as de facto connector state.
Bind credentials to a specific target audience or service where supported.
Request narrowly scoped authorization for the operation class, such as read-only search rather than administrative management.
Use short expiration periods and avoid passing bearer tokens into model context.
Keep secrets in a broker or secure runtime mechanism, not in prompts, tool descriptions, source repositories, or ordinary application logs.
Require explicit reauthorization when a new tenant, resource class, or high-impact action is requested.
For machine-to-machine operations, a workload identity may be necessary. Even then, it should be separate by environment and tool domain. A connector that can search a development knowledge base should not automatically have authority to modify production infrastructure. The practical objective is to make the effective permission set small enough that an incorrect model decision has a limited blast radius.
Make policy decisions at request time, not at installation time
A remote connector may be approved by an administrator or authorized by a user, but approval is not a permanent proof of safety. Anthropic notes that remote tools can change behavior after approval, meaning install-time trust may no longer apply. This is one of the strongest arguments for stateless connector architecture: each request can be evaluated against current policy and current risk signals rather than inheriting trust from a prior connection event.
Runtime authorization should consider more than whether a token is valid. A valid token might still be inappropriate for a particular action, destination, time, device posture, workspace, data category, or workflow state. The policy engine should therefore receive structured context from the connector before the request reaches the tool.
A practical request-time policy input set
The exact attributes vary by organization, but a defensible policy decision often includes the authenticated user or workload identity, organization and tenant, tool name and version, requested method, target resource, requested scopes, data classification, environment, destination, and action risk. It should also include whether the request is read-only or mutating, whether it is a bulk operation, and whether the model is acting autonomously or under a human approval step.
For example, a policy can allow a connector to search documents within the caller’s workspace while denying export of content from a restricted repository. It can permit creation of a draft support response while requiring confirmation before the response is sent. It can allow a deployment-status query from a production environment while denying production changes outside a designated change workflow.
Separate discovery from execution
Tool discovery is valuable, but a broad tools list can itself expose unnecessary capabilities. The OpenAI tunnel-client connector documentation illustrates a sequence in which OAuth completes first, followed by initialization, tools/list, and tool calls through the MCP endpoint. This flow is useful conceptually because authentication occurs before runtime tool traffic. A secure implementation can go further by filtering discovery results according to the caller’s current identity and policy.
Authenticate the user or workload and establish the organization context.
Initialize the connector with a bounded configuration and an authenticated channel.
Return only the tools and operations the caller is eligible to discover.
Validate the specific tool request against schema, allowlists, and policy.
Obtain or exchange runtime credentials only for the permitted downstream target.
Invoke the tool in an isolated execution context.
Inspect and log the result before it is returned to the model or used in a subsequent action.
This approach prevents a common error: treating tools/list as a harmless metadata operation. Tool descriptions influence model planning. A malicious or overly broad description can shape which actions the model attempts, so discovery metadata deserves provenance, review, and policy controls too.
Reduce network exposure with outbound-only connectivity and segmentation
Network architecture remains important even when identity and policy are strong. Anthropic states that outbound-only MCP tunnels avoid opening inbound firewall ports or exposing services publicly. For many deployments, this is a substantial reduction in attack surface. A private service can establish an outbound connection to a managed endpoint or relay rather than accepting unsolicited inbound traffic from the internet.
Outbound-only connectivity is not a substitute for authorization. A compromised connector could still make harmful outbound calls if egress is unrestricted. Its value is that it removes one major exposure path and lets teams apply more deliberate controls to where a connector can connect, how it authenticates, and which services it may reach.
Design the network path deliberately
Keep tool services private where possible.
Avoid making an internal database, workflow engine, or administrative API publicly reachable just to support model access.
Constrain egress.
Allow connector workloads to reach only approved identity endpoints, relay endpoints, and downstream services.
Segment by trust domain.
Separate connectors for finance, engineering, HR, customer support, and production operations when their data sensitivity and permissions differ.
Encrypt in transit.
Use authenticated, encrypted connections and validate certificates rather than accepting unauthenticated endpoints.
Limit inbound management paths.
Administrative configuration, diagnostics, and deployment channels should be distinct from routine tool traffic.
OpenAI’s security materials emphasize layered controls that include network segmentation, workload isolation, and encryption. Those layers apply directly to connector systems. No one layer can reliably defend against malicious prompt content, an over-permissive token, an unreviewed connector, and a vulnerable execution environment at the same time. Layering makes a single failure less likely to become a full compromise.
AWS provides another concrete implementation direction through native VPC support for secure tool access. The important architectural concept is not a dependency on one provider’s product. It is that tool execution should be able to reach private resources through controlled network paths, with network policy reinforcing application-level identity and authorization.
Isolate execution and treat tool output as untrusted input
Stateless protocols should be paired with isolated execution. If multiple users, tenants, or tool calls share mutable memory, files, or credentials, a connector can reintroduce the very implicit state that stateless design is meant to avoid. Isolation also limits the damage if a tool package, dependency, or response behaves unexpectedly.
AWS highlights microVM-based session isolation and separate CPU, memory, and file-system resources for AgentCore Runtime. This is a concrete example of the desired property: each tool-execution session can be separated rather than relying on a shared process state. Depending on the environment, teams may use microVMs, containers, sandboxes, isolated worker processes, or other mechanisms, but the security objective is consistent.
Controls for the execution boundary
Start each invocation with a clean or tightly controlled runtime. Mount only the files it needs, inject only temporary credentials, limit network destinations, and set resource limits. Prevent tool code from reading unrelated connector configuration or credentials. For sensitive operations, consider one-time execution workers that terminate after the transaction completes.
Then address a less obvious issue: tool output. A response from a trusted business system can still contain user-authored, attacker-controlled, malformed, or misleading content. Anthropic warns that once a poisoned tool return steers an agent toward exfiltration, logs may show only a successful authorized API call. Traditional audit trails may therefore reveal the final action without explaining that an adversarial tool return influenced the model’s decision.
Harden the model-to-tool feedback loop
Do not pass every tool response directly into a model as if it were a trusted instruction. Preserve the distinction between data and commands. Tool results should be schema-validated where possible, size-limited, categorized, and marked as untrusted external content for the model orchestration layer. High-risk strings, unexpected URLs, embedded instructions, or requests to disclose secrets should trigger additional inspection or interruption of autonomous action chains.
Use strict input and output schemas for deterministic fields such as identifiers, amounts, destinations, and action types.
Apply allowlists to sensitive destinations, exports, recipients, and resource namespaces.
Require human confirmation for high-impact writes, external communications, credential changes, and broad data exports.
Limit the number and type of chained tool calls an agent may make without review.
Keep raw tool output available for investigation while minimizing unnecessary exposure of sensitive values in ordinary logs.
These controls do not require the system to perfectly detect every prompt injection. They reduce the model’s ability to convert hostile content into privileged action, particularly when the connector enforces destination, scope, and action constraints independently of the model’s reasoning.
Govern the connector fleet as a changing supply chain
A connector fleet is a software supply chain with unusually direct access to data and actions. It includes remote MCP servers, locally deployed adapters, identity integrations, tool schemas, dependency packages, container images, configuration, and approval records. A stateless request path does not make this supply chain safe; it makes ongoing governance even more important because each request may be routed through dynamic components.
Anthropic’s MCP Directory Policy provides useful baseline signals. It requires security review and compatibility checks, OAuth 2.0 with recognized certificates when authentication is needed, and documentation explaining how a server works and its intended purpose. These expectations reduce opaque tool exposure. They also help reviewers distinguish a narrowly scoped connector from a broadly privileged integration with unclear behavior.
Adopt a lifecycle, not a one-time approval
Inventory:
maintain a current record of every connector, server endpoint, owner, intended purpose, data classes, tool methods, authorization model, and dependencies.
Review before enablement:
inspect requested scopes, network paths, endpoint identity, tool descriptions, data flows, and operational ownership.
Stage before production:
test connectors with representative but non-sensitive data and adversarial scenarios, including malformed responses and prompt-injection attempts.
Constrain rollout:
begin with limited users, limited workspaces, read-only methods, or non-production environments where appropriate.
Continuously verify:
watch for endpoint, tool schema, version, scope, or behavior changes after approval.
Revoke quickly:
retain the ability to disable a connector, invalidate credentials, remove discovery visibility, and block methods without waiting for a full deployment cycle.
Organization-level connection controls, described in Anthropic connector help materials, are important here. Users should not necessarily be able to connect arbitrary remote tools to a sensitive organizational environment. Central administrators need the ability to permit approved connectors, constrain where they can be used, and remove access when risk changes.
Documentation is also a security control. A connector should state its owner, purpose, downstream services, permissions, data handling expectations, authentication flow, network requirements, action categories, and support contact. Clear documentation does not guarantee trustworthy behavior, but it makes unexpected behavior easier to detect and gives users meaningful information before they authorize access.
Make observability useful for security decisions
Logging every successful API call is necessary but not sufficient. In a model-driven tool workflow, investigators may need to understand the full sequence: user request, connector selection, available tools, policy decision, credential exchange, normalized tool input, downstream response, any output filtering, and subsequent action. Without that sequence, a harmful outcome can look like an ordinary authorized operation.
The proposed Secure Model Context Protocol (SMCP) research offers a relevant blueprint: unified identity management, mutual authentication, security context propagation, fine-grained policy enforcement, and audit logging. Whether or not an organization adopts that proposal directly, these are sound design goals for a production stateless connector architecture. They make security context portable across components without requiring each component to rely on shared implicit session state.
What an actionable audit record should establish
An audit trail should let a reviewer answer who initiated the activity, which connector and version handled it, what tool and method were selected, what policy allowed or denied the request, which credential class was used, which resource was targeted, and what result followed. Use correlation identifiers that connect events across the model host, connector, identity service, policy engine, execution runtime, and downstream application.
Protect the audit system itself. Logs can contain sensitive prompts, business content, identifiers, and tool arguments. Apply access controls, retention policies, encryption, and redaction appropriate to the data. Record enough to investigate decisions, but do not create a second unrestricted repository of the organization’s most sensitive content.
Use monitoring as a runtime control
Detection should feed back into enforcement. Alerts can identify unusual tool-call volume, attempts to access unfamiliar resource types, newly requested OAuth scopes, changes in server metadata, repeated policy denials, unexpected egress destinations, or sequences that resemble bulk extraction. For a high-risk event, the connector can downgrade to read-only behavior, require human confirmation, suspend a tool, or revoke a temporary credential.
This is especially important because security norms for open tool ecosystems remain underdeveloped. Anthropic’s RFI response on agentic security notes both the competitive value of open protocols and the immaturity of security norms around open tool ecosystems. Teams should plan for changing guidance, new attack patterns, and evolving connector behavior rather than assuming a single security review permanently settles the risk.
Implement a secure stateless connector baseline
A secure deployment does not need to begin with every possible control. It should begin with a baseline that prevents the most consequential failures: public exposure of internal tools, long-lived broad credentials, unbounded tool discovery, unchecked model-directed writes, shared execution state, and insufficient auditability. From there, controls can become more sophisticated as tool coverage and risk increase.
Minimum baseline for production-facing tools
Use authenticated remote connections and avoid exposing internal tool services directly to the public internet when an outbound-only pattern is feasible.
Apply permission inheritance or equivalent delegated authorization so the model does not exceed the caller’s rights.
Use short-lived, runtime-retrieved credentials and keep secrets out of model context.
Evaluate authorization per request with user, tenant, tool, method, resource, scope, and action-risk context.
Filter tools and methods during discovery so users see only capabilities they may legitimately use.
Isolate tool execution and restrict filesystem access, network egress, and credential availability.
Schema-validate tool inputs and treat tool returns as untrusted content that can influence the model.
Require approvals or confirmations for irreversible, externally visible, financially material, or broad-scope actions.
Maintain connector inventory, ownership, review records, version visibility, and rapid disablement procedures.
Record end-to-end audit events and monitor for policy failures, anomalous behavior, and connector changes.
The right balance depends on the tool. A read-only search connector for a low-sensitivity knowledge base may need fewer gates than a connector that can alter infrastructure, transfer money, send external communications, or access regulated data. The principle is to match protections to consequence, not to apply the same generic configuration everywhere.
Securely exposing tools to large models is ultimately a trust-minimization exercise. MCP’s stateless direction can make systems easier to scale and reason about, but only when connector layers explicitly carry the security responsibilities that persistent protocol sessions once obscured. Use delegated and short-lived access, outbound-only and segmented networking, isolated execution, request-time policy checks, untrusted-output handling, fleet governance, and correlated audit evidence. Those controls let organizations gain useful model-to-tool capabilities while keeping authority narrow, observable, and revocable.
There is no basis for assuming that a connector remains safe simply because it was approved, authenticated, or successful yesterday. Remote tools can change, model inputs can be adversarial, and authorized calls can still produce harmful outcomes. A stateless connector architecture gives teams repeated opportunities to verify intent and constrain action at runtime. Treat those opportunities as mandatory security checkpoints, and the connector becomes a controlled mediation layer rather than an unchecked path from generated text to powerful systems.