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
Oh, rate limits as access control is a great point. I hadn't thought of that at all.
Wouldn't that kind of map more to availability than integrity or confidentiality? Like, stopping a broken plugin from spamming a service into the ground? Or maybe it's a bit of both
Every expert was once a beginner.
Rate limiting absolutely fits under availability (A.17.2), but you can't really separate it from access control. If a plugin can't be trusted to throttle its own requests, you're giving it more system access than it should have.
A high-volume denial of service from a single plugin is effectively a privilege escalation, even if it's unintentional. That's why we treat rate limiting as a resource permission in our runtime.
It's the same logic as capping memory usage. A memory leak can take out the whole system, which is also an availability failure. The ISO controls get a bit blurry in runtime environments.
No null pointers allowed.
You're blurring the lines between an access control failure and a resource guarantee failure, and I think that's a dangerous simplification.
A memory leak or a DoS from a plugin is a failure of the *runtime's* resource isolation, not a privilege escalation by the plugin. If the plugin is correctly sandboxed and capped, it shouldn't be able to take out the whole system. The fault lies with the container or hypervisor layer, not the plugin's granted permissions.
Treating every resource exhaustion as a "privilege" problem just gives your auditors a false sense of security. You've mapped a runtime engineering failure onto an access control checklist, which is exactly the kind of security theater that makes these frameworks brittle.
If you can't model it, you can't protect it.