What an AI agent should be allowed to do.

An AI agent is software that reads, decides and then does something: updates a record, sends a message, books a shift, raises an invoice. The doing is what separates it from a chatbot, and it is also where the risk sits. An agent can only do what its access lets it do, so the most important design decision in an agent project is often not the model. It is the list of things the agent is allowed to touch.

This piece sets out how to decide that list, where a person should approve the agent's work, what the audit trail needs to hold, which Australian rules shape the answer, and what to ask an AI consulting firm about permissions before an agent goes live.

Why an agent needs its own permissions.

The quickest way to get an agent working is to give it an existing login: a staff member's account, or a shared service account that already reaches every system. It works on day one, and it means the agent can do anything that account can do, including things nobody intended it to do.

Two things make that more serious for an agent than for a person. First, an agent follows instructions it finds in the text it reads. An email, a form or a document can contain wording that steers it, which is known as prompt injection, and an agent with broad access turns a strange sentence into a real action. Second, an agent works fast and does not get tired, so a mistake made once can be repeated hundreds of times before anyone notices. The OWASP list of risks for large language model applications names the underlying problem "excessive agency": an agent given more access, more functions or more autonomy than its job needs.

The answer is the same principle security teams already apply to people: least privilege. The agent gets its own identity, and that identity gets the smallest set of permissions that lets it do the one job it was built for.

Four levels of access.

It helps to place every action an agent might take on one of four levels, and to agree the level for each action before the build starts rather than after the first incident.

• Read only. The agent can look up records and answer questions, but changes nothing. Most first agents should start here, and many useful ones never leave.
• Draft for approval. The agent prepares the change, the email or the entry, and a person approves it before it takes effect. This is where most agents that touch customers, clients or money should sit.
• Act within limits. The agent can act on its own inside hard limits set in the system, not in the prompt: a dollar ceiling, a fixed list of record types, a daily volume cap. Anything outside the limits goes back to a person.
• Act alone. The agent acts without review. Reserve this for actions that are low impact, easy to reverse and well tested, such as tagging, filing or routing work to the right queue.

One agent will usually hold different levels for different actions. It might read the whole client file, draft a reply for approval and file the correspondence on its own. That is the point of setting levels per action rather than per agent. Our piece on where AI agents do not work yet covers the jobs that should stay with people altogether.

Where the human approval belongs.

An approval step only protects you if the person approving can actually judge what they are approving. Put the approval on the actions that matter most, and design it so it is not a rubber stamp.

• Put it where the action is hard to undo. Payments, messages that leave the organisation, changes to someone's record and anything that closes a case.
• Put it where the decision affects a person. Eligibility, pricing, rostering and anything that changes what a client, patient or participant receives.
• Show the reviewer what the agent saw. The source records and the reason for the suggestion, next to the suggestion itself, so the check takes a minute and not a re-investigation.
• Watch the approval rate. If reviewers approve every item without change for months, either the agent has earned a higher level for that action or the review has stopped being a real check. Both are worth knowing.

A person in the loop does not remove your obligations. Our piece on AI agents and the 10 December privacy rule explains why an automated decision with a human sign-off can still need to be disclosed.

The audit trail you will be asked for.

Sooner or later someone will ask why the agent did something: a client, an auditor, a regulator or your own board. The answer has to come from records written at the time, not from re-running the agent and hoping it does the same thing twice. For each action, keep:

• the request or event that triggered it;
• the records and documents the agent retrieved;
• what the agent proposed and what it actually did;
• who approved it, if anyone, and when;
• which model and which version of the instructions were in use.

Store the trail where the agent cannot edit it, keep it for as long as the records it relates to, and treat it as the sensitive data it is, because it will contain the same personal information the agent handled.

Australian rules that shape the design.

No Australian law sets out agent permissions as such, but several existing obligations land on them directly.

• The Privacy Act. Australian Privacy Principle 11 requires reasonable steps to protect personal information from misuse and unauthorised access. An agent with access to more personal information than its job needs is hard to call a reasonable step.
• The Notifiable Data Breaches scheme. If an agent discloses personal information to the wrong person and serious harm is likely, that can be an eligible data breach, with the same assessment and notification duties as any other.
• The Essential Eight. The Australian Signals Directorate's baseline includes restricting administrative privileges. An agent running on an administrator account cuts straight across it.
• CPS 234 for APRA-regulated entities. Banks, insurers and super funds must keep information security controls in line with the threats they face, and an agent is a new identity with access to information assets.

What this looks like in a care provider.

Take an agent that drafts shift notes for an NDIS or home care provider. It reads the roster and the participant's support plan, so it needs read access to those records for the people on that worker's shifts, not for every participant. It drafts the note for the support worker to check and submit. It never writes to the incident register on its own: if its draft mentions something that could be a reportable incident, it flags it to a person, because notifying the NDIS Quality and Safeguards Commission within the required timeframe is a judgement and a duty that stays with the provider. Our piece on AI consulting for NDIS and home care providers covers how that kind of engagement is set up.

What to ask an AI consulting firm.

• Will the agent have its own identity, or run on a person's or a shared account?
• Which actions sit at which of the four levels, and is that written into the design?
• Are the limits enforced by the systems the agent connects to, or only by its instructions?
• What does a reviewer see when approving the agent's work?
• What does the audit trail hold, where is it kept, and who can change it?
• How do we switch the agent off, and how long does that take?
• Who reviews the permissions after go-live, and how often?

A firm that answers these clearly has built agents that run in production. If the answers are vague, our guide to which kind of AI consulting firm you need may help you find one that fits.

Why RUBIX.

RUBIX is an independent, Australian-owned data and AI consultancy, founded in Melbourne in 2011. For 15 years our work has been the data underneath AI: platforms, governance and reporting, and more recently the agents that run on top of them. We have delivered more than 450 projects for over 115 organisations. Permissions are a data question before they are an AI question, and that is where we start.

• Access designed into the foundation. For a leading NDIS provider we joined six disconnected systems into one governed data foundation with security set from support worker to director. That role-based model is what an agent's permissions are built on. Read the NDIS provider case study.
• Senior people, embedded. Our forward deployed engineers work inside your team, so the people who agree the permission levels are the people who build them.
• Governance as part of the build. Our AI and data governance work sets the access rules and the audit trail alongside the agent, not after it.

If you are planning an AI agent, agree what it is allowed to do before you agree what it will cost. The permission list is the clearest picture you will get of the job it is actually being given.

Frequently asked questions.

General information only, not legal, financial or regulatory advice. Current as at November 2026.