Before your AI agent gets access to the inbox.

A practical reason to examine access.

Hong Kong’s Privacy Commissioner has published guidance on personal data privacy in the use of agentic AI. It recommends limiting access to the information and systems needed for a defined purpose, granting minimum necessary rights and providing traceability. Human oversight, retention and clear responsibilities are also addressed. [1]

Reed Smith published a client alert on the guidance on 9 September. The alert draws attention to the practical work involved in adopting agents. [2]

The example below applies selected ideas to a fictional enquiry. The access rules and approval sequence are my design choices for this task. They are not a complete implementation of the guidance.

How much authority does this enquiry need?

A fictional office-supplies business receives a question about a storage tray. The approved product sheet contains the pack size. Live stock sits elsewhere. The agent can prepare an answer about the pack size; stock remains a question for a person.

Start with the action the business needs.

There are three useful stopping points. A draft gives the colleague something to work from. Updating a register also changes the business’s record of progress. Sending a reply puts the answer in someone else’s inbox.

In this example, “draft prepared” means text exists for review. It does not mean that stock was checked or the customer received a reply. That distinction matters when another colleague picks up the record.

The send scenario also keeps register access separate. Sending a message does not silently grant permission to update other systems. A real workflow may need both actions, but both should be specified.

Leave the unanswered question visible.

The enquiry asks about stock, and the approved product sheet cannot answer it. The proposed response says that stock needs confirmation. It gives the colleague a visible follow-up instead of turning missing information into an assurance.

I would keep that unresolved question beside the draft and its source. If the approved sheet changes, the response needs another review. If the task expands to checking stock, it needs a named source and an explicit decision about access.

The simulation clears approval when the requested action or permissions change. In a connected system, changes to the message, source version, recipient or draft would also need to invalidate the relevant approval. That behaviour would have to be enforced by the system that performs the action.

A small workflow still needs an owner.

For a first pilot, I would write down the permitted inputs, the allowed action, the reviewer and the evidence kept after each run. The team would also need to decide how long that evidence remains and who can inspect it.

Testing should include an enquiry with an unsupported request, an outdated source and a recipient change after approval. These are useful ways to check whether the proposed boundary survives everyday work.

This specimen shows the decisions on screen. A production integration needs to enforce them through permissions and action checks, with the wider privacy and security review appropriate to the data involved.