As Australian businesses move from experimenting with chatbots to deploying autonomous “agents” that can act on their behalf, one question keeps surfacing in boardrooms and engineering stand-ups alike: how do you stop a system that can take actions from taking the wrong ones? Google’s latest guidance leans on an old idea from software engineering to answer it, checking data against a strict schema, but doing so continuously while the agent is running.
According to a report in IT Brief Australia, Google has outlined an approach in which the inputs and outputs of AI agents are validated against defined schemas at runtime, that is, at the moment an agent tries to call a tool, hand data to another system or return a result, rather than only being reviewed after the fact or during design. The pitch is straightforward: if an agent’s action doesn’t conform to the expected structure, it can be caught and blocked before it does any damage.
Why schema checks, and why now
Agentic AI is the current frontier of the generative boom. Where a large language model simply produces text, an agent chains reasoning together with the ability to call functions, query databases, send emails or trigger workflows. That autonomy is precisely what makes agents useful, and precisely what makes them risky. A model that hallucinates a fact in a chat window is an embarrassment; an agent that hallucinates a malformed API call, an incorrect parameter or an unexpected instruction can move money, delete records or leak data.
Schema validation is a well-worn technique in conventional software: you define the shape of the data you expect, the fields, the types, the permitted values, and reject anything that doesn’t fit. Applying it at runtime to AI agents is an attempt to bring that determinism to a fundamentally probabilistic system. Because a language model’s output can’t be guaranteed in advance, the argument runs, you need a hard, non-negotiable gate between what the model proposes and what actually executes. The schema becomes a contract the agent cannot talk its way around.
The approach also dovetails with a broader industry push toward standardised ways for agents to describe their capabilities and communicate with one another, including Google’s own Agent Development Kit and the emerging agent-to-agent interoperability efforts. In those frameworks, structured definitions of tools and their expected arguments are already central; runtime enforcement extends that structure from a description into an active safeguard.
Two ways to read it
Supporters see runtime schema checking as a pragmatic, engineering-first answer to a problem that has so far attracted a lot of hand-wringing and few concrete controls. Rather than relying on the model to behave, or on a second model to police the first, an approach that simply stacks probabilistic systems on top of one another, schema validation offers a deterministic checkpoint that behaves the same way every time. For regulated industries, that predictability is attractive: it produces an auditable, testable boundary that a compliance officer can actually reason about.
Sceptics counter that schema conformance is necessary but nowhere near sufficient. A tool call can be perfectly well-formed and still be catastrophic, transferring the right data type to the wrong recipient, or executing a valid instruction that a user was manipulated into approving. Schema checks validate structure, not intent or context. There is also the risk of a false sense of security: teams that bolt on runtime validation may conclude their agents are “safe” while leaving the harder problems of authorisation, data governance and prompt injection unaddressed. And every additional check adds latency and engineering overhead, which matters when agents are expected to feel responsive.
The honest reading is that runtime schema validation is one layer in what security professionals call defence in depth. It closes off a whole class of malformed and unexpected actions cheaply and reliably, which is worth having, but it is a floor, not a ceiling.
What it means for Australia
For Australian organisations, the timing is pointed. Agentic AI is being spruiked hard by the major cloud vendors to banks, insurers, government agencies and retailers, all of whom are under pressure to show productivity gains. At the same time, the local risk environment has rarely been sharper. The Optus and Medibank breaches reset public and regulatory expectations around data handling, and the reforms to the Privacy Act, including a statutory tort for serious invasions of privacy, raise the stakes for any system that touches personal information autonomously.
Australia’s AI policy settings reinforce the point. The federal government’s proposed guardrails for AI in high-risk settings, and the voluntary AI Safety Standard promoted by the Department of Industry, Science and Resources, both emphasise testability, human oversight and the ability to demonstrate that a system behaves within defined bounds. A runtime schema check is exactly the kind of concrete, evidenceable control that maps onto those expectations, the sort of thing an organisation can point to when a regulator or an auditor asks how it constrains an autonomous system. For a chief information security officer trying to say yes to an agentic pilot without betting the company on the model’s good behaviour, a deterministic gate is a useful thing to be able to show the board.
There is a competitive dimension too. Australian firms tend to be fast followers rather than first movers on enterprise AI, and much of the tooling they will adopt is being shaped now by vendors like Google. Whether schema enforcement becomes a default, built-in feature of agent platforms or an optional extra that teams must wire up themselves will materially affect how safely local deployments land. Smaller Australian software companies building on these frameworks will inherit whatever defaults the platform ships with.
What’s next
Expect runtime validation to become table stakes rather than a differentiator. As agent frameworks mature, structured contracts between agents, tools and each other are likely to be enforced by default, and the interesting work will move up the stack, to policy engines that reason about intent, authorisation layers that decide what an agent is actually allowed to do, and observability tooling that lets teams see and replay what their agents did and why. Standardisation efforts around how agents describe and verify themselves will be worth watching, because interoperability and safety are increasingly the same conversation.
For now, the message from Google is a reminder that some of the most durable answers to cutting-edge problems are old ones. Australian teams weighing an agentic deployment would do well to treat runtime schema checks as a baseline to insist on, while remembering that a well-formed action and a safe one are not the same thing.
Sources: IT Brief Australia.
