Discussion points raised while converting the deck

Note Not from the source deck. These points were noticed while transcribing the deck and cross-checking slides against each other. They are prompts for discussion and may have simple answers. Record outcomes in the table at the bottom.

1. Risks #5, #8 and #13 are missing, and the "19 requests" mapping is not in the deck#

Eighteen distinct risk numbers appear (#1–#4, #6, #7, #9–#12, #14–#21). Numbers #5, #8 and #13 never appear. Slide 18 says "19 requests mapped in appendix", but the appendix (slides 19–26) holds Wrike documentation references and no mapping of requests to risks. Question: are #5, #8 and #13 out of Pilot scope, covered elsewhere, or missing? Where is the request mapping?

See: risk register, Pilot readiness.

2. Restricting who can create agents does not restrict who can appoint existing ones#

The Pilot control for #3/#15 is to "give creation rights only to approved Pilot builders" (slide 8), and #1 relies on user type permissions (slide 3). The documentation reference on slide 20 says these permissions "do not stop users from appointing existing agents to locations". The sample user-type screenshot on slide 4 also shows the AI Agents permission switched on for Regular User (with the note "Must be a space admin to do this"). Question: what controls who can appoint an existing Pilot agent to a new location, and how will WPP notice if it happens?

See: Identity and permissions, Governance: ownership and visibility, references.

3. The prompt-injection statement for AI Agents is absolute and labelled "Pilot"#

Slide 16 (#18) says under AI Agents: "malicious instructions can't be injected", and that Wrike also uses the Prompt Shield API from Microsoft. It is labelled Pilot (a proposed control), although it reads as a statement about Wrike's product. Slide 23 says of the prompt-writing guidance: "Good prompts are an operating practice, not guaranteed injection protection." Question: is this a Wrike capability (Today) or a Pilot position, what evidence supports it, and should the wording be softened?

See: Tools and data boundaries, references.

4. One #20 cell on slide 5 looks cut off#

The AI Agents / MCP cell for #20 reads "Test a high-impact write in the chosen assistant to confirm LLM client controls" and ends without saying what the controls should do. Compare slide 12, which asks for confirmation that "high-impact write tools require the intended human approval". Question: is slide 12's wording the intended completion?

See: Governance: review and action oversight, Human review.

5. Autonomous actions (#20) have no run-time limit for native agents#

Taken together, slides 5, 10 and 12 say that AI Agents have no delete action, act only in their assigned location, are reviewed up front and can be tested in the sandbox, but that they do not ask for approval before each action and that a small location "is not an enforced record-count or request-rate cap" (slide 10, Gap). Slide 17 adds Taskforce review after the fact. Question: is the Pilot willing to accept that residual risk, and what size of location counts as small enough?

See: Data scope, Human review, Disablement and incident response.

6. Almost every "Confirm" item has no named owner#

The deck says "Name an operator" for stopping an MCP connection (#9) and asks WPP to "assign a named owner" for agents (#1), but the other Confirm items say what to check without saying who does it. Slide 18 groups responsibilities by Wrike, WPP and Joint, but only by risk group. The open items tracker has an Owner column for this.

7. "Taskforce" is used but not defined#

The Taskforce reviews use cases before agent activation (#6), keeps approval records (#10), and reviews performance and further Wrike requirements (#20, slide 17). The deck does not say who is in it, how it decides, or how it records decisions. This matters because the Gap on slide 12 says Wrike has no native workflow routing activation to an approver, so the Taskforce is the only approval step.

8. Attribution and audit evidence have documented limits#

Slide 14 (#12) says MCP actions appear in Activity Audits and comment stream traces. Slide 24 qualifies this: "Some API/MCP updates omit agent identity; attribution is not shown in email or print", and "Logging does not by itself establish immutability". Question: do these limits matter for the evidence WPP needs for #10, #12 and #19, and what is the retention period (#12)?

See: Audit and traceability, references.

9. Token revocation is raised three times without an answer#

Slide 8 (#4) asks WPP to show how tokens are revoked. Slide 9 warns that an allowlist change does not guarantee existing tokens stop working. Slide 17 (#9) and slide 18 ask for a rehearsal of shutdown and token revocation. Question: who owns the revocation procedure, and when will the rehearsal happen relative to Pilot start?

See: Identity and permissions, MCP connections, Disablement and incident response.

10. Documentation hazards to carry into Pilot setup#

• Slide 25: the Help Center MCP article includes legacy SSE endpoint and attribution details. Pilot setup should follow the current v2 Developer Portal documentation.
• Slide 26: AI Essentials and AI Elite differ in features and allowances. Check WPP's subscription before relying on plan-specific features.
• Slide 22: for newer "Active locations" setup, also check the current creation guide.

See: references.

Discussion log#