Cross-Workspace Usage-Count Exposure Automation: Any Workspace's Number, for the Asking
A privileged function is exactly as safe as its own internal checks, and no safer
A database function that runs with elevated privilege specifically so it CAN read data the calling user's own row-level permissions would otherwise block is a completely normal, often necessary pattern — the number a usage screen needs to show usually lives behind exactly that kind of boundary. The risk is structural: once a function has been granted that elevated privilege, every protection a caller would normally get from row-level security has to be re-implemented, explicitly, inside the function itself. A privileged function with no internal check is not a smaller version of the protection that existed before — it is the complete absence of it, wearing the same name.
How the underlying problem shows up before you fix it
A database function is granted elevated privilege specifically so it can compute an aggregate figure across rows a calling user's own permissions would not normally let them read directly.
The function accepts an identifier — a workspace id, an account id — as a plain argument, and trusts that argument at face value rather than independently verifying the calling user has any real relationship to it.
A feature works correctly and looks entirely normal for every legitimate caller, because a legitimate caller only ever supplies their own workspace's identifier — the gap only appears if someone deliberately supplies a different one.
A regression test exercises the happy path (the correct workspace, the correct user) extensively, with no test attempting to call the function with a MISMATCHED user-workspace pair to see whether anything actually stops it.
A feature's own aggregate output (a monthly count, a usage percentage) is real and accurately computed — the defect is not in the arithmetic, it is entirely in who is allowed to ask for the answer.
How the gap was found during a broader schema investigation, and how the fix closes it without changing what the function computes
The usage-count function was never a bad piece of arithmetic — its job, computing how many messages a given workspace sent in the current month, was implemented correctly and returned a real, accurate number. The gap was entirely in what the function was willing to accept as proof that the caller had any right to ask. Because the function carried elevated database privilege specifically so it could read across the underlying send-history table, and because it performed no check tying the calling user's own identity to the workspace argument they supplied, any authenticated user could call it with any workspace's identifier and receive that workspace's real number back.
The fix does not touch the arithmetic at all — it adds exactly the check that was missing before the function does anything else: confirming the calling user holds an actual row in the platform's own team-membership table for the specific workspace being asked about. A caller with no such membership record now receives a refusal instead of a real number, regardless of what elevated privilege the function itself still carries internally. The privilege the function needs to compute the aggregate did not change; what changed is that the privilege is now gated behind a real relationship between the caller and the workspace, rather than trusting whatever identifier happened to be supplied as an argument.
This defect surfaced during the same broader investigation into database-write and database-read mismatches across Flow — a reminder that a privileged function's own internal logic deserves the same direct scrutiny as a plain, unprivileged query, precisely because a privileged function's mistakes are invisible to the row-level security that would normally have caught them.
What is actually built today
Centriu Flow's monthly-usage function requires the calling user to hold an actual membership record for the specific workspace being queried before it returns any figure.
A caller with no membership record for the requested workspace receives an explicit refusal, not a default, an empty result, or a number belonging to a different workspace.
The usage figure itself remains computed exactly as before — the fix adds a caller-authorization check without altering how the monthly count is calculated.
The same investigation confirmed the function's storage-usage counterpart is scoped identically — both usage metrics a workspace's own screen displays are now checked against the same membership requirement.
A companion improvement measured that the underlying event and storage counters themselves had been silently blind before this same investigation (a related, separately-fixed measurement gap) — this specific automation covers the ACCESS-control fix, not that measurement fix.
The fix applies at the database function itself, so no caller — internal tool, external integration, or future feature — can bypass the membership check by calling the function through a different path.
One workspace's identifier, a different workspace's number (illustrative framing of the actual measured finding)
A person authenticated to one workspace supplies a DIFFERENT, unrelated workspace's identifier when calling the usage function directly. Before the fix, the function has no way to notice the mismatch — it reads the requested workspace's real send history and returns the real, accurate number, exactly as it would for that workspace's own legitimate user. After the fix, the identical call is checked against the platform's own membership records first; finding no relationship between the calling user and the requested workspace, the function refuses outright instead of returning any figure at all.
What changes operationally
Centriu Flow's usage-count function now verifies the calling user actually belongs to the workspace being queried before returning any figure, closing a gap where a real, accurate monthly send count for any workspace could be obtained by any authenticated user who supplied that workspace's identifier.
When this is not the right fit
This automation governs who is authorized to call a specific privileged usage-reporting function inside Flow — it does not change how usage itself is measured or displayed to a workspace's own legitimate members.
Trusting an argument vs. verifying a relationship
Accepting a workspace identifier as a plain function argument and trusting it at face value is a completely invisible shortcut right up until someone supplies an identifier that is not their own — a privileged function has no row-level security left to catch that mistake for it. Centriu's fix treats the calling user's actual relationship to the requested workspace as something to verify explicitly inside the function itself, precisely because the function's own elevated privilege means nothing else is checking on its behalf.
Related systems
Main system: Centriu Flow.
What it does NOT do
- Does not change how a workspace's monthly usage figure is calculated — the fix is entirely about who is authorized to request it, not the arithmetic behind it.
- Does not retroactively audit or report on any historical call made to the function before this fix shipped.
- Does not affect a workspace's own legitimate members' ability to view their own usage — a caller with a real membership record continues to receive the figure exactly as before.
- Does not claim to have found every privileged-function access-control gap across the platform — this fix closes the specific function and gap measured in this investigation.
- Does not change the underlying send-history data the function reads from — it changes only whether a given caller is permitted to ask for an aggregate over it.
- Does not replace a workspace's own review of who holds legitimate access to its account.
Security and governance
The usage-count function now requires a verified team-membership record linking the calling user to the specific workspace requested before returning any figure, closing a gap where elevated database privilege was not paired with any caller-authorization check. Any business or usage data referenced remains subject to Brazil's LGPD (Law No. 13,709/2018). Full detail on access control lives at /governanca and /iso.
Pricing and contracting
Available by monthly subscription, with tiered plans. Values and terms come from the official pricing table at /precos (Centriu's central source — never restated here).
Frequently asked questions
Could a real workspace's usage number actually be obtained by an outsider?
Yes, structurally — any authenticated user calling the function directly with a different workspace's identifier as an argument received that workspace's real, accurate monthly send count back.
Was the usage number itself ever wrong?
No — the arithmetic computing the monthly count was correct throughout; the gap was entirely in who was allowed to request the answer for a given workspace.
What check was added?
The function now requires the calling user to hold an actual row in the platform's own team-membership table for the specific workspace being queried, refusing the request outright if no such relationship exists.
Does this affect legitimate users viewing their own usage?
No — a caller with a real membership record for their own workspace continues to receive their usage figure exactly as before.
Was a similar gap found in any other usage metric?
Yes — the same investigation confirmed the storage-usage counterpart is scoped by the identical membership requirement.
What does Centriu Flow cost?
It is sold by subscription with a published starting price — exact current values are on the central pricing page.
See how Centriu Flow scopes usage reporting to a verified workspace membership
Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.