How do you get value from AI that you can defend?

Why is it so hard to find out what good looks like?

The reference model arrived before the mandate last time. This time it has not.

You have an AI assistant switched on across your tenancy and two or three agent pilots running that you did not commission. People tell you the tools are useful. What you cannot say, if anyone asks you directly, is whether the answers coming out of them are ones the organisation could act on and defend under scrutiny.

The move to cloud was methodical, and in hindsight that is easy to undervalue. Organisations had a shared vocabulary, published reference architectures, landing zone patterns they could adapt, an established assessment pathway for sensitive workloads, and enough comparable case studies that a technology leader could point at another organisation of similar shape and say that we will do that, adjusted for our constraints. The industry converged before most organisations had to commit.

AI has not offered that interval. The technology has re-baselined repeatedly inside eighteen months, so the reference material is either not written yet or is out of date by the time it is published. That has a practical consequence for the reader. The workforce cannot make informed decisions at the speed the decisions are being demanded, not because the people are behind, but because the evidence base they would normally draw on does not exist in a settled form.

That is starting to change, and it is worth knowing where. In June 2026 the Digital Transformation Agency published an Agentic AI addendum to the Australian Government's AI technical standard. It describes agents grounding their reasoning in enterprise knowledge stores through governed retrieval and governed memory, using approved tools through standard interfaces, with each action executed in a controlled environment under least privilege, and all tasks observable, auditable and able to be rolled back. It puts security and governance underneath the whole arrangement rather than beside it.

That is the closest thing Australia currently has to a public statement of what good looks like, and it is three months old. It is written for Commonwealth agencies, so for a superannuation fund or a university it is guidance rather than obligation, and it is useful to them anyway. It also leaves open the two questions this article is about. It does not tell you which sources an agent may treat as authoritative for a given question, and it does not tell you how to know that the tools an agent used at run time were the ones that were approved.

So the honest position is not that nobody has worked this out. It is that the working out is happening now, in public, and the organisations that do well will be the ones that decide what they need from AI clearly enough to specify it, rather than waiting for a pattern to arrive.

What does AI have to deliver before it counts as value?

An answer nobody can act on is worth nothing. An answer nobody can defend costs you something.

An AI deployment produces value when someone changes what they do because of what it told them, and the organisation is comfortable with that having happened. Both halves matter. An answer nobody acts on has produced nothing but a licence cost. An answer that gets acted on and later cannot be defended under scrutiny costs more than it delivered, because the work has to be unwound and the tool loses the trust that made it useful.

That second failure is the one worth understanding, because it does not look like a failure while it is happening. One of us ran a leading vendor's AI assistant across a tenant to see what it would do in practice. Every control behaved exactly as designed. Authentication held. Transport was encrypted. The tenancy boundary held. Nothing was reachable that a user was not already permitted to open. On the security controls, the vendor did its job, and the tool was genuinely useful. It also produced misleading information and presented it as settled fact, because the tenant it was reading was a mess. The agent referenced draft documentation and working data sitting in the environment, and where the answer was not there at all, it produced one anyway.

Nothing in that stack was evaluating whether a document was a legitimate basis for the answer being given. A draft, a set of working notes and a signed policy all carry the same permission, so at the moment of retrieval they carry the same weight. Status and authority are not permission concepts. No control in a standard deployment assesses them, or assesses them against the context of the request, which matters because the same document can be a reasonable source for one question and actively misleading for another.

This is the specific shape of the gap, and it is different from the identity problem. Identity answers whether this person, through this agent, was allowed to reach this document. It says nothing about whether the document should be shaping this answer.

ServiceNow's Enterprise AI Maturity Index, published on 30 July 2026, found that Australian organisations more than doubled their AI spend year on year, up 115 per cent, while only 23 per cent have AI testing or auditing processes in place and 17 per cent have a system to track governance and compliance. After data accuracy, the challenge Australian executives named most often was the lack of transparency and the potential for misinformation from AI, at 62 per cent. Confidence has moved faster than evidence.

There is a further reason retrieval matters. The channel an agent uses to pull in a document is the same channel an attacker would use to reach it. In June 2025, researchers at Aim Security disclosed a vulnerability in Microsoft 365 Copilot, tracked as CVE-2025-32711 and named EchoLeak, in which a single crafted email with no user interaction could cause the assistant to reach internal files and send their contents to an attacker-controlled address. Microsoft patched it server-side and reported no exploitation in the wild. The instruction arrived through the same retrieval path the product uses legitimately, which is the point. Whatever your platform is permitted to hand a model is also what an outsider can attempt to influence. Deciding what may be retrieved is not a quality control that also helps security. It is the same control, doing both jobs.

