ArchitectureA supervised JVM-class runtime — OLTP on seven engines, OLAP on three. AI-native, MCP-native, observable as plain SQL.Read the architecture
Está viendo la edición Perú. Está viendo la edición Colombia. You're viewing the Pakistan edition. Cambiar a la edición global →Cambiar a la edición global →Switch to the global edition →
Product Release

MCP tool and resource access gated by caller role — the permission perimeter extends into autonomous agents

The MCP server's tool and resource surfaces now enforce per-caller access checks at the SPI level. listTools and canAccess gates extend the platform's role and attribute-level security model into autonomous agent interactions, with backward-compatible defaults.

The Model Context Protocol (MCP) server is the surface external assistants — Claude Desktop, ChatGPT desktop, Cursor — use to interact with the platform on behalf of a logged-in user. This release closes the gap between "the user has a role" and "the autonomous agent acting in the user's name has the same role" : the MCP server now enforces per-caller access checks at the Service Provider Interface (SPI) level, so a tool the user cannot reach is not exposed to an agent calling on their behalf.

Two SPI methods, two access gates

  • listTools(McpRequestContext). Each tool provider returns the subset of its inventory visible to the calling user. The MCP discovery surface returns only the tools the user could legitimately invoke ; tools the user lacks permission for are invisible, not greyed out.
  • canAccess(McpRequestContext). Enforced on readResource. Closes the bypass where a caller could fetch a resource by URI even after listing had denied it — the SPI gate runs on every access path, not only the listing path. The check returns a structured deny rather than a generic 403 so the agent can explain the refusal back to the user.

Backward compatibility

Both gates default to permissive when a provider does not override them. Existing MCP tool providers that have not migrated continue to work exactly as before ; the new safety only applies where the provider opts in. The migration path is one method per provider — write the role check, return the filtered list — and can land service-by-service.

Where this matters

  • Multi-tenant deployments. A tenant administrator's MCP session cannot see another tenant's tools, even if the underlying providers are shared infrastructure.
  • Row- and column-level security. The existing platform model — security expressions injected into every query — now flows through MCP. An agent that asks "what are the order totals for last month" sees only the rows the user could see in the application's own UI.
  • Audit. Every MCP tool invocation logs to the platform's activity log with the caller's user identity, the tool name and the access decision. Forensic reconstruction of an agent session is the same shape as forensic reconstruction of a user session.

See the feature →

← All posts