Session Persistence
- Category
- Rogue Agent
- Confidence
- 71% confidence
- Finding
The same metadata-handling behavior appears twice in the findings because it can persist local session-derived MCP identity into automation configuration and prompt content. This creates a risk of unintended disclosure of environment-specific integration details and can couple saved automations to sensitive user/session state.
- Content
md - `serverIdentifier` — the scoped folder name the agent runtime uses (e.g. `dashboard-team-1-Linear`, `plugin-pagerduty-pagerduty-mcp`, `cursor-app-control`). - `serverName` — the plain name the user configured on cursor.com (e.g. `Linear`, `pagerduty-mcp`, `Databricks SQL`). Write `serverName` into `workflow.actions[].mcp.server.name` and any `@[MCP: ...]` prompt mentions. Never write `serverIdentifier` / the folder name, never invent or paraphrase a prefix (`team-…`, `user-…`, `<orgId>-…`), and never hand-strip prefixes from the folder name — many `serverName`s contain spaces (e.g. `Databricks SQL`, `statsig read only console`), so string-munging the identifier is fragile. The Automations editor matches on trim + lowercase, so casing does not matter, but pass the exact `serverName` from `SERVER_METADATA.json` anyway. When you have a useful URL, you may also pass `templateMcpHints: [{ name: <serverName>, url: <serverUrl> }]` so a URL match can rescue a name drift. **Eligibility — dashboard-backed servers only.** Only dashboard-backed servers appear in the Automations editor's `GetAvailableMcpServers` response, which is what the editor uses to resolve a prefilled `mcp` action to a connected server. Their `serverIdentifier` always begins with one of these prefixes:
