AI Agents Cross Boundaries. Who Takes Control?

An agent investigates a cloud service alert. It gathers the permitted telemetry, compares recent changes and prepares a response. Then it encounters a blocked dependency and proposes changing an access rule to continue. The original objective was reasonable. The next action exceeds its mandate.

Who can stop the attempt? Who decides whether a broader action is justified? If a request has already reached another system, how does the team establish what happened?

These questions belong in the workflow design. Human supervision needs an authorised person, an effective intervention path and evidence that connects the request to the result. A dashboard can reveal a problem without giving anyone the means to contain it.

The UK’s October developments give this operating question renewed urgency. For enterprises, the practical issue is how to delegate useful work while retaining authority over its consequences.

What changed in October, and what did not

On 12 October 2026, the UK government announced further work on growing AI risks, including preparations for serious incidents involving autonomous agents, model evaluations and consideration of stronger protections through the Cyber Security and Resilience Bill regime. The release also discusses identifying and reporting near misses. It describes announced activities and possible measures; it does not establish a new universal reporting duty for every enterprise agent.

The ICO’s agentic AI call for evidence opened on 8 October and closes at the end of 20 November 2026. It seeks evidence to inform guidance. The supporting explanation covers security, transparency, accountability, automated decision-making, fairness and purpose limitation, and lawful processing. This is a consultation, rather than final new agent-specific guidance.

Existing obligations remain relevant where UK data protection law applies. The ICO’s principles guide sets out lawfulness, fairness, transparency, purpose limitation, minimisation, accuracy, storage limitation, security and accountability. It carries a review notice following the Data (Use and Access) Act. Specific legal applicability needs current review. The control design below is an operational recommendation, not a statement that every suggested mechanism is mandatory under law.

What the research adds to the operating question

The research literature offers concrete reasons to evaluate both task completion and the boundaries around it. It does not supply a universal failure rate for enterprise agents.

AgentDojo examines tool-using agents exposed to untrusted data. Its value here is the evaluation design: useful-task performance and adversarial behaviour need separate measurement. An agent can fail at an ordinary task without an attack, and a successful task can still violate a security boundary.

CaMeL moves control and data-flow enforcement into a protective layer around the model. Its guarantees depend on its threat model, policies and implementation; the paper assumes a trusted user query and uncompromised memory, and excludes some text-only deception. The reported completion comparison also makes the utility tradeoff visible. It should not be read as proof that every agent can be secured by copying one architecture.

Our proposed editorial position follows from those distinctions: delegation should increase only when the enterprise can demonstrate useful output, enforce its action boundary and recover the process when that boundary is challenged. A model’s willingness to follow instructions is one input to that decision. The complete operating system carries the responsibility.

A mandate has to survive contact with the tools

An agent’s objective describes what it should accomplish. Its mandate defines what it may do in pursuit of that objective. Those are separate decisions.

For the cloud example, “investigate the service alert” can authorise reading telemetry and preparing a proposal. It need not authorise changing network rules, expanding infrastructure or modifying production configuration. The distinction should be explicit before execution begins.

Our recommendation is a versioned workflow mandate with:

• a business purpose and a recognisable accepted outcome;
• permitted data sources, resources and destinations;
• allowed tools and actions, including limits on delegation to other agents;
• conditions requiring a person’s approval or an immediate pause;
• a process owner, an operational responder and a backup;
• a route for amending the mandate and authorising a restart.

The ICO’s security consultation theme discusses deliberate choices about autonomy, proportionate permissions and approval thresholds. It also asks for evidence about identities and structured action records. That supports the relevance of these questions; it does not certify a particular implementation.

A prompt can explain the mandate. Enforcement should also sit at the tool and infrastructure boundaries. Give the agent a scoped identity, restrict tool operations and validate the action against policy before admitting it. If the agent requests a forbidden operation, the system should deny it even when the model supplies a convincing explanation.

