What's New in FLUID 0.7.4 — Runtime agentPolicy Enforcement at the MCP Gateway

FLUID 0.7.4 makes an expose agent-consumable over MCP and turns exposes[].policy.agentPolicy into a gate the FLUID MCP output-port gateway enforces on every read.

The headline change is behavioral, not structural: policy.agentPolicy's shape is unchanged from 0.7.3. What's new is that the gateway now actually enforces it at request time instead of treating it as advisory metadata.

✅ 0.7.4 is fully backward-compatible with 0.7.3. This release is purely additive — every valid 0.7.3 contract validates as 0.7.4 unchanged. See Backward compatibility — fully additive for details.

🔌 exposes[].mcp — opt an expose into the MCP gateway (NEW)

A new exposeMcp block declares an expose as agent-consumable over MCP and carries per-expose overrides for the output-port server:

exposes:
  - exposeId: customer_profiles
    kind: table
    # ...contract, binding, policy...
    mcp:                          # NEW in v0.7.4
      sampling:
        maxRows: 100              # integer ≥ 1, default 100
      classification:
        dataClass: confidential   # public | internal | confidential | restricted
  • mcp.sampling.maxRows — integer, minimum 1, default 100. A hard cap for the sample MCP tool. Defends against an over-curious agent asking for petabyte-scale samples.
  • mcp.classification.dataClass — one of public | internal | confidential | restricted. Surfaced on the describe tool so consumer agents can declare downstream handling. Advisory only — it is a hint, not an enforced control.

🛡️ Runtime agentPolicy enforcement (behavioral change)

The FLUID MCP output-port gateway now enforces exposes[].policy.agentPolicy on every read:

  • allowedModels / deniedModels — the calling model is checked against the allow/deny lists before any data is returned.
  • allowedUseCases / deniedUseCases — the declared use case is checked against the controlled vocabulary.

Requests that violate the policy are rejected at the gateway rather than served. The agentPolicy shape is unchanged from 0.7.3 — if you already declared it, no edits are needed; it simply becomes a live gate.

🙈 PII / PHI value redaction

When a column is classified as PII/PHI, the gateway redacts the values, not the column: the column stays visible in the response shape, but each value is replaced with [REDACTED-PII]. Agents still see the schema and can reason about structure without ever receiving the sensitive payload.

phi is not new in 0.7.4 — it has been a value in the column sensitivity enum since 0.5.7.

🐘 New binding platform and formats (NEW, additive)

  • binding.platform gains postgres — for the MCP output-port PostgreSQL driver. Existing platforms (gcp, aws, azure, snowflake, databricks, kafka, local, kubernetes, other) are unchanged.
  • binding.format gains postgres_table, athena_table, and glue_table — added alongside (not replacing) the existing formats including snowflake_view and the redshift_* values.
binding:
  platform: postgres        # NEW in v0.7.4
  format: postgres_table    # NEW in v0.7.4 (also: athena_table, glue_table)
  location: { database: analytics, schema: public, table: customer_profiles }

fluidVersion also moves from const: "0.7.3" to enum: ["0.7.3", "0.7.4"], so existing 0.7.3 values still validate against the 0.7.4 schema.

Backward compatibility: fully additive

0.7.4 is fully backward-compatible with 0.7.3. Every valid 0.7.3 contract validates as 0.7.4 unchanged — the release only adds optional fields and enum values. Nothing was removed:

  • Top-level governance and binding.governance (the AWS Lake Formation blocks — data-lake admins, LF-tag / TBAC definitions, per-resource principal grants, row/column filters) remain valid.
  • binding.format still accepts snowflake_view, redshift_table, redshift_serverless, and redshift_external_schema — the new postgres_table / athena_table / glue_table values are added alongside them.
  • runtime.platform still accepts athena, glue, and redshift.
  • Acquisition enums are unchanged: catalog register still accepts datamesh_manager; managed-deployment target still accepts opentofu.

The only schema-level change beyond the additions is that fluidVersion moves from const: "0.7.3" to enum: ["0.7.3", "0.7.4"], so a 0.7.3 value keeps validating.

Upgrading

fluidVersion: "0.7.4"
  • To use any field added in 0.7.4 (exposes[].mcp, platform: postgres, the new formats), declare "0.7.4". A document is validated against the schema of the version it declares, so a contract that declares "0.7.3" and uses exposes[].mcp is invalid, even though the 0.7.4 schema's fluidVersion enum also accepts "0.7.3".
  • If you use no new field, bumping is optional — the contract stays valid either way.

Nothing was removed, so there is nothing to migrate off. See Choosing fluidVersion.

References

  • Schema Changelog — the field-by-field machine diff for every version.
  • Full 0.7.3 → 0.7.4 diff — the complete auto-generated change list (additive: new exposes[].mcp block, new postgres platform and postgres_table / athena_table / glue_table formats, and fluidVersion widened to an enum).