Why is trust an architecture rather than a feature?
Trust is an architecture rather than a feature because an AI employee acts inside an organization's systems with the organization's credentials, and no single control makes that safe. Isolation without gating lets a well-contained agent act wrongly; gating without isolation lets a well-supervised agent see the wrong data; both without a record leave nobody able to say what happened. Trust is what remains when every layer has been examined and found to hold.
This whitepaper describes the seven layers as they operate on ftes.ai, each as a mechanism that can be inspected in the product or asked about in writing, and without claiming any certification the platform does not hold. It is written for the security reviewer, the data protection lead, and the finance leader who each need a different layer to be true, and for the manager who needs all of them to be true without having to think about them every morning.
How does isolation work?
Isolation is the outermost layer and it has two boundaries. The organization boundary: every record on the platform is scoped to an organization, and every query that reaches the database carries the organization it acts for, including background work such as measurement sweeps and briefs, so that no path, including internal tools and jobs, can return another organization's rows. This is enforced at the data layer rather than filtered in the interface, which is the difference between isolation that holds and isolation that appears to.
The property boundary: within an organization, websites, stores, and ad accounts are separate properties, each with its own memory, targets, and setup, and a Digital FTE working on one never sees another's. This matters for agencies and multi-brand groups, where one client's facts must not appear in another's pages, and it matters for accuracy everywhere. Isolation extends to the AI layer: memory, drafts, logs, and credentials are scoped the same way as the main records, because an AI employee's memory of a business is tenant data.
How are credentials handled?
Credentials are the layer most often done badly elsewhere, because the easy path is a shared admin login. On ftes.ai a connection is granted per organization and per property, with the permissions chosen at the tool when connecting, so scope is structural: a Finance Controller FTE connected with read access and the ability to propose cannot post, because the connection does not allow it. Dedicated accounts or tokens for the FTE, rather than a person's login, mean revoking one affects only the FTE.
Integration credentials and API keys, including a bring-your-own model provider key, are encrypted before storage with a key held separately from the data, never appear in responses or logs, and are not visible in the workspace after entry. Any integration can be disconnected from the workspace at any time, revoking the held credential, and the change is logged. Connector links that themselves carry a credential, such as the one that exposes a Search Visibility FTE to an external assistant, are returned exactly once and are rotated rather than recovered if lost. Transport is HTTPS between browser, platform, and connected systems, and the browser never talks to the API directly.
How do permissions and gates bound behaviour?
Permissions bound what people can do; gates bound what the FTE can do. Role-based permissions, with owner, admin, member, and custom roles, decide who can hire, approve, publish, and spend, and every protected action checks a permission. Plan changes and top-ups are permissioned to owner and admin roles. Changing an FTE's manager, budget, or autonomy is a permissioned, logged action.
The approval gate requires a named person to approve every action a Digital FTE proposes until that class of action has earned autonomy on the ladder, per class, from the approval record, reversibly. Two lists never climb: the always-escalate categories set per role, and the never-automated actions fixed by the platform, such as anything affecting a person's employment outcome. The fact gate blocks any published claim without a source before a person sees the draft, so that a model's tendency to be confidently wrong is contained by structure rather than by prompting. Together, permissions and gates mean that neither a person without authority nor an FTE without an earned record can cause an effect the organization did not sanction.
What does the audit trail record?
The audit trail records, for every action, the proposal and its evidence, the decision and its reason, who made it and when, the autonomy level that applied, and the effect: what was published, sent, posted, or spent. It also records the management of the FTE: promotions and step-backs on the ladder with the grantor, budget changes, connection and disconnection of integrations, manager changes, and credential rotations. Token spend is recorded in an immutable ledger, so cost is part of the trail.
The trail is built as a by-product of the approval gate and the ledger, as work happens, rather than written up afterwards, which is where trails usually fail. A reviewer can trace any action end to end months later and produce the sentence that governance requires: this was approved by this person on this date from this evidence, or auto-approved under this grant made by this person on this record. Ask any vendor whether their trail contains these elements and whether it can be exported; a trail that cannot be exported is one the organization does not own.
How is spend bounded and how does the model provider fit?
Spend is bounded by the wallet: one per organization, drawn on by every Digital FTE, with per-FTE and per-mission budgets inside it, a hard stop that pauses every FTE when the wallet is empty so nothing runs on credit, and spend visible against budget in the morning brief with warnings as limits approach. The maximum exposure in any period is the plan, and the plan is a permissioned purchase. For a finance leader, this is the layer that makes usage-based AI safe to approve.
The model provider fits as a documented sub-processor. Work runs through the Claude Agent SDK; the platform does not train models on customer data; and an organization can bring its own provider key so that model usage runs on its own agreement, billing, and data terms, with the key protected like every other credential and the gates, trail, and isolation unchanged. A security review should ask which providers process data, under what terms, and whether those terms are passed through in writing. The platform's GDPR page states its position on processing, transfers, and sub-processors; the terms should be confirmed in writing rather than from any article.
How does revocation complete the architecture?
Revocation completes the architecture because trust must be withdrawable at the speed it was granted. A manager can step any class of action back to gated with one logged change, pause a Digital FTE entirely, disconnect any integration from the workspace and thereby revoke its credential, replace or remove a bring-your-own key, and, through the wallet, halt all work by declining to top up. Each is immediate and each is in the trail.
At the end of a role or a relationship, offboarding is a process with a path: revoke every connection, retain the audit trail as a business record and optionally the confirmed Brand Brain for a successor, request deletion of the rest through the privacy contact, and record who did what and when. Because access lives in one place and the record is the organization's own, offboarding an AI employee is faster and cleaner than offboarding a person. The incident response plan in the library is the same architecture exercised on a bad day: stop, trace, fix, record, with every step a workspace action.
What should a reviewer conclude?
A reviewer should conclude that trust in an AI employee is a property of mechanisms that can each be checked, and should check them: fetch a page as a scriptless crawler and confirm isolation is not cosmetic; ask for the credential storage and exposure model in writing; confirm the approval gate starts at Level 0 and the never-automated list is fixed; read a sample of the audit trail end to end; confirm the wallet's hard stop; ask what the model provider's terms are and whether a bring-your-own key is available; and walk the disconnect and deletion paths before they are needed. The security checklist in the library turns these into twelve items with pass conditions.
The architecture does not claim to make an AI employee infallible. It claims that an error will be caught at a gate or, failing that, contained by isolation, traced in the trail, bounded by the wallet, and reversed by revocation, with a named person accountable at every step. That is the standard the ftes.ai platform is built to and the standard any AI employee vendor should be held to. Where a vendor cannot describe a layer as a mechanism, treat the layer as absent.
How do you apply the architecture in a security review?
Apply the architecture as a review by checking each layer with a method rather than a question. For isolation, fetch two pages as a scriptless crawler, read the vendor's written statement that every query carries the organization including background jobs, and ask how you could verify that a request for another organization's record returns nothing. For credentials, connect one tool with a dedicated token, confirm the secret is not visible in the workspace after entry, disconnect it, and confirm the disconnection appears in the audit trail with a name. For permissions, attempt a protected action with a member role and confirm it is refused.
For the gates, open a new Digital FTE's Setup and confirm every class is at Level 0, read the always-escalate list in its remit, and read the fact-gate result on its first draft. For the trail, trace one action end to end. For spend, read the wallet, the per-FTE budget, and the brief's spend line, and ask what happens at zero. For the provider, read the written answer on which provider processes data, whether the vendor trains on it, and whether you can bring your own key. For revocation, walk the disconnect and deletion paths before you need them. Twelve items, each with a method, filed with names and dates, is the security checklist on ftes.ai, and it is the architecture applied.
What objections does the architecture meet, and what are the honest answers?
The first objection is that no architecture prevents every error. The honest answer is that this one does not claim to; it claims that an error is caught at a gate or, failing that, contained by isolation, traced in the trail, bounded by the wallet, and reversed by revocation, with a named person accountable at each step. The second is that the vendor holds the credentials. The honest answer is that it holds them encrypted with a separately held key, scoped per property, never exposed, and revocable by you from one place, and that a dedicated token per role limits what any one credential can reach.
The third is that the model provider sees the data. The honest answer is that the provider is named, its terms are stated, the vendor does not train on customer data, and a bring-your-own key puts model usage on your own agreement. The fourth is that a certification would settle it. The honest answer is that a certification describes controls at a point in time and does not answer how isolation, credentials, gates, or deletion work, and that a vendor who answers those with mechanisms has told you more than a badge can. The architecture is a set of things to check, and its honesty is in saying what each check does and does not establish.