Faster cyber attacks demand limits on AI agents

Faster attacks make governable autonomy the priority

An autonomous system that decides on contracts, inventory routing or capital allocation gives attackers a way to influence business operations. Google Cloud’s cybersecurity forecast warns that attackers could corrupt the information or business logic these systems use, causing harmful decisions across a business. For security leaders deploying agentic AI, systems in which AI agents carry out tasks autonomously, the risk extends to the authority they give software to make consequential choices.

Protecting those decisions requires defences that respond within the time an attack allows. Yet faster execution also makes it more important to set an agent’s authority before it acts. Google Cloud proposes combining automated defence with governable autonomy: agents work within defined permissions, their decisions remain open to examination, and people remain responsible for constraints and escalation.

Google Cloud sets out this forecast in its Cloud CISO Perspectives for 2027, with coverage titled Google Cloud warns AI agents will reshape cyber defence. Chris Betz, Chief Information Security Officer at Google Cloud, developed it with contributions from Google Cloud and Google security leaders Karthik Narain, Ramya Chitrakar, Heather Adkins, Sandra Joyce and Charles Carmakal. Google Cloud sells cloud and security services, so it has a commercial interest in organisations investing in the automated defence and governance it recommends.

“In 2027, there is a high risk that threat actors will shift from direct data theft toward decision manipulation, subtly poisoning data or compromising logic to prompt autonomous agents into making harmful business choices at scale,” said Betz. The attack begins when someone alters data or logic that autonomous systems then use. The systems turn that interference into business harm through the decisions they make.

Agent-speed attacks require controls during execution

The pressure for faster defence begins with changes in software development itself. Google Cloud says AI agents are finding and repairing vulnerabilities at scale, helping shorten release cycles from weeks or months to hours or days. Because an agent can help identify a flaw and deliver its repair, security teams must account for a faster path from discovery through code changes to release.

Attackers are also shortening the time available to respond. Google Cloud says attacks with several stages now execute within seconds, putting them beyond the reach of a weekly vulnerability scan or a month-long patching process. Those schedules can still organise security work, but they cannot provide an immediate response to activity that finishes between checks. Protection therefore needs to operate while software is running.

To provide that protection, Google Cloud expects more controls to run inside software runtimes, the environments where software executes. Automated defences could then respond as activity occurs, at machine speed. Google Cloud also describes a shift towards checks on individual transactions or operations, reducing dependence on security at the network perimeter. Those checks would cover models, permissions, infrastructure and supply chains, so a workflow’s attempted action and its authority could be assessed during execution.

Controls during execution also matter when defenders have little advance warning. Google Cloud says attackers exploit vulnerabilities before vendors know about them, so a response process that waits for vendor awareness can begin too late. It separately says multi-agent frameworks, in which several agents work together, support large-scale credential harvesting in less than six hours. Credential theft over that interval differs from the multi-stage attacks measured in seconds; each puts pressure on processes that require a person to review every event.

Human review adds the analyst’s waiting and handling time to the response. Google Cloud therefore calls for greater use of automated systems alongside structured governance, with rules separating actions an agent may take immediately from conditions requiring human judgement. Teams need to make those decisions before an incident forces them to do so under pressure.

The same planning extends to the software agents help produce. Google Cloud says attackers are targeting open-source software, external libraries and MCP tools that coding assistants can automatically bring into corporate codebases. MCP, the Model Context Protocol, connects AI systems to external tools and data. If an attacker compromises an upstream dependency or tool and an assistant incorporates it during development, the assistant creates a route into enterprise software. Controls must therefore cover what agents consume, incorporate and execute as well as how quickly they find and repair flaws.

Establish authority before agents act

Controlling what agents can use begins with knowing which agents have been deployed. Google Cloud calls deployment ahead of governance “agent sprawl” and describes it as a new form of shadow IT: technology introduced before the organisation has the oversight and controls to manage it. It says many enterprises follow this pattern. Each deployment can add an actor able to use tools and exercise permissions, making its granted authority an immediate security concern.

