RFC-0060: Starlark Session Initialization for vMCP

[jerm-dro]

Introduce a Starlark-based session initialization script for vMCP. A single script runs once per session, receives discovered backends and their capabilities, and calls publish() to declare what the agent sees — optionally wrapping handlers with additional logic. Existing config knobs remain fully supported, but customization of vMCP behavior can now be exactly tailored to the use case without adding more knobs. Increasing configurability no longer means decreasing maintainability.

[yrobla]

Strong RFC overall — the problem framing, prior art, and alternatives section are all excellent. The backends() + publish() model is clean, and the default preset sketch makes backward compatibility concrete rather than aspirational.

Filing 3 blockers, 3 should-address items, 2 questions, and 2 nits.

[JAORMX]

I like the proposal and think that overall this is a good step to provide more customizability and programmability to vMCP. I'd be wary of fully relying on this mechanism for vMCP's programmability, API Gateways tend to offer programming languages as pluggability options (as you mentioned, Envoy's usage of Lua) but they often don't recommend them for critical paths and instead opt for other type of programmability or extensions. e.g. ext_proc via a sidecar which is quite standard to see in the wild or even c++ extensions since they support that too. For us it's a little tricky to know without previous data. So I'd say let's start getting it by adding this addition, but still opt for built-in middleware for extensibility since that's the paved path we have today. e.g. rate limiting should still be implemented via dedicated middleware IMO.

[yrobla]

Good RFC overall — the core argument (config knob interactions grow quadratically, Starlark + built-ins inverts this) is solid and the prior art section grounds it well. Comments below on a few specific areas.

[yrobla]

Restructuring to ship optimizer + authz together makes sense — the bypass isn't a "we'll fix it later" trade-off, it's a correctness bug. find_tool's dispatch table hands out access to tools Cedar would block (#4374). The interim fix in #4385 plugs one hole but the model is still broken, so shipping the optimizer alone would be knowingly shipping a privilege escalation.

On rate limiting: have you considered just implementing THV-0057 as a check_rate_limit() built-in rather than standalone middleware? Mechanism is identical (Redis token bucket), the default preset reads the same rateLimiting config block so non-script users see zero difference, and you avoid writing middleware that you're going to replace anyway. The main gap is that without current_user() you can only key on tool name — no per-user limits yet. That's fine as long as the Phase 2 scope note is explicit about it, otherwise it'll land as a disappointment.

[jerm-dro]

Thanks for the thorough follow-up. On rate limiting — we discussed this in the gateway channel and landed on shipping THV-0057 as standalone middleware first. The main reason is that rate limiting needs to cover both MCPServers and MCPRemoteProxy, not just vMCP sessions. The middleware approach gives us production data on usage patterns before we commit to the Starlark model. The plan is to benchmark both implementations (middleware vs. Starlark built-in with the same Redis backing) once the middleware is stable. I've updated the "Interaction with rate limiting" section to reflect this.

On phases — restructured the implementation plan into three phases:

• Phase 1: POC — validates the programming model and benchmarks Starlark vs. native Go middleware for rate limiting.
• Phase 2: Backwards compatibility — full feature parity (including optimizer + authz shipped together, current_user(), composite tool deprecation). This phase is substantial and will ship incrementally.
• Phase 3: New functionality — speculative capabilities like scrub_pii(), code mode, and future built-ins.

[yrobla]

Worth nailing down the semantics before this ships: is current_user() meant to be called at script top-level only (gives you the session-creation user), or also inside handler closures (gives you the request-time user)? Use Case 5 calls it inside a wrapper function that runs per-request — that only works if it reflects the current request's identity. Those are two pretty different contracts and threading request context into handler calls has real implementation implications. If you leave this ambiguous now you'll probably end up with a breaking change to handler semantics when current_user() actually lands.

[jerm-dro]

current_user() returns the same user for the lifetime of the session — the user who created it. There is no distinction between top-level and handler calls; it is the same value everywhere. This simplifies the implementation (no request context threading) and matches the session-scoped execution model. Updated the built-in description to clarify this.

[yrobla]

The RFC is careful to separate "script controls what tools exist" from "Cedar controls who can use them" — but current_user() makes that line leaky. An admin can write if "admin" in current_user().groups: publish(admin_tool, fn) and now you've got authz logic in two places. That might be totally fine given the trust model (admins write scripts), but it's worth one sentence in the security section saying whether identity-based tool filtering in scripts is intentional or something you want to steer people away from in favor of Cedar.

[jerm-dro]

Fair point. Identity-based tool filtering in scripts is intentional and complementary to Cedar — there's no one-size-fits-all answer here. Administrators who prefer the declarative Cedar policy model can continue using it for access control. Those who need something simpler or prefer an imperative approach can express it in the script. Both are valid and coexist. Added a note to the security section clarifying this.

[yrobla]

Replacing the existing code paths with the default preset is clean, but it also means the preset is now a single point of failure for everyone who hasn't written a custom script. The equivalence tests cover correctness, but what about a bug that ships mid-upgrade? Is there a way to pin to a preset version, or is "fork it via show-preset" the intended escape hatch? Just worth thinking through — a subtle behavior change in the preset silently affects all existing deployments at once.

[jerm-dro]

show-preset + fork is the intended escape hatch. If the default preset has a bug, an admin can show-preset default, copy the source, and use sessionInit.scriptFile to pin to their known-good copy. Preset versioning adds complexity we don't need — the equivalence tests gate the transition, and the fork path provides a recovery mechanism without introducing a versioning scheme.

[yrobla]

The "put current_user() logic at the end" heuristic is going to confuse people. If sessionless MCP is a real possibility, I'd just commit to a two-hook model now: on_session_init() for what tools exist and how they're shaped, on_request() for per-request concerns like rate limiting and user-specific filtering. It maps directly onto the distinction the RFC already makes, survives the sessionless transition cleanly, and removes a footgun where script ordering determines correctness in a non-obvious way.

[jerm-dro]

I like the two-hook model idea. We don't need to commit to it now since the single-script model covers Phase 2, but it's a strong candidate if sessionless MCP lands. Updated the open question to note on_session_init() + on_request() as a promising direction and removed the "put current_user() at the end" heuristic.