Google Says Zero Trust Is Not Enough for AI Agents: What Beyond Zero Changes for Business Automation

Google’s Beyond Zero does not discard zero trust. It extends security from verifying who or what may enter a system to authorising each action an AI agent attempts on a specific resource, using live context, investigation, challenge and containment.

For Sydney and NSW businesses, this means automation projects need action-level permissions, human approval thresholds, complete logs and emergency stop controls before agents can safely update customer, property, payment or project systems.

Google’s latest security proposal arrives as AI agents move from answering questions to performing work. Agents can now retrieve documents, update records, call external tools, prepare customer communications, change schedules and move information between systems without waiting for a person to direct every step.

That capability creates a control problem that traditional enterprise security was not designed to resolve on its own. Confirming that an agent has a valid identity and may enter an application does not establish that every action it attempts inside that application is appropriate.

In its Beyond Zero announcement , Google proposes extending zero-trust principles into the authorisation layer.

Instead of treating access as a broad permission to use a system, the model evaluates individual actions against specific resources and the context in which each action is being attempted.

Google Is Extending Zero Trust, Not Declaring It Obsolete The phrase “Beyond Zero” may suggest that zero trust is being replaced. Google’s position is more measured.

Zero trust remains necessary for establishing identity, checking devices, restricting network access and reducing the assumption that anything inside an organisation should automatically be trusted.

The problem is that an AI agent can be properly authenticated, operate from an approved environment and still attempt an unsuitable action. It may misunderstand an instruction, use excessive permissions, respond to malicious content, select the wrong customer record or pursue a valid objective in an unsafe way.

Google DeepMind’s separate AI Control Roadmap makes a similar operational distinction. It treats capable internal agents as systems whose behaviour must be monitored, with harmful actions blocked before execution when the possible impact is high.

Beyond Zero therefore asks a more precise question.

It is no longer only: “Should this identity have access?”

It is also: “Should this identity, acting through this agent, perform this particular action on this particular resource, at this moment, for this purpose?”

Once Software Can Act, Application Access Becomes Too Coarse Conventional permissions are often organised around applications and roles. A project coordinator may have access to a CRM, document system, calendar and quoting platform. An AI agent acting for that coordinator may inherit some of those permissions.

That structure becomes risky when the agent can move across several systems in one workflow.

Access to the CRM may allow it to read a customer record, overwrite a site address, change a project status, export the contact database or trigger a follow-up. These actions do not carry the same commercial or privacy risk.

Primary Decision Traditional zero-trust emphasis: May this user, device or service access the system?

Beyond Zero emphasis: May this exact action be performed on this resource?

Permission Scope Traditional zero-trust emphasis: Application, role, folder or environment

Beyond Zero emphasis: Record, field, document, transaction or tool action

Decision Timing Traditional zero-trust emphasis: At login, connection or session establishment

Beyond Zero emphasis: Before and during consequential agent actions

Context Traditional zero-trust emphasis: Identity, device, network and location

Beyond Zero emphasis: Identity, business purpose, data sensitivity, action history and risk

Response Traditional zero-trust emphasis: Allow, deny or terminate access

Beyond Zero emphasis: Allow, deny, challenge, restrict, investigate or contain

This distinction matters for businesses deciding whether to use an AI agent or deterministic workflow automation .

A rules-based automation can be tightly constrained to known inputs and outputs. An agent may interpret unstructured information and choose its own sequence of tools, which makes runtime authorisation more important.

The Five Beyond Zero Principles in Operational Terms Google describes five principles for Beyond Zero. Their practical significance is clearest when translated from security architecture into everyday business controls.

