Acceptance criteria
Permit a read while refusing write, delete or other destructive actions, with every attempt logged and attributable.
Why it matters
One agent can read, write and delete in the same workflow. Allow or deny per app is too blunt.
How to verify
Reads to a connected system are allowed while attempts to change or delete information are blocked.
OWASP adoption context
Citizen-built, code-executing and MCP-extended workflows can take consequential tool actions, making operation-level permissions relevant.
Framework mappings
Allowing reads while refusing writes, deletes and destructive operations enforces least privilege at the tool-call boundary. Enforce restrictions before the operation and record every attempt with usable attribution, retention, protection and analysis. Warnings or a live view alone are insufficient; runtime refusal does not review or revoke the underlying connector grant.
A defined, enforced boundary between permitted reads and prohibited destructive actions implements a concrete responsible-use procedure for agents. It contributes to the wider AI-use process without implying that the standard prescribes these exact API scopes.
Operation-level refusal limits destructive tool misuse and actions attempted through excessive or misapplied delegated identity. Attributable attempts help investigate those failures; the control covers the operations and tool paths where it is enforced.