Control what agents can delete

Connected AI agents (Claude Code, Cursor, ChatGPT, and other MCP clients) can read and update your projects. By default they cannot delete anything. The Governed operations group, at the top of Agent Policies, lets an Owner or Admin turn on specific high-impact operations, one at a time, so agents do only what your organization has explicitly allowed.

Note

This policy governs connected (external) agents over MCP. It does not change the in-app assistant, which already acts as the signed-in person.

How it works

• Deny-by-default. Every destructive operation is off until you enable it. An empty policy means agents can delete nothing.
• One operation at a time. You enable each operation individually (for example, “Delete a task” without enabling “Delete a project”).
• Still permission-checked. Enabling an operation does not bypass permissions. The agent still needs the underlying right (for example, permission to delete a task), and a project-scoped connection still only reaches its own projects.
• Audited. Every agent deletion is recorded in the audit log, and the operations available today are recoverable from the recycle bin.

Enable an operation

1. Go to Settings → Agents → Agent Policies and find the Governed operations group pinned at the top.

2. Find the operation you want to allow. Each row shows whether it is recoverable (restorable from the recycle bin) and its blast radius (what it affects).

3. Toggle it on.

4. Click Save policy. The change takes effect immediately for every connected agent in your organization, and is recorded in the audit log.

To revoke, toggle the operation off and save again. Connected agents are denied the operation on their next call.

What agents can be allowed to do

Today the group covers the recoverable deletions:

• Delete a task: removes a task and its subtasks. Recoverable from the recycle bin.
• Delete a project: removes the entire project and all its tasks, sprints, epics, and milestones. Recoverable from the recycle bin. This is the highest-impact operation. Enable it only if you trust your connected agents with it.
• Delete a list: removes a workspace list (table) and its rows. Recoverable from the recycle bin.
• Delete a document: removes a workspace document. Recoverable from the recycle bin.

To restrict deletes only in a certain scope rather than turn them off entirely (for example, “no deletes in finance projects”), leave the operation enabled here and add a rule in the Agent Policies list below the group.

Caution

Enabling an operation applies to all connected agents in the organization, not a single agent. Review your connected agents under Settings → Agents before turning on a high-impact operation.

Who can change the policy

Editing the policy requires the Manage agent destructive-op policy permission, which defaults to Owner and Admin. You can tighten it to Owner-only (or adjust it) in the Permissions matrix. Anyone who can open the tab can view the current policy; only authorized roles can change it.

Frequently asked questions

Does this affect the in-app “Run with Onplana Agent”? No. This policy governs connected (external) MCP agents. The in-app assistant is unchanged.

What happens when an agent tries a disabled operation? The request is denied and the agent is told the operation is disabled for your organization. Nothing is deleted.

Are deletions reversible? The operations available today (delete task, project, list, document) move items to the recycle bin, where a manager can restore them. They are not permanent deletions.

Best practices

1. Stay deny-by-default; enable cautiously. The default protects you. Enable specific operations only when an agent workflow needs them.
2. Use contextual rules to scope by project. “No deletes in finance projects” via the Agent Policies rules list below the governed-ops group.
3. Prefer the narrowest op. Enable delete-task rather than delete-project when the workflow only needs task cleanup; you can always widen later.
4. Review enabled ops monthly. What was enabled 6 months ago for a one-off may be stale today. Disable if no longer needed.
5. Test with a low-stakes agent first. Before enabling delete-project across the org, verify with a project-scoped agent on a sandbox project.

Troubleshooting / common pitfalls

• Agent’s delete request denied. Op not enabled. Toggle on + Save.
• Op enabled, agent still can’t delete. Permission check failed. Agent lacks underlying permission.
• Saved, but old agent still seeing old policy. Per-call evaluation; agent’s next call uses new policy.
• Toggle disabled for me. Permission insufficient. Owner/Admin only by default.
• Deleted item not in recycle bin. All enabled ops route through recycle bin. If missing, file bug.

How this combines with other features

• Agent governance + Agent Policies rules. Pinned destructive ops + contextual rule list. Two surfaces, one panel.
• Agent governance + Audit log. Every destructive op writes to audit log. See Read audit logs.
• Agent governance + Recycle bin. All destructive ops route through recycle bin. See Restore from the recycle bin.
• Agent governance + Agent connections. Per-agent project scoping further limits blast radius. See Connect an external agent.

Coming from another tool

Tool	Mapping
Custom RBAC for AI	Onplana’s first-class deny-by-default
Microsoft Copilot data controls	Direct concept
Salesforce Einstein scoping	Similar
ServiceNow AI governance	Direct
Custom firewall for AI	Onplana’s app-level enforcement

Related

• Connect an external agent, agent setup
• Restore from the recycle bin, recovery path
• Read audit logs, destructive op history