AI Agents Do Not Need More Access. They Need Contextual Authority.

AI Agents Are the Ultimate Insiders

An employee needs credentials to read email, query a database, access customer records or trigger a payment. An AI agent needs the same access if it is expected to complete real work.

That is the promise and the risk.

In its new State of AI Infrastructure analysis, Google Cloud says 79% of technology leaders identify security, governance or operations as their most significant challenge to scaling AI inference. Thirty-five percent of senior IT decision-makers cite insufficient security for multi-system access as a primary obstacle to deploying agents.

Google is a platform vendor promoting a full-stack answer, so its preferred solution should not be treated as neutral. The underlying problem is independently credible: OWASP documents emerging agentic threats, and the NIST AI Risk Management Framework requires governance to continue through design, deployment, measurement and management.

Identity Is Necessary but Not Sufficient

Giving every agent a unique non-human identity is a good start. It lets security teams attribute actions, revoke credentials and audit behaviour.

But identity does not answer the harder question:

What is this agent allowed to do right now, for this task, with this data, on behalf of this person?

That is contextual authority.

A customer-support agent may be allowed to read an order and draft a refund, but not approve a £10,000 payment. A campaign agent may edit bids inside an agreed range, but not create a new destination URL or change consent logic. A research agent may read public documents, but not export confidential CRM data into an external model.

Static role-based access was designed for relatively predictable human responsibilities. Agents can plan, branch, call multiple tools and respond to untrusted data. Their legitimate authority changes with context.

The Agentic Threat Model Is Operational

Google highlights tool poisoning and indirect prompt injection. In both cases, an attacker manipulates information or a tool description that an agent treats as instruction.

The important difference from a chatbot error is consequence. A chatbot may produce a bad answer. An agent may act on it.

Our earlier analysis asked whether an enterprise can stop an agent once it starts doing the wrong thing [blocked]. Contextual authority reduces the probability and radius of failure; killability limits the duration.

Governance Must Sit in the Execution Path

A governance policy in a slide deck cannot stop an API call. Effective controls must sit between the agent's plan and the action.

For high-impact workflows, the execution path should include:

1. Agent identity: a unique, revocable non-human identity.
2. Task context: the user, objective, environment and data classification.
3. Policy decision: whether the requested tool and action are permitted.
4. Constrained execution: limits on value, volume, time and destination.
5. Human approval: required when risk exceeds a defined threshold.
6. Audit and interruption: complete logs, anomaly detection and a tested stop mechanism.

This is why multi-agent conflicts [blocked] are not solved by checking whether each agent is individually authorised. Two agents can both have valid access while pursuing contradictory objectives.

Google's Full-Stack Answer and the Lock-In Question

Google says 69% of surveyed executives rate a full-stack platform as critical and 80% say data compliance is the primary factor determining the choice. Integrated control planes can improve visibility and reduce policy fragmentation.

They can also concentrate operational dependency in one vendor.

Enterprises should evaluate portability before adopting a platform answer:

• Can agent identities and policies move across model providers?
• Are audit logs exportable in a usable format?
• Can tool permissions be enforced outside the vendor's orchestration layer?
• Is the human-approval service independent of the agent runtime?
• Can security teams revoke access centrally during an incident?

The goal is unified governance without becoming unable to govern outside one ecosystem.

Modi's PoV: Replace "More Access" With "Enough Authority"

Most agent prototypes fail commercially because they sit at one of two extremes.

The first has too little access and cannot complete useful work. The second has broad standing access and creates unacceptable risk.

Contextual authority is the middle path. The agent receives enough authority to complete a bounded objective, then loses that authority when the task, time window or risk context changes.

For marketing agents, that might mean:

• Read performance data but not export raw personal information.
• Adjust campaign bids inside a defined percentage range.
• Draft ads but require approval before publishing regulated claims.
• Update a CRM record but not delete accounts.
• Pause spend when anomaly thresholds are exceeded.

Our Agentic AI service [blocked] starts with the decision boundary and permission model, not the demo. If you want to experience a general-purpose autonomous agent before designing a production workflow, try Manus with this referral link and use the experience to document which actions you would never permit without approval.

A Minimum Viable Agent-Control Standard

Before moving an agent from pilot to production, require a named owner, defined business objective, unique identity, least-privilege tool access, short-lived credentials, classified data boundaries, action limits, human approval thresholds, observable logs, incident procedures and a tested kill switch.

Then review the authority whenever the model, tool, data source or workflow changes.

The safest useful agent is not the one with the most access. It is the one whose authority expands and contracts with legitimate context.