• Checklist
  • Governance
  • 5 min read

AI Employee Security Checklist

Twelve items. If each one has a mechanism you can point at, the AI employee is ready to make its first proposal.

Author
ftes.ai Editorial
ftes.ai Team

The short answer

Before an AI employee makes its first proposal, confirm twelve things: tenant and property isolation, scoped credentials, encrypted storage, role permissions, the approval gate at Level 0, the always-escalate list, the audit trail, the wallet hard stop, the model provider's data terms, and the disconnect and deletion paths. Each has a mechanism on ftes.ai.

Put a Digital FTE on thisEvery role proposes with evidence and reports to you.

Key takeaways

  • Twelve items, each with a mechanism rather than a promise.
  • Isolation and credentials are structural; check they are enforced, not described.
  • The approval gate at Level 0 and the always-escalate list are the behavioural controls.
  • The wallet hard stop bounds spend; the audit trail bounds uncertainty.
  • The disconnect and deletion paths are checked before you need them.

What should be confirmed about isolation and access?

Confirm that tenant isolation is enforced on every database query, not only in the interface; on ftes.ai every record and every query carries the organization. Confirm that properties are isolated from each other, with separate memory, targets, and setup. Confirm that the credentials you grant are scoped per tool and property with the narrowest permissions the tool allows.

Confirm that credentials are encrypted before storage with a separately held key and never appear in responses or logs. Confirm that role-based permissions decide who in your organization can hire, approve, publish, and spend, and that every protected action checks one.

  • 1. Tenant isolation enforced on every query
  • 2. Property isolation with separate memory and setup
  • 3. Credentials scoped per tool and property, narrowest permissions
  • 4. Credentials encrypted at rest, never in logs or responses
  • 5. Role-based permissions on every protected action
Revocation — disconnect, step back, pause, from one placeWallet — hard stop; spend bounded and visibleAudit trail — who, what, when, evidence, levelGates — approval on every action; fact gate on every claimPermissions — roles check every protected actionCredentials — scoped, encrypted, never exposedIsolation — organization on every query; properties separate
Figure 1The twelve checks map onto seven layers. Confirm each layer with a method you performed, not a sentence you were told.

What should be confirmed about behaviour?

Confirm that the Digital FTE starts at Level 0 on the autonomy ladder, with every action gated behind a named person's approval. Confirm that the always-escalate list for the role is written and fixed: the categories that reach a person regardless of confidence and never earn autonomy.

Confirm that the fact gate applies to anything the role publishes, so that unsourced claims are blocked before approval. These three are the behavioural controls; the structural ones above bound what the FTE can reach, and these bound what it does with it.

  • 6. Autonomy ladder at Level 0, every action gated
  • 7. Always-escalate list written and fixed for the role
  • 8. Fact gate on everything published

What should be confirmed about records and spend?

Confirm that the audit trail records every proposal, approval, publish, and token spent with who, what, and when, and that you know how to read it. Confirm that the wallet's hard stop is in place: at zero the FTEs pause and nothing runs on credit, and per-FTE budgets are set in Setup.

These two turn governance into something you can demonstrate: the trail shows what happened, and the wallet shows the maximum that could have been spent.

  • 9. Audit trail complete and readable
  • 10. Wallet hard stop and per-FTE budgets set

What should be confirmed about the provider and the end?

Confirm the model provider's data handling terms for the vendor's account and whether you can bring your own key; on ftes.ai work runs through the Claude Agent SDK, you can bring your own provider key, and the platform does not train models on your data. Confirm the disconnect path: any integration can be removed from the workspace at any time.

Confirm the deletion path: how you request deletion of your organization's data and how it is confirmed. On ftes.ai the request goes to the privacy contact on the security page. Check both paths before you need them.

  • 11. Model provider terms known; bring-your-own key available
  • 12. Disconnect and deletion paths confirmed

How should you use the checklist?

Use it once at hiring, with a named person confirming each item and where they checked it, and again at each quarterly review, where the items most likely to drift are 3, 7, and 10: connections accumulate, escalation lists get relaxed, and budgets get raised.

The checklist is deliberately short. A longer one that nobody completes is worse than twelve items that are actually confirmed, and each of these twelve corresponds to a mechanism the security page on ftes.ai describes.

What does a completed checklist look like in the procurement file?

A completed checklist in the procurement file is twelve lines, each with the item, the person who confirmed it, the date, and where they checked: item one confirmed by the security lead on a stated date by fetching two pages as a scriptless crawler and reading the vendor's written answer on query-level isolation; item four confirmed by reading the credential handling answer and inspecting that a connection's secret is not visible in the workspace after entry; item six confirmed by the function manager opening the Digital FTE's Setup tab and seeing every class at Level 0.

Items seven and eight are confirmed by reading the remit's always-escalate list and the fact-gate result on the first draft. Item nine by tracing one action end to end in the audit trail. Item ten by reading the wallet and per-FTE budget in Setup and the spend line in the morning brief. Items eleven and twelve by the vendor's written answers on the model provider and on disconnection and deletion, filed with the data processing agreement. The file is then the evidence that the organization checked, which is a different thing from having been told, and it is what the quarterly review is compared against.

Frequently asked questions

What should I check before an AI employee starts?

Twelve items: tenant and property isolation, scoped and encrypted credentials, permissions, Level 0 autonomy, the escalate list, the fact gate, the audit trail, the wallet stop, provider terms, and the disconnect and deletion paths.

Which items are structural?

Isolation, credential storage, and permissions. Check that they are enforced by the platform rather than described in a document.

Which items are behavioural?

Level 0 autonomy, the always-escalate list, and the fact gate. These bound what the FTE does with the access it has.

How often should I re-check?

Quarterly. Connections, escalation lists, and budgets are the items most likely to drift.

Does ftes.ai train on my data?

No. Work runs through the Claude Agent SDK, you can bring your own key, and the platform does not train models on your data.

  • Governance
  • Security checklist
  • Onboarding
  • Controls
  • Digital FTE
Further reading

Keep going.

Related guides on hiring and managing Digital FTEs.

Explainer · Governance · 5 min

Security Questions to Ask Any AI Employee Vendor (SOC 2 and Beyond)

A certification is a starting point, not an answer. The questions a security reviewer should ask an AI employee vendor about data, credentials, isolation, model providers, and what happens at the end. And how ftes.ai answers them, plainly.

Read

Ready to hire your first Digital FTE?

Pick a role, connect the tools it needs, and review its first proposals this week.