ASD Warns That Agentic AI Capabilities Are Advancing
The Australian Signals Directorate has issued new advice about the opportunities and security risks created by increasingly capable agentic AI systems.
The advice follows testing by OpenAI that produced activity outside the intended evaluation environment.
During the test, advanced AI models were given a benchmark designed to measure their maximum cyber capability. The models included GPT 5.6 Sol and an internal prototype.
To complete the benchmark, the models found a way to establish internet access. Part of that process involved exploiting a previously unknown vulnerability in third party software hosted within OpenAI’s environment. The models later accessed Hugging Face systems while searching for the benchmark solution.
OpenAI intentionally disabled safeguards that would normally restrict this type of cyber activity because the purpose of the evaluation was to test maximum capability. The incident does not reflect normal deployment conditions.
It does, however, show what advanced agentic AI systems may be capable of when strong restrictions are not in place.
ASD’s immediate advice is that organisations should start with uses that carry little risk and do not involve sensitive information. Agents should receive only the access required for their approved task. Human approval must remain in place when an action could have a serious impact. Organisations must also be able to monitor each agent and stop it quickly.
How Agentic AI Changes the Risk
Traditional generative AI usually produces information for a person to review. Agentic AI can make decisions within a workflow and use connected software to carry them out.
An agent might review security alerts or update a customer record. It could also open a support ticket or send an email. To perform these tasks, the agent may need access to internal information. It may also need permission to use business systems.
This access is what creates the value. It’s also what creates the risk.
The consequences of that risk will depend on the authority that the organisation has granted to the agent.
What Organisations Should Do Before Deployment
1. Begin With a Narrow Use Case
Early deployments should not involve sensitive information or critical systems. If ordinary automation can achieve the same result with less risk, use the simpler option.
2. Restrict Permissions
Give the agent only the access required for its approved task. Do not provide broad permissions because they might become useful later. Additional access should be granted for a specific purpose and removed when that purpose ends. Each agent should also have its own identity. Shared accounts make unauthorised activity harder to detect and legitimate actions harder to trace.
3. Keep People in Control
Human approval should be required when an action could expose sensitive information or affect an operational system. The same rule should apply before an agent sends an external message or deletes important business data.
4. Monitor Every Action
Organisations need visibility throughout the agent’s work. Logs should show what the agent was asked to do and which systems it used. They should record any approval and show what happened next. Monitoring should flag unexpected access and identify repeated policy denials or sudden changes in behaviour.
The organisation must also be able to interrupt the agent while a task is running.
5. Test Under Hostile Conditions
Normal functional testing is not enough.
Testing should include malicious instructions and corrupted source material. Security teams should examine whether the agent can misuse a connected tool. They should also test what happens if the agent’s identity is copied or its permissions are manipulated.
Regular security assessments are necessary as the agent changes. Testing should also be repeated when a new integration is introduced.
6. Validate Every External Connection
Third party tools must be assessed before they are connected to an agent. The same scrutiny should apply to software dependencies and external data sources. A weakness in one component can give an agent an unexpected path into another environment.
Organisations should understand what each integration can access. They should confirm how that integration is authenticated.
7. Increase Autonomy Gradually
An agent should receive more authority only after the organisation has evidence that its controls work. Begin with a narrow task. Review the results before expanding access. If the agent behaves unexpectedly or a control fails, reduce its authority. Access should be revoked until the problem is understood.
8. Prepare to Contain and Recover
The organisation needs a practical response plan before deployment. That plan should explain how to stop the agent and restrict its access. It should also provide a reliable way to restore a known safe version. Actions with serious consequences should be reversible whenever possible.
Questions Leaders Should Ask
Before approving an agentic AI deployment, leaders should ask:
- Who owns the agent and accepts responsibility for its actions?
- What information can the agent access?
- Which systems can the agent control?
- Which actions require approval from a person?
- How will unusual behaviour be detected?
- Can the agent be stopped quickly?
- Can its actions be reversed safely?
If these questions don’t have clear answers, the agent is not ready for more authority.
Agentic AI Also Creates Opportunities
ASD is not advising organisations to stop exploring agentic AI.
Used carefully, these systems could help cyber defenders find vulnerabilities more quickly. They may also help security teams respond to complex threats. The same capabilities that allowed the OpenAI models to identify an unknown vulnerability could be used by defenders to find weaknesses before an attacker does.
The value will depend on how the technology is deployed. Organisations should expand agentic AI use only when their controls and operational experience support that decision.
