The owner summary

Give an agent a job before you give it access. For that one job, write down the information it needs, the actions it may take, what requires approval and who can stop it. Start with the smallest useful permission. If a checklist or fixed rule can do the work, you may not need an agent at all.

A draft is different from an action

An AI assistant can suggest a reply for a person to review. A connected agent may also read an inbox, update a record or send the reply. Those are different levels of authority, even when the screen looks similar.

The Australian Cyber Security Centre's small business cyber security handbook, published on 7 October 2026, asks owners to review the systems, accounts and data an agent can access before enabling it. It advises minimum access and human oversight for significant changes, communications and transactions. That is a useful starting point for an owner decision: which parts of this task can the agent prepare, and which parts may it actually carry out?

Write a permission card for one job

Take one workflow, such as sorting incoming enquiries. A page of answers is enough for an initial decision:

QuestionWhat to record
What is the job?The specific input, useful output and what is out of scope.
What may it read?Named folders, records or fields, and why each is needed.
What may it prepare?Drafts, labels or recommendations that a person will check.
What may it change or send?Every action in a live system, including edits, messages and transactions. Mark each as allowed, approval required or prohibited.
Who owns the result?A named person who checks work, handles exceptions and can revoke access.
What happens when it fails?Where the record of its action goes, how work returns to a person and how the business stops or reverses an action where possible.

This card is NAVE's editorial worksheet, not a government form or a claim that a single set of permissions suits every business. The National AI Centre's workflow guidance likewise recommends clear roles, checkpoints, escalation and a way to pause AI use. The amount of human checking depends on the consequence of a wrong action.

A hypothetical enquiry example

Imagine a small service business that wants help sorting enquiries. During a test, it uses fictional enquiries. The agent labels each message by topic and prepares a reply for a staff member. It does not connect to the live inbox, send messages, change customer records or promise a booking.

If that test is useful, the owner might then consider limited access to a dedicated enquiry mailbox. Before doing so, the owner would need to decide whether the information is necessary, what the provider does with it, which account grants access and who checks the output. A possible starting boundary is read only what the task needs; prepare a draft; have a person approve any external reply or consequential record change.

This is a hypothetical workflow, not a NAVE client example or a tested result. It makes one distinction visible: “draft the reply” and “send the reply” should be separate permissions. So should “suggest a CRM update” and “make the update.” If the product cannot separate those actions, the owner should not assume that a prompt telling it to wait provides the same control as a system permission or an enforced approval step.

Check the data path before connecting an account

Permissions inside the business are only part of the decision. Ask what information the provider receives, where it is processed or stored, whether the provider or another party can access inputs and outputs, what settings apply and how data can be removed. If the proposed workflow involves personal information, check the applicable privacy obligations for the business and the specific use.

The Office of the Australian Information Commissioner recommends due diligence on commercial AI products, including their data flows, access and human oversight. It advises against entering personal information, especially sensitive information, into publicly available generative AI tools as a matter of best practice. That guidance does not make every tool or every use unlawful; the decision depends on the facts, the product and the organisation's obligations. Get qualified privacy advice where the use is sensitive or the obligations are unclear.

Decide whether an agent earns its access

Before granting any live permission, compare three options for the same job:

  1. Fix the process. Could a clearer enquiry form, shared template or better handoff remove the friction?
  2. Use a fixed rule. Could an email filter or standard automation sort the predictable cases?
  3. Use a limited agent. Is there enough variation in the input to justify AI, with an owner able to review its work and handle exceptions?

The National AI Centre advises considering simpler rules-based automation and process changes where AI is a poor fit. A constrained agent may be useful when the variation matters and the benefit still exceeds the time needed to check and correct it. If the team cannot name the task, limit access or review the consequences, defer the connection. That is a practical decision, not a failed AI project.

If you are still deciding which job to test, start with NAVE's first-workflow guide. If an agent is already running, the post-launch checking guide covers correction records and pause rules. This article is the permission decision between those two steps.

Sources and limits

The permission card, hypothetical enquiry example and three-option decision are NAVE's editorial synthesis. They are general business guidance, not a vendor security assessment or legal advice. Permissions, technical controls and privacy obligations must be checked for the actual system and use.

A relevant next step

If you have one defined task and want to discuss a bounded build, NAVE's AI Agents offer explains how task scope, permissions, human review, testing and handover are agreed. A first conversation should establish whether a simpler process would serve you better.