Resource and action-based security: An agent should not receive broad permission to “use the CRM”. Policies should distinguish between reading an approved project record, changing a customer’s contact details, exporting information and deleting a record. The same controls should apply whether the action originates through a user interface, an API or a connected agent protocol. Static rules combined with dynamic controls: Stable rules remain useful. An enquiry agent may always be prohibited from accessing payroll or changing bank details. Dynamic checks can then be added when behaviour becomes unusual, such as an agent attempting to export hundreds of records after normally accessing one project at a time. Automatically enriched context: An authorisation decision can consider what the employee is working on, which customer or project is involved, whether the requested information is necessary, what the agent has already done and whether the proposed action is reversible. Automated investigation: Suspicious behaviour should not merely generate an alert for later review. A high-risk signal can trigger an immediate investigation, collect relevant evidence and determine whether the agent should continue. Challenges and containment: A system may require fresh human approval, stronger authentication or additional evidence before an action proceeds. Where the risk is unacceptable, it should contain the agent, withdraw a tool, end the session or isolate the affected workflow. Google says its early internal prototypes have improved access-abuse detection and intellectual-property protection.

However, Beyond Zero should not yet be treated as a universal product, certification or established industry standard. Google has described an emerging paradigm and plans to release further technical and implementation material over time.

A Sydney Project Workflow Exposes the Difference Consider a Sydney property and renovation operator using an agent to process a new apartment enquiry.

The agent receives an email, extracts the address, checks the CRM, reviews site photographs, identifies likely strata access requirements, prepares inspection questions and proposes available appointment times.

Most of that work is administrative and reversible. The risks change when the same agent is connected to quoting, payment, document and scheduling systems.

Reading the customer’s submitted project description may be automatically permitted Accessing unrelated identity documents should be denied because they are not needed for the task Adding an internal note about lift access may be permitted and logged Changing an approved quotation should require commercial review Sending bank or deposit instructions should be blocked or require verified human approval Deleting site records, signed approvals or compliance documents should remain prohibited Exporting the project file to an unapproved destination should trigger investigation and containment A conventional access model may see one authenticated agent using approved applications. An action-level model sees seven different risk decisions.

This is why production preparation cannot stop at connecting tools.

Elyment’s analysis of what businesses should prepare before AI agents move into production identifies the need for clear system boundaries, tool permissions, approval rules and escalation paths before an agent is given operational responsibility.

Risk Should Follow the Action, Not the Application Beyond Zero supports a more practical way to classify automation.

Instead of labelling an entire platform as safe or unsafe, the organisation assigns controls according to the consequence and reversibility of each action.

Low-Risk Actions Examples: Classify an enquiry, summarise an internal note or prepare a draft checklist

Suitable control: Automatic execution with logging and periodic review

Moderate-Risk Actions Examples: Update a project status, create a task or suggest an appointment

Suitable control: Action-level permission, validation and rollback capability

High-Risk Actions Examples: Send a client message, change a quote, issue an invoice or disclose personal information

Suitable control: Pre-execution checks and named human approval

Critical-Risk Actions Examples: Change payment instructions, alter privileges, delete records or make safety-critical decisions

Suitable control: Prohibition, dual approval or a tightly isolated specialist workflow

This approach avoids two costly extremes.

The first is excessive autonomy, where agents receive broad permissions because limiting each action appears difficult.

The second is excessive restriction, where every action requires approval and the automation delivers little operational benefit.

The control level should reflect the likely harm, the value of the resource, the reliability of the workflow and whether the action can be reversed quickly.

Beyond Zero Changes the Sequence of an Automation Project Many automation projects begin with platform selection and integration. An action-level security model requires more operational work before the technology is connected.