To manage that authority, Google Cloud recommends treating each agent as a first-class identity: an actor explicitly recognised within the organisation’s identity controls. Each agent should have verifiable credentials and least-privilege access, which limits permission to what its task requires. Security teams can then establish which agent is acting and whether the action falls within its assigned authority. Separating agents this way also helps keep useful capabilities from carrying permissions beyond the intended work.

Permissions also need to reflect how security work is divided. Google Cloud recommends teams of specialised agents for complex tasks, with roles such as hunter, decoder and responder, rather than assigning the whole operation to a general-purpose agent. Each role has a distinct responsibility in the system’s design. Dividing the work gives teams a basis for assigning different permissions and degrees of autonomy to different parts of the operation.

Google Cloud pairs these specialised roles with graduated autonomy and a central coordinator. Graduated autonomy gives agents or activities different levels of freedom to act, while the coordinator can refer an issue to a person when needed. Because identity, permissions and deployment checks establish boundaries in advance, authorised actions can proceed automatically within them. Human review can then focus on decisions that cross those boundaries or meet defined escalation conditions.

But teams also need to examine how agents behave within those boundaries. Google Cloud calls for observability, the ability to inspect system activity, covering agent inputs, reasoning, tool calls and compliance with policy. Teams need records of the information an agent received, what it recorded about its decision, the tools it used and whether its actions followed the rules. Recorded reasoning gives investigators material to examine, though they should read it as the agent’s recorded account of a decision.

With these records, investigators can follow the sequence that produced a harmful action and find where it went wrong. Incomplete traceability makes validation and debugging harder, and Google Cloud also links traceability to trust in autonomous actions. For the business decisions described earlier, a team needs enough detail to investigate how an agent reached a consequential choice.

Investigation after an event must be paired with testing before deployment. Google Cloud recommends mandatory adversarial red-teaming: deliberate attempts to challenge an agentic system and expose unsafe behaviour before it receives operational authority. Those tests help teams set constraints before use, while decision records let them examine behaviour and refine the constraints once the system is running.

Human judgement and internal context give defenders an advantage

With more immediate defensive work assigned to automated systems, Google Cloud expects human security teams to spend more time managing risk and less time handling alerts. It presents reduced workload as a potential benefit. Decision records support that human role by showing how agents use their authority and what rationale they record. People still need this insight to judge acceptable risk, set permissions and decide when escalation is necessary.

Those judgements can draw on information that Google Cloud says is unavailable to attackers. It identifies identity privilege graphs, network architecture, code lineage and runtime data as sources of defenders’ internal knowledge. Identity privilege graphs map the relationships between identities and their permissions, while code lineage records where code came from and how it developed. Combined with the network’s structure and evidence from running systems, these records help defenders connect access rights to actual behaviour inside their organisation.

That connection can reveal dangerous combinations of permissions before they are abused. Google Cloud argues that defenders can use their internal knowledge to identify combinations an attacker has yet to exploit, allowing security teams to change authority before it contributes to harm. Teams can apply that knowledge when assigning agent permissions, setting escalation conditions and examining autonomous behaviour. Even when a defensive action happens too quickly for manual approval, people can use their understanding of the organisation to decide which actions an agent is allowed to take.

Key highlights

• Put controls inside running systems: Google Cloud warns that multi-stage attacks can execute within seconds. Security teams need automated checks on operations, permissions and dependencies during execution, with clear rules for escalation to people.
• Set agent authority before deployment: Security and platform owners need to give each agent a verifiable identity, task-specific permissions and defined limits on autonomous action. Adversarial testing and records of inputs, decisions and tool calls help expose unsafe behaviour and investigate harmful choices.
• Use internal knowledge to guide autonomy: Security teams can combine permission maps, network architecture, code lineage and runtime data to identify dangerous access combinations before abuse occurs. That evidence helps people set agent permissions, refine escalation rules and manage business risk.