When AI only helps draft text or find information, businesses can often manage risk by defining which tools are allowed and what data must not be entered into them. That approach becomes insufficient when AI agents can retrieve internal documents, call business systems, create requests or recommend actions within a workflow. The question is no longer only, “May we use this application?” It becomes, “What action may the AI take on what data, in what situation, and who supervises it?”
In a July 27, 2026 article, Google introduced its Beyond Zero approach to enterprise security. A notable element is that control is placed at the level of resources and actions rather than at the level of an application or tool. This is not yet a universal standard for every organization, but it accurately reflects the change managers need to prepare for: an agent should not receive broad access simply because the application it uses has been approved.
From permission to use a tool to permission to do a job
In the familiar model, a company may allow employees to use one AI platform and block others. With agents, the same platform can do very different things: summarize a public policy, search an internal repository, create a refund request, change an order status or send a customer notification. The risks are not the same. A broad tool-level permission can therefore be too wide for some tasks and too restrictive for others.
An action-based approach requires the organization to identify the resource an agent may access, the operation it may perform and the conditions under which that operation is allowed. A customer-service agent, for example, may view the delivery status of the order being discussed by the authenticated customer, but it should not download the customer’s full purchase history. It may draft a refund proposal, while approval and sending remain human decisions when the value exceeds a threshold or the complaint falls outside policy.
The management implication reaches beyond security teams
This is not simply a technical issue. To define action-level rights, the organization must clarify workflows, data and decision rights often distributed across operations, technology, legal, risk and business functions. If a security team is asked to “secure AI” without a description of work, exception standards and business accountability, it cannot design suitable controls. The outcome is often one of two extremes: permissions are opened too quickly, or controls are so broad that useful experimentation cannot create value.
Example
An internal agent helps an HR team answer questions about leave policy. It may search and cite the current policy in approved documents. If an employee asks about remaining leave, however, the agent should retrieve only the logged-in employee’s data, display the result and guide the request process. The agent should not change leave data itself or view another person’s record. When a request involves an exception, it should route the matter to the responsible person rather than interpret policy on its own.
Three control layers to prepare
The first layer is an action inventory. Every use case should state whether an agent may read, recommend, draft, create, execute or send. The second layer is data scope: which data the agent may access, for whom, for how long and whether it may be retained. The third layer is oversight: which actions may be automatic, which require approval, what trace must be retained and who reviews exceptions.
These layers make the discussion less abstract. Rather than asking whether the organization trusts AI, the implementation team can test each scenario: what happens if the agent is wrong; who detects an improper data access; and where are rights and instructions updated when a policy changes? These questions do not slow innovation. They help the organization automate the right work while keeping people where judgement or accountability is required.
What businesses should do next quarter
Select two or three use cases where an agent already touches, or will soon touch, internal data. For each use case, create a short record covering the business objective, necessary data, intended action, approval threshold, business owner and monitoring indicator. Next, test unusual situations: an out-of-scope question, missing data, changed user permissions or a request that conflicts with policy. Finally, review the design regularly because a permission appropriate today may no longer be appropriate when a workflow or data set changes.
Investing in agents is not only a decision to deploy a more capable tool. It is a decision to expand the ability to act within an enterprise system. Value and risk will grow together when access rights are not designed with enough specificity.
References
Adkins, H., & Ramamoorthy, A. (2026, July 27). Going Beyond Zero: A new paradigm for enterprise security. Google. https://blog.google/security/going-beyond-zero-a-new-paradigm-for-enterprise-security/
