A Leaked Token That Outlived the Contractor, a Guest With Too Much Sight, and an EU Residency Demand
Halden Health Logistics (280 employees, US and Germany) runs client operations in ClickUp. Two weeks ago a contractor's personal API token was found in a public GitHub repository. The contractor's workspace access was removed, but the token was still creating tasks in a logistics List 11 days later, under a generic "automation" name. In the same review, the security team found that a client guest had been invited to a Folder containing rate-card and margin data for other clients, and that the German team's workspace sits in the US region - something their works council says is unacceptable. The CPO also wants a written answer to two questions: is our ClickUp data used to train AI models, and who can switch Brain on? The board wants a report in 72 hours.
1. The token still worked 11 days after access was removed. Explain how that is possible and lay out the containment steps in order.
Read the worked answer
If a token genuinely belonged to a deactivated account, requests would normally be rejected. The fact that writes continued points to one of three things, and identifying which is the first task:
- The credential is not tied to the contractor. It may belong to a shared "automation" user, a service account, or an OAuth app that predates the contractor and merely passed through their hands.
- The deactivation was incomplete - the person was removed from a Space or Team but their account remains active.
- A second credential exists that nobody has inventoried.
Containment order:
- Revoke the token and any OAuth grants associated with that identity. Revoke first, investigate second - do not leave a live credential in place while you analyse.
- Identify the owner: check which account created the tasks and which identity the integration authenticates as.
- Determine blast radius: what did that identity create, edit, delete or export in the 11 days, and before. Task history and, on Enterprise, audit logs are the evidence.
- Rotate anything else the contractor could have seen - other tokens, webhook secrets, shared credentials.
- Replace with a dedicated service account, least privilege, secrets in a secret manager.
- Add secret scanning to repositories and check for other leaked credentials.
The report should state facts verified versus inferred, and say plainly that the exposure window was 11 days, not two weeks.
2. How do you assess and fix the guest exposure, and what policy prevents a repeat?
Read the worked answer
Start by establishing exactly what the guest could see, because guest invitations are item-level and the answer is narrower than "everything" - but wider than people expect if the invitation was made at the wrong container.
Assessment:
- List every item shared with that guest and everything inside those containers: tasks, subtasks, attachments, comments and any linked documents. Sharing a Folder shares what is in it.
- Check whether the margin data sits in a Folder the guest was invited to, or whether it sits in a shared parent and the guest inherited visibility.
- Check for public share links and any "anyone with the link" access, which bypasses guest permissions entirely.
- Check whether the guest's access was via a group rather than an individual invitation.
Remediation:
- Remove the guest from the margin Folder immediately, then confirm with a test guest account what remains visible.
- Move commercially sensitive data into a Private Space with an explicit, small member list - not just a private List inside a Space the guest can see.
- Notify the account owner if confidential data was exposed; that is a contractual question, not just an IT one.
Policy: a three-tier data classification (public to clients / internal / restricted), a rule that restricted content lives only in Private Spaces, a named approver for any guest invitation, and a quarterly guest access review.
3. Draft the substance of the CPO's two answers on AI and on EU data residency. What can you state, what must you verify, and what is the decision?
Read the worked answer
Separate the two questions; they have different owners and different timelines.
AI and training data. Verify the current commitment in ClickUp's security and trust documentation rather than relying on memory or a sales call, and get the answer in writing for the board. Establish: whether customer content is used to train models, where AI processing occurs, what retention applies to prompts and outputs, and which administrative controls exist per plan. Then answer the second half - who can switch Brain on - by finding out what your own Workspace actually permits: which roles can enable AI features, whether the setting can be restricted at Workspace level, and whether any Space-level control exists. A policy line for the report: AI features are enabled only by Workspace admins, with a named owner, and reviewed quarterly.
EU residency. Data region is normally chosen when a Workspace is created, not toggled on later, so the realistic options are: create a new Workspace in the EU region and migrate the German team's Spaces, Lists, attachments and users, or accept the current region if legal and the works council agree. Verify what residency options your plan and contract actually include before promising anything.
Decision for the board: state the verified facts, flag the assumptions needing legal sign-off, and give a dated plan with owners. Do not put unverified compliance claims in a 72-hour report.