Before connecting an AI assistant to the business, I would like to see the permissions screen.
The demonstration can wait a moment.
An assistant that summarises a document you give it has a fairly specific job. An agent that searches shared drives, reads email, updates customer records and sends messages has a much larger one. It can now act inside systems other people depend on.
What have you actually given it permission to do?
That question is a useful starting point for agentic AI security in Australia. The model's ability to produce a convincing answer tells you very little about whether it should have access to the accounts connected to it.
The Software Around the Model Matters
ASD's ACSC published its agentic AI harnesses guidance on 11 September 2026. A harness is the surrounding software that connects a model to tools, data, memory and workflows, and controls how proposed actions are executed.
ASD identifies this layer as an important place to enforce permissions, constrain tools, require human approval for sensitive actions and record activity. It also explains why prompt injection cannot reliably be addressed inside the model alone. External content can be mistaken for instructions; controls are needed around what the system can subsequently do.
The related May guidance on careful adoption recommends incremental deployment limited to low-risk tasks. The full publication is more explicit: low-risk, non-sensitive tasks, without broad or unrestricted access. An approval button is not a blanket endorsement for connecting sensitive systems.
My practical reading is to start by defining a small job and its boundaries. Buying a capable model does not do that work for you.
The headline's user-account comparison is shorthand. An agent might use an application identity, a service account or permissions delegated by a person. It may use several identities. The point is to give that access the same scrutiny you would give any other account with responsibility inside the business.
ASD's September system-access guidance expressly includes AI agents among non-human users covered by identification, authentication, authorisation and monitoring controls. It also calls for an agent register covering ownership, purpose, identities, credentials, tools, permissions and accessible repositories.
For a small business, that can begin as a short document. Somebody needs to know the agent exists.
Read the Permission, Then Compare It With the Job
Suppose an Australian business wants an assistant to draft replies to routine product enquiries. For an initial trial, I would give it approved product information and invented enquiries, with no connection to the live support platform.
That lets the business test whether the drafts are useful before deciding whether any live integration is justified. It also exposes a surprisingly ordinary problem: perhaps the product information is incomplete. Giving the assistant the entire shared drive will not necessarily improve it.
If an integration is later considered, separate the functions. Searching approved reference material, reading customer correspondence, changing a customer record and sending a reply are different permissions with different consequences. A useful draft does not establish a need for all four.
Microsoft's permissions documentation distinguishes delegated access, where an application acts on behalf of a user, from application access that operates without a signed-in user. Delegated access is bounded by both the application's permissions and what the user can access. An over-permissioned person can therefore still be a poor starting point.
For a Microsoft 365 connection, ask which mailboxes and files it can reach, whether it can write or send, and whether it continues operating without the person present. Check the actual grant and resource restrictions. The friendly name on the consent screen is not a description of the full access arrangement.
My article on stronger MFA covers protecting human sign-ins. Application permissions need their own review. Successfully authenticating the person who approved a connection does not tell you whether the connection was appropriately scoped.
Least privilege means giving the agent only the access required for the agreed task. If the product cannot support that boundary, reduce the task or choose a different implementation. Administrator access should not become the workaround for a disappointing settings menu.
A Draft and a Sent Message Are Different Events
I would draw the action boundaries before a trial starts, while there is still time to think about them.
For a coding assistant, a useful boundary might be an isolated repository containing demonstration code, with permission to propose changes. Production credentials and the ability to deploy the real website would stay outside it. For an accounting workflow, test categorisation against synthetic transactions before considering any access to live financial records.
These are examples of scoping a trial, rather than claims that a particular product supports every restriction. Verify the controls in the service you are actually using.
Where an approval is required, the person needs enough information to make a decision. For a proposed outbound message, that includes the recipient, full text and attachments. For a record change, it includes the existing value and proposed replacement. A button labelled "Continue" is not much help if the consequence is hidden.
The approval should apply to that specific action. Changing the recipient afterwards should require another decision. The connected service should also enforce its own access limits, so a mistaken model instruction cannot simply grant new authority.
An email or document containing hostile instructions does not automatically produce a compromise. The outcome depends on whether the agent follows them and what its tools, permissions and other controls allow. I would test those boundaries with harmless simulated instructions and test data before exposing a workflow to outside content.
Give the Connection an Owner and an Exit
For each trial, I would record the person responsible, the agreed data sources and the permitted actions. Include when the trial ends and who can stop it. An experiment should not quietly become a permanent background service because everybody forgot about it.
Use credentials intended for the integration, protected appropriately, with the narrowest practical scope. Where supported, prefer short-lived credentials over a permanent secret copied into a configuration file. Document revocation and test that it stops the relevant access; do not assume changing a human password ends every application session.
I would also run a small, recognisable test action and find its records. Can we identify the agent, the tool used, the target and the result? If someone approved it, can we connect that approval to the action? Assign someone to review unexpected behaviour, repeated failures or activity outside the agreed task.
Keep sensitive material out of test logs where possible, and protect the logs themselves. Duplicating private documents into a widely accessible activity dashboard would create another permissions problem.
When One Assistant Can See the Whole Household
A private technology setup can make broad integration particularly tempting. One assistant could potentially coordinate calendars, travel arrangements, property information and correspondence with advisers. Add cloud storage, household staff and smart-home services, and it starts connecting areas that previously had separate access arrangements.
Consider a travel-planning trial. Public destination information and a fictional itinerary may be enough to evaluate its usefulness. Private medical correspondence, banking documents and the ability to alter property access codes have no place in that trial.
Even apparently convenient combinations deserve thought. A calendar may reveal when a property is empty. Property systems may control who can enter it. An agent connecting both would concentrate information and authority that should be assessed together.
This is personal technology governance in plain English: decide who can connect services, what can be shared and who remains responsible. The mixed environment described in my secure home office guide is worth mapping before adding another integration across it.
Solway Web Consulting's Sydney private-client cybersecurity consulting can help establish account ownership and permissions before new services are connected. That groundwork also makes it easier for an assistant or adviser to explain why a proposed connection needs a closer look.
If I hired a new staff member, I would not give them administrator access to every system on day one. I would give them a defined job and the access needed to do it.
An AI agent deserves an equally specific job description. Bring that to the demonstration, along with the permissions screen.