Why go beyond the certification?
A SOC 2 report or similar attestation describes a vendor's controls as audited at a point in time, and it is a reasonable thing to ask for. It does not tell you how the product isolates your data from another customer's, how it stores the credentials you give it, or what the model provider does with the text it processes.
For an AI employee, which acts inside your systems with your credentials, those mechanisms are the security review. Ask about them directly, and expect specific answers. Where ftes.ai is concerned, the answers below are the ones its security page gives, stated plainly, without claiming certifications it does not hold.
What should you ask about data isolation?
Ask how tenant isolation is enforced at the database level, not just in the interface. On ftes.ai every record is scoped to an organization, and queries that reach the database carry the organization on every request. Within an organization, properties such as websites, stores, and ad accounts are separate, and one FTE's property never sees another's memory, targets, or setup.
Ask also who inside the vendor can see your data, under what controls, and whether the vendor trains models on it. The ftes.ai answer to the last is no.
What should you ask about credentials?
Ask how integration credentials and API keys are stored, whether they appear in logs or responses, how they are scoped, and how they are revoked. On ftes.ai credentials are encrypted before storage with a key held separately from the data, they never appear in responses or logs, they are granted per organization and per property, and any integration can be disconnected from the workspace at any time.
Ask about the vendor's own access path too. The ftes.ai app uses short-lived access tokens with a rotating httpOnly refresh cookie, and the browser never talks to the API directly.
- Storage: encrypted at rest, key held separately from the data
- Exposure: never in responses or logs
- Scope: per organization and per property
- Revocation: from the workspace, any time, logged
What should you ask about the model provider?
Ask which model providers process your data, whether you can bring your own provider key, and what the provider's data handling terms are for the vendor's account. On ftes.ai work is done through the Claude Agent SDK, you can bring your own provider key so usage runs on your own agreement, and the platform does not train models on your data.
Ask whether model provider terms are passed through to you in writing, and check them against your own requirements. The vendor cannot change the provider's terms; it can tell you what they are.
What should you ask about the trail and the end?
Ask what the audit trail contains and whether you can export it. On ftes.ai every proposal, approval, publish, and token spent is logged with who, what, and when, and role-based permissions decide who can hire, approve, publish, and spend, with every protected action checking a permission.
Ask what happens at the end: how you disconnect, how you get your data, and how deletion is confirmed. On ftes.ai any integration can be disconnected from the workspace at any time, and deletion of an organization's data is requested through the privacy contact on the security page. Ask any vendor for these answers in writing, and treat a vendor who will not give them as having answered.
What does a good written answer look like, and what does a bad one look like?
A good written answer names a mechanism and where it lives. Asked about isolation, it says that every record is scoped to an organization and every database query carries the organization, including background jobs, and that properties within an organization are separate with their own memory and setup. Asked about credentials, it says they are encrypted before storage with a separately held key, never appear in responses or logs, are scoped per property, and can be revoked from the workspace. Asked about the model provider, it names the provider, states whether the vendor trains on customer data, and says whether you can bring your own key.
A bad written answer uses adjectives where a mechanism should be: enterprise-grade, bank-level, fully secure, industry-standard. It points to a certification as the answer to a question the certification does not address. It declines to name the model provider or its terms. It describes isolation in the interface rather than at the data layer. And it does not say what the vendor does not claim, which a good answer always does, because a vendor who has thought about security knows where its guarantees end. Keep both answers in the procurement file; the second kind is a finding.