We're building out our compliance docs for an agent runtime using OpenClaw, and I'm trying to map our plugin permission model to ISO 27001's access control requirements (A.9). The standard is pretty broad about "application access control," and our auditors keep asking how we ensure "least privilege" for automated agents.

Our approach is to define permissions in the tool manifest, but I needed to categorize them for the ISMS. Here's my mapping so far:

```yaml
# Example plugin manifest with ISO control tags
name: data_processor
permissions:
- object: "s3://customer-data-*"
operations: ["read"]
# Maps to A.9.1.2 (Access to networks and network services)
# and A.9.4.4 (Use of privileged utility programs)
iso_controls: ["network_access", "utility_program_access"]

- object: "POST /api/v1/alert"
operations: ["execute"]
# Maps to A.9.1.2 and A.9.4.2 (Secure log-on procedures)
iso_controls: ["network_access", "application_logon"]
```

The tricky parts I'm still working through:

* **Rate limits as an access control?** Does a `max_requests_per_minute` constraint satisfy parts of A.9.4.5 (Access control to program source code) by limiting abuse potential, or is that purely a availability concern?
* **State management and session control.** If an agent maintains conversation state across tool calls, how are you documenting this against A.9.2.6 (Removal or adjustment of access rights)? Is the agent's "session" equivalent to a user session?
* **Error logging.** Permission denials are logged, but do those logs need to specifically tie back to the agent's "identity" and the policy rule that triggered the denial for A.9.2.3 (Management of privileged access rights)?

Has anyone else gone through this mapping exercise? I'm particularly interested in how you've handled:

* Dynamic permission grants (e.g., a tool that temporarily gets a token based on user input)
* The "segregation of duties" concept when an orchestration workflow chains multiple tools under a single agent identity