Security and approvals
FlowPSA gives each person a role, such as Admin, Operator, Billing, or Viewer, that limits what they can do. Important steps, like approving a change or posting an invoice, need a person's approval, and AI can never give it. Request history is never rewritten, and every time entry change is recorded. For example: Alex asks to post an invoice, and Sam, a second person, must approve it.
The approval gate
FlowPSA checks these rules itself, for every path including AI connections (MCP). The AI agent role cannot decide any approval. Invoice posting is limited to Billing and Admin. For approvals that need a second person (four-eyes), the person who asked cannot approve their own request. A solo operator can relax specific approval types, on purpose, in configuration.
| Action | MCP agent | Person |
|---|---|---|
| Open a ticket, add an internal note | Yes | Yes |
| Assign an owner, add tasks | Yes | Yes |
| Send a customer-visible note | Proposes | Approves |
| Log billable time | Proposes | Yes |
| Resolve without an RMM verify event | Proposes | Vets |
| Approve a change | Never | Second person |
| Post an invoice | Never | Second person |
FlowPSA signs in through Azure Container Apps authentication with a tenant-specific issuer. Entra security groups grant Admin, Operator, Billing, and Viewer roles. Unknown roles, other tenants, and unassigned users are denied.
A second reviewer must really be someone else. For Microsoft sign-ins, the requester’s immutable Entra object ID is kept on the approval, so changing a display name cannot satisfy the four-eyes rule.
Integration tokens, webhook secrets, and the portal signing secret live in Key Vault. The runtime uses its own least-privilege identity, separate from FlowRMM’s.
Portal links are signed, expire after 24 hours, and are bound to tenant, company, contact, and email. Changing the contact’s email or rotating the secret invalidates them. Clients never decide internal approvals.
Request histories can only be added to, never rewritten (append-only). Time edits need a reason and keep a field-level diff. Invoice drafts fingerprint their time entries, so posting fails if anything changed.
Attachments are limited in type and size, and are downloaded rather than rendered as active page content.
Where it runs
FlowPSA runs as an Azure Container App next to FlowRMM, in its own Postgres schema. FlowRMM keeps endpoint authority and execution. FlowPSA never embeds a remote-control transport and never reports a fix it cannot see.
What FlowPSA will not do: send invoices on its own, let an agent approve a change or post an invoice, mark a remediation successful without a FlowRMM execution record, or invent licence true-ups from inventory counts.
Found a vulnerability? Please tell us privately. We read every report.
Responsible disclosure policyFlowPSA is for IT support companies (MSPs), in-house IT teams, and solo operators who use FlowRMM or plan to.
