Skip to content
flowlakes FlowLakes documentation home

Safety model

The safety model is how FlowLakes keeps agents least-privilege and human-supervised. It rests on three things working together: read tools run on their own, writes are gated by the agent’s autonomy mode, and any error in a permission check is treated as a denial rather than a grant. So an agent can gather what it needs freely, but a change to your data either executes, waits for approval, or becomes a proposal, and a bug or outage in the checks locks access down instead of opening it.

When you’d use it

  • Decide how much an agent can do unattended by choosing its autonomy mode.
  • Keep a change behind human review by running an agent in propose mode.
  • Reason about the worst case before you grant an agent write tools.
  • Explain to an auditor why an agent can never quietly escalate privilege.

What you manage

You set the safety posture when you configure an Agent:

  • Autonomy mode. Propose, bounded, or autonomous (the comparison is on the Agents page).
  • Tool grants. The exact tools the agent may call.
  • Service-account role. The roles that decide what the agent may read and what its writes are permitted to touch. It starts read-only on a short list of tables.

How writes are gated

The autonomy mode decides what happens to every write:

  • Propose. Writes become a proposal a human reviews; the agent holds no direct write tool.
  • Bounded. Writes require approval before they execute.
  • Autonomous. Writes execute directly, and only if the service account holds a write-granting role.

Read-only tools run on their own in every mode.

What an agent can read

Reading is granted separately from writing, and it comes in two shapes.

  • Named tables. The default. You give the service account a role that lists the tables it may read, and the agent sees those and nothing else. Precise, and worth keeping for an agent with one narrow job.
  • Broad tenant reads. Add the built-in Records Reader role (agent_record_reader) to the service account and the agent may read your tenant’s records generally, including tables you add later. Use it for an agent that has to follow a trail it cannot predict, such as one working an incident toward resolution.

Broad does not mean unlimited. Even with Records Reader, these stay closed and cannot be opened by adding the role:

  • credential and secret stores, including fl_credentials
  • platform and tenant configuration, such as fl_config and the tenant registry
  • the access model itself: roles, permissions, and their mappings and assignments
  • audit logs and AI usage records
  • skill bodies, which are prompt content

Reads of the tables that stay open are still filtered to your tenant, and secret-bearing columns come back masked wherever they appear, so a connection config reads with its host and username intact and its password hidden.

Good to know

  • Permission checks fail closed. An evaluation error denies with a distinct message, so an outage or bug never becomes an accidental grant.
  • A denial and a failure are distinguishable, so you can tell a missing grant from an outage.
  • A propose-mode agent never holds a direct write tool. Its writes are redirected to a proposal, so nothing commits without review.
  • Outbound tools gate on their own permissions on top of the autonomy mode.

How it connects

The safety model decides the gate; it does not perform the permission evaluation (Identity and access does) or run the tool (the agentic loop does). What an agent may propose flows into Plans and governance.