Australian Government agencies now have much more specific guidance for agentic AI: systems that can plan tasks, use tools and take actions with limited human supervision.
The Digital Transformation Agency’s new Agentic AI addendum to the AI technical standard moves the conversation beyond broad principles. It sets practical expectations for accountability, permissions, memory, evaluation, monitoring and intervention across the full system lifecycle.
For software and delivery teams, the message is useful and blunt: an AI agent is not merely a smarter chatbot. Once it can open a pull request, query an internal system, update a ticket or trigger a deployment workflow, it becomes an operational actor that needs engineering controls.
What the New Addendum Changes
The addendum does not replace the existing AI technical standard or the Policy for the responsible use of AI in government. Agencies are expected to apply it alongside both. Its contribution is to address the extra risk created when AI can act across multiple steps and systems.
The standard requires agencies to:
- assign a human who remains accountable for agent decisions and outcomes;
- define human-in-the-loop or human-on-the-loop oversight, including intervention for irreversible or high-risk actions;
- give each agent a distinct role, identity and least-privilege access;
- govern memory, including what is stored, retention, audit, correction and deletion;
- test individual agents as well as their interactions with tools, memory and the operating environment;
- continuously monitor behaviour, permissions, cost, latency, errors and goal drift;
- provide fail-safes, escalation paths and operational kill switches.
That is a stronger and more useful model than asking whether a particular language model is “safe”. Reliability depends on the whole delivery system: identity, tools, data, workflow, approvals, tests, logs and operators.
What This Means Inside Software Delivery
Agentic AI is already moving into development workflows. A coding agent may read an issue, inspect a repository, change several files, run tests and create a pull request. A release agent may summarise changes, prepare deployment artefacts or coordinate routine environment checks.
These are good candidates for automation because their outputs can be reviewed and tested. They also illustrate why autonomy must be bounded.
A sensible software-delivery agent should have:
- A narrow goal: for example, prepare a tested pull request for one approved issue — not “improve the application”.
- A unique service identity: its actions should be distinguishable from those of a developer and attributable in audit logs.
- Repository-scoped permissions: read and branch-write access may be justified; direct production access usually is not.
- Deterministic verification: linting, type checks, tests, dependency scanning and policy checks should run before AI judgement is considered.
- A protected approval boundary: the agent can propose a merge or deployment, but cannot approve its own work or bypass branch protections.
- Complete action records: task, model and agent version, tool calls, changed files, test results, approvals and final outcome should be traceable.
- A safe failure mode: timeouts, unavailable tools, ambiguous requirements and failed tests should stop or escalate the workflow rather than encourage improvisation.
This is where the addendum connects directly with practical CI/CD design. The safest automation is not a free-roaming agent with broad credentials. It is a constrained participant inside an existing delivery pipeline.
Five Controls to Build Before Increasing Autonomy
1. Separate proposing from approving
An agent may create code, a change request or a deployment plan. Approval should come from a separate, authorised control. For higher-risk changes, preserve a human decision at the point where the action becomes difficult to reverse.
2. Enforce permissions outside the prompt
Instructions such as “never deploy to production” are useful context, but they are not an access control. Enforce the boundary through repository permissions, environment protection rules, short-lived credentials, network policy and tool allowlists.
3. Treat memory as governed data
Agent memory can contain task history, retrieved documents, user preferences and previous outputs. Define what may enter memory, where it is hosted, how long it is retained, who can inspect it and how stale or poisoned information is removed. Do not let convenient context become an unmanaged records system.
4. Evaluate actions, not only answers
A fluent response is not evidence that an agent chose the correct tool or supplied safe parameters. Tests should cover task completion, tool selection, parameter accuracy, access boundaries, recovery from failures and behaviour under malicious or unexpected input.
5. Make stopping ordinary
A kill switch should not be a document nobody has rehearsed. Operators need a practical way to pause new runs, revoke credentials, block a tool, quarantine output and preserve logs for investigation. The safer default is to stop cleanly and ask for review.
A Practical Pilot for a Government Delivery Team
The addendum does not mean every pilot needs a large new platform. It does mean the pilot should produce governance evidence, not only a demonstration.
- Choose one bounded use case. Good examples include test generation, dependency-update pull requests, documentation changes or first-pass accessibility checks.
- Map the workflow. Record every system, tool, data source, decision point, permission and human hand-off.
- Classify the actions. Separate read-only, reversible, approval-gated and prohibited actions. Implement those distinctions technically.
- Create an evaluation set. Use representative tasks, known edge cases, deliberately incomplete requirements and adversarial inputs. Define success before running the agent.
- Instrument the run. Capture tool calls, errors, retries, cost, latency, human interventions and the evidence supporting the final result.
- Exercise failure. Test an unavailable API, expired credential, poisoned document, failing test and attempted out-of-scope action.
- Review before scaling. Compare delivery time, accepted output, false positives, incidents and operator workload against the existing process.
A successful pilot may conclude that the agent should remain read-only, that one action can be automated, or that the process is not ready. That is valuable evidence. Autonomy is a design choice, not the measure of success.
Do You Need a “Control Tower”?
The DTA describes a control tower as a central governance layer for monitoring agent operations, risk, security, cost and compliance. The capability matters; the label and product choice matter less.
For an early pilot, existing delivery tooling may provide much of what is required:
- identity and access management for agent identities;
- Git history, protected branches and environment approvals;
- CI/CD logs and test artefacts;
- centralised application and security logging;
- cost, token and latency metrics;
- alerting, incident response and credential revocation.
As the number of agents, tools and cross-system workflows grows, a more central view becomes valuable. Build it around operational questions — what ran, who authorised it, what it accessed, what changed and how it can be stopped — rather than buying an “AI control tower” before the workflow exists.
Where GovCMS and Digital-Service Teams Can Start
For GovCMS, Drupal and broader government digital delivery, useful early applications are usually adjacent to production rather than inside it. Examples include:
- drafting tests for custom modules and integrations;
- checking pull requests against project-specific security and accessibility standards;
- analysing build failures and suggesting a documented remediation;
- preparing release notes and evidence packs from approved changes;
- identifying configuration drift without changing the environment;
- triaging content or support requests for human action.
Direct publication, personal-data access, destructive content changes and production deployments deserve stronger controls and, in many cases, explicit human approval. The degree of autonomy should follow the consequence of error.
This builds on our recent articles, Where AI Actually Pays Off in Software Development and AI Code Review That Knows Your Team’s Standards: use AI for bounded, verifiable work and place it inside engineering controls that already have authority.
Working with NAITEC Digital
NAITEC Digital helps government and business teams turn agentic-AI ideas into controlled software-delivery workflows. We can map a use case, design the permission and approval model, integrate agents with CI/CD, build evaluation and monitoring, and establish a clear path from pilot evidence to production operation.
We are a Newcastle, NSW software consultancy, a BuyICT registered supplier, and GovCMS/Drupal specialists on the Drupal Services Panel. Our capabilities span AI integration, automation and custom software delivery and government digital services, GovCMS and Drupal.
If your agency or delivery team is considering an AI agent, talk to NAITEC Digital before broad access and autonomy become the architecture by accident.
Frequently Asked Questions
What is the Australian Government Agentic AI addendum?
It is DTA best-practice guidance that supplements the Australian Government AI technical standard. It addresses the additional design, governance, data, evaluation, monitoring and decommissioning considerations for AI systems that can plan and act with a degree of autonomy.
Does the addendum ban autonomous AI agents?
No. It supports risk-based use with defined accountability, appropriate human oversight, least-privilege access, continuous evaluation, monitoring and mechanisms to intervene or stop the system.
Can an AI agent deploy software to production?
Technically it can, but that does not make unrestricted deployment sensible. Production actions should be controlled through deployment permissions, environment protections, auditable approvals and tested rollback procedures. High-risk or irreversible actions should have a clearly defined human intervention point.
What should an agency test in an AI agent?
Test more than answer quality. Evaluate task completion, tool choice, tool parameters, permissions, memory retrieval, unexpected and adversarial inputs, failure recovery, cost, latency, traceability and whether the agent stays inside its defined scope.
How should agent memory be governed?
Define what may be stored, the hosting location, retention period, access controls, audit records, correction and purge mechanisms, and protections against leakage, duplication, staleness and poisoning. Apply records, privacy and data-classification requirements to memory just as you would to other information stores.
Can NAITEC Digital help with an agentic-AI pilot?
Yes. NAITEC Digital can design a bounded pilot, integrate it with your development and delivery systems, implement approvals and guardrails, and build the evaluation evidence needed to decide whether it should scale. Contact us to discuss the workflow.