Agencies and IT teams now ship AI agents that read databases, update CRMs and call internal APIs, not just static sites and REST integrations. Much of that connectivity runs on the Model Context Protocol (MCP), which Anthropic introduced in November 2024. In December 2025 Anthropic donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI. The latest specification revision, 2026-07-28, made the protocol stateless and tightened authorization. The maintainers report close to half a billion monthly downloads across the Tier 1 SDKs.
That growth creates two operational risks that most project plans ignore:
- The agentic handover crisis. When an engagement ends, the agent’s non-human identities (API keys, OAuth grants, service accounts, hosting accounts) are often still tied to the agency’s accounts or to one departed employee.
- The MCP expiration trap. Tokens, schemas, hosting and even protocol features expire or change underneath a running agent, and the failure is often quiet.
Credentials already leak at scale. GitGuardian’s State of Secrets Sprawl 2026 counted 28.65 million new hardcoded secrets in public GitHub commits in 2025. AI-service secrets rose 81% year over year to 1,275,105. The report also found 24,008 unique secrets in public MCP configuration files, 2,117 of them valid. It attributes part of the problem to setup guides that tell users to put keys directly in config files or command-line arguments.
Part 1: The Agentic Handover Crisis
Why agent offboarding differs from a website handover
A traditional handover means transferring a domain, CMS logins and a database backup. An agent deployment spreads credentials across several layers, and each layer may belong to a different account:
| Layer | Typical credential | Common build-time owner |
|---|---|---|
| Model provider | API key, service account or federated identity | Agency org or a developer’s personal account |
| Agent host / MCP client | Config file, environment variables, secrets store | Agency repo or developer laptop |
| MCP server | OAuth client registration or static key it requires from callers | Agency hosting account |
| Upstream tool (CRM, database, Git host, Workspace) | OAuth grant, PAT or database role the server holds | Whichever employee clicked “Authorize” |
| Memory and observability | Vector store keys, tracing keys, cache credentials | Agency SaaS accounts |
The MCP authorization model keeps the two middle credentials separate on purpose. The specification requires an MCP server to accept only tokens issued for itself, and forbids passing a client’s token through to upstream APIs. The server therefore holds its own upstream credential, and you must inventory it separately.
Three failure modes
- The orphaned key. A key created in the agency’s account is hardcoded into the client’s deployment. Offboarding forces a bad choice: revoke it and break production, or leave it active and keep paying for the client’s usage. Anthropic’s documentation says legacy workspace keys keep working whether or not their creator leaves the organization.
- The shared identity trap. The agent runs on one person’s OAuth grant or personal key. The same documentation warns that a shared personal key acts as one person and breaks when they leave. Personal keys are archived when the person is removed from the organization. Anthropic recommends service accounts for shared or automated workloads.
- The shadow execution risk. Credentials nobody remembers keep working after the contract ends, so scripts and agents can still reach client data. If you process a client’s personal data, you may be a processor under GDPR, and that role carries contractual obligations (see Art. 28). Have counsel confirm what applies to your engagements.
A step-by-step handover protocol
Step 1: Map every credential the agent touches. Build the inventory before changing anything. Cover:
- Model provider keys, service accounts and workload identities.
- MCP server hosts (serverless platforms, containers, Cloudflare Workers) and the repos that deploy them.
- Upstream tool credentials: OAuth apps, refresh tokens, PATs, database roles.
- Memory and tracing: vector database keys, cache credentials, observability keys.
- Which MCP packages are in use. For example,
@modelcontextprotocol/server-postgresis deprecated on npm, and the MCP project moved it into an archived repository with no security updates promised.
Step 2: Move ownership to client-controlled accounts. Anthropic supports separate Console organizations with their own members, billing and workspaces. Where the provider offers identity-backed credentials, prefer them. Anthropic’s service-account keys stop working when the service account is archived, so they cannot silently outlive the workload. Role names differ by provider (Anthropic uses Admin, Billing, Developer and User; OpenAI project roles are Owner and Member), so map your handover roles to each provider’s actual names. Give the agency a temporary, scoped role with a documented end date.
Step 3: Rotate rather than transfer. Never hand over production keys that have lived in agency accounts.
- Create new credentials in the client’s account, with an expiration where the provider supports one.
- Put them in the client’s secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical or similar).
- Redeploy or reload the MCP server and agent host.
- Disable the agency-owned key before deleting it. In the Claude Console, Disable is reversible and Delete is permanent, so you can watch logs for failed requests and roll back.
- Delete the old key after a clean observation window.
Step 4: Transfer hosting and configuration. Hand over infrastructure-as-code (Terraform, Dockerfiles or the platform’s equivalent) and repo access, and re-point agent hosts to client-owned endpoints. Keep secrets out of config files, since that is the pattern GitGuardian found leaking. One option for a local server is to launch it through your secrets manager’s CLI, so the config file holds no credentials. Replace <server-package> with the package you use:
{
"mcpServers": {
"crm-tools": {
"command": "doppler",
"args": ["run", "--", "npx", "-y", "<server-package>"]
}
}
}
Who should hold what after handover
| Asset | Holder after handover | Agency’s role during transition |
|---|---|---|
| Model provider account and billing | Client’s own organization | Time-boxed, scoped access |
| API keys and service accounts | Client’s organization | Help create, then relinquish |
| MCP server code and deployment templates | Client, per the contract’s licence terms | Deliver repo, docs and IaC |
| MCP hosting account | Client | Assist with migration |
| Upstream tool OAuth apps and database roles | Client-owned apps and accounts | Re-authorize under client identities |
| Expiry and alert routing | A client-controlled shared mailbox or on-call channel | Configure, then hand off |
Spell out these boundaries in your master services agreement or statement of work. Include a post-handover clause covering run-away agent costs, third-party API changes and who monitors expiry dates. Have a lawyer draft it, because enforceability varies by jurisdiction, and no clause fully removes liability.
Part 2: The MCP Expiration Trap
Why failures go quiet
A broken web page shows an error to a person. An agent calling a dead tool is different. MCP typically returns a failed tool call to the model as an error result, so what happens next depends on the model and the agent loop. Some agents retry, some route around the tool, and some answer from partial information. You cannot predict which. Plan to detect failures outside the agent, and cap the damage inside it:
- Set workspace spend limits and rate limits at the provider. Anthropic supports both per workspace, though not on the Default Workspace.
- Cap retries and loop iterations in your agent framework.
- Add a circuit breaker so a repeatedly failing tool is reported as unavailable.
Four decay points to audit
1. Tokens and keys.
- Google: Google documents that refresh tokens expire after seven days when an external app is in “Testing” status. Published apps can lose tokens after about six months of non-use, or when the user revokes access. Password changes for Gmail scopes and admin policies can also invalidate them.
- Salesforce: Admins choose a refresh token policy for each connected app. The default is valid until revoked, but admins can switch to expiry after a fixed time or after inactivity. Salesforce also offers an idle-TTL limit that caps inactivity at 30 days.
-
Anthropic: Console API keys can be created with presets of 3 hours, 1 day, 7 days or 30 days, a custom duration, or no expiry. Expiry cannot be changed afterward. Anthropic emails the key’s creator 7 days before expiry for keys with a lifetime of at least 14 days, and 1 day before for keys with a lifetime of at least 7 days. If the creator has left, nobody receives the warning. The Admin API reports an
expires_atfield for each key, so you can audit expiry centrally.
2. Tool schema drift. Agents rely on the tool definitions a server publishes (tools/list). If an upstream API renames a parameter, the agent keeps sending the old shape. The 2026-07-28 spec adds cache hints to list results (ttlMs and cacheScope), so clients may legitimately hold a cached catalog until its TTL lapses. Know the TTLs your servers set.
3. Protocol and hosting changes. The July 2026 revision removed the initialize handshake and the Mcp-Session-Id header, so servers that stored state in sessions need rework. It also:
- deprecated Dynamic Client Registration in favor of Client ID Metadata Documents;
- bound client credentials to the issuer that minted them;
- required clients to validate the issuer parameter (RFC 9207) before redeeming an authorization code;
- deprecated the legacy HTTP+SSE transport, with a year-long offramp, and the Roots, Sampling and Logging features, which remain supported for at least twelve months.
Also check where servers run. Local stdio servers run as child processes of the host app, so they stop when it does. Serverless hosts impose cold starts and execution limits, and Cloudflare Workers can now host servers directly.
4. Supply chain.
-
Malicious package: In September 2025, researchers reported that a copycat
postmark-mcpnpm package began BCC’ing every email to an attacker-controlled address from version 1.0.16. Postmark said it had no involvement. - Hosting platform flaw: A path traversal flaw in Smithery’s MCP hosting exposed a token controlling more than 3,000 hosted apps. The issue was fixed within two days of disclosure in June 2025, and there was no indication of exploitation.
Pin versions, review where servers come from, and prefer servers maintained by the vendor of the service they connect to.
A hardening blueprint
1. Centralize secrets and track expiry. Keep credentials in a secrets manager, not in MCP config files or committed .env files. Record an expiry date and a monitored notice contact for every credential. Alert well ahead of expiry, for example at 30, 14 and 3 days. Where the provider supports it, favor short-lived credentials. Anthropic’s Workload Identity Federation swaps static sk-ant-api keys for short-lived tokens issued from an identity provider you already trust. Anthropic notes that federation is only as strong as the identity provider’s configuration.
2. Follow the authorization spec for remote servers. The spec treats authorization as optional, but HTTP-based servers that support it must act as OAuth 2.1 resource servers. Clients must use PKCE and the RFC 8707 resource parameter. Servers must reject tokens not issued for them. The spec says authorization servers should issue short-lived access tokens, and for public clients they must rotate refresh tokens. For stdio servers, credentials come from the environment instead.
3. Put a gateway in front of production servers. The 2026-07-28 spec puts method and tool names in Mcp-Method and Mcp-Name HTTP headers, so gateways, rate limiters and WAFs can route and authorize without parsing request bodies. A gateway can centralize audit logging, rate limiting and circuit breaking. It can also validate calls against known schemas.
4. Run synthetic checks on a schedule. The following sketch connects to a remote server, lists its tools and fails when the tool list is empty or any input schema differs from a stored baseline. It uses the current TypeScript SDK v2 packages. If you are still on the v1 @modelcontextprotocol/sdk package, the import paths differ. For protected servers, supply a dedicated, least-privileged audit credential as the SDK’s auth documentation describes. Servers with many tools also return paginated results.
import { createHash } from "node:crypto";
import { readFile } from "node:fs/promises";
import { Client, StreamableHTTPClientTransport } from "@modelcontextprotocol/client";
const SERVER_URL = new URL(process.env.MCP_SERVER_URL!);
// Baseline format: { "tool_name": "<sha256 of inputSchema>" }
const BASELINE_PATH = "./tool-baseline.json";
const fingerprint = (schema: unknown) =>
createHash("sha256").update(JSON.stringify(schema)).digest("hex");
async function auditMcpServer(): Promise<void> {
const client = new Client({ name: "mcp-audit", version: "1.0.0" });
try {
await client.connect(new StreamableHTTPClientTransport(SERVER_URL));
const { tools } = await client.listTools();
if (tools.length === 0) throw new Error("Server connected but returned zero tools");
const baseline: Record<string, string> = JSON.parse(
await readFile(BASELINE_PATH, "utf8"),
);
const drift = tools.filter((t) => baseline[t.name] !== fingerprint(t.inputSchema));
const missing = Object.keys(baseline).filter((n) => !tools.some((t) => t.name === n));
if (drift.length || missing.length) {
throw new Error(
`Schema drift: changed or new [${drift.map((t) => t.name)}], missing [${missing}]`,
);
}
console.log(`MCP audit passed: ${tools.length} tools match baseline`);
} catch (error) {
console.error("MCP audit failed", error);
process.exit(1); // let CI or your scheduler raise the alert
} finally {
await client.close();
}
}
auditMcpServer();
Appendix: MCP Credential and Integration Audit Template
Use this during client offboarding and quarterly reviews. Fill one row for each credential, including upstream credentials held by MCP servers.
| Layer | Asset | Owner (client / agency) | Credential type | Expiry date or “none” | Notice contact | Rotation owner |
|---|---|---|---|---|---|---|
| Model provider | API key / service account / federated identity | |||||
| MCP server | Host account and deploy pipeline | Hosting credentials | ||||
| MCP server | Authorization setup (OAuth client, issuer) | OAuth client registration | ||||
| Upstream tool | CRM, database, Git host, Workspace | OAuth grant / PAT / DB role | ||||
| Memory and observability | Vector store, cache, tracing | API key |
Offboarding checklist
- Model provider accounts and billing live in client-owned organizations.
- Agency-created keys are replaced with client-created credentials. Old keys are disabled, observed for failures, then deleted.
- No agent runs on an individual employee’s personal key or OAuth grant.
- No MCP config file or repository contains plaintext secrets.
- No deprecated or archived MCP servers remain in the stack.
- Infrastructure-as-code and deployment documentation are delivered.
- Spend limits, rate limits and expiry alerts point to client-controlled contacts.
- Synthetic health and schema checks run in the client’s monitoring.
- A lawyer has reviewed the post-handover responsibilities clause.
- Agency access is removed on the agreed cutover date.
Operational Summary
Agent projects fail at handover for the same reason they fail in production: credentials and expiry dates belong to the wrong people, and the failure shows up as odd behavior rather than a clear error. Fix ownership first, so client-held accounts and identity-backed credentials replace agency-held keys. Then track every expiry date with a monitored notice contact, and automate checks for token validity and schema drift. Finally, review the stack each time the MCP specification, SDKs or hosting platforms ship breaking changes.
Originally published at https://instarenewal.com/blog/ai-agent-model-context-protocol-mcp-infrastructure-mitigating-the-offboarding
Top comments (0)