Skip to main content
An agent that can work a real finance process is an agent with real access. The controls are what make that access something you can sign off on.

​
Roles and scoping

Users and agents are both scoped to projects. An agent isn’t a superuser that happens to run inside your account — it’s permissioned the way a team member is, and it can only reach the project it belongs to. Within a project, members carry a role that determines what they can do: Permissions are granular and scoped to capabilities — configuring agents, approving and rejecting, adding integrations — rather than being all-or-nothing per project. This is what lets you widen access as adoption grows: a controller who only reviews doesn’t need the rights to reconfigure the agent, and a stakeholder who only wants to see findings doesn’t need either.

​
Per-table data access

Every reconcile table has a Data Access list: the storage and extraction tables its agent may query. That list is the boundary. A table the agent wasn’t granted doesn’t exist as far as that agent is concerned. Grants are per table, not per project, so two processes in the same project can have different reach — an order-matching agent sees customer and item master; an invoice-audit agent sees POs and receipts. Neither sees the other’s data.

​
Per-table connector grants

The same applies to connected systems. Connectors are granted on the reconcile table, so an agent can only use the integrations that process actually needs. Connecting an app to the project makes it available; granting it to a table makes it usable by that agent.

​
Approval gates

Nothing critical leaves the system on the agent’s own authority:
  • Drafted emails are drafts until someone approves them.
  • Writes back into a connected system of record pass a gate.
Once a process has proven itself, you can hand the routine approvals to an approval agent that checks results against the SOP — see agentic approval. The gate doesn’t disappear; the routine cases stop needing a person.

​
Full audit trail

Every case carries what happened to it: the input it received, the queries the agent ran, the files it read and wrote, the actions it took, its reasoning, the review outcome, and who decided. This isn’t a summary written after the fact. It’s the record of the work, attached to the case, which is what makes an agent-worked process auditable in a way a person-worked one usually isn’t.

​
Zero retention

For workloads where intermediate results must not be persisted, zero-retention mode runs the process without storing them.
  • Per workflow — toggle it in the workflow’s settings.
  • Per API run — pass "zero_retention": true on the run request.
Zero retention means you don’t get the intermediate artifacts either. Use it where the compliance requirement demands it, not by default — the trace is most of what makes review work.

​
Compliance and residency

  • ISO 27001:2022 certified.
  • SOC 2 compliant — controls are in place and operating.
  • EU data residency — processing in the EU for customers who require it.

​
Least privilege, in one paragraph

The design assumption is that the agent will be given exactly what the process needs and nothing else, and that everything it does with that access is visible afterwards. Grants are per table, connectors are per table, the environment is scoped to the project, actions that reach the outside world pass a gate, and the whole run is recorded on the case. When you widen a grant, you’re making a deliberate decision, and you can see what was done with it.

​
Two standing commitments

Your ERP stays the system of record. cloudsquid works the process and produces the result; it doesn’t become the place your financial data lives. Nothing posts or pays without approval. No booking, no payment, no outbound communication happens on the agent’s authority alone.

Review & approvals

How gates and agentic approval work in practice.

The agent runtime

What the agent can reach, and what scopes it.