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 →

Guardrails on model-written SQL: row security enforced, agent loops capped

SQL written by a model passes a strict security resolver that validates row policies on the table and its secured parents and refuses a query that skips a join. Iteration caps are set per agent.

A model writes plausible SQL. Plausible is not the same as permitted. This release puts the platform's row-security resolver in the path of every query a model writes, and bounds how long an agent may keep trying.

Row security on model SQL

  • Strict resolution The resolver validates the row-level policies of the queried table and of its secured parents. A query that references a secured parent without joining it raises an exception rather than leaking rows.
  • Transformed, not injected Predicates are applied by transforming the query model rather than by splicing text, and foreign-key relationships are validated on the way.

Bounded agents

  • Caps per agent The global default of fifteen iterations gives way to seven for the SQL, coding and dictionary agents, five for knowledge and document, and eight for the orchestrator.
  • Approval without code A tool defined in the dictionary can demand approval through a flag, and dictionary writes are gated for every user by default.

The approval gate decides whether an action runs. These guardrails decide what the model is allowed to ask for in the first place.