The Agent Finished the Job. Where Did the Work Go?

A government contract can specify where data may be processed. Can the system integrator prove where an agent actually worked?

Imagine a council asking an agent to summarise a set of residents’ submissions. The application and its database are in a UK cloud region. A manager sees the completed summary and signs it off. The contract says the underlying data must be processed only in approved locations.

Now ask a different question: where did the work happen? Did a model in another region read the submissions? Did a tool call send excerpts to a specialist service? Was a failed attempt retained in a provider log? Could a support engineer elsewhere open that log? If the agent switched provider after a timeout, did the contract allow the new route?

This is a hypothetical job, not an allegation against any supplier. It exposes a gap between a location promised in a contract and a route demonstrated for a particular transaction.

A UK database is not the whole journey

The UK government's cloud guide says there is no blanket policy preventing departments from using cloud services in a particular country. Departments make risk-based decisions. Individual contracts and data-sharing arrangements can be much more restrictive. DWP's published cloud policy, for example, limits data residency and processing to approved jurisdictions and addresses remote access from outside the UK. UKHSA's processing-location standard gives another example of a defined boundary for a particular class of protected data.

The boundary is not simply where a server stands. The government guide includes who manages a service and who can access the data. The NCSC's cloud security principles ask where data is stored, processed and managed, and explicitly include derivatives such as logs and machine-learning models. A locally stored file can still be accessible elsewhere.

Data-protection law adds another test. The ICO says sending personal information to a separate organisation abroad or making it accessible there can amount to an international transfer, subject to a three-step assessment of the particular arrangement. A cross-border route is not automatically prohibited. Nor does calling a system “UK hosted” answer the question. The roles, entities and flows must be mapped. ICO guidance

An agent makes the route conditional

Conventional systems can be complicated enough. An agent may add model routing, search, external tools, retries, caches, human review and recovery after a failed call. Those are useful capabilities. They also mean that two apparently identical jobs may take different paths.

Suppose the approved UK model is unavailable. A routing service sends the next attempt to a cheaper overseas model. The final answer may be perfectly good. The breach, if the contract forbids that processing, has already happened before anyone reads it.

The same problem arises when an integrator knows the region of its main cloud account but cannot see the location of a subcontracted model call, the vendor's logging service or a human support session. A screenshot of the cloud configuration proves what was configured. It does not prove every step of this job occurred there.

So the important unit of assurance is the job, not merely the application. For each step, the integrator needs to know what data crossed which boundary, which provider processed it, what region was actually used, what was retained and who was able to access it. If a provider cannot supply that evidence, the honest answer is “not established”, not “probably compliant”.

Who may use the data afterwards?

There is a second boundary: purpose. An organisation may authorise a provider to process a request without authorising it to use the material to train a model, improve a service, create a benchmark or retain a searchable record indefinitely. Those questions need explicit contractual and technical answers. The ICO distinguishes the purposes of model training and deployment and says they must be specified separately when personal data is involved. ICO purpose-limitation guidance

Not every log is a forbidden second use. Logs may be needed for security, billing, incident response and audit. But the integrator must be able to say which logs exist, where they are, how long they last, who can read them and whether they contain the original data or a meaningful derivative. Deleting the input from the application's database is not necessarily the same as deleting every copy made during execution.

What would an auditor actually receive?

I would ask an integrator for two linked records.

The first is the authority record: the contract clause and policy version in force at the time, permitted locations and providers, approved subprocessors, allowed purposes, retention rules, and who authorised any exception. It must be dated. A change to the approved list next month does not rewrite what was permitted today.

The second is the execution record: a job identifier; the model, tool and provider selected at each step; the provider-reported region; timestamps; the data classes sent; retries and fallbacks; resulting files and logs; support access; and the evidence used to accept the outcome. It should show both successful and failed attempts. A final-answer transcript alone leaves the most important movements invisible.

Those records need independent corroboration. Match integrator routing logs against provider usage and region records, access logs, configuration history, contractual subprocessor notices and appropriate third-party assurance. The NCSC cautions that confidence based on a supplier's assertion differs from confidence supported by independent validation. Government AI procurement guidance also calls for end-to-end auditability through process logs.

This still is not mathematical proof that no copy exists anywhere. The integrator can only attest to the scope its controls and suppliers make observable. That limitation should be stated in the audit report. A useful assurance statement distinguishes “configured for UK processing”, “provider attests UK processing” and “the recorded job route was reconciled with independent evidence”. Those are different claims.

A control that can refuse the job

My work on Agent Control and the Digital Labour Exchange starts with an authorised job, its budget, its route and the evidence for an accepted outcome. That is a practical design lens here, not proof that any platform has solved the wider assurance problem.

A location rule should be enforced before a model or tool receives data. If a selected route is not approved, the agent should use an authorised alternative or stop and escalate. Retries must be subject to the same rule. The exception cannot be that a faster model silently gets the work done.

That changes the question for a buyer. Ask the supplier to demonstrate a real or representative job that fails over, invokes an external tool and produces a log. Then ask: which countries processed the original and derived data; which people could access it; what did each party keep; and can you produce the evidence six months later under the rules that applied on the day?

The agent may finish the task. The organisation still has to account for the journey. In a contract with geographic boundaries, “done” must include knowing—and being able to prove—where the work went.

Cover illustration: AI-generated conceptual image. The depicted routes illustrate questions for assurance; they do not describe the behaviour of any named provider.

Also published on Medium ↗.

This article reflects the evidence and development status at its original publication date.