What is the AI value chain, and where does it break?

Seven links, and value only survives if each one holds.

The tenant in that story did not fail at one point. It failed at several, and none of them announced themselves. The corpus was never defined, so anything readable was fair game. Retrieval had no basis for preferring a signed policy over a draft. The answer came back with no indication of where it came from. Each of those is a separate failure, and any one of them alone would have been enough to make the output unusable.

That is the useful way to think about an AI deployment. Value does not arrive in one step. It travels a path from the decision you want supported through to the result someone acts on, and it only survives if every part of that path holds. A weak link does not slow the chain down. It produces a confident answer that nobody should rely on, which is worse, because there is nothing to notice.

If value is the objective, then, it is worth being explicit about the path it travels, because each stage sets a condition on the one before it. The seven links of the value chain:

1. The use case: the decision or task the organisation wants supported, named specifically enough that someone owns the outcome.

2. The corpus: the set of sources the model is permitted to draw on for that use case, defined by authority and currency rather than by whatever the requester happens to be able to open.

3. Retrieval: what is actually pulled at the moment of the request, and on what basis it was selected.

4. Thinking: what the model infers from what it was given.

5. Reasoning: what the agent decides to do with that, including which tools it calls.

6. Action: what happens as a result, whether that is text returned to a person, a record updated, or a step taken in a workflow.

7. Outcome: the business result, and the record that allows someone to explain it later.

Two capabilities determine whether that chain holds, and they are two halves of the same problem. The data serving layer decides what the model may be handed. The orchestration layer decides, and records, what was then done with it. Neither is sufficient on its own. A perfect serving contract with no orchestration record tells you what the model could have used and nothing about what it did. A complete orchestration record over an ungoverned corpus tells you precisely how you arrived at an answer that was never sound.

The break points show up as business failures rather than as incidents. A draft is treated as policy and a decision is made on it. An agent takes a step nobody agreed it should take, using a tool that was added to its surface after the approval was given. An answer is acted on and, when someone asks where it came from, nobody can reconstruct the path. In each case the security controls did their job and the value still did not survive the chain.

What has to be true of your data before AI can produce value from it?

The serving contract is a set of business decisions, not a platform configuration.

Our companion article on core data platforms argued that a platform is designed from the consumption layer backwards, and that the serving layer should hand each named consumer four things: the classification of the data, its provenance, the purpose it may be used for, and its currency at the moment it is served. That holds. What an AI consumer adds is a fifth and a sixth, and they are the ones the AI assistant experience above exposed.

Authority: which source is the one that governs, for this kind of question. Somebody has to have decided that the policy register is authoritative for policy questions and that the shared drive is not, and that decision has to be recorded somewhere the platform can act on.

Status: whether an item is a draft, superseded, or current. This is metadata almost every organisation already holds somewhere and almost nobody enforces at retrieval.

The important thing about both is that they are business decisions, not technical ones. No architect can decide which source is authoritative for eligibility questions. The person accountable for eligibility decides that, and the platform enforces it. In our experience this is where the work stalls, because the answer is frequently that nobody has written it down, and writing it down means someone has to own it.

There is a practical shortcut worth taking. Rather than classifying the whole estate, start from a named use case and define the corpus for that use case alone. What may this agent read to answer this kind of question, on whose authority, and what is explicitly out of scope. That is a scoped decision a business owner can actually make in a workshop, and it produces a control you can enforce on Monday rather than a programme of work that reports quarterly.

How do you know the AI did what you approved it to do?

Approval describes a system at a point in time. The record has to describe what actually ran.

The other half of the chain is orchestration, meaning everything between a person's request and the answer they receive. Retrieval sits inside it. So does the assembly of context, the model's selection of tools, the sequence of calls when one step feeds the next, and any handoff between agents. The Model Context Protocol, which is the current common way of exposing tools to an agent, is one interface within orchestration rather than the whole of it.

The business question is simple to state. Is the thing you approved the thing that ran, and can you show it? Answering that requires three things to be pinned.

Who initiated the work: the person whose authority the agent is acting under. We covered this in our earlier article on agent identity, and the pattern is a gateway that carries a human's authorisation through to the agent acting on their behalf, so the receiving system records who authorised the request rather than only that a request occurred.

