Dora NodaThree launches in three days just made agent-to-infrastructure tool calls a production pattern — and handed operators the security baseline for it in the same week. On September 14, changelog tool ReleasePad launched an MCP server letting AI coding agents draft, publish, and analyze product changelogs from a conversation. On September 15, Rubrik announced Rubrik MCP, co-engineered with Anthropic and powered by Claude, giving enterprise agents a programmable path into its Security Cloud data, identity, and application intelligence. And on September 16, the Center for Internet Security released the CIS MCP Server Benchmark v1.0.0: 55 prescriptive, consensus-developed recommendations across 10 security domains for securely configuring MCP servers, free to download, each with a rationale, an audit procedure, and remediation guidance.
That sequencing matters. Rubrik MCP is already in private preview with general availability targeted for October 2026, and Rubrik says one-third of its global customers already trust Rubrik AI — agents touching production security data is weeks, not years, away. Meanwhile 55.3% of data-security decision makers are already conducting vendor security assessments of AI platforms. The question for a self-hosted platform is no longer whether tenant agents will call your infrastructure tools, but whether your MCP surface would survive that assessment.
This post is a control-by-control reading of the benchmark's ten domains, applied to the MCP surface a PaaS actually exposes: deploy, rollback, scale, and operate tools that tenant agents invoke against production state. The checklist table below is the whole thing in one page; the sections after it explain what each group of domains demands and where a typical self-hosted platform already passes versus what has to change before agent credentials touch production. CIS publishes the full recommendation text as a free download — what follows maps each domain to the concrete check, not a substitute for the document.
The 10-domain checklist, in one table
| # | CIS domain | What it demands of a PaaS MCP surface | Your pass/fail check |
|---|---|---|---|
| 1 | Governance and Versioning | Versioned tool contracts; a deprecation policy so agents never call a silently-changed deploy tool | Every tool has a version; CI fails on unversioned tool changes |
| 2 | Transport and Connectivity | Encrypted, authenticated transport for every client-server hop, local and remote | No plaintext MCP endpoint reachable in any environment |
| 3 | Authentication and Authorization | Per-agent identity with least-privilege tool grants, not one shared API key | Revoking one agent breaks only that agent; a read-only agent cannot invoke a mutating tool |
| 4 | Client (Host) Configuration | Hardened host side: pinned server allowlist, no auto-connect to arbitrary servers | An agent cannot add a new MCP server without operator approval |
| 5 | Server Configuration | Secure defaults, no debug/admin surface exposed to tool callers | Production servers run with defaults audited; admin endpoints unreachable from tool-call path |
| 6 | Data Protection and Privacy | Tool inputs/outputs treated as sensitive; no secrets or PII leaking through tool results | No credential or PII appears in logged tool payloads or agent-visible error text |
| 7 | Observability and Audit | Every tool call logged with identity, arguments, and result | You can answer "which agent called deploy, with what args, and what happened" for any call |
| 8 | Supply Chain Security | Pinned, verified MCP server artifacts; no unreviewed third-party tool code in the call path | Every server image/dependency is pinned and traceable to a reviewed source |
| 9 | Isolation and Execution Safety | Tool execution sandboxed; untrusted tool output never executed or trusted blindly | A malicious tool description or result cannot escape the sandbox or poison the agent |
| 10 | Resource Limits and Caching | Rate limits, timeouts, and cache boundaries so one agent cannot starve or poison others | Limits trigger under load test; cached tool data cannot cross tenant boundaries |
CIS frames the stakes plainly: because MCP servers "often provide access to sensitive systems and data, misconfigurations can create opportunities for unauthorized access, data exposure, tool manipulation, and execution of untrusted code." "As organizations continue adopting AI agents, securing the systems that connect them to enterprise resources is essential," said Erin Haggerty, Director of the Cloud Team at CIS. Note the scope, too — the benchmark explicitly addresses both local and remote MCP deployments, including gateway and proxy technologies, so a stdio sidecar next to your deploy pipeline is in scope just as much as a remote HTTPS endpoint.
Identity first: auth, transport, and client config
Domains 2, 3, and 4 form one question: which agent is calling, over what channel, from a host you trust? This is where most self-built MCP surfaces are weakest, because the demo-era pattern — a local server, a shared token in an env var, full tool access — works fine until the tools can restart production.
Authentication and Authorization is the domain the TODO spec calls out explicitly, and it deserves the emphasis. Least privilege for tools means something stricter than API scopes: each agent identity gets grants per tool, and mutating tools (deploy, rollback, scale, secret-rotate) sit behind grants a read-only diagnostics agent never holds. The benchmark-era MCP authorization story builds on OAuth 2.1 for remote servers, which gives you per-agent tokens with expiries and scopes instead of one long-lived shared secret — the check in the table is deliberately operational: revoke one agent and confirm nothing else breaks. If your MCP surface cannot do that today, it has one identity, and it is yours.
Transport and Connectivity is the least surprising domain and the easiest to pass: TLS everywhere, no plaintext fallback, including the "it's only localhost" hops operators like to exempt. Client (Host) Configuration is its mirror image and the one teams forget — it governs the agent host, demanding a pinned allowlist of MCP servers rather than letting an agent connect to whatever endpoint a prompt mentions. The February 2026 SANDWORM_MODE npm worm is the reason this domain exists in spirit: it planted a rogue MCP server with prompt-injecting tool descriptions via 19 typosquat packages, targeting Claude Code, Cursor, Windsurf, and Continue users to exfiltrate credentials and SSH keys. A host that auto-connects to any server an agent names is a host waiting for that exact payload.
Execution safety: the domain the incident record wrote
If identity answers who calls, Isolation and Execution Safety plus Data Protection and Privacy answer what happens when a tool lies. MCP's structural risk is that tool descriptions are natural language the agent reads and follows — a compromised or malicious server poisons the agent through the very interface it uses to work. The 2026 incident record reads like a justification section for these two domains.
The Azure Data Explorer MCP Server carried a KQL injection flaw whose CVE record describes an attacker — "or a prompt-injected AI agent" — executing arbitrary KQL queries against the cluster, scored 8.3 High. Kong's Konnect MCP Server shipped an indirect prompt injection letting a remote attacker steer the server into executing unintended API requests. In August, researchers filed MCP-2026-008 (cache poisoning) and MCP-2026-015 (prompt injection) against the protocol ecosystem itself. And the OWASP AISVS project's MCP security chapter catalogs these alongside enterprise-scale audit findings, including a 2026 YARA-scan audit across 33 MCP servers and 433 tools.
For a PaaS surface, these domains cash out as three engineering rules. First, never construct executable commands from untrusted tool arguments without strict allowlisting — a deploy tool that shells out with agent-supplied args is the KQL-injection pattern wearing a different uniform. Second, treat tool output as untrusted content: sanitize results before they enter model context, and never let a tool result carry credentials, session tokens, or PII back to an agent that only needed a status string. Third, sandbox execution so a poisoned description or result cannot escape into the host — the benchmark pairs isolation with execution safety deliberately, because description-poisoning and result-poisoning are the same attack arriving from opposite directions.
Supply chain, governance, and the unglamorous rest
Domains 1, 5, 8, and 10 are the operational tail that decides whether the exciting controls above survive contact with a real release cadence. Supply Chain Security demands pinned, verifiable MCP server artifacts — the SANDWORM_MODE typosquats again, but also the quieter risk of an auto-updating community server whose new version adds a tool your agents immediately start calling. If your deploy pipeline pins container images by digest but pulls its MCP servers floating, the agent path is now the least-governed way to change production.
Governance and Versioning is the domain that sounds bureaucratic until an agent calls a deploy tool whose semantics changed overnight. Versioned tool contracts with a real deprecation policy are the API-versioning discipline the industry learned for REST, re-applied to a surface where the client is a model that cannot read a changelog unless you put it in context. Server Configuration covers the familiar ground — secure defaults, no debug or admin surface reachable from the tool-call path — and Resource Limits and Caching closes the noisy-neighbor loop: timeouts, rate limits, and cache boundaries, with the MCP-2026-008 cache-poisoning report as the warning that a shared tool-result cache is a cross-tenant data leak waiting for a key collision.
Observability and Audit deserves to stand slightly apart from this group, because it is the domain operators will feel first. "Logging that ties every tool call to an identity" is not a nice-to-have once agents act on production — it is the only way to answer the incident-review question that replaces "who ran this migration" with "which agent, prompted by whom, called rollback with what arguments, and what did it return." If your MCP surface logs tool calls without the calling identity and full argument set, you have telemetry, not an audit trail, and the benchmark draws that line explicitly.
Where a self-hosted PaaS already passes — and what has to change
Here is the honest gap analysis the title promises. A typical self-hosted PaaS, built on the boring virtues — TLS everywhere, an existing auth layer, pinned container images, structured logging — already half-passes this benchmark without aiming at it. Transport hardening is usually done: your platform terminates TLS at the edge and mints tokens through an existing identity system. Supply-chain instincts transfer directly: pinning an MCP server image by digest is the same muscle as pinning a workload image. Server-configuration hygiene and resource limits are familiar operational ground.
What has to change is everything the benchmark adds because the caller is an agent. Four gaps show up in nearly every demo-era MCP surface. First, per-agent identity with per-tool least privilege — replacing the shared token with OAuth-scoped, revocable agent credentials, and splitting read-only diagnostics tools from mutating deploy/rollback tools at the grant level. Second, a real tool-call audit trail: identity plus arguments plus result for every invocation, retained and queryable, not debug logs. Third, execution sandboxing with output sanitization — allowlisted command construction, untrusted-output handling, and a sandbox boundary between tool execution and the host. Fourth, host-side server allowlisting, so tenant agents can only reach operator-approved MCP servers and the SANDWORM_MODE pattern dies at connection time.
None of these is exotic technology; all four are work that demo code skips and production checklists catch. That is precisely what a CIS Benchmark is for — it converts "we hardened the agent surface" from a vibe into 55 testable statements an assessor can verify, at the exact moment 55.3% of data-security decision makers are running vendor security assessments of AI platforms and Rubrik-scale vendors are putting agent tool calls into private preview. Download it, run the ten checks in the table above, and fix the four gaps before agent credentials touch production state. The agents are already here; the baseline finally is too.
Bex.co treats AI agents as first-class operators — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API your agents can drive today. Star the repo on GitHub or deploy your first app and put your agent surface behind a real audit trail.
