Most data sovereignty controls were designed for systems that move data when a person tells them to. An agent does not work that way. You give it a goal, and it decides at runtime which documents to retrieve, which tools to call, which sub-model to route a subtask to, and what to write into memory. Each of those decisions is a potential disclosure, and none of them appear in the architecture diagram you approved at procurement.
That is the gap. Your data residency posture was assessed against a model endpoint. Your exposure is now the transitive closure of everything that endpoint can reach.
The perimeter is the tool list, not the model
When you run inference on Australian infrastructure, the sovereignty question has a clean answer: the weights, the prompt and the response stay in one jurisdiction. Agentic systems break that cleanliness in four specific places.
Tool calls. A tool is an outbound network call with your data in the request body. A calendar tool, a CRM lookup, a web search, a code interpreter that pulls a package from a foreign registry. The model may be onshore. The tool endpoint frequently is not.
Retrieval. Retrieval-augmented generation pulls documents into context. If the vector store, the embedding model or the reranker sits with a different provider from the inference layer, your source documents have crossed a boundary before the model ever sees them. Embeddings are derived from the source text, and they should be classified accordingly rather than treated as opaque numbers.
Model routing. Multi-model orchestration is now normal. A planner model decomposes a task and hands subtasks to specialist models, sometimes to a third-party API chosen at runtime on cost or capability grounds. A routing decision made in milliseconds is a cross-border disclosure decision.
Memory and traces. Agent frameworks persist a great deal: conversation memory, tool call arguments, intermediate reasoning, evaluation traces sent to an observability vendor. Trace pipelines are the least governed part of most agent stacks and they carry the most complete record of what the agent saw.
What Australian law actually asks of you here
APP 8 of the Privacy Act requires an APP entity to take steps that are reasonable in the circumstances to ensure an overseas recipient does not breach the Australian Privacy Principles in relation to personal information you disclose to them. Section 16C then makes you accountable: if the overseas recipient does something that would have breached the APPs had you done it, you are taken to have breached the APPs. The OAIC’s APP guidelines set this out in Chapter 8 on cross-border disclosure.
Two things follow for agent design. First, “the vendor’s terms say they do not train on our data” is not the control. The 2024 reforms sharpened the focus on accountability once personal information leaves Australia, and contractual assurance is not a proxy for compliance. Second, you cannot discharge a reasonable-steps obligation against a recipient list you cannot enumerate. If your agent can select a tool at runtime from a registry that changes weekly, you do not have a recipient list.
The OAIC’s October 2024 guidance on privacy and the use of commercially available AI products is the other document to read. It confirms that privacy obligations apply to AI inputs and outputs, and it asks deployers to take a privacy-by-design approach with a privacy impact assessment before deployment rather than after. For an agent, the input set is not the user’s prompt. It is everything the agent is permitted to retrieve.
On the security side, the ASD’s Australian Cyber Security Centre published Engaging with Artificial Intelligence in January 2024, co-sealed with international partners. It is aimed at organisations using AI systems rather than building them, and it directs you to apply that guidance alongside the Essential Eight. That framing is useful: an agent is a privileged user account, and you already know how to govern one of those.
The failure modes are documented
The OWASP GenAI Security Project published its Top 10 for Agentic Applications in December 2025, built from a threat taxonomy covering agent design, memory, planning and autonomy, tool use, and deployment. The first three entries are Agent Goal Hijack (ASI01), Tool Misuse (ASI02) and Identity and Privilege Abuse (ASI03).
Read those as sovereignty risks rather than only as security risks. Indirect prompt injection is the common mechanism: instructions hidden in a retrieved document, a web page, a ticket comment or a tool response, which the agent treats as context rather than as untrusted input. The agent then acts with its own legitimate credentials. Nothing is breached in the traditional sense. Data simply goes somewhere you did not authorise, using access you did authorise. That is the confused deputy problem, and it is difficult to detect precisely because every individual action is permitted.
The Model Context Protocol has made tool integration far more consistent. Its authorisation specification is built on OAuth 2.1, with PKCE, authorisation server metadata, protected resource metadata and resource indicators. That is a real improvement over bespoke integration code. But the specification standardises how tools are described and authorised; it does not enforce authorisation logic, input validation or runtime monitoring in your deployment. A tool description is text the model reads, which means the tool catalogue itself is an injection surface.
Controls that hold
Five that survive contact with a live agent.
Deny egress by default at the tool boundary. Run the agent runtime in a network segment with no general outbound access. Every tool endpoint is an explicit allowlist entry with a named owner and a recorded jurisdiction. If a tool cannot be added without a change record, your recipient list stays enumerable.
Give the agent its own identity, scoped down. Not the calling user’s token, and not a service account with standing broad privileges. Short-lived credentials, per-tool scopes, and no ability to mint new credentials. This is the control that limits blast radius when ASI01 succeeds.
Classify at the retrieval index, not at the prompt. Filter the corpus before it is indexed. A document that is not permitted in an agent workload should not be reachable by the retriever, regardless of what the user asks. Enforce residency labels on the index, the embedding model and the reranker as one unit.
Pin the model route. Disable automatic fallback to an offshore model on latency or capacity events. If a workload is classified for onshore inference only, a failed onshore call should return an error your application handles, not silently succeed against a foreign endpoint. Failover is where residency quietly breaks.
Keep the traces onshore and complete. Log tool name, arguments, destination, jurisdiction, model route and outcome for every step, held under Australian jurisdiction with the retention your regulator expects. If your evaluation or observability vendor processes traces offshore, that pipeline is itself a cross-border disclosure and needs the same assessment as the agent.
What to ask a platform before you deploy
Where does the control plane run, and who operates it. Which tools are available by default and can that list be locked. Whether agent identity is separable from user identity. Whether model routing can be pinned per workload class. Where traces, memory and evaluation data are stored and for how long. Whether the provider or its parent is subject to a foreign disclosure regime. For Commonwealth-adjacent work, whether the hosting provider holds certification under the Hosting Certification Framework, where Certified Strategic is the highest level of assurance and all sensitive government data, whole-of-government systems and systems rated PROTECTED must be hosted using certified services.
Amaze is ISO 27001 certified and operates as an Australian company, with data residency in Australia and no CLOUD Act exposure. For agent workloads the practical value of that is narrower and more useful than it sounds: it removes the jurisdiction question from the inference layer, so the remaining work is the tool boundary, the retrieval index and the trace pipeline. Those are engineering problems with known answers. They are only tractable once the layer underneath them is settled.
Related reading: Cloud governance for AI: guardrails for responsible use and Data sovereignty and AI in Australia.
Frequently asked questions
If the model runs in Australia, is the agent sovereign? No. The model endpoint is one component. The agent’s disclosure surface includes every tool endpoint it can call, the retrieval and embedding layer, any sub-model it routes to, and the trace and memory stores. Assess the whole set, not the inference layer alone.
Are embeddings personal information? Treat them as derived from the source text and classify them at the same level. Embeddings are generated from the content of the documents they represent, so a vector store built from records containing personal information should be governed as though it holds that information, including for residency purposes.
Does using the Model Context Protocol make tool calls safe? It makes them consistent. The specification defines authorisation on OAuth 2.1 with PKCE and resource indicators, which is a solid base. It does not enforce authorisation decisions, validate tool inputs or monitor runtime behaviour in your environment, and tool descriptions are model-readable text, so the catalogue is an injection surface you still have to control.
How do you handle a workload that genuinely needs an offshore frontier model? Make it an explicit, per-workload decision with the classification recorded, rather than a runtime fallback. Restrict which data classes may enter that path, complete the APP 8 reasonable-steps assessment for that recipient specifically, and make sure the route cannot be selected automatically for any other workload.