Which agent ran: the specific agent instance, not the class of agent.

Which version of the tool contract it ran against: this is the pin most organisations do not have, and it is the one that quietly comes loose. An approval is a statement about the tools an agent was described as having when someone reviewed it. What the agent can actually do is whatever its tool surface exposes at the moment it runs. Those two drift apart, and nothing in a standard deployment detects the drift, so the approval still looks intact while the thing it approved has changed underneath it.

Our view on where to anchor that third pin is that the gateway should perform the check, because it is the only component with the full picture of a request at the moment of the call, but it should not be the component asserting what the tool surface contains. Verifying a claim the server makes about itself is not much of a check. The gateway should compare the live tool contract against a signed attestation published by the tool provider, so that drift is detectable rather than merely recorded. A gateway that signs its own attestation is grading its own homework.

This is not settled ground yet, and it would be misleading to present it as available. Three independent efforts are working towards it: a proposal within the Model Context Protocol project for servers to publish a content digest for every exposed tool version, a related proposal for a signed manifest binding a server release to its tool definitions for the express purpose of drift detection, and an IETF internet-draft specifying a cryptographic layer over the protocol that includes signed tool definitions. None has landed. That three groups arrived at the same problem independently is the clearest available signal that the gap is real, and it tells a technology leader what to ask vendors for now, in advance of the standard existing.

Two things belong at the gateway alongside those three pins. The first is guardrails, meaning inspection of what goes into the model and what comes back out of it. The injection problem described earlier arrives through the retrieval path, and the check for it has to sit at the point every request passes through rather than being dispersed across each application. The second is model routing, which decides which model answers a given request. That is usually introduced as a cost control, and it is one, but it is also the thing that lets you change models without touching the applications that call them.

In the meantime the practical position is to record what you can. What was retrieved, which tools were called, in what order, under whose authority, and what the tool surface looked like at the time. That record is what turns an AI output from something that appeared into something the organisation can explain.

What does a blueprint for your organisation look like?

Eight parts, and the decisions each one carries are business decisions, not platform ones.

Both halves have now been argued separately. Set side by side they describe one arrangement, and it is worth drawing because a technology leader can hold a picture up in a room in a way they cannot hold up an argument. It is the same shape whichever model you choose and whichever platform you already run.

The two do not line up end to end, and it is worth saying why. The value chain is a logical sequence, while the architecture is the path a request actually travels, so the corpus sits second in the chain and last in the architecture. Reading across, the requester carries the outcome they want and the channel carries the use case that delivers it, the model does the thinking, the agent harness carries the reasoning and the action, the MCP server carries the retrieval, and the data platform holds the corpus. The gateway carries no link of its own. It sits across all of them, which is the point of putting it there.

Each part carries a decision, and in almost every case the decision belongs to the business rather than to the technology function. That is the useful thing about drawing it. It shows you who you have to go and ask.

Requesters: a requester is whoever wants the outcome, and that is not always a person. In practice the list runs wider than most first releases assume: a staff member working a case or answering a call, a customer or member on a self-service journey, a clinician, a case officer, an adviser or an assessor working inside a system of record, a partner organisation querying you through an integration, a business system triggering work as part of a process, a scheduled process running overnight with nobody watching, or another agent calling this one as a step in its own task. Only the first three have a human present at the moment of asking, and that difference decides whether the request carries a person's authority or needs an identity of its own.

Channels: the channel is how the ask arrives, and each one is a separate path that needs its own answer on who is on the other end: a chatbot or assistant someone types into, a copilot embedded in a productivity suite, an assistant built into a line-of-business application where the user may not think of it as AI at all, an agent API another system calls directly, a webhook fired by an event elsewhere in the estate, a scheduled job, an email address that accepts requests and replies, a voice or contact centre channel, or a messaging platform an employee already lives in. The decision here is which of these you are prepared to support at all, because every channel you allow is a path you then have to govern.

The agent harness: the harness is what runs the agent: the orchestration that assembles a request, the retrieval that fetches what the agent will reason over, and the tool selection that decides what it will try to do. Most organisations inherit this rather than choose it, because it arrives with whichever framework the first prototype used. The decision worth making deliberately is what the harness is required to record, since it is the only component that sees the whole run from end to end.

