Singapore Tells Consumers How to Rein In Personal AI Agents. Product Teams Should Read It as a Spec

On Friday, November 6, 2026, three Singapore government bodies, the Cyber Security Agency of Singapore (CSA), the Government Technology Agency (GovTech), and the Infocomm Media Development Authority (IMDA), issued a joint advisory called Using Personal AI Agents Safely and Securely: What Consumers Should Know. It is written for the public, not for companies. It describes assistants that can read email, browse websites, make bookings, and act in the background, and its summary line is blunt: users “cannot treat them like human assistants and give them the same broad access to your information and implicit trust.” For companies that build these agents, or whose platforms agents will act on, the advisory works as a description of the controls consumers will now expect to find.

What the advisory covers

The document separates agents from chatbots. Personal AI agents, it says, can connect to apps and accounts, browse websites, manage email, make bookings, and remember preferences. It names Dots, Hermes, Muse, Grok Bot, and OpenClaw as examples, and it refers readers to a separate CSA advisory and an IMDA case study on OpenClaw. It lists the risks in plain terms. Depending on the access granted, an agent may read and reveal sensitive information, make mistakes, take unintended actions, keep running in the background, be manipulated by malicious websites or messages, and deal with people who do not realise they are not talking to a human.

It also addresses responsibility directly. Users “remain responsible” for how they use agents, including actions taken on their behalf, and “may also be held liable” depending on the circumstances and applicable law. That puts the risk on the consumer, which is exactly why consumers will look to product design to help them manage it.

For organisations, this sits alongside IMDA’s January 2026 Model AI Governance Framework for Agentic AI, which addressed enterprises that deploy agents. The new advisory covers the other side of the same transaction: the individual who installs one on a phone and connects it to a personal inbox.

The five steps, read as product requirements

The CSA advisory page links to the full PDF. Each step tells consumers what to do. Read from the other side, each step also says what an agent needs to offer before a consumer can follow the advice.

1. Limit what your AI agent can access. Connect only the apps and accounts the agent needs, start with low-risk accounts, and avoid banking, government, and healthcare accounts. Never give the agent passwords, one-time passcodes, or card details. For Singpass, use passkeys and complete authentication yourself. Implication for builders: scoped connectors, folder-level permissions, and a clear list of everything the agent can reach.
2. Stay in control of important actions. Start read-only, require approval before sending messages, deleting or sharing files, or posting publicly, and choose one-time approval over “always allow.” The advisory also warns users not to rely only on chat instructions to restrict an agent, because those “may not always be followed consistently,” and to use app settings instead. Implication: permission limits enforced in settings, not just in prompts, plus an activity history users can actually review.
3. Find out how your information is used and stored. Check what the provider collects, who it shares data with, how long it keeps it, whether chats and connected-account data train models or personalise ads, and what the agent remembers. Many agents have persistent memory and can build profiles of users and their contacts. Implication: memory that users can view and delete, and clear settings for training and ads.
4. Protect yourself from scammers or other malicious actors. Hidden instructions in web pages, emails, calendar invites, documents, or images can manipulate an agent. Users are told to watch agents while they browse, make sure only they can give instructions, use strong authentication, install only official apps and trusted add-ons, and, if something goes wrong, stop the agent, disconnect accounts, look for changes such as new payees or forwarding rules, and clean up memories and credentials. Implication: an obvious stop control, per-connector revocation, and exportable activity records.
5. Think about the impact on others. Inboxes and files contain information about family, friends, and colleagues. Users should avoid sharing sensitive information about others, say when an email or message was sent by an AI agent, and never ask an agent to get around paywalls, logins, or other access controls. Implication: built-in disclosure that a message was sent by an agent, and memory hygiene that covers third parties.

Step one is easy to misread as a general instruction to share less in conversation. The full advisory text is more specific: limit which apps and accounts the agent can reach, and keep credentials away from it. That distinction matters for product teams, because connectors and scopes are product decisions.

The annexes are a design audit

Annex A lists the common names for agent controls, such as connectors, permissions, approvals, activity logs, data controls, memory, stop and pause, download and reset, account security, and add-ons, and says what users should do with each. Annex B walks through all five steps for Meta’s Muse, with settings described as accurate on November 5, 2026, for specific iOS and Android versions in Singapore. The agencies state that this is not an endorsement or a security assessment of Muse.

Several details in Annex B are worth noting for any product team. Users of a Meta account in the same Accounts Centre as Facebook, Instagram, or Threads will find those accounts connected to Muse automatically. Meta says it does not review custom connectors. Approval options range from “Allow once” to “Always allow,” and the advisory tells users to check the scope of each grant. If what the agent says in chat does not match its activity log, users should rely on the log. Resetting the agent deletes chat history and files but does not undo actions already taken. A company whose agent lacks one of those controls now has a public government document showing users what to look for.

The memory guidance deserves particular attention. The advisory treats long-term memory as something users should inspect and prune, including what the agent stores about other people. That matches a growing concern about the hidden architecture of AI agent memory, in which profiles accumulate without the user ever seeing them.

Where the law comes in

The advisory is not a regulation, and it creates no new obligations. Singapore’s Personal Data Protection Act still governs how organisations collect, use, and disclose personal data, and companies running agents for Singapore users should already have mapped their obligations. The comparison of Singapore’s PDPA and the GDPR is a reasonable place to start for teams working across both regimes. What the advisory adds is a clear statement of expectations. If an agent quietly connects accounts, defaults to “always allow,” or hides its memory, regulators and plaintiffs will find it easier to argue that the design fell short of what users were told to expect.

The same reasoning applies outside Singapore. US regulators have said that deploying an autonomous system does not move accountability onto the software, which is the argument in the FTC’s message to businesses deploying autonomous AI. Practitioners have been writing similar control lists, such as this practical guide to AI agent risks and safeguards. Infrastructure incidents, including the issues covered in Moltbot and the privacy risks of agentic AI infrastructure, show why the advisory spends so much time on add-ons, fake installers, and credentials.

Employers face a quieter question. The advisory tells users to check whether their employer allows an agent on a work account. Few workplace acceptable-use policies say anything about personal agents yet. A short rule on whether staff may connect personal AI agents to corporate email, calendars, or files, and on what scope and approvals are required, would close a gap that scammers have already started to target.

Frequently asked questions

Is the Singapore advisory legally binding?

No. It is consumer guidance from three government agencies. Existing laws, including the PDPA, continue to apply to the organisations involved.

Why does it warn against relying on chat instructions?

Because an agent may not follow instructions given in conversation consistently. Settings in the agent’s app and in the connected service, such as an email account, give firmer limits.

What should a user do first if an agent misbehaves?

Stop the current task, disconnect affected accounts both in the agent and in the account itself, change passwords, check for unauthorised changes, and save activity records before resetting anything. If money is at risk, the advisory points users to their bank’s kill switch and the ScamShield helpline at 1799.

Does the advisory apply to business deployments?

It is written for consumers. Organisations deploying agents should look to IMDA’s agentic AI governance framework and their own legal obligations, while using the advisory as a guide to what end users will expect.

Narrow access, explicit approval

The advisory is short and practical, and that is why it matters. It gives ordinary users a vocabulary, including connectors, one-time approval, activity log, memory, and stop, for judging whether an agent deserves their trust. Product teams that treat those five steps as a release checklist will find most of the work is permissions engineering rather than model tuning. Those that leave the steps to users will find that the government has already explained to those users what to look for.