Agent governance is a permissions problem before it is a model problem

What it says#

The piece walks through a regulator's treatment of one product. On 28 May 2026 Singapore's Cyber Security Agency published an advisory on the cybersecurity risks of OpenClaw, an open-source agent platform ¹. The advisory points to a case study by the Infocomm Media Development Authority on its responsible deployment ¹. The advisory defines autonomous agents as AI systems that can understand context, formulate plans and take independent actions to achieve specified objectives ¹.

Its five named risks are unpatched vulnerabilities, weak access controls, sensitive data exposure, malicious third-party skills and memory poisoning ¹. The article's reading of that list is the point of the piece: not one of the five is about the quality of an answer. They are about what the agent can reach and what it inherits from the user who installed it. They are about what it sends to the model provider as context, what it loads from a public skills marketplace, and what an attacker can write into its long-term memory to trigger later.

The advisory's recommendations for organisations follow the same logic. It asks for zero-trust principles and several narrowly scoped agents instead of one all-purpose agent. It asks for dedicated credentials, injected as short-lived tokens from a vault and rotated ¹. Outbound connections go through a policy-enforcing proxy, and logging is persistent and attributable. High-stakes or irreversible actions need system-level human approval, deployment is preceded by negative tests, and a compromise ends in a rebuild from a known-good baseline. The advisory lists all of these ¹. The article's summary of the underlying principle comes from the IMDA case study. Accepting the risk of a broadly capable agent should be a conscious decision, never the result of an ignored default.

What we take from it#

Read as a control set, the advisory is an identity and access programme with an agent in the subject line. Dedicated credentials, scoped tokens, an egress proxy, approval gates, attributable logs and baseline rebuilds are what a mature organisation already applies to service accounts and privileged automation. The novelty is the subject, not the controls.

That framing settles a question we hear often: which team owns agent security. If the risks are permission inheritance, credential exposure, unvetted extensions and persistent state, the owner is whoever owns identity, access and change control today. A model-evaluation team can assess outputs; it cannot rotate a token.

The memory-poisoning risk deserves its own line in a threat model, because it breaks a habit. A compromised agent is not cleaned by a restart if the instruction sits in its memory store, its vector index or a downstream configuration. The advisory's answer, rebuild from a known-good baseline, is the same discipline as rebuilding a compromised host rather than patching it in place. Programmes that have that discipline for servers should extend it to agents before the first incident, not after.

For the compliance officer there is a translation to make. An agent with write or execute permissions is an automated actor inside the scope of the management system. Its identity, its permissions and its logs are evidence in the same way a privileged account's are, and the approval that granted them should be findable.

Where we would push back#

The advisory, and the article with it, describe a control layer that is expensive: a separate control plane, an egress proxy, a vault and negative testing. The piece does not ask what an individual or a small team can afford, and its own tiering of deployment contexts is the honest answer. Experimental use on a dedicated machine with nothing sensitive on it needs a subset of the list, not all of it.

The count of vulnerabilities the article quotes for the platform is given without a baseline, and a large count can reflect an active community as much as a fragile product. We would not cite it as evidence of anything except attention.

Finally, the recommendation to prefer several narrow agents runs against the direction of the products people buy, which converge on one assistant with broad reach. The advisory's own note that agent-to-agent interaction adds uncertainty suggests the narrow-agent design has a coordination cost the piece does not price.

Related on GRCIDE#

• AI governance stand-up under the EU AI Act, on where an agent estate sits in a governance programme.
• From regulation to controls, on writing the control objective and naming the owner.