Map the existing process: Identify what initiates the workflow, which systems are used, who owns each decision and where delays or errors currently occur. Inventory every possible agent action: Separate reading from writing, drafting from sending, suggesting from approving and updating from deleting. Classify resources and consequences: Identify customer information, property records, commercial pricing, payment details, legal documents, access instructions and safety information. Define the user behind the agent: Establish whose authority the agent is exercising, whether that authority can be delegated and what should happen when the user’s role or employment changes. Set static boundaries: Prohibit unnecessary systems, data classes and high-consequence actions before considering dynamic access. Add contextual approval rules: Require additional checks when the amount, destination, customer, data sensitivity or behavioural pattern falls outside expected conditions. Design investigation and containment: Decide who receives an alert, what evidence is captured, which tools are withdrawn and how affected records are protected. Test with restricted authority: Begin with drafts and recommendations before enabling external communication, system changes or transactions. Expand only from operational evidence: Increase authority after reviewing error rates, rejected approvals, unusual actions, response times and user behaviour. This sequencing also protects the business from spending heavily on the wrong architecture.

As Elyment’s review of why poorly designed automations remain expensive explains, low software prices do not compensate for unclear processes, weak data, missing ownership or unreliable handovers.

NSW Governance Is Moving Towards Lifecycle Assurance Beyond Zero is a Google security proposal, not an Australian regulatory requirement. Its emphasis on continuous assessment nevertheless aligns with the direction of NSW public-sector governance.

The NSW AI Assessment Framework is mandatory for NSW Government agencies and applies across the design, procurement, deployment, use and operation of AI systems.

The framework was updated to capture newer capabilities, including agentic AI, while maintaining attention to privacy, security, transparency and accountability.

Private Sydney businesses are not automatically subject to that government framework. It remains a useful assurance benchmark for organisations working with government, infrastructure, property, legal services, health, finance or other trust-sensitive environments.

The NSW Cyber Security Policy and the 2026–2028 NSW Government Cyber Security Strategy also reflect a continuing approach to governance, assurance, cyber resilience and risk management rather than treating security as a one-off implementation project.

Privacy obligations create another layer.

The Office of the Australian Information Commissioner’s guidance on commercial AI products advises organisations to assess whether AI is necessary, conduct due diligence, embed human oversight, apply privacy by design and continue monitoring throughout the product lifecycle.

For entities covered by the Australian Privacy Principles, action-level controls can help demonstrate that personal information is accessed and used for defined purposes rather than being made broadly available to an agent.

Security controls do not, however, replace consent, notification, accuracy, retention, disclosure or other privacy obligations.

Additional APP 1 transparency requirements for certain automated decisions are scheduled to commence on 10 December 2026.

Organisations in scope should review whether computer programs use personal information to make decisions that could reasonably be expected to significantly affect an individual’s rights or interests, and obtain advice about the resulting privacy-policy requirements.

Procurement Teams Need Evidence, Not Security Labels A vendor saying that its platform supports zero trust does not answer how an agent will be controlled after access is granted.

Procurement, operations, privacy and technology teams should ask for evidence at the action level.

Does every agent have a distinct identity and attributable owner? Can the system preserve the identity and authority of the user behind the agent? Can permissions distinguish reading, creating, changing, sending and deleting? Are policies enforced consistently across interfaces, APIs and agent connections? Can high-risk actions require fresh approval before execution? Are tool calls, data access, approvals and policy decisions logged? Can the business suspend one agent without disrupting the entire platform? Can unauthorised changes be rolled back or isolated? How does the system respond to prompt injection or manipulated source material? Can unusual behaviour trigger containment rather than merely generate an alert? How are subcontractors, departed staff and changed roles removed from delegated authority? What additional licensing, integration, monitoring and log-retention costs apply? Businesses comparing multiple agent platforms should also review which AI tools should be connected to operational systems first .

The most capable platform is not necessarily the safest first connection. The decision depends on the workflow, information, authority and consequences involved.

The Cost Will Shift From Licences to Control Infrastructure Beyond Zero may reduce the cost of incidents, but it is not cost-free.

Granular authorisation requires:

Policy design System integration Agent identities Observability Log storage Approval interfaces Incident procedures Ongoing review The largest cost is often organisational.

Someone must decide which actions are acceptable, identify the accountable owner, resolve conflicts between security and speed, and update controls when the business process changes.

Useful performance measures include:

