How are organizations and properties kept apart?
At the data layer, on every query, including background jobs. Every record on ftes.ai is scoped to an organization, and everything a Digital FTE touches for a website, store, or account is additionally scoped to that property, so one client's or one property's facts, credentials, drafts, and trail never reach another's workspace. A request for another organization's record returns nothing rather than an error. The AI layer, memory, drafts, and logs, is scoped the same way. A security lead can verify by asking in writing how a cross-tenant read behaves and by fetching a page as a scriptless crawler.
The security lead persona piece lists the twelve checks; the property glossary entry describes the property boundary.
How are credentials held?
As dedicated accounts or tokens, one per role and tool, created by whoever owns access at the tool with the narrowest permissions the remit needs, scoped to one property, encrypted before storage with a key held separately from the data, never shown in the workspace after entry, never written to logs or responses, and disconnectable from the workspace in one logged action. The permission at the tool is the strongest control, because it holds even if every other layer failed, which is why the connection review confirms it at the tool rather than in the workspace.
The credential management piece describes the lifecycle; the connection review is quarterly.
What does a Digital FTE remember, and is it personal data?
The Brand Brain holds business knowledge: voice, facts, policies, products, preferences, and competitor facts, each item with a provenance showing where it came from and who confirmed it. It does not hold personal data about individuals: a support ticket's customer details, a candidate's application, a prospect's contact information stay in the connected systems the role works from and are not written into memory. Drafts and proposals follow the retention of the underlying activity. The memory is readable and exportable, so what the system knows about your business is a document rather than a mystery.
The myth piece on learning your business on its own explains what the memory does and does not learn.
Which model provider processes our data, and is it trained on?
The platform runs on the Claude Agent SDK. It does not train models on customer data. Organizations can bring their own provider key so that model usage runs on their own agreement, billing, and data terms; the key is encrypted like any credential, replaceable and removable by an owner or admin, logged, and the approval gates are unchanged by whose key is in use. The sub-processor list, including the model provider, is available with the data processing terms, and the data protection lead should read both before the first connection.
The CTO persona piece describes the provider and key questions from engineering's side.
What does the audit trail record, and can we export it?
Every proposal, approval with the approver's name and time, send-back with its reason, escalation with its receiver, action by a promoted class with its class and bounds, memory change with provenance, connection change, plan change, and permission change. It is exportable per role and per period, which is what a financial, security, or data protection audit asks for. The audit preparation playbook in the library describes what to export for each kind of audit and what each export answers.
An auditor who can trace one entry end to end usually stops sampling early.
Does ftes.ai claim security certifications?
These pages describe mechanisms and state what is not claimed. Ask for certifications in writing as part of the security questionnaire, and verify the mechanisms regardless, because a certification describes a process and the mechanisms are what the review is about. The vendor security questionnaire template in the library is written to be answered by any vendor, including this one, and the security and GDPR pages on the site state what exists.
A security lead who wants a badge should ask for it and then perform the twelve checks anyway.
What happens when we leave?
The offboarding checklist: pause each role, disconnect every connection from the workspace, remove the dedicated accounts at the tools, revoke any connector links, export the audit trail and the Brand Brain, decide what to retain, request deletion through the privacy contact, and file the confirmation. Nothing about leaving depends on the vendor's goodwill: the credentials were always yours to revoke at the tools, the trail and memory are exportable at any time, and the connector credential is never retrievable, only rotatable. Walk the path on a test connection at go-live so it is known before it is needed.
The offboarding checklist gives the steps with verification for each.