Plaintext-Token Allowlist and Org-Scope Join Discipline Automation: Two Quiet Rules Behind Eight AI-Agent Tools

A platform-wide security mechanism, like row-level security scoping every table by organization, is genuinely valuable specifically because it removes the need to think about that boundary in most individual queries. The risk that mechanism creates is a false sense of universal coverage: the moment ONE table in the schema is scoped by something other than organization — a user's own identifier, say, for reasons that made sense when that table was designed — every query against it silently falls outside the safety net everyone has learned to rely on elsewhere, unless someone explicitly knows that and compensates for it in the query itself.

A security gap that affects every table in a schema tends to get caught early, precisely because it's so broad that almost any serious review trips over it. A gap confined to exactly one table, designed at a different time for reasons that made sense then, survives specifically BECAUSE most of the system genuinely does behave the way people expect — the one place it doesn't is easy to miss unless someone deliberately audits each table's actual security scope rather than assuming consistency across the schema.

Before writing any of the eight new agent tools onto Maestro's data, the migration that built them records two specific facts about the underlying schema directly in its own header — not buried in a separate document, but stated as the premise every one of the new functions has to respect.

The first: the table holding a connected advertising account's OAuth credentials stores its access and refresh tokens as plain, unencrypted text. That fact by itself doesn't change what the database contains, but it changes what a QUERY against that table is allowed to look like. Every one of the new tools that reads from this table does so through a fixed, explicitly named column list — platform, account name, connection status, when the token expires, when the account last synced — and nothing resembling a broad, wildcard selection appears anywhere in this code. The practical effect: even if the live token value sits one column over in the same row, no path built by this migration can accidentally include it in a response, because the response is built from an explicit list that simply does not name that column, rather than from "everything in the row minus whatever someone remembered to strip out."

The second: the campaigns table itself is scoped, in its own row-level security policy, by an individual user's identifier — not by organization, the dimension nearly every other table in the platform is scoped by. Stated plainly in this migration's own header: that means row-level security, on its own, does not enforce an organization boundary for this specific table. Every one of the eight new functions compensates for that explicitly, joining from campaigns through the owning client record to that client's own organization column, in the query itself, before any row is returned — rather than trusting a platform-wide security assumption that, for this one table, does not actually hold. A shared context-resolution function establishes which organization the requesting agent belongs to before any of the eight tools runs, and every one of them carries that same explicit join, not just the ones that seemed most obviously sensitive.

Both choices come from the same discipline: treating what a specific table's own security posture actually is as a fact to look up and design around, not an assumption to inherit from how most of the rest of the schema happens to behave.

An agent asks to see the health of a client's connected ad accounts. The underlying table's row for that account genuinely contains a live access token in plain text, one column away from the fields the agent needs. Because the query names exactly which columns to return — platform, account name, status, expiry, last sync — the token column is never part of the result in the first place, regardless of what the agent asks for or how the request is phrased.

Eight new AI-agent tools onto Maestro's paid-media data operate with two specific, documented risks in the underlying schema deliberately designed around rather than inherited by accident: a plaintext-credential table that can only ever be read through a safe, named column list, and a non-organization-scoped table that gets its organization boundary enforced explicitly, in every query, rather than left to a security layer that does not cover it.

This page covers how these eight specific tools read from two particular tables with documented, nonstandard security characteristics — it is not a claim that every table these tools touch has the same characteristics, or a general audit of Maestro's entire schema; the migration's own header names these two facts specifically because they required deliberate handling, not because they are the only two tables in the system.

Writing a new query against the assumption that "row-level security already handles organization scope, like it does everywhere else" is a reasonable-sounding shortcut that fails silently, exactly once, on the one table where that assumption happens to be wrong. Centriu's approach treats each table's actual, specific security posture — what it's scoped by, whether it holds anything unencrypted — as a fact to check and design eight functions around individually, rather than a property to assume from how the rest of the schema generally behaves.