Retrieved documents, logs and external pages are inputs to evaluate. They should not be able to rewrite permissions or appoint a new approver. An instruction embedded in a document is not authority from the process owner. Treat missing information and conflicting instructions as reasons to follow the exception path, rather than permission to improvise a wider task.

Follow one workflow through the boundary

The following is a hypothetical design, not a customer deployment or a released Flashback capability. It follows one cloud alert from investigation to intervention.

Suppose the agent discovers that it cannot reach a diagnostic resource. It proposes widening an access rule. If that change is outside the mandate, enforcement should deny it and route the case to the assigned responder. The blocked attempt is evidence to inspect; it is not automatically proof of a malicious agent.

The responder needs to know why the action was attempted, which resources it would affect, whether anything executed and what permitted alternatives remain. They may choose manual investigation, ask for a revised proposal or seek approval for a new scope. The agent cannot grant itself the missing permission.

Figure 1. The proposed action meets an external permission check. An out-of-scope attempt is held and handed to a named responder; the agent cannot expand its own authority.

This changes the unit of design. The team is building a controlled process with an exception path, rather than adding a conversational interface to an existing screen.

Assign operational authority without confusing legal roles

“A human is in the loop” leaves several questions unanswered. Who is available? What can they see? Which actions can they stop? Who decides whether the process should resume?

We recommend separating the responsibilities even when one person holds several roles:

These are operating responsibilities. They do not assign legal controller or processor status. The ICO’s accountability consultation theme examines who determines the purposes and means of personal-data processing, including choices about goals, access, tools and permissions. Legal allocation depends on the actual processing arrangements, rather than the title “agent owner”.

Make the operating handover usable. Provide a backup when the named responder is unavailable, identify where alerts arrive and define what happens while a decision is pending. A queue with no coverage preserves a task without resolving its authority. Escalation rules should match the consequence of delay as well as the consequence of execution.

Approval belongs to an exact action

A meaningful approval binds the reviewer’s decision to a particular proposal: the operation, resources, destination, relevant data, limits and current conditions. The interface should expose unresolved assumptions and the recovery options, rather than bury them behind a generic “approve” button.

For the cloud example, approval to investigate does not authorise a production change. Approval to change one identified resource does not extend to every resource the agent later discovers. If the target, material parameters or relevant state changes after review, the system should require reconsideration.

Keep the execution check distinct from the proposal check. A technically valid action can still lack authority. Conversely, an authorised objective can produce a proposal that fails acceptance criteria. Both decisions need evidence.

Automation can help: ordinary software can validate schemas, resource allowlists, version matches and required approvals. A model can identify inconsistencies or summarise the proposal for a reviewer, but its assessment needs evaluation too. Agreement between two agents does not establish permission or correctness.

Define bounded execution windows, action budgets and retry rules where useful. Those settings should follow the workflow’s risk and operational needs. No universal number of retries or approval timeout can replace that design work.

Cloud integration determines whether a stop works

An agent can span an application, a model service, a tool gateway, credentials and several enterprise APIs. Each boundary can admit an action, queue it or return an uncertain result. Map that path before deciding how intervention will work.

An intervention may pause new work, suspend tool access, revoke an identity or quarantine a task. Its actual effect depends on the architecture. Verify what is blocked and what remains in flight. Closing a chat or stopping the model process does not establish that a downstream job has stopped.

When an external operation times out, first reconcile its status. Where the interface supports it, use a stable operation identifier and duplicate prevention. Where it does not, route an uncertain outcome to an operator before repeating a consequential action. A request accepted by an API and an intended business outcome achieved are separate events.

Figure 2. Containment spans the session, tool gateway, queued work and external API. Stopping new activity does not reverse effects already produced; uncertain results need reconciliation.

Cloud placement also shapes data handling, availability and operational responsibility. Establish where source data and model requests are processed, which providers receive them and what contractual and technical controls apply. Moving the workload to another environment does not by itself resolve its governance.

If a policy service or required approval channel is unavailable, a recommended default for consequential actions is to hold execution until authority can be verified. Read-only investigation may follow a different explicit rule. Test the fallback instead of assuming an unavailable dependency produces a safe state.

Recover the process before restarting the agent

Containment prevents further activity. Recovery addresses effects already produced. Treat them as separate stages.

Start with a protected record of the run: original request, mandate and policy versions, identities, relevant source context, attempted actions, tool acknowledgements, approvals and confirmed outcomes. Preserve the versions that applied at the time. A link to a document that later changes may be insufficient.

The record should support investigation without becoming an uncontrolled duplicate of enterprise data. Limit access, redact secrets and unnecessary personal information, and define retention for the evidence’s purpose. A model-generated account can help organise the investigation; it cannot substitute for the actual action records. Access to hidden model reasoning is not required to establish which request a tool received and what it did.

Then reconcile affected systems. Separate proposed, denied, accepted, completed, cancelled and unknown actions. Use a tested rollback when reversal is possible. Where it is not, assign a compensating action through the appropriate business process. An external disclosure cannot be made undone merely by restoring a database value.

Restart requires an authorised decision: what failed, what changed, which residual uncertainties remain and which conditions permit another run. Replaying the original request against unchanged permissions may reproduce the same problem. Restrict scope, repair enforcement or continue manually when the evidence calls for it.

Figure 3. Recover the process before restarting. Confirm effects and uncertainty, obtain an owner decision, then choose an authorised restart or manual continuation under explicit conditions.

Test the handover and measure the whole outcome

A normal successful run is useful evidence about output. It says less about intervention. Before expanding the mandate, deliberately test cases that exercise the boundary:

• a proposed action outside the resource allowlist;
• a misleading instruction in retrieved material;
• a changed proposal after approval;
• an unavailable policy service or human reviewer;
• a timed-out operation that may already have completed;
• queued work that remains after the visible agent stops.

For each case, observe whether the operation is denied or held, the right person receives usable evidence and the team can complete recovery. Record missed violations, false alarms and uncertain outcomes alongside successful cases. A blocked attempt may reveal that enforcement worked, even if the overall task was not completed.

Measure the whole workflow: accepted output, review and exception effort, rework, recovery, model and infrastructure consumption, and integration maintenance. Include incomplete and difficult cases. Otherwise, a process that offloads effort to reviewers or abandons its hardest work can appear more efficient than it is.

Define the baseline, observation period and acceptance conditions before drawing conclusions. Reduced manual effort can release capacity; it does not automatically reduce cash expenditure. These are measurement recommendations, not Flashback performance claims.

Where Flashback starts the transformation

Flashback is an Agentic Transformation Company. Agentic Transformation redesigns enterprise workflows around bounded agent actions and retained human authority. Agents gather permitted context, use existing tools and systems, and recommend or execute bounded actions while humans retain policy, material decisions, approvals and exceptions.

That definition makes intervention part of the transformation. Discovery identifies the workflow, accepted outcome and decision owners. Build and integration connect the relevant systems with enforceable boundaries. Governance defines approval and escalation. Ongoing operation uses evidence to improve the process and reconsider delegation. Architecture and delivery commitments remain engagement-specific.

Start with one recurring workflow. Name the person who can take control, give them the necessary intervention mechanisms and rehearse what happens after a boundary is crossed. Increase authority only when the observed behaviour, evidence and recovery path justify it.

Book a call to discuss a workflow your team wants to delegate while retaining control over its consequences.

Sources and publication note

Primary regulatory pages were checked on 13 October 2026. Government proposals and the ICO consultation may develop; recheck their status before publication. The ICO principles guide carries a statutory-change review notice. The cloud scenario, control architecture and evaluation sequence are Flashback recommendations, not customer results, guaranteed protections or released product features. Canonical Flashback positioning is grounded in the repository’s approved records, including PROD-001, CLM-022 and CLM-023; editorial approval of this new article remains pending.