GATE010: Destructive tool exposed

The agent has tools that delete, drop, destroy or otherwise irreversibly remove state.

What Gate detected

Gate classified one or more tools or grants as carrying the delete capability, deleting files, dropping tables, deleting branches or repositories, revoking access, terminating resources.

Why this matters

Destructive operations are the ones you cannot fix by re-running the agent correctly. Every other class of mistake is recoverable at some cost; deletion frequently is not, and the cost lands on whoever needed the data.

Agents make destructive mistakes for reasons that have no analogue in normal software: a misread instruction, a hallucinated resource name, an injected instruction in a document, or simple over-eagerness in cleaning up. The mitigation is not better prompting: it is not granting deletion, or gating it behind a human.

Example

This is the shape of configuration that triggers the rule.

// github.delete_branch     -> delete
// postgres.drop_table      -> delete
// filesystem.move_file     -> write, delete

Remediation

Remove destructive tools from the agent unless deletion is the job. Where it is, use a credential that cannot delete, add a soft-delete layer, or require explicit human approval for that specific tool. Backups are a control here too: a destructive capability against a system with tested restores is a different risk from one without.

Suppressing this rule

If this finding is acceptable in your repository, record why alongside the suppression:

export default defineConfig({
  ignore: [
    {
      rule: 'GATE010',
      reason: 'Why this is acceptable here',
    },
  ],
})

Gate refuses to apply an ignore entry with no reason. The reason is the only thing that will tell the next person whether the suppression is still true.

References

• OWASP Top 10 for Agentic Applications (2026)
• NIST SP 800-53 AC-6: Least Privilege