The model: less consequential than the attention it receives, and the choice matters less than people expect. Every other part of the blueprint stays where it is. The serving contract is the same whichever model sits behind it, because it describes what leaves your platform, and the gateway checks the call either way. What the choice changes is where that data goes and what record you hold afterwards. A frontier model consumed as a service gives the strongest general capability and the fastest start, and needs the most contractual and configuration attention because the data crosses into someone else's environment; an open-weight model you host keeps the data inside your boundary at the cost of running it, often the right answer where residency or classification constraints are firm rather than negotiable; a smaller model tuned to a narrow task is frequently the best value for a specific, repetitive decision. The decision is a business one about where data may sit and what you need to be able to prove later, not one that changes what your platform owes the model.

The AI gateway: this is the component most organisations do not have and the one that changes the position most. It is the single place every request passes through on its way out of the agent, which makes it the only practical place to verify who is behind a request, apply policy as code, check that the tool contract is the one that was approved, run guardrails over what goes to the model and what comes back, route between models, and write the run record. Verifying who is behind a request is identity chaining: the person authenticates as they normally would, and the agent acting for them is issued a scoped, time-limited credential that carries that person's identity forward, so the system at the far end records both the human who authorised the work and the agent that carried it out rather than an anonymous service account. Put these checks anywhere else and they are dispersed across every application, which means they drift. The decision here is whether you are prepared to make the gateway a condition of go-live, because retrofitting one after three agents are in production is considerably harder than requiring it before the first.

The MCP server: the integration point. It publishes what tools exist and what each one accepts, invokes them, and returns the result. It is deliberately unglamorous, and the reason it appears at all is that it is where the tool contract lives. What an agent can actually do is whatever this component exposes at the moment it runs, which is why it matters that something verifies that surface against what was approved.

The data platform: everything our companion article described sits behind this, but from the agent's point of view only two things matter: the serving contract that says what may be handed over and what travels with it, and the approved corpus that defines what may be drawn on for a given question. The decision is who owns each corpus, and that owner is in the business.

Security and governance: both run underneath all of it rather than beside any one part. Identity, classification, access and audit apply to every component in the picture. Named ownership, corpus approval and a register of the decisions AI is permitted to support apply to the whole arrangement. Neither is a component you buy. They are conditions the arrangement has to satisfy.

What does this look like when someone asks you to account for it?

The board, the auditor and the regulator are all asking a version of the same question.

The chain earns its cost the first time someone asks where an answer came from. That question arrives from several directions, and the answer draws on both halves.

A board asking whether AI use is under control is asking whether someone owns each of these decisions. An internal auditor is asking whether the approved design and the running system are the same thing. And from 10 December 2026, the Privacy Act asks a specific version of it.

New subclauses 1.7 to 1.9 of Australian Privacy Principle 1, inserted by Part 15 of Schedule 1 to the Privacy and Other Legislation Amendment Act 2024 (Cth), commence on that date. Where an entity has arranged for a computer program to make, or do a thing substantially and directly related to making, a decision that could reasonably be expected to significantly affect an individual's rights or interests, and personal information is used, the entity must set out in its privacy policy the kinds of personal information used and the kinds of decisions made.

Two things about it are worth a technology leader's attention. The first is that it is a transparency obligation rather than a prohibition, and that is exactly why it is a platform question. You cannot describe what personal information feeds a decision unless your serving layer can tell you, and you cannot describe the kinds of decisions being made unless your orchestration record can tell you.

The second is that the threshold may be wider than assumed. The Office of the Australian Information Commissioner released an Issues Paper on the obligation on 18 May 2026, with submissions closing on 15 June 2026 and guidance intended by September 2026. Commentary on that paper has read the regulator as signalling a broad interpretation, including the possibility that a decision where a human makes the final call on the basis of an AI-generated summary or recommendation could still be captured. That reading is not settled and the guidance may land differently. It is a reason to map where AI touches consequential decisions rather than to assume that human review takes you outside the obligation.

Being clear about scope: designing the chain makes the disclosure possible. It does not satisfy the obligation. The threshold assessment, the privacy policy wording, and the privacy impact assessments behind them remain separate pieces of work, and no architecture completes them.

What do you specify before the next pilot goes live?

Two specifications and two conditions, none of which require a budget to start.

The work is specification rather than construction, and most of it can be done before anything is bought.

Specify the serving contract, per named consumer: for each agent or assistant, write down what the platform will hand it: the classification of the data, where it came from, what it may be used for, how current it is, which sources are authoritative for the questions it will be asked, and what status of document is admissible. Name the business owner who approved that corpus.

