Wednesday, 28 Oct 2026 · Hong Kong Hong Kong and China labour news in English
CLB.org.hk China Labour Bulletin Board
Hong Kong news · dedicated AI coverage 中國勞工資訊板 · Labour, employment, jobs and AI.
Artificial Intelligence

AI agents at work: decide what they may read, change and send before deployment

A practical guide for Hong Kong workers and managers to build a permissions-and-approval matrix for AI agents, covering email, files, databases, and external actions, plus logs and a kill switch.

AI agents at work: decide what they may read, change and send before deployment

You have just been told your team will get an AI agent to handle customer emails, update spreadsheets, and pull data from the company database. The promise is efficiency. The worry is that the agent might read something it should not, change a critical file, or send a message to the wrong person. Without clear boundaries, an AI agent can become a liability. This article provides a protocol you can run to build a permissions-and-approval matrix that controls what an AI agent may read, change, and send, and ensures you have logs and a kill switch in place before deployment.

Why permissions matter for AI agents

An AI agent is not a human colleague. It does not have common sense or context awareness. If you give it access to a folder, it may read every file in that folder. If you let it send emails, it may reply to a customer with incorrect data. The Hong Kong Office of the Privacy Commissioner for Personal Data (PCPD) has issued guidance on AI and agentic systems, emphasising that organisations must ensure data minimisation and purpose limitation. The NIST Generative AI Profile (July 2024) similarly calls for mapping data flows and enforcing access controls. A permissions matrix is the practical tool to meet these requirements.

Building the permissions matrix

A permissions matrix is a table that lists each resource an agent can access and specifies exactly what actions are allowed. Use the following categories as a starting point.

  • Email: Define which mailboxes the agent can read, which it can send from, and whether it can delete or archive messages. For example, allow read-only access to the support inbox, but require human approval before sending any reply that contains a price quote.
  • Files: Specify folders and file types. An agent may read PDFs in a shared drive but not edit them. It may write new documents to a staging folder but not overwrite existing ones. Restrict access to folders containing personal data or financial records unless explicitly needed.
  • Databases: Grant read-only access to specific tables or views. Never give write access to production databases. If the agent needs to update records, route those changes through a separate approval queue.
  • External actions: This includes posting to social media, sending API calls to third-party services, or making payments. Each external action should require explicit approval from a human supervisor before execution.

For each resource, document the permission level: read, write, update, delete, or execute. Then add a column for approval requirements: none, automatic, or manual. Manual approval means a human must review and confirm the action before the agent proceeds.

Setting up approval workflows

Not every action needs a human in the loop. Low-risk actions, such as reading a public FAQ document, can be automatic. High-risk actions, such as sending an email with a customer’s personal data, must require manual approval. Design your workflow so that the agent flags the action and waits for a yes or no from a designated approver. The approver should see a clear summary of what the agent intends to do, including the data involved and the recipient.

Consider using a tiered approval system. For example:

  • Tier 1: Read-only actions – automatic.
  • Tier 2: Writes to non-sensitive folders – automatic with logging.
  • Tier 3: Sends external communications or writes to sensitive data – requires manual approval.
  • Tier 4: Deletes data or makes payments – requires two-person approval.

This tiered approach balances efficiency with safety.

Logging everything the agent does

Logs are your audit trail. Every action the agent takes should be recorded with a timestamp, the resource accessed, the action type, and the outcome (approved, rejected, or failed). Logs should be stored in a separate system that the agent cannot modify. This ensures that if something goes wrong, you can trace exactly what happened.

NIST’s AI RMF recommends continuous monitoring and logging as a core practice for trustworthy AI. In Hong Kong, the PCPD expects organisations to maintain records of data processing activities, especially when automated decisions are involved. Your logs should be reviewed regularly, not just after an incident.

Installing a kill switch

A kill switch is a mechanism that immediately stops the agent from taking any further actions. It should be accessible to a designated human operator, preferably via a simple interface such as a button in a dashboard or a command in a chat tool. The kill switch must override all permissions and approval workflows. When activated, the agent should stop all pending actions and enter a safe state where it cannot read, write, or send anything until manually reset.

Test the kill switch before deployment. Simulate a scenario where the agent is about to send a message to the wrong recipient. Activate the kill switch and verify that the message is not sent. Document the test results.

Limitations and privacy considerations

No permissions matrix is foolproof. An agent may misinterpret a permission or a human may approve a risky action without proper review. Always apply the principle of least privilege: give the agent the minimum access needed to perform its task, and no more. Review permissions regularly, especially when the agent’s role changes.

Privacy is a key concern. If the agent accesses personal data, you must comply with Hong Kong’s Personal Data (Privacy) Ordinance. The PCPD guidance advises conducting a privacy impact assessment before deploying any AI system that processes personal data. Ensure that the agent does not retain data longer than necessary and that logs do not contain unnecessary personal information.

Practical checklist for deployment

Before you let an AI agent work on live systems, run through this checklist:

  1. Map all resources the agent will access: email, files, databases, external services.
  2. Define read/write/delete permissions for each resource.
  3. Assign approval tiers: automatic, manual, or two-person.
  4. Set up logging: capture action, timestamp, resource, outcome.
  5. Install a kill switch and test it.
  6. Conduct a privacy impact assessment if personal data is involved.
  7. Review permissions with the team and get sign-off from a manager.
  8. Schedule a periodic review of permissions and logs.
  9. By following this protocol, you can deploy AI agents with confidence, knowing that you have controls in place to prevent unauthorised reads, unwanted changes, and unintended sends. The goal is not to eliminate risk entirely, but to manage it transparently and responsibly.

Sources and further reading

Guidance and regulations can change; check the current primary sources before applying them to a consequential workplace decision.

Adam
Editor in Chief

Editor in Chief overseeing CLB.org.hk coverage and editorial standards.