Percentage of agent actions covered by an explicit policy Number of actions blocked before execution Approval requests generated per completed workflow Approval rejection and correction rates Time required to investigate an unusual action Percentage of system changes that can be reversed Number of dormant or over-privileged agent identities Human review time relative to time saved by the automation Customer, project or privacy incidents attributable to agent activity Cost per successfully completed and verified workflow These measures reveal whether the control architecture is protecting the business or simply adding friction.

A well-designed system should allow routine, low-consequence work to proceed quickly while concentrating human attention on unusual or consequential actions.

What Beyond Zero Cannot Fix Action-level authorisation cannot repair a business process that has no clear owner, no reliable source data and no agreed approval pathway.

It also cannot determine which quotation is commercially correct, whether a strata approval has been interpreted properly or whether a proposed site activity is safe unless those responsibilities and evidence requirements have first been defined.

Beyond Zero also does not remove the need for:

Accurate operational procedures Staff training and acceptable-use policies Privacy and legal review where appropriate Data classification and retention controls Vendor and supply-chain assessment Tested backups and recovery procedures Human accountability for consequential decisions Regular review when systems, roles or business conditions change Review the Action Before the Agent Changes the System Assess workflow boundaries, data access, approval thresholds, compliance considerations, system connections, audit evidence and containment procedures before an AI agent is given operational authority.

Request an Automation Control Review

The Business Impact Is Controlled Delegation Google’s Beyond Zero proposal marks a change in how businesses should think about agent security.

The agent is not simply another employee account, chatbot or integration. It is an operational actor capable of selecting tools and executing a sequence of actions faster than a human supervisor may be able to review them.

For Sydney and NSW organisations, the practical response is not to abandon AI automation. It is to design authority more carefully.

Agents should receive the minimum resources they need, separate permission for consequential actions, contextual checks when behaviour changes and a clear containment path when the organisation cannot confidently authorise the next step.

Zero trust determines whether an identity should enter. Beyond Zero attempts to govern what happens next.

That distinction is likely to become increasingly important as agents move deeper into customer communication, property operations, project coordination, compliance workflows and commercial systems.

The businesses best positioned for that transition will not be those that grant agents the widest access.

They will be those that know exactly which work can be delegated, which actions require evidence and where accountable human judgement must remain.

Key Answers for Business Leaders Does Beyond Zero Replace Zero Trust? No. Google presents Beyond Zero as an extension of zero trust into continuous, resource-level and action-level authorisation.

Identity, device and access controls remain necessary.

Is Beyond Zero a Product Businesses Can Purchase? Not as a universal standalone product or certification.

Google has introduced a security paradigm based on internal architecture and early deployments, with further technical publications expected.

Do Smaller Sydney Businesses Need Enterprise Security Architecture? They may not need Google-scale infrastructure, but they still need the underlying controls:

Limited permissions Separate agent identities Human approval for consequential actions Useful logs A reliable way to stop or reverse a workflow Which Agent Actions Should Remain Under Human Control? Actions involving payments, customer commitments, legal documents, pricing, privacy disclosures, access privileges, record deletion and safety-critical decisions generally warrant pre-execution review, dual control or prohibition.

Sources and References Google: Going Beyond Zero—A New Paradigm for Enterprise Security Google DeepMind: Securing the Future of AI Agents Elyment: AI Agent vs Workflow Automation Sydney Elyment: Preparing AI Agents for Production Elyment: Why Poorly Designed Automations Remain Expensive NSW Government: NSW AI Assessment Framework NSW Government: Cyber Security Policies NSW Government: 2026–2028 NSW Government Cyber Security Strategy OAIC: Guidance on Privacy and Commercially Available AI Products Elyment: Which AI Tools Should Businesses Connect First? Elyment: Contact and Automation Control Review Important: This article provides general operational information and does not constitute legal, privacy, cybersecurity or regulatory advice. Requirements should be assessed against the organisation, information, workflow and jurisdiction involved.