AI Agents Need Authorization at the Action Level

Why application-level permission breaks with agents

On July 27, Google introduced “Beyond Zero,” a proposed enterprise-security model for an environment shaped by AI. Google describes a contextual, risk-based authorization layer designed to operate at machine speed for both people and agents. Its central principle is that security decisions should apply to individual actions on specific resources rather than granting broad access to an application or tool.

That distinction matters because agents do not use software like employees do. A person may open a claims system, inspect two records, and stop. An agent can search thousands of records, combine information across systems, create derivative files, and trigger downstream actions within minutes. The same credential can therefore produce a very different risk profile depending on the task and the sequence of actions.

NIST’s Zero Trust Architecture already established that network location or asset ownership should not create implicit trust. It focuses protection on users, assets, and resources rather than network segments. AI agents extend that principle. The organization must decide not merely whether an agent can enter a system, but whether this agent, acting for this user, may perform this operation on this resource now.

Consider an agent used for procurement. Reading an approved supplier list may be routine. Exporting the complete vendor database, changing bank details, or sending a purchase order creates a different consequence. All four actions might occur through the same application. Tool-level permission treats them as equivalent. Resource-and-action authorization does not.

The authorization decision needs fresh context

A useful decision combines stable rules with current signals. Google’s model pairs static policy with dynamic controls and proposes enriching decisions with information about the user, expected work, target data, intended action, and available mitigations. It also describes challenges and containment measures that can be triggered when risk rises.

For an enterprise agent, the authorization service should be able to evaluate at least five questions:

1. Who is accountable for the task? Identify the user, service account, agent, active role, and delegated authority. A technically valid token is not the same as a valid business purpose.

2. What exact resource is involved? Resolve the target to a record, file, knowledge base, system object, or bounded dataset. Labels and ownership should travel with the resource.

3. What operation is requested? Distinguish read, search, summarize, copy, modify, delete, share, approve, and execute. Similar-looking actions can have very different consequences.

4. What has happened earlier in the session? A request may be acceptable in isolation but suspicious after unusual retrieval volume, repeated failures, a prompt-injection signal, or an unexpected change in task.

5. What safeguard can reduce the risk? The result need not be a simple allow or deny. The system can narrow the dataset, remove write access, require fresh authentication, request human approval, isolate the operation, or stop the session.

This is a policy decision, not a model opinion. The agent may provide context, but the enforcement point should apply deterministic organizational rules and record why access was granted, constrained, challenged, or denied.

Google DeepMind’s earlier AI-control work supports the need for this separation. Its framework treats advanced internal agents as potentially misaligned and combines monitoring with prevention and response. It also distinguishes lower-risk, reversible actions that may tolerate later review from high-risk actions that require real-time blocking. That is a useful design rule for regulated industries: authorization latency and review strength should rise with consequence and irreversibility.

Private AI makes the enforcement boundary visible

A private AI platform can keep models, data access, policy enforcement, and audit evidence within infrastructure controlled by the organization. A governed AI gateway can provide a consistent point for authentication, scoped model access, tool restrictions, and attribution. In a private enterprise workspace, project and knowledge-base boundaries can limit which context is available before an action is proposed.

On-premise AI does not make every authorization decision correct. Its architectural benefit is control over the full path. Security teams can connect identity, data classification, tool calls, policy versions, and audit records without relying on disconnected control planes. They can also disable external tools, contain an agent, or preserve evidence inside the enterprise boundary when a decision is challenged.

An action-level authorization checklist

Before an agent receives production credentials, test its permission model at the level where business consequences occur.

• Inventory actions, not just tools. List every read, write, share, delete, approve, and execute capability available through each integration.

• Map resources to owners and classifications. The policy engine needs dependable metadata for the records, files, datasets, and systems an agent may touch.

• Bind delegation to purpose and time. Define which user or process authorized the task, its permitted objective, and when that authority expires.

• Use progressive privilege. Begin with read-only, narrow-scope access. Add broader or irreversible actions only after the workflow demonstrates a need and passes evaluation.

• Reauthorize at high-impact boundaries. Require a new decision before external sharing, bulk access, sensitive changes, financial actions, or execution in production.

• Offer safer alternatives. Where possible, return filtered data, a preview, a draft, or a human-approval request instead of a hard failure.

• Log the decision evidence. Preserve the policy version, relevant context, requested resource and action, outcome, and reviewer intervention without retaining unnecessary sensitive payloads.

• Exercise containment. Simulate compromised credentials, prompt injection, unexpected tool sequences, and policy-service failure. Confirm that the agent fails closed where impact is high.

NIST’s AI Risk Management Framework organizes risk work around governance, mapping, measurement, and management. Action-level records make those activities concrete: teams can measure which requests were allowed, challenged, denied, overridden, or later found inappropriate, then improve policy based on observed behavior.

Conclusion

AI agents turn access into a rapid sequence of decisions. The safest unit of control is therefore not the application, connector, or session. It is the action on a specific resource, evaluated with current context and an enforceable policy. Organizations that build this layer early can give agents useful access while preserving the ability to narrow, challenge, explain, and stop what they do.

Author

Author: Ivan Martinez Toro, Co-Founder & Co-CEO at Zylon
Published: July 29, 2026
Ivan leads private, on-premise AI deployments for regulated industries, helping financial institutions, healthcare organizations, and government entities implement secure, sovereign enterprise AI infrastructure.

Sources

• Google, “Going Beyond Zero: A New Paradigm For Enterprise Security”

• Google DeepMind, “Securing the future of AI agents”

• NIST, “Zero Trust Architecture,” SP 800-207

• NIST, “Artificial Intelligence Risk Management Framework (AI RMF 1.0)”