An AI assistant becomes a different business risk when it can do more than draft an answer. If it can send email, update customer records, approve a purchase or change a booking, its mistakes and compromised access become real business actions.
That does not mean Australian SMEs should avoid AI agents. It means leadership should decide exactly what an agent is authorised to do before connecting it to sensitive data or critical systems.
The key question for AI agent security is simple: what can this agent read, change, send, approve, buy or delete, and how would you know if it crossed the line?
An AI agent is different from a chatbot
A chatbot usually produces content for a person to review. It might summarise a document, suggest a response or explain a spreadsheet. A person then decides what happens next.
An AI agent can connect to other tools and act. It may search a customer database, create a support ticket, send a message, change a record or start another automated process. Some agents can plan and complete several steps without asking a person at each stage.
The Australian Signals Directorate's guidance on agentic AI makes this distinction clear. Generative AI creates content for human use. Agentic AI integrates with software so it can reason, plan and take actions with less human intervention.
The business benefit is also the source of the risk. An agent can only save meaningful time when it has enough access to complete useful work. Every new permission also increases what could go wrong if the agent misunderstands a request, uses an unsafe tool or has its credentials compromised.
ASD highlighted this issue in August 2026 through a reported Australian booking-system example. According to ASD's summary of an ABC News report, an AI assistant made changes outside the user's intended request, including bypassing booking limits and removing another customer from a waiting list.
This was not described as a cyber attack or a malicious act. It was a useful warning about authority. The system could take an action, and the user had not clearly approved the path it chose.
Start with what the agent can actually do
Product demonstrations tend to focus on the outcome. Leadership needs to examine the permissions underneath it.
Before approving a pilot, list every system, data source and tool the agent can reach. Then separate its capabilities by action. Reading a calendar is different from changing it. Drafting an email is different from sending it. Preparing a payment is different from approving one.
| Agent capability | Possible business consequence | Evidence to request |
|---|---|---|
| Read customer or staff data | Privacy exposure or inappropriate use | Data sources, fields and access rules |
| Send email or messages | Incorrect commitments, disclosure or fraud | Approved recipients, sending limits and message logs |
| Change business records | Corrupted customer, financial or operational data | Allowed fields, change history and rollback process |
| Approve or purchase | Unauthorised financial commitment | Transaction limits and human approval rules |
| Delete information | Lost records or interrupted operations | Deletion restrictions, backups and restore test results |
| Connect another tool | Expanded access through an unreviewed component | Approved-tool list and connection audit trail |
This capability map turns a vague AI discussion into a business decision. It also exposes combinations that matter more than individual permissions. An agent that can read supplier invoices, send email and update bank details presents a more serious path than one that can perform only one of those tasks.
The same approach applies to employee-created experiments. An agent does not become low risk because it was connected with a free account or without a formal project. If it can reach business information or act through a staff member's account, it belongs in the inventory.
Give the agent its own identity and the minimum access
People sometimes connect an agent by giving it their own password, access token or broadly privileged service account. This may be quick, but it makes accountability difficult. A log can show that the account changed a record without showing whether the person or the agent performed the action.
The US National Institute of Standards and Technology describes this as an emerging identity problem. Its August 2026 guidance on AI-agent identity warns that shared credentials create accountability, privacy and legal gaps. It argues that agents should be treated as distinct identities with their own credentials and permissions.
Where the platform supports it, give each agent a separate identity. Link that identity to a named business owner, an approved purpose and a defined review date. Do not allow several agents to share one identity if the business needs to distinguish their actions.
Then apply least privilege. This means giving the agent only the access required for its approved task.
For example, an agent that drafts replies to customer enquiries may need to read a limited set of support records and create a draft. It may not need permission to send messages, export the customer database, issue refunds or change account ownership.
Minimum access should cover more than application roles. Consider:
- which customers, folders, mailboxes or projects the agent can access
- whether it can read, create, change or delete information
- which tools and external services it can call
- how much money, data or work it can affect in one action
- when its access expires or must be reviewed
- whether it can create another agent or request more access
Review the access again when the agent's purpose, model, tools or data sources change. Approval for a small pilot should not silently become approval for a wider production role.
Put meaningful approval points around consequential actions
Human approval is useful when it sits immediately before an action that matters. It is much less useful when a person receives so many vague prompts that approving them becomes automatic.
Decide which actions always need a person to approve them. Common examples include:
- sending a message to a customer, regulator or large distribution list
- changing payment details or approving a financial transaction
- granting, removing or increasing access
- deleting business records
- publishing content in the company's name
- moving sensitive information to another system
- accepting a contract or making a binding commitment
The approval screen should show what will happen, which system and records are affected, and whether the action can be reversed. A button labelled "continue" is not meaningful approval if the consequence is hidden.
Do not rely on a written instruction inside the AI prompt as the only control. Restrictions should also exist in the connected system where practical. An agent told not to approve payments should not hold payment-approval permission in the first place.
For lower-risk actions, use practical limits. Restrict recipients, values, record types, working hours or the number of changes allowed in one run. Start with a narrow pilot and increase autonomy only after the business has reviewed actual behaviour and exceptions.
This is consistent with ASD's recommendation for progressive deployment, constrained objectives and human control points. The guidance is not a universal legal rule for SMEs, but it provides a sound benchmark for a leadership decision.
Keep evidence and a reliable stop process
An agent's activity should be visible enough to answer three questions:
- What did it do?
- Why was it allowed to do that?
- Who noticed and acted when something unexpected happened?
Keep logs of important actions, approvals, permission changes, failed requests and connections to other tools. Logs need a named owner and a review process. Collecting them without checking meaningful exceptions provides little assurance.
Define a stop process before deployment. Your IT team or provider should be able to disable the agent, revoke its credentials and block its connected tools without relying on the agent itself. Test that process. A procedure that has never been tried is still an assumption.
Recovery matters too. If the agent can change or delete records, confirm that the business can identify the affected information and restore it to a known good state. That may require application history, versioning, backups or a reconciliation process. The right method depends on the system and the consequence.
This is the same evidence-led principle used for employee and application access during offboarding. Knowing that access should stop is different from proving that it did.
Vendor responsibility also needs to be clear. If a provider hosts the agent or supplies connected tools, ask who controls identities, stores activity logs, investigates unexpected behaviour and notifies your business about a security issue. These questions complement a broader review of supplier Cyber Security risk.
Questions to answer before approving an AI agent
Leadership does not need to design the technology. It should require clear answers and evidence from the people proposing it.
Ask:
- What business task has been approved, and why does it require an agent rather than simpler automation?
- Which systems, tools and data can the agent access?
- What can it read, create, change, send, approve, purchase or delete?
- Does it have its own identity, or is it acting through a person's account?
- Are its permissions limited to the smallest useful scope?
- Which actions require meaningful human approval?
- Can restrictions be enforced by the connected systems, not only by instructions to the model?
- What third-party tools or data sources can influence its actions?
- Which actions and approval decisions are logged, and who reviews exceptions?
- How will the business disable access, contain a problem and recover unwanted changes?
- What must be retested when the model, tools, permissions or process changes?
- Who owns the business risk and decides whether to expand the agent's autonomy?
An unclear answer does not always mean the project should stop. It may mean the pilot needs less access, a smaller task or better evidence before it proceeds.
The decision is about authority, not enthusiasm for AI
An AI agent should not inherit trust simply because the product is useful or the pilot is exciting. Its authority should match the business value of the task and the consequence if something goes wrong.
Start with a low-risk use case. Give the agent a distinct identity and narrow permissions. Put deliberate approval around consequential actions. Keep evidence, test the stop process and prove that unwanted changes can be recovered.
If an agent can reach sensitive data or critical workflows and its access is difficult to explain, a Breach Prevention Assessment can map that path alongside the wider identity, cloud and supplier risks facing the business.