Specify the orchestration record, per invocation: write down what must be captured every time the agent runs: who initiated it, which agent instance, which tools were called and in what order, what was retrieved, and what the tool surface looked like at the time. If your platform cannot produce a field today, record that as a gap rather than dropping the field.

A named corpus, not a tenancy: no agent goes live reading everything its requester could open. The corpus is defined, owned, and narrower than the permission set.

A traceable answer: for any output that supports a consequential decision, someone must be able to reconstruct which sources produced it. If that is not possible, the use case is not ready, whatever the demo showed.

There is a version of this you can run in a fortnight, without funding and without a vendor. Take the AI use already running in your organisation, pick the one closest to a decision that affects a person, and write the serving contract and the orchestration record you would need for it. The gaps are the scope. That page is a more persuasive case than any platform proposal, because it is grounded in something already happening in your business.

As Martin Barnier, Principal Consultant at Lumaris Co, puts it: "A secure AI integration and a trustworthy one are different builds. Authentication and encryption decide whether the request was legitimate. Only the serving layer decides whether the answer is defensible."

So where does this leave you?

A secure AI integration and a trustworthy one are different builds.

You will be able to tell your legal team, your board, or your auditor which agents touch decisions that matter, what each one is permitted to draw on, and who decided that, with the evidence behind every answer.

That is a different conversation to the one most technology leaders are having about AI at the moment. It moves the discussion away from whether the tools are secure, which they generally are, and towards whether the organisation is getting value it can defend under scrutiny. The industry has not finished writing down what good looks like here, and the organisations that do well will be the ones that decided what they needed from AI clearly enough to specify it.

If you have AI running against your data and you need to know whether the answers it produces can be acted on and defended under scrutiny, Talk to us. If you would rather map your own chain first, our Connected Risk Guide walks through the same questions against your own environment. Get the Connected Risk Guide.

Where do the claims in this piece come from?

The claims and figures behind this piece, for anyone checking the trail.

1. Digital Transformation Agency, Agentic AI addendum to the AI technical standard for Australian Government, published June 2026. digital.gov.au. Used for the description of governed retrieval, approved tools, controlled execution, auditability and rollback, and for the statement that an Australian reference now exists.

2. Digital Transformation Agency, Policy for the responsible use of AI in government, version 2.0, effective 15 December 2025. Referenced in passing as the policy the addendum complements.

3. ServiceNow, Enterprise AI Maturity Index, Australian findings released 30 July 2026. 115 per cent year-on-year increase in AI spend; 23 per cent with AI testing or auditing processes; 17 per cent with a governance and compliance tracking system; 72 per cent citing data accuracy, access and management; 62 per cent citing lack of transparency and potential for misinformation. Vendor-commissioned.

4. CVE-2025-32711 (EchoLeak), disclosed by Aim Security (Aim Labs) in June 2025. Zero-click indirect prompt injection in Microsoft 365 Copilot; patched server-side by Microsoft; no reported exploitation in the wild.

5. Privacy and Other Legislation Amendment Act 2024 (Cth), Schedule 1 Part 15, inserting APP 1.7 to 1.9. Commencing 10 December 2026.

6. Office of the Australian Information Commissioner, Automated Decision-Making Transparency Obligation (APP 1) Issues Paper, 18 May 2026. Submissions closed 15 June 2026; guidance intended by September 2026. The "broad reading" characterisation is drawn from legal commentary on the Issues Paper rather than from an OAIC statement, and is presented in the text as commentary, not as the regulator's settled position.

7. Model Context Protocol project, SEP-1766, Digest-Pinned Tool Versioning and Interceptor-Based Validation in MCP, proposed 5 November 2025. Status at time of writing: proposed, without a sponsor.

8. Model Context Protocol project, Tool Bill of Materials (TBOM) discussion proposal, signed manifest binding a server release to canonicalised tool definition digests for drift detection. Status: discussion.

9. IETF internet-draft, draft-sharif-mcps-secure-mcp-00, MCPS (MCP Secure), March 2026. Cryptographic layer over MCP including signed tool definitions. Status: internet-draft.

10. Lumaris Co, What does a core data platform need to look like before AI can use it?, August 2026. Companion article, source of the serving contract concept.

11. Lumaris Co, Your AI agents can access your patient records. Can you prove they should?, 10 July 2026. Companion article, source of the identity gateway pattern.