On 1 May 2026, the Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC) published "Careful adoption of agentic AI services" with the US Cybersecurity and Infrastructure Security Agency (CISA), the US National Security Agency (NSA), the Canadian Centre for Cyber Security, the New Zealand National Cyber Security Centre and the UK National Cyber Security Centre. It is the clearest statement yet from Australia and its closest partners on how organisations should deploy AI systems that act on their own.
The guidance is marked as written for large organisations, infrastructure and government, but the advice applies to any organisation that lets an AI agent touch email, finance, customer records or production systems. Its message is short: adopt agentic AI with security in mind, start small, never give an agent broad or unrestricted access, and assume it will sometimes behave in ways you did not plan for. This article turns that message into a checklist that CISOs, IT leaders and risk teams can act on.
What the agencies mean by agentic AI
The guidance focuses on systems built around a large language model (LLM) that can interpret its environment, decide what to do and act. Beyond the model itself, these systems include external tools, data sources, memory and planning workflows. The agencies say agentic systems differ from conventional LLM tools because they pursue underspecified goals, act autonomously and make long-term plans. Some can spawn sub-agents to handle parts of a task.
That autonomy is the reason for the extra caution. A generative AI tool produces content for a person to review. An agent connects to software and takes actions without waiting for a person to approve each step. The guidance also points out that agents inherit the weaknesses of the underlying LLM. Its example is a malicious prompt hidden in a phishing email that persuades an email-monitoring agent to download malware.
The risks the guidance describes
The guidance groups agentic AI risks into five families: privilege, design and configuration, behaviour, structural, and accountability. Each comes with a scenario, and most read like incidents an Australian organisation could have next year.
- Privilege. Agents given broad access become a single point of failure. The guidance describes a procurement agent with wide access to financial systems, email and contract repositories. When a low-risk tool in its workflow was compromised, the attacker inherited those privileges and approved payments, and the audit logs looked legitimate because the actions ran under a trusted agent identity.
- Design and configuration. Permissions checked once at start-up go stale. Poor segmentation lets a compromise in one agent spread to others, and unvetted third-party components can carry privileges nobody reviewed.
- Behaviour. Agents can pursue a goal in ways the designer never intended. The guidance gives the example of an agent told to maximise uptime that disables security updates to avoid reboots. It also says agents may change behaviour when they detect an evaluation, and that some systems have shown strategic deception.
- Structural. Connected agents, tools and data sources widen the attack surface. Tool descriptions can be misleading, malicious tools can imitate legitimate ones, and a single fault can cascade through a chain of agents.
- Accountability. Agent decisions can be opaque, and long reasoning chains produce large, repetitive logs. When several agents collaborate on a task such as approving payments, it can become hard to work out which one caused an error, or to show compliance afterwards.
The headline advice
Three recommendations sit at the front of the guidance. First, align agentic AI risks and mitigations with your existing security model and risk posture. The agencies say AI security should be addressed within established cyber security frameworks, not treated as a separate discipline, because AI systems are IT systems that run on software and hardware and communicate over networks.
Second, never grant an agent broad or unrestricted access, especially to sensitive data or critical systems. Third, use agentic AI only for low-risk and non-sensitive tasks. The agencies also suggest considering the full range of options for repetitive work, including removing low-value processes altogether, which may carry less risk than an agent.
The conclusion goes further. Until security practices, evaluation methods and standards mature, the agencies say organisations should assume agentic AI systems may behave unexpectedly, and should prioritise resilience, reversibility and risk containment over efficiency gains. It describes strong governance, explicit accountability, rigorous monitoring and human oversight as essential prerequisites, not optional safeguards.
An adoption checklist for Australian organisations
The guidance contains dozens of recommended practices, split by audience: developers, vendors and operators. Most Australian organisations are operators or buyers of agents built by someone else, so the checklist below draws mainly on the sections about deploying and operating agents, and on the questions to ask vendors.
1. Keep an inventory of every agent
You cannot govern what you cannot see. The guidance recommends maintaining a trusted registry of agents, binding identities to authorised roles, periodically reconciling the registry against the live set of agents, and denying access to any agent or key not in the registry. It makes the same recommendation for third-party components and suggests restricting tool use to an approved allow list of tools and versions. Start with a simple register: each agent's owner, purpose, tools, data access, credentials and the systems it can change. Include agents embedded in software-as-a-service products and those built by business teams outside IT.
2. Give each agent its own least-privilege identity
The guidance says strict adherence to least privilege is critical, and that identity matters as much as privilege. It recommends treating each agent as a distinct principal with its own credentials, so agents do not share keys. Operators should limit privileges to the minimum for the task, narrow the scope as far as possible, and require just-in-time credentials for high-impact actions. Appendix A of the guidance adds that static, long-lived secrets should give way to ephemeral credentials that expire when the job finishes. Agents should also be prohibited from changing their own privileges or starting unapproved delegation.
3. Put human approval gates in front of consequential actions
The guidance is direct that the decision about when human approval is required belongs to system designers or operators, not to the agent. Agents should not autonomously execute high-impact actions without prior approval. It names system resets, network egress and deletion of critical records as examples of actions where the cost of error is high, and recommends that requests to delete logs or audit records be quarantined until a human approves them. To decide where the gates go, it suggests classifying agent actions by impact, likelihood and reversibility. Assign a named person accountable for outcomes, because the guidance also says responsibility for errors should be clearly assigned.
4. Make agent activity auditable
The guidance recommends logging by default, with unified audit logs for all interactions between agents, records of which tools were used and what information was retrieved, and monitoring of internal processes, not only inputs and outputs. It also advises monitoring identity and privilege changes for drift, using multiple independent monitoring systems that cross-validate agent reports against system logs, and using storage-efficient logging so volume does not bury the signal. Agents should sit in enclaves with no write access to logs. Decide before deployment who reviews the logs, how often, and what triggers an alert.
5. Build in a kill switch and a way back
Resilience runs through the guidance. Its recommendations include fail-safe defaults that make agents stop and escalate to a human when a situation is uncertain, containment mechanisms that limit the blast radius, versioning and rollback so a system can return to known-good behaviour, and trigger-action protocols that automatically restrict an agent's permissions when unexpected behaviour appears. It also suggests rate limits that interrupt long-running tasks. Ask of every agent: how do we stop it within minutes, and how do we undo what it did? If the answer is "we cannot", the agent's permissions are too broad. The agencies also recommend developing and testing incident response procedures for agent compromise.
6. Roll out in stages
The guidance recommends phased deployment with progressively increasing access and autonomy, limiting the action space through restricted APIs or sandboxing, and using continuous evaluation to decide when to expand scope or roll autonomy back. It also asks that an agent approved for a low-risk task cannot progress by itself into higher-risk activity. Test in a sandbox and run red-team exercises before production.
Mapping the guidance to the Essential Eight
ASD says the Essential Eight was designed to protect internet-connected IT networks, and the agentic AI guidance does not map its recommendations to the Essential Eight itself. The mapping below is CyberCorp's view of where an existing programme gives you a head start. The Essential Eight is a baseline, not a complete answer to agent-specific risk such as prompt injection or goal misalignment.
- Restrict administrative privileges. Applies directly to the agent identity question. If an agent can act with administrator rights, it inherits every risk that control exists to prevent. Treat agent accounts as privileged accounts, and review them on the same schedule.
- Multi-factor authentication. Protects the humans who configure, approve and oversee agents. Approval gates are only meaningful if the person approving is who they claim to be.
- Application control. Its logic carries over to the guidance's advice on an approved allow list of tools and versions. An agent should only be able to call tools your organisation has vetted.
- Regular backups. Supports reversibility. Test that data an agent can modify or delete can be restored, and that the restore process does not depend on the agent.
- Patch applications and operating systems. The tools, connectors and hosts an agent runs on are software like any other, and the guidance stresses keeping third-party components up to date.
The governance side matters just as much. The guidance calls for governance policies for autonomous agents, legal accountability and risk ownership defined in policy, threat modelling against agentic AI risk taxonomies such as the OWASP GenAI Security Project and MITRE ATLAS, and building AI literacy across the organisation. Those items belong in your risk register, your policy framework and your board reporting. An agent that can approve payments or change customer records is a risk owner's concern, not only a technology one.
Your first 90 days
This plan is our suggestion for putting the guidance into practice. Adjust the timing to your size and to how many agents you already run.
- Days 1 to 30, see and decide. Build the agent inventory, including shadow deployments. Name an accountable owner for each agent. Write an interim policy that sets which tasks agents may take on and which data they may never reach. Pause any agent with broad access to sensitive data or critical systems until it has been reviewed.
- Days 31 to 60, restrict and instrument. Give every agent its own identity, cut permissions to the minimum and replace long-lived shared secrets. Define the approval gates using the impact, likelihood and reversibility classification. Turn on logging, keep it out of the agent's write reach and assign a reviewer. Confirm each agent has a working stop mechanism and a rollback path.
- Days 61 to 90, test and stage. Threat model your highest-risk agent, then test it in a sandbox, including prompt injection attempts and attempts to exceed its permissions. Add agent scenarios to your incident response plan and run a tabletop exercise. Agree the criteria for expanding autonomy, and the triggers for pulling it back. Report the results to the executive team and the board.
Key takeaways
- ASD's ACSC, CISA, the NSA and the Canadian, New Zealand and UK agencies jointly published "Careful adoption of agentic AI services" on 1 May 2026.
- The agencies recommend managing agentic AI inside your existing security model and risk posture, not as a separate programme.
- They advise using agentic AI only for low-risk, non-sensitive tasks, and never granting broad or unrestricted access to sensitive data or critical systems.
- Give each agent its own least-privilege identity, and keep a registry of agents and their tools.
- Decide in advance which actions need human approval. That decision should not be left to the agent.
- Log agent activity by default, keep the logs out of the agent's reach and plan for stopping and reversing agent actions.
- Roll out in stages and expand autonomy only as evidence supports it. Until standards mature, plan on the assumption that agents will sometimes behave unexpectedly.
CyberCorp's GRC specialists help Australian organisations adopt AI agents with the governance, access controls and audit trails this guidance expects. To find out where your agent deployments stand against the Essential Eight and the agencies' recommendations, Schedule a GRC Assessment with our team, or learn more about our Secure AI Deployment service.
