The inherited moat (run-as-caller)

When a workflow reads or writes a Management record — or runs an integration that does — it does not run as an all-powerful system account. It runs as the caller: the user (or the authenticated API client) who triggered it. Every permission that applies when that person opens the record in the Management UI applies identically inside the workflow. This is the inherited moat, and it is enforced by Workflow even though the entity and its rules were defined in Management.

Three layers, always on

• Row visibility. The node can only see the records the caller is allowed to see. Row-visibility rules you defined in Management (for example "agents see only tickets in their group") are applied to the node's reads and lists — a workflow cannot enumerate rows its caller could not.
• Field projection. Fields the caller may not read are stripped from the pins the node emits, and fields they may not write are ignored on create/update. The node's data contract narrows to what this caller is entitled to.
• Verb guard. Before a create, update or delete runs, the node checks that the caller actually holds that permission on that entity. No permission, no operation — the node returns a permission error instead of performing the write.

Why this matters

A workflow is a powerful thing to hand a non-admin user. The inherited moat means the automation is only ever as capable as the person running it. It cannot be used as a privilege-escalation ladder, because the same Management permissions travel with the execution. The definition living in Management and the execution happening in Workflow does not widen the blast radius — the moat is inherited whole.