Why think about access in layers?
Thinking about access in layers makes least privilege achievable. A single question, what can this AI see, is too broad to answer well; four narrower questions, each with its own mechanism, can be answered precisely and checked.
On ftes.ai the four layers are the organization, the property, the connection, and the remit. The first two are structural and enforced by the platform; the second two are set by the manager.
How does the organization boundary work?
The organization boundary is the outermost layer. Every record on the platform is scoped to an organization, and every query that reaches the database carries the organization, so a Digital FTE in one organization cannot reach another's data by any path. This is the tenant isolation that a multi-tenant platform depends on.
It is enforced on every request rather than assumed from the interface, which is the difference between isolation that holds and isolation that looks like it does. The tenant isolation guide on ftes.ai describes it in more depth.
How does the property boundary work?
The property boundary separates the things a role works on within one organization: websites, stores, ad accounts. Each property has its own memory, targets, and setup, and a Digital FTE working on one property never sees another's. A Search Visibility FTE managing two websites holds them apart.
This matters for agencies and multi-brand organizations, where one property's data may be confidential from another's team, and it matters for accuracy, because a role that mixes two properties' facts will write the wrong facts about both.
- Organization: structural, every query, no crossing
- Property: structural, separate memory, targets, and setup
- Connection: set by the manager, per tool and property
- Remit: set by the manager, what the role reads and does within connections
How do connections and remit narrow it further?
Connections are the tools a role can reach, granted per property with the permissions you choose when connecting. A Finance Controller FTE connected to the ledger with read access and the ability to propose entries cannot post, because the connection does not allow it. Narrow permissions at the tool are the strongest control available.
The remit narrows further: within its connections, what the role reads and acts on. A Customer Support FTE connected to the helpdesk might be remitted to specific ticket categories, with the rest invisible to it. The remit is written at hiring and refined from the approval record.
How should you set the layers?
Set connections with the narrowest permissions the tool offers, using a dedicated account or token for the role. Write the remit to name what the role reads and acts on, and what it does not. Confirm the role's Memory tab shows only what it should know about the property, and correct anything it should not.
Review quarterly. Roles accumulate connections as their remit grows; remove any no longer needed. And when a role is stopped, disconnect everything from the workspace, as the offboarding guide describes.
What does a scoping mistake look like, and how is it caught?
The common scoping mistake is a connection granted with broader permissions than the role needs, because it was quicker at setup: a ledger connection that allows posting when the role only proposes, a helpdesk connection that reaches every ticket category when the remit covers two, a CRM connection made with a person's login rather than a dedicated token. Each is harmless until a bad day, when it widens what an error or a leaked credential can reach.
It is caught in three places. The security review at setup, which the security checklist on ftes.ai makes a twelve-item pass. The quarterly credential review, which asks of every connection whether its scope is still the narrowest the tool allows. And the audit trail, which shows every connection added and by whom, so a broad grant made in a hurry has a name and a date and can be narrowed. The remit is the fourth layer and the cheapest to fix: even where a tool's permissions cannot be narrowed enough, the remit can restrict what the role reads and acts on within them, and that restriction is enforced by the approval gate.