Consolidated risk view: programme and Wrike response
Warning This page combines two confidential decks: the WPP Media readiness programme (private and confidential) and the Wrike vendor deck (© Wrike, Inc. | Confidential). Keep it within the teams involved.
About this page#
One place to read, for every programme risk, what WPP requires and what Wrike has said in response.
| Source | Used for | |
|---|---|---|
| Programme | WPP Media, Wrike AI & MCP Readiness Programme, September 2026. Slides 6–9, see the risk and controls matrix. | The risk, its impact, the controls WPP proposes, the owner and the stage each is required for. |
| Wrike response | Wrike vendor team, WPP × Wrike — Pilot Risk Controls | Working Draft, slides 3–17. Transcribed in the WPP × Wrike AI Pilot section. | What Wrike provides today, what WPP must confirm or evidence, what the Pilot proposes, and known gaps. |
The two decks use the same risk numbers (#1 to #21) and the same risk names.
Each risk section ends with a Capability delivery table: the capabilities from the programme's capability delivery view that address that risk. Capability numbers use the CD prefix (CD1 to CD7 for the groups, CD1.1 and so on for the capabilities) so they are not confused with risk numbers (#1 to #21). These tables are generated from the capability delivery page when the site is built, so edit them there. Hover a capability link for Smart Context: open it in a new tab, or view that capability here without leaving the page.
How to read the Wrike response#
The Wrike deck assesses each risk for two execution models. They sit beside the programme matrix's AI and MCP columns.
| Wrike deck | How it works | Where controls sit |
|---|---|---|
| Wrike AI Agents | A builder sets up an agent inside Wrike and chooses where it acts. It runs like an automation within that setup. | Wrike provides creation permissions, a Space registry, location scope, action logs and individual-agent disablement. |
| Wrike MCP (assistant + Wrike MCP) | A user works in an external assistant. The assistant calls Wrike tools through MCP to read or change work. | Wrike checks access. WPP must confirm what its middleware/gateway and LLM assistant enforce for connections, tools, tokens and human approval. |
Labels used by the Wrike deck:
| Label | Meaning |
|---|---|
| Today: | Wrike capability. What exists now. |
| Confirm: | Setup or evidence that must be checked or shown. |
| Pilot: | Proposed WPP process or control for the Pilot. |
| Gap: | A known shortfall, with no current control. |
| Note: | Context or a limit to keep in mind. |
Note The Wrike deck's Pilot: label means a proposed control. It is not the same as the programme's Required For: Pilot stage.
In the Wrike response tables, n/a is the deck's own entry, a dash (—) means the deck has no entry for that model on that slide, and text in italics is the deck's cross-reference. The "Concern" column gives the risk as the Wrike deck words it, with its slide number. One risk can appear on several slides from different angles.
Coverage at a glance#
Programme columns come from the matrix. The Wrike columns list which labels the Wrike deck uses for that risk and model. Rows follow the programme's risk numbers.
| Risk | Required for | Programme AI / MCP | Wrike deck: AI Agents | Wrike deck: MCP |
|---|---|---|---|---|
| #1 Governance & Accountability | Pilot | Y / Y | Today, Pilot | Pilot |
| #2 Data Exposure & Scale | Pilot | Y / Y | Today, Pilot | Confirm |
| #3 Permissions & Identity | Pilot | Y / Y | Today, Pilot | Today, Confirm |
| #4 MCP Security | Pilot | N / Y | n/a | Today, Confirm, Note |
| #5 Accuracy & Hallucination | Rollout | Y / Y | Not in Wrike deck | Not in Wrike deck |
| #6 Process & Approval Bypass | Pilot | Y / Y | Today, Pilot, Gap | Confirm |
| #7 Monitoring & Visibility | Rollout | Y / Y | Today, Pilot | Pilot, Confirm |
| #8 Token Consumption & Cost | GA | Y / Y | Not in Wrike deck | Not in Wrike deck |
| #9 Operational Support | Pilot | Y / Y | Today, Pilot | Confirm |
| #10 Compliance & Regulatory | Pilot | Y / Y | Today, Pilot | Pilot, Confirm |
| #11 Agent Sprawl | Rollout | Y / N | Today, Pilot | cross-reference |
| #12 Audit & Assurance | Pilot | Y / Y | Today, Confirm | Today |
| #13 Vendor Dependency | GA | Y / Y | Not in Wrike deck | Not in Wrike deck |
| #14 Reputation & Client Trust | Pilot | Y / Y | Pilot | Pilot |
| #15 Tool Misuse | Pilot | N / Y | Today, Pilot | Today, Confirm |
| #16 Cross-System Data Leakage | Pilot | N / Y | Pilot | Confirm, Note |
| #17 Identity Propagation | Pilot | N / Y | n/a | Today, Confirm |
| #18 Prompt Injection | Pilot | Y / Y | Pilot | Pilot, Confirm |
| #19 Lack of Traceability | Pilot | Y / Y | Confirm | Confirm |
| #20 Autonomous Actions | Pilot | Y / Y | Today, Pilot, Gap, Note | Pilot, Confirm |
| #21 External AI Platform | Pilot | N / Y | Pilot | Pilot, Confirm, Note |
Reading notes#
- Risks #5 Accuracy & Hallucination, #8 Token Consumption & Cost and #13 Vendor Dependency have no entry in the Wrike deck.
- The programme marks #15 and #16 as MCP only (AI = N). The Wrike deck gives AI Agents entries for both.
- The programme marks #11 Agent Sprawl as AI only (MCP = N). The Wrike deck's MCP entry for #11 refers to risk #21.
#1 Governance & Accountability#
Programme position (matrix, slide 6)
- Key risk: Agents created without review or ownership.
- Potential impact: Uncontrolled deployment; unclear accountability.
- Proposed controls: Registration, approval, governance review and named owners.
- Wrike proposed capability: Agent Registry; Approval Workflow; Named Ownership.
- Global Wrike Team controls: Manual Taskforce review and approval before activation; central register; named owner; time-limited approval. Secondary owner, automated owner alerts and mature retirement workflow can follow at Rollout.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Wrike Product Team + Global Wrike Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Agents lack review or ownership. (slides 3–4) | Today: The Space registry lists agents, + user type permissions control who can create them. Pilot: WPP assigns a named owner to every Pilot agent. | Pilot: WPP keeps a list of approved MCP connections and their owners, so each integration has someone responsible for its setup and use. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD1.1 Agent Registry | CD1 Governance & Lifecycle Management | Yes / Yes | Wrike Product Team + Global Wrike Team | Pilot |
| CD1.2 Agent Approval Workflow + Time-limited approval | CD1 Governance & Lifecycle Management | Yes / Yes | Wrike Product Team | Pilot |
| CD1.3 Named Primary & Secondary Ownership | CD1 Governance & Lifecycle Management | Yes / Yes | Global Wrike Team + Business Owner | Pilot |
| CD1.4 Owner Status Monitoring & Alerts | CD1 Governance & Lifecycle Management | Yes / Yes | Wrike Product Team + Global Wrike Team | Rollout |
| CD1.5 Reactivation Approval | CD1 Governance & Lifecycle Management | Yes / No | Wrike Product Team + Global Wrike Team | Rollout |
| CD1.6 Agent Retirement Process | CD1 Governance & Lifecycle Management | Yes / No | Global Wrike Team | Rollout |
| CD6.2 Ownership Reporting & Alerts | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Rollout |
#2 Data Exposure & Scale#
Programme position (matrix, slide 6)
- Key risk: Programmatic retrieval, extraction or update at scale.
- Potential impact: Data leakage, mass updates or mass data corruption.
- Proposed controls: User-scoped access, monitoring and approval controls.
- Wrike proposed capability: Scoped Service Accounts; High-Impact Action Approval.
- Global Wrike Team controls: Delete disabled; approved spaces, fields and actions only; bulk update/extraction limits; record-return and rate limits; time-, scope- and volume-bounded approval; preview for high-impact actions.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Wrike Product Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Large-scale retrieval or updates. (slide 10) | Today: An agent acts in selected folders or projects. Pilot: WPP approves those locations and checks how much data and work they contain. | Confirm: Show which data the middleware lets MCP read or change, how much it can return, and whether bulk operations have enforced limits. Confirm WPP LLM client and/or MCP gateway can control which tools can be used. |
| Bulk actions affect unintended records. (slide 12) | Pilot: Keep actions within the agreed scope and exclude operations needing an unavailable preview. Wrike offers agent sandbox for testing agents before running them. | Confirm: A reviewer can check affected records and the approved time, scope and volume. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD3.1 Bulk Update & Extraction Limits | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.2 Record-Return & Rate Limits | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.3 Time-Bounded, Scoped and Volume-Bounded Approval | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.6 Preview Impacted Records | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.8 Protected Fields | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Rollout |
| CD3.9 Rollback Capability | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Rollout |
#3 Permissions & Identity#
Programme position (matrix, slide 6)
- Key risk: Excessive permissions or privileged accounts.
- Potential impact: Broader access and weakened traceability.
- Proposed controls: Least privilege and recurring recertification.
- Wrike proposed capability: Scoped MCP Tokens; No Shared Credentials.
- Global Wrike Team controls: Least privilege; no shared credentials; approved identity; manual access check before activation. Automated recertification reporting can follow at Rollout.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Wrike Product Team + Global Wrike Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Excess access; unintended actions. (slide 8, shared with #15) | Today: Permissions limit who can create agents, and each agent has a selected location. Pilot: Give creation rights only to approved Pilot builders. | Today: Wrike access follows the authenticated user. Confirm: Check that middleware scope and assistant tool settings keep access within the approved use case. |
| Unapproved applications gain access. (slide 9) | — | Today: An account-side allowlist limits which OAuth/API applications can access the WPP Wrike account. Confirm: Agree the approved client IDs and configure them with Support. |
| Privilege changes or rule bypass. (slide 10, shared with #6) | Today: Agents cannot change access controls or approval rules. Pilot: Review the agent's configured actions before it is used in an approved location. | Confirm: Test the user's Wrike access, the assistant's allowed tools and middleware restrictions together, including an action that should be denied. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD2.1 Scoped MCP Tokens | CD2 Identity, Access & Security Controls | No / Yes | Wrike Product Team | Pilot |
| CD2.6 No Shared Credentials | CD2 Identity, Access & Security Controls | No / Yes | Global Wrike Team | Pilot |
| CD2.8 Access Recertification Reporting | CD2 Identity, Access & Security Controls | Yes / Yes | Wrike Product Team + Global Wrike Team | Rollout |
| CD3.5 Access & Approval-Rule Protection | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
#4 MCP Security#
Programme position (matrix, slide 6)
- Key risk: Weak authentication or token misuse.
- Potential impact: Data or system compromise.
- Proposed controls: OAuth, token management and restricted access.
- Wrike proposed capability: OAuth; IP Restrictions; Controlled Token Issuance.
- Global Wrike Team controls: OAuth or approved authentication; controlled token issuance; expiry, revocation and rotation; no shared token. Central token inventory/reporting can mature at Rollout.
- Applies to: AI: N · MCP: Y
- Accountable owner: Wrike Product Team + Global Wrike Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Weak authentication or token misuse. (slide 8) | n/a | Today: OAuth 2.0 authenticates the connection. Confirm: WPP shows how its setup issues, expires, rotates and revokes the tokens used for MCP access. |
| An integration connects to the wrong account. (slide 9) | — | Today: An OAuth-client allowlist limits which Wrike account IDs the integration can connect to. Confirm: Set the approved corporate accounts and check the supported OAuth flow with Support. |
| Previously issued tokens retain access. (slide 9) | — | Note: Changing an allowlist does not guarantee that existing tokens stop working immediately. Confirm the separate revocation procedure before relying on a list change to remove access. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD2.2 OAuth Authentication | CD2 Identity, Access & Security Controls | No / Yes | Wrike Product Team | Pilot |
| CD2.3 Controlled Token Issuance | CD2 Identity, Access & Security Controls | No / Yes | Wrike Product Team | Pilot |
| CD2.4 Token Rotation, Expiry & Time-Bounded Access | CD2 Identity, Access & Security Controls | No / Yes | Wrike Product Team + Global Wrike Team | Pilot |
| CD2.5 Token Inventory | CD2 Identity, Access & Security Controls | No / Yes | Wrike Product Team + Global Wrike Team | Rollout |
| CD4.3 MCP Connection Details in Logs | CD4 Audit, Compliance & Traceability | No / Yes | Wrike Product Team | Rollout |
#5 Accuracy & Hallucination#
Programme position (matrix, slide 6)
- Key risk: Incorrect, incomplete or misleading responses.
- Potential impact: Wrong decisions and reduced trust.
- Proposed controls: Validation and human review.
- Wrike proposed capability: Not currently identified.
- Global Wrike Team controls: Pilot outputs must be manually validated by the Taskforce and users; no unreviewed reliance on generated output. Formal source attribution, confidence indicators and scaled validation workflow required by Rollout.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Wrike Product Team + Global Wrike Team
- Required for: Rollout
Wrike response
Not addressed in the Wrike deck.
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD5.4 Source Attribution | CD5 AI Safety & Trust Controls | Yes / Yes | Wrike Product Team | Rollout |
| CD5.5 Confidence Indicators | CD5 AI Safety & Trust Controls | Yes / Yes | Wrike Product Team | Rollout |
| CD5.6 Validation Workflow | CD5 AI Safety & Trust Controls | Yes / Yes | Wrike Product Team + Global Wrike Team | Rollout |
#6 Process & Approval Bypass#
Programme position (matrix, slide 7)
- Key risk: AI circumvents established controls.
- Potential impact: Governance breach and unauthorised outcomes.
- Proposed controls: Human approval and audit review.
- Wrike proposed capability: Agent Approval Workflow.
- Global Wrike Team controls: Taskforce approval of each use case plus separate approval for bulk, workflow, permission or high-impact actions. Agent cannot alter access controls or override approval rules.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Wrike Product Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Established controls are bypassed. (slide 5) | Today: Agents cannot change access permissions or approval rules. Pilot: WPP's Taskforce reviews the proposed use case before the agent is activated. | Confirm: Check which write actions the assistant asks a person to approve, and which actions WPP's middleware blocks or allows. |
| Privilege changes or rule bypass. (slide 10, shared with #3) | Today: Agents cannot change access controls or approval rules. Pilot: Review the agent's configured actions before it is used in an approved location. | Confirm: Test the user's Wrike access, the assistant's allowed tools and middleware restrictions together, including an action that should be denied. |
| AI bypasses established controls. (slide 12) | Pilot: WPP's Taskforce reviews the use case before AI Agent activation. Gap: Wrike does not provide a native workflow that routes AI Agent activation to an approver. | Confirm: WPP LLM client offers enforceable approval capability when human approval is required and which write operations are available. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD1.2 Agent Approval Workflow + Time-limited approval | CD1 Governance & Lifecycle Management | Yes / Yes | Wrike Product Team | Pilot |
| CD1.5 Reactivation Approval | CD1 Governance & Lifecycle Management | Yes / No | Wrike Product Team + Global Wrike Team | Rollout |
| CD3.1 Bulk Update & Extraction Limits | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.3 Time-Bounded, Scoped and Volume-Bounded Approval | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.4 High-Risk Action Approval Gates | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.5 Access & Approval-Rule Protection | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
#7 Monitoring & Visibility#
Programme position (matrix, slide 7)
- Key risk: No visibility of agents, owners or actions.
- Potential impact: Weak oversight and investigations.
- Proposed controls: Registry, dashboards and scheduled reviews.
- Wrike proposed capability: Agent Registry; Dashboard; Activity Feed.
- Global Wrike Team controls: Manual register and review of all five Pilot agents and actions. Enterprise dashboard, automated ownership reporting and anomaly monitoring required by Rollout.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Wrike Product Team
- Required for: Rollout
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Agents, owners or actions are unseen. (slides 3–4) | Today: The Space registry shows agents and configuration; audit reports record actions. Pilot: WPP manually reviews the Pilot inventory and activity. | Pilot: WPP tracks which MCP connections are in use and reviews their activity. Confirm: Check what activity the middleware actually makes visible. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD1.1 Agent Registry | CD1 Governance & Lifecycle Management | Yes / Yes | Wrike Product Team + Global Wrike Team | Pilot |
| CD1.4 Owner Status Monitoring & Alerts | CD1 Governance & Lifecycle Management | Yes / Yes | Wrike Product Team + Global Wrike Team | Rollout |
| CD2.5 Token Inventory | CD2 Identity, Access & Security Controls | No / Yes | Wrike Product Team + Global Wrike Team | Rollout |
| CD6.1 Enterprise Dashboard & Activity Feed | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Rollout |
| CD6.2 Ownership Reporting & Alerts | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Rollout |
| CD6.3 Approval Expiry & Abnormal Behaviour Alerts | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Rollout |
| CD6.8 Central Agent Management | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Rollout |
#8 Token Consumption & Cost#
Programme position (matrix, slide 7)
- Key risk: Usage grows without ownership.
- Potential impact: Budget overruns and allocation challenges.
- Proposed controls: Quotas and consumption monitoring.
- Wrike proposed capability: Usage Quotas; Cost Attribution.
- Global Wrike Team controls: Manual usage and cost review is acceptable for Pilot/Rollout while volumes are controlled. Quotas, forecasting and cost attribution required before GA.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Wrike Product Team + Global Wrike Team
- Required for: GA
Wrike response
Not addressed in the Wrike deck.
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD7.1 Usage Quotas | CD7 Commercial & Consumption Controls | Yes / Yes | Wrike Product Team | GA |
| CD7.2 Cost Attribution | CD7 Commercial & Consumption Controls | Yes / Yes | Wrike Product Team | GA |
| CD7.3 Threshold Alerts | CD7 Commercial & Consumption Controls | Yes / Yes | Wrike Product Team | GA |
| CD7.4 Forecasting | CD7 Commercial & Consumption Controls | Yes / Yes | Wrike Product Team | GA |
| CD7.5 Consumption Reporting | CD7 Commercial & Consumption Controls | Yes / Yes | Wrike Product Team + Global Wrike Team | GA |
#9 Operational Support#
Programme position (matrix, slide 7)
- Key risk: No clear support ownership.
- Potential impact: Longer incidents and support burden.
- Proposed controls: Support, escalation, disablement and recovery.
- Wrike proposed capability: Support Model; Central Management.
- Global Wrike Team controls: Named support contact, incident route, recovery procedure and individual-agent disablement required for Pilot. Formal SLA and scaled support model can mature later.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Wrike Product Team + Global Wrike Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Unclear ownership prolongs incidents. (slide 17) | Today: A native agent can be disabled individually. Pilot: Name the person who can disable it and the person responsible for recovery. | Confirm: how to stop the assistant or middleware connection and revoke access tokens. Name an operator who can carry out those steps. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD1.3 Named Primary & Secondary Ownership | CD1 Governance & Lifecycle Management | Yes / Yes | Global Wrike Team + Business Owner | Pilot |
| CD6.4 Support Model & SLA | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team + Global Wrike Team | GA |
| CD6.5 Support Ownership Matrix | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team + Global Wrike Team | Rollout |
| CD6.7 Individual Agent Disablement | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Pilot |
| CD6.8 Central Agent Management | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Rollout |
#10 Compliance & Regulatory#
Programme position (matrix, slide 7)
- Key risk: Regulatory or contractual conflicts.
- Potential impact: Compliance exposure.
- Proposed controls: Governance reviews and approvals.
- Wrike proposed capability: Audit Logging.
- Global Wrike Team controls: Taskforce screens every Pilot use case against client, market, contractual and data restrictions; retain approval evidence. Full compliance reporting and retention model required before GA.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Global Wrike Team + Business Taskforce
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Contractual or regulatory conflicts. (slide 14) | Today: Agent actions are recorded in audit logs. Pilot: Keep the Taskforce's approval record and evidence of the controls agreed for each use case. | Pilot: Check the use case against client and contractual restrictions, and retain the approval. Confirm: Identify the evidence available for MCP activity. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD1.3 Named Primary & Secondary Ownership | CD1 Governance & Lifecycle Management | Yes / Yes | Global Wrike Team + Business Owner | Pilot |
| CD4.1 Immutable Audit Logging | CD4 Audit, Compliance & Traceability | Yes / Yes | Wrike Product Team | Pilot |
| CD4.2 User vs Agent Attribution | CD4 Audit, Compliance & Traceability | Yes / Yes | Wrike Product Team | Pilot |
| CD4.5 Approval Expiry Evidence & Audit Retention Controls | CD4 Audit, Compliance & Traceability | Yes / Yes | Wrike Product Team | GA |
| CD4.6 Compliance Reporting | CD4 Audit, Compliance & Traceability | Yes / Yes | Global Wrike Team + Business Taskforce | GA |
#11 Agent Sprawl#
Programme position (matrix, slide 8)
- Key risk: Duplicate and unmanaged agents.
- Potential impact: Complexity and support burden.
- Proposed controls: Registry, standards and rationalisation.
- Wrike proposed capability: Agent Registry; Naming Standards.
- Global Wrike Team controls: Manual register is sufficient for five Pilot agents. Naming standards, approved templates, duplicate review and retirement workflow required by Rollout.
- Applies to: AI: Y · MCP: N
- Accountable owner: Global Wrike Team
- Required for: Rollout
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Duplicate or unmanaged agents. (slides 3–4) | Today: The registry makes agents in each Space visible. Pilot: Review that list for duplicates and agents that no longer have a clear purpose or owner. | MCP connections are tracked separately under risk #21, with an approved purpose and a named owner. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD1.1 Agent Registry | CD1 Governance & Lifecycle Management | Yes / Yes | Wrike Product Team + Global Wrike Team | Pilot |
| CD1.5 Reactivation Approval | CD1 Governance & Lifecycle Management | Yes / No | Wrike Product Team + Global Wrike Team | Rollout |
| CD1.6 Agent Retirement Process | CD1 Governance & Lifecycle Management | Yes / No | Global Wrike Team | Rollout |
| CD1.7 Agent Naming Standards & Templates | CD1 Governance & Lifecycle Management | Yes / No | Global Wrike Team | Rollout |
| CD6.8 Central Agent Management | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Rollout |
#12 Audit & Assurance#
Programme position (matrix, slide 8)
- Key risk: Activity cannot be evidenced.
- Potential impact: Audit findings and failed assurance reviews.
- Proposed controls: Audit trail and recurring reviews.
- Wrike proposed capability: Immutable Audit Logging.
- Global Wrike Team controls: Retain Pilot approval, owner, configuration/version and activity evidence; identify user versus agent. Exportable records and formal retention/assurance model can mature before GA.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Wrike Product Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Activity cannot be evidenced. (slide 14) | Today: Audit logs provide a record of agent actions. Confirm: Check how long records are kept and how they are protected against alteration. | Today: MCP actions are present in Activity Audits as well as comment stream traces. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD4.1 Immutable Audit Logging | CD4 Audit, Compliance & Traceability | Yes / Yes | Wrike Product Team | Pilot |
| CD4.2 User vs Agent Attribution | CD4 Audit, Compliance & Traceability | Yes / Yes | Wrike Product Team | Pilot |
| CD4.4 Exportable Audit Records | CD4 Audit, Compliance & Traceability | Yes / Yes | Wrike Product Team | GA |
| CD4.5 Approval Expiry Evidence & Audit Retention Controls | CD4 Audit, Compliance & Traceability | Yes / Yes | Wrike Product Team | GA |
#13 Vendor Dependency#
Programme position (matrix, slide 8)
- Key risk: Required enterprise controls are unavailable.
- Potential impact: Governance gaps remain open.
- Proposed controls: Gap assessment, roadmap follow-up and compensating controls.
- Wrike proposed capability: Product Commitment.
- Global Wrike Team controls: Track product gaps from Pilot and use compensating controls. Formal roadmap commitments and delivery dates are required before GA where unresolved gaps affect scale.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Wrike Product Team
- Required for: GA
Wrike response
Not addressed in the Wrike deck.
Capability delivery
No capability in the capability delivery view addresses this risk.
#14 Reputation & Client Trust#
Programme position (matrix, slide 8)
- Key risk: AI incidents reduce trust.
- Potential impact: Adoption resistance and client concerns.
- Proposed controls: Controlled rollout and oversight.
- Wrike proposed capability: Not identified.
- Global Wrike Team controls: Taskforce-approved use cases, client-impact review, named communications owner and incident route required for Pilot.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Global Wrike Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| AI incidents reduce trust. (slide 17) | Pilot: Agree who investigates, escalates, restores service and communicates with WPP if an agent causes an incident. | Pilot: Agree how teams coordinate an incident spanning the assistant, middleware and Wrike, including who updates WPP and any affected stakeholders. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD6.6 Incident Communications Framework | CD6 Monitoring & Operational Controls | Yes / Yes | Global Wrike Team | Pilot |
| CD6.7 Individual Agent Disablement | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Pilot |
#15 Tool Misuse#
Programme position (matrix, slide 9)
- Key risk: Agent performs unintended actions.
- Potential impact: Operational disruption or data impact.
- Proposed controls: Restrict tools to approved use cases.
- Wrike proposed capability: Scoped MCP Tokens.
- Global Wrike Team controls: Delete disabled; approved tool catalogue; restrict write tools to approved use case; individual-agent disablement. Finer tool-level administration can mature at Rollout.
- Applies to: AI: N · MCP: Y
- Accountable owner: Wrike Product Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Excess access; unintended actions. (slide 8, shared with #3) | Today: Permissions limit who can create agents, and each agent has a selected location. Pilot: Give creation rights only to approved Pilot builders. | Today: Wrike access follows the authenticated user. Confirm: Check that middleware scope and assistant tool settings keep access within the approved use case. |
| Unintended actions disrupt work. (slide 16) | Today: The agent's configured actions and assigned location limit what it can do. Pilot: Review that setup against the approved use case. | Confirm: Turn off unapproved tools in the LLM assistant / MCP gateway, then test both an allowed action and an action the Pilot should prevent. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD2.1 Scoped MCP Tokens | CD2 Identity, Access & Security Controls | No / Yes | Wrike Product Team | Pilot |
| CD3.7 Read-Only Agent Mode | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Rollout |
| CD5.2 Tool Restrictions | CD5 AI Safety & Trust Controls | No / Yes | Wrike Product Team | Pilot |
| CD5.3 Tool-Level Permissions | CD5 AI Safety & Trust Controls | No / Yes | Wrike Product Team | Rollout |
| CD6.7 Individual Agent Disablement | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Pilot |
#16 Cross-System Data Leakage#
Programme position (matrix, slide 9)
- Key risk: Information exposed across connected systems.
- Potential impact: Client confidentiality and contractual risks.
- Proposed controls: Data boundaries and classification controls.
- Wrike proposed capability: Scoped MCP Tokens.
- Global Wrike Team controls: Pilot limited to approved connections, spaces and data; restrict context and returned volume; no sensitive cross-system flow unless specifically approved.
- Applies to: AI: N · MCP: Y
- Accountable owner: Wrike Product Team + AI CoE + Global Wrike Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Data crosses approved boundaries. (slide 9, shared with #21) | — | Note: Tracking cross-system data passage is out of Wrike MCP boundaries and should be governed on the LLM client / MCP gateway layer. |
| Data crosses approved boundaries. (slide 16, shared with #21) | Pilot: Keep native-agent work in approved Wrike locations, and review which data is present there before enabling the agent. | Confirm: Gateway restricts connections and data access; assistant policies control shared context. Test the handling of sensitive cross-system information. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD2.1 Scoped MCP Tokens | CD2 Identity, Access & Security Controls | No / Yes | Wrike Product Team | Pilot |
| CD3.1 Bulk Update & Extraction Limits | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.2 Record-Return & Rate Limits | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD5.3 Tool-Level Permissions | CD5 AI Safety & Trust Controls | No / Yes | Wrike Product Team | Rollout |
| CD5.7 Data Boundary Enforcement | CD5 AI Safety & Trust Controls | No / Yes | Wrike Product Team + AI CoE + Global Wrike Team | Pilot |
| CD5.8 Context-Sharing Restrictions | CD5 AI Safety & Trust Controls | No / Yes | Wrike Product Team | Pilot |
#17 Identity Propagation#
Programme position (matrix, slide 9)
- Key risk: Identity misuse across systems.
- Potential impact: Loss of accountability.
- Proposed controls: User-scoped authentication.
- Wrike proposed capability: Scoped Service Accounts.
- Global Wrike Team controls: User-scoped identity; no shared accounts; delegated access checked before activation; approval expires with identity or access change.
- Applies to: AI: N · MCP: Y
- Accountable owner: Wrike Product Team + Global Wrike Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Identity misuse across systems. (slide 8) | n/a | Today: MCP calls use an authenticated user context. Confirm: Check whose identity reaches Wrike, what access is delegated and that shared accounts are avoided. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD2.2 OAuth Authentication | CD2 Identity, Access & Security Controls | No / Yes | Wrike Product Team | Pilot |
| CD2.6 No Shared Credentials | CD2 Identity, Access & Security Controls | No / Yes | Global Wrike Team | Pilot |
| CD2.7 User Context Enforcement | CD2 Identity, Access & Security Controls | No / Yes | Wrike Product Team + Global Wrike Team | Pilot |
#18 Prompt Injection#
Programme position (matrix, slide 9)
- Key risk: Malicious instructions alter AI behaviour.
- Potential impact: Unauthorised extraction, updates or actions.
- Proposed controls: Restricted tools, monitoring and training.
- Wrike proposed capability: Not confirmed.
- Global Wrike Team controls: Manual use-case review is not sufficient alone: restrict tools, limit bulk actions and require approval for high-impact writes. Advanced prompt-injection detection can follow at Rollout.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Wrike Product Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Malicious instructions alter behaviour. (slide 16) | Pilot: AI Agents instructions are defined during creation and malicious instructions can't be injected. Wrike also uses Prompt Shield API from Microsoft to prevent any system-lvl malicious instructions. | Pilot: Limit tools and high-impact writes. Confirm: Test whether malicious instructions can trigger an unapproved action or data disclosure. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD3.7 Read-Only Agent Mode | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Rollout |
| CD5.1 Prompt Injection Protection | CD5 AI Safety & Trust Controls | Yes / Yes | Wrike Product Team | Rollout |
| CD5.2 Tool Restrictions | CD5 AI Safety & Trust Controls | No / Yes | Wrike Product Team | Pilot |
| CD5.3 Tool-Level Permissions | CD5 AI Safety & Trust Controls | No / Yes | Wrike Product Team | Rollout |
| CD6.3 Approval Expiry & Abnormal Behaviour Alerts | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Rollout |
#19 Lack of Traceability#
Programme position (matrix, slide 9)
- Key risk: Requester or action cannot be identified.
- Potential impact: Difficult investigation and root-cause analysis.
- Proposed controls: End-to-end audit logging.
- Wrike proposed capability: Immutable Audit Logging.
- Global Wrike Team controls: Pilot must identify requester, agent and resulting action. MCP connection detail, export and longer retention can mature at Rollout/GA.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Wrike Product Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Requester or action is unidentified. (slide 14) | Confirm: Use a real log example to identify the agent, its action and the resulting change, rather than relying only on a description of logging. | Confirm: Follow one real request from its originating user through the MCP call to the resulting Wrike change, and identify the evidence at each step. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD4.1 Immutable Audit Logging | CD4 Audit, Compliance & Traceability | Yes / Yes | Wrike Product Team | Pilot |
| CD4.2 User vs Agent Attribution | CD4 Audit, Compliance & Traceability | Yes / Yes | Wrike Product Team | Pilot |
| CD4.3 MCP Connection Details in Logs | CD4 Audit, Compliance & Traceability | No / Yes | Wrike Product Team | Rollout |
| CD4.4 Exportable Audit Records | CD4 Audit, Compliance & Traceability | Yes / Yes | Wrike Product Team | GA |
| CD6.1 Enterprise Dashboard & Activity Feed | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Rollout |
#20 Autonomous Actions#
Programme position (matrix, slide 9)
- Key risk: High-impact actions execute without oversight.
- Potential impact: Mass data corruption or operational disruption.
- Proposed controls: Human approval gates.
- Wrike proposed capability: Agent Approval Workflow.
- Global Wrike Team controls: Delete disabled; update limits, bounded approvals, high-impact preview, individual kill switch and manual review. Rollback, protected fields and automated anomaly detection can mature at Rollout.
- Applies to: AI: Y · MCP: Y
- Accountable owner: Wrike Product Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| High-impact actions lack oversight. (slide 5) | Today: AI Agents work similar to automations within their assigned location, with no delete action. Note: AI Agents do not ask for approval before each action. | Confirm: Test a high-impact write in the chosen assistant to confirm LLM client controls |
| High-impact actions lack oversight. (slide 12) | Pilot: Review the agent's configured actions and possible impact upfront. Note: AI Agents do not offer a separate approval step before each action. | Confirm: High-impact write tools require the intended human approval. |
| High-impact changes at scale. (slide 10) | Pilot: Start with approved locations and use cases. Gap: A small location reduces exposure, but it is not an enforced record-count or request-rate cap. | Confirm: MCP gateway behaves as expected in terms of action limits. |
| Damaging actions continue unchecked. (slide 17) | Pilot: Taskforce reviews the AI Agents performance and details what/if any further in-product requirements they have for Wrike. | Pilot: Taskforce reviews the actions done via MCP and its performance and details what/if any further in-product requirements they have for Wrike. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD1.2 Agent Approval Workflow + Time-limited approval | CD1 Governance & Lifecycle Management | Yes / Yes | Wrike Product Team | Pilot |
| CD3.1 Bulk Update & Extraction Limits | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.2 Record-Return & Rate Limits | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.3 Time-Bounded, Scoped and Volume-Bounded Approval | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.4 High-Risk Action Approval Gates | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.5 Access & Approval-Rule Protection | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.6 Preview Impacted Records | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Pilot |
| CD3.7 Read-Only Agent Mode | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Rollout |
| CD3.8 Protected Fields | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Rollout |
| CD3.9 Rollback Capability | CD3 Action Governance & Data Protection | Yes / Yes | Wrike Product Team | Rollout |
| CD6.3 Approval Expiry & Abnormal Behaviour Alerts | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Rollout |
| CD6.7 Individual Agent Disablement | CD6 Monitoring & Operational Controls | Yes / Yes | Wrike Product Team | Pilot |
#21 External AI Platform#
Programme position (matrix, slide 9)
- Key risk: Data leaves approved governance boundary.
- Potential impact: Compliance and governance risk.
- Proposed controls: Approved architecture and review process.
- Wrike proposed capability: Registry; Approval Workflow.
- Global Wrike Team controls: External platform/connection architecture must be approved before Pilot use; register each connection and restrict scope. Enterprise-standard hosting/gateway maturity required before GA.
- Applies to: AI: N · MCP: Y
- Accountable owner: AI CoE + Global Wrike Team
- Required for: Pilot
Wrike response
| Concern in the Wrike deck | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Data leaves approved boundaries. (slide 5) | This risk concerns an external AI platform connecting to Wrike through MCP. Native-agent ownership and creation rights are covered on the earlier slide. | Pilot: WPP approves the external platform, connection design and data scope before use, then records each approved connection and its owner. |
| Data crosses approved boundaries. (slide 9, shared with #16) | — | Note: Tracking cross-system data passage is out of Wrike MCP boundaries and should be governed on the LLM client / MCP gateway layer. |
| Data crosses approved boundaries. (slide 16, shared with #16) | Pilot: Keep native-agent work in approved Wrike locations, and review which data is present there before enabling the agent. | Confirm: Gateway restricts connections and data access; assistant policies control shared context. Test the handling of sensitive cross-system information. |
Capability delivery
Capabilities from Risk coverage and capability delivery that list this risk under Risks Addressed.
| Capability | Capability group | AI Agent / MCP | Owner | Required For |
|---|---|---|---|---|
| CD1.1 Agent Registry | CD1 Governance & Lifecycle Management | Yes / Yes | Wrike Product Team + Global Wrike Team | Pilot |
| CD1.2 Agent Approval Workflow + Time-limited approval | CD1 Governance & Lifecycle Management | Yes / Yes | Wrike Product Team | Pilot |
| CD5.7 Data Boundary Enforcement | CD5 AI Safety & Trust Controls | No / Yes | Wrike Product Team + AI CoE + Global Wrike Team | Pilot |
Responsibilities before the Pilot starts#
Wrike deck, slide 18. Purpose: confirm evidence and configuration; agree owners and residual-risk decisions. The deck groups the risks into three sets (it also says "19 requests mapped in appendix"). Labels here show who is responsible: Wrike, WPP, or Joint (agreed together).
| Risk group | Wrike AI Agents | Wrike MCP |
|---|---|---|
| Governance & oversight (#1, #6, #7, #11, #20) | Wrike: Demonstrate the registry, creation rights and protected rules. Joint: Agree named owners, use-case review and treatment of high-impact actions. | WPP: Record connections and owners. Joint: Agree which client approval settings and middleware restrictions apply to high-risk writes. |
| Identity, data & tool boundaries (#2, #3, #4, #15–#18, #21) | Wrike: Show the actions and locations configured for Pilot agents. Joint: Check the data present and agree the acceptable exposure for the Pilot. | WPP: Demonstrate OAuth, allowlists, token handling, permitted tools and middleware scope, including how the assistant handles shared context. |
| Audit, support & client trust (#9, #10, #12, #14, #19) | Wrike: Show real logs, agent attribution and disablement. Joint: Confirm the evidence WPP needs and who owns incident response and recovery. | Joint: Trace a real MCP action, rehearse shutdown and token revocation, and agree which team owns audit evidence and incident communications. |
Further detail in the Wrike deck#
The Wrike deck also carries screenshots and documentation references, transcribed in the WPP × Wrike AI Pilot section:
- Space-level Agent registry and user permissions for AI: Governance: ownership and visibility
- AI Agent configuration interface, available actions and reasoning logs: Governance: review and action oversight
- Configuring AI Agent location scope: Data scope
- Testing an AI Agent in the sandbox before activating: Human review
- Audit reports and comment stream traces for MCP actions: Audit and traceability
- Official Wrike documentation references: Official Wrike documentation references