Skip to content

Control and permissions

How do I stop an employee's AI seeing financial data?

A simple guide for owners who want staff to use AI for their own work without every assistant seeing the books.

Concept guideApplies to Your connected systems · Claude

Short answer

You give each person their own key, and the key decides what their AI can reach. An associate’s assistant does not have the financial tools at all. Nothing is refused in the moment, because the tools are simply not there to call. The owner can also wall off specific topics, so a lower tier never reaches them even by accident. Permission is decided by the key, not by how a question is worded.

An owner who wants associates and managers to use AI for their own work, while payroll, margins, and the books stay with the people who should see them.

  • A short list of roles and what each role should be able to reach.
  • The systems you are connecting.
  • A gateway that carries per-person permissions, rather than trusting each person’s app to behave.
  1. Each person carries their own key. The connector a person adds to their Claude signs in as them, not as a shared account.
  2. The key decides the tools. What a person can ask is set by their access, not by the phrasing. Rewording a question does not widen it.
  3. A lower tier simply has fewer tools. An associate’s assistant does not hold the financial lookups. They are not there to call, so there is nothing to refuse and nothing to leak in a refusal.
  4. The owner can wall off topics. Subjects the owner designates are filtered out before a question is even matched, so a lower tier never reaches them.

It can

  • Keep financial data with the owner and manager while associates still get a useful assistant.
  • Change what a role can reach by changing its key, without touching the underlying system.
  • Hold every assistant to pre-vetted queries only, never free SQL, with read-only enforced on the server.
  • Give each person a view that fits their job, from the Claude they already use.

It cannot (as we run it today)

  • Fix a shared login. If everyone signs in as the owner, every assistant sees what the owner sees. Separate keys are the thing to set up first.
  • Show or hide fields a system does not expose in the first place.
  • Enforce anything on data that never travels through the gateway. The control lives at the gateway.

Is the read-only limit enforced, or just requested?

Section titled “Is the read-only limit enforced, or just requested?”

Enforced. The AI can only run pre-vetted queries, never free SQL, and read-only is enforced on the server rather than left to good behavior. Together with per-person keys, that means what a role can reach is set by the connection, not by how cleverly a question is phrased.

Yes. Access is set up by need and stays adjustable. What a role can reach changes when you decide it should, by changing its key, without touching the underlying system.

EvidenceSupported capability under gate

This is the model running at the jewelry store where our gateway is in production on The Edge. It runs three roles, owner, manager, and associate, each person carrying their own key, with owner-designated topics filtered before a question is matched. We last verified that deployment running on August 27, 2026. Read-only is enforced on the server, not by good behavior, and the AI can only run pre-vetted queries, never free SQL.