Generative AI entered mining as an assistant: search the document, summarise the event, draft the report. Agentic AI changes the risk equation because it can connect to tools, pursue goals and take actions.
That transition is no longer theoretical. Recent mining analysis describes agentic systems beginning to orchestrate preventive responses within defined safety parameters, including ventilation adjustments and vehicle rerouting. At the same time, the Australian Signals Directorate (ASD) has issued specific guidance for agentic AI in critical environments.
For mining leaders, the question is therefore not simply whether an AI system can act. It is:
What is it authorised to do, on whose authority, using which evidence, and what record remains after it acts?
When AI gains tools, the safety case changes
A conventional chatbot produces content for a person to consider. An agentic system can be given access to data, memory, software tools and execution privileges. ASD defines the “harness” as the software layer that connects a large language model to organisational data, tools and systems. Its September 2026 guidance recommends least-privilege access, controlled tool use, output validation, monitoring and human oversight of high-impact actions. Crucially, it says organisations should enforce controls through the harness and surrounding infrastructure, rather than rely only on model behaviour or prompt instructions (ASD: Agentic AI harnesses).
That distinction matters in a mine. An incorrect draft is serious, but it can still be caught in review. An agent that can alter a workflow, dispatch work, close an action, change a threshold or interact with operational technology creates a different exposure. The failure has moved from information quality to execution control.
Joint guidance from ASD and international cyber agencies recommends restricting initial agentic use to low-risk, well-defined tasks and avoiding broad or unrestricted access to sensitive data or critical systems (ASD: Careful adoption of agentic AI services). The practical implication is clear: autonomy should expand only when the control environment is ready, not merely when the model appears capable.
Establish four levels of authority
A useful starting point is to classify AI use by the authority granted to the system. This is not a universal risk taxonomy; it is a practical leadership tool.
1. Read and summarise
The system retrieves approved information, organises evidence or summarises records. It cannot change a source record or initiate an operational action.
Controls should focus on source quality, permissions, citation, confidentiality and review.
2. Draft and recommend
The system proposes a finding, action, bowtie, performance standard or investigation output. A competent person validates the evidence and owns the decision.
Controls should define the required source links, uncertainty handling, approval role and prohibited conclusions.
3. Transact within a workflow
The system may create a task, populate a controlled field, route an approval or update a record. Its write permissions are narrow, attributable and reversible.
Controls should include least privilege, approval gates, complete logging, segregation of duties, exception handling and rollback.
4. Influence or execute a safety-affecting action
The system may affect plant, dispatch, access, ventilation, isolation, maintenance priority or another operational condition.
This level requires an engineered safety case, explicit accountable ownership, verified operating limits, fail-safe behaviour, independent testing, change control, monitoring and a reliable stop mechanism. In many use cases, the defensible boundary will remain “recommend and escalate”, not “execute”.
The purpose of the model is not to make every workflow slow. It is to prevent a low-friction pilot from acquiring high-consequence authority by accident.
Human oversight must be an operating control
“Human in the loop” is meaningful only when the person has the competence, time, evidence and authority to challenge the system. A nominal approval click under production pressure is not an effective control.
Australia’s Voluntary AI Safety Standard calls for an accountable owner for each AI system, defined intervention requirements, measurable acceptance criteria, pre-deployment testing, continuous monitoring and auditable logs. It also makes an important procurement point: responsibility between the deployer and supplier should be agreed and documented (Department of Industry, Science and Resources: the 10 guardrails).
The NIST AI Risk Management Framework reinforces the same operating discipline: define the tasks the system supports, document the roles in human-AI configurations, establish oversight processes and test performance in conditions similar to deployment (NIST AI RMF Core).
Mining already has a strong analogy. The 2026 ICMM Critical Control Management guide assigns distinct roles across executives, operational leaders, control owners and support functions. It states that support functions provide guidance and oversight but do not replace operational ownership (ICMM Critical Control Management Good Practice Guide). AI governance should preserve that line of accountability.
Treat the authority boundary like a critical control
Before connecting an agent to a safety workflow, write a performance standard for its authority boundary. At minimum, define:
- the accountable owner and intended outcome
- permitted and prohibited actions
- approved data, tools and systems
- conditions that trigger human review
- evidence required before an action or recommendation
- the person authorised to approve, override or stop
- logs needed to reconstruct what happened
- failure, fallback and rollback behaviour
- acceptance tests and review frequency
- the change-control process for models, prompts, tools and permissions
Then verify the boundary. Test attempted actions outside scope. Confirm that read access cannot silently become write access. Exercise the stop and rollback paths. Review overrides, near misses, anomalous tool calls and cases where the agent lacked sufficient evidence.
This is the executive shift: assurance must cover not only whether the AI gives a good answer, but whether it remains inside its authorised role.
Recent mining analysis argues that AI can strengthen safety while emphasising sustained leadership alignment, frontline adoption, workforce capability and human monitoring as technologies scale (McKinsey: Harnessing AI to make mining safer). Those organisational conditions are not implementation detail. They are part of the control environment.
How MineGuard AI supports governed adoption
MineGuard AI’s published responsible-AI position is explicit: its systems do not make final safety, legal, engineering, medical, employment or operational decisions. Outputs must be reviewed, validated, edited, approved or rejected by authorised people (MineGuard AI: Responsible AI).
That principle is implemented in specific workflows. Incident AI structures evidence, supports timelines and draft outputs, and requires human approval before export (Incident AI). Critical Risk AI assists with bowties, controls and performance standards while keeping review and approval with the user (Critical Risk AI).
For organisations designing broader AI-enabled workflows, MineGuard AI Consulting provides verified service lines covering human decision boundaries, logging requirements, data rules, target operating models, workflow integration and rollout planning. Its published deliverables include governance playbooks, RACI models, assurance checklists and future-state workflow plans. MineGuard also publishes its trust architecture and Incident AI subprocessor register so buyers can assess data handling, deployment and third-party dependencies rather than rely on generic assurances.
The right next step is an authority-boundary review of every AI use case that can influence safety work. Identify what each system can read, recommend, write and execute; assign an accountable owner; define evidence and approval requirements; and test the stop conditions before extending autonomy.
Agentic AI may become a valuable part of mining operations. The organisations that benefit safely will be the ones that make authority explicit before capability outruns governance.
Key sources
- ASD, Agentic AI harnesses, September 2026
- ASD and international partners, Careful adoption of agentic AI services, May 2026
- Australian Government, Voluntary AI Safety Standard
- NIST, AI Risk Management Framework Core
- ICMM, Critical Control Management Good Practice Guide, 2026
- McKinsey, Harnessing AI to make mining safer, September 2026