Autonomy is a permission decision

In September 2025, the G7 Cyber Expert Group published a statement on AI and cybersecurity in the financial sector. It brought three sides of the technology into one short paper: AI as a defensive tool, AI as a capability for attackers, and AI systems as targets of attack in their own right.

The group also linked increasingly complex and autonomous systems to operational resilience, human oversight, model risk and concentration among third-party providers. It did not set regulatory expectations or issue guidance. Its purpose was to raise awareness and offer questions for institutions and authorities.

That restraint helps. The paper does not tell leaders whether to deploy an agent. It does show why capability, authority and dependency have to be considered together.

From capability to authority

The G7 put autonomy inside the risk discussion

The group described AI as a defensive tool that could improve anomaly detection, fraud detection, patching and security-operations work. It also said malicious actors could use AI to increase the precision, speed and scale of cyber activity. And it treated AI systems themselves as targets or routes for attack through data poisoning, data leaks and prompt injection.

A widely used AI provider could also become a shared financial-sector dependency. The scale of any disruption would depend on how critical its services were and how readily they could be replaced.

An agent therefore belongs inside the organisation's existing cyber and operational-risk decisions. It can strengthen defence. The same access that lets it inspect data or act through production tools can let a mistake cause harm. Reliance on its provider or orchestration service can also leave the workflow unable to continue if either fails.

What must change before an agent can act

Software that recommends an action leaves the final decision elsewhere. Software that takes the action has been given authority by the organisation that connected it to data, tools and production services.

That authority can grow in useful stages. An agent may observe and explain, recommend a change, prepare work in a reversible environment, or act against a production system within explicit limits. At each stage, the practical question is what the agent can now make happen.

Some actions finish before a person can inspect or stop them. Prohibited actions therefore need to be blocked by the system in advance.

Human oversight still matters, but a named owner and an approval process cannot prevent an action that has already completed.

For actions the organisation permits, the owner needs evidence of what happened, authority to stop or revoke the workflow where intervention is still possible, and a workable recovery route if something goes wrong. The more serious the possible consequence, the stronger those controls need to be before the permission is granted.

An airport kept part of the journey moving

The G7 paper discussed concentration and substitutability as policy considerations. A September airport disruption offered a separate, non-AI example of what a limited fallback can achieve.

After a cyber incident affected a shared passenger-processing service, Berlin Brandenburg Airport said manual check-in and boarding could still cause delays and cancellations. Its 24 September update also said self-service bag drop and check-in remained available for passengers of 19 connected airlines because those facilities ran on deliberately redundant infrastructure.

The fallback did not keep the whole airport running normally. It preserved self-service check-in and bag drop for passengers of those 19 airlines while the shared service was impaired. That limited result is still useful: an alternative contributes to resilience when it preserves a meaningful part of the service through a genuinely different route.

Final perspective

I'd focus first on the authority being granted. If an action could finish before anyone can intervene, the sponsor and technical owner should be able to explain what the system prevents in advance and what recovery remains possible.

For continuity, I'd want the service owner to name the minimum service we could rely on if the agent, model provider or orchestration service failed. Berlin's limited fallback is useful precisely because it kept a defined part of the journey moving.

Historical reconstruction based on evidence available by 4 October 2025.