Apply Now!
← Back to Blog

Your AI Agent Has a Permission Problem

Dhaval Bhatt
A glowing AI worker moving through transparent permission gates toward a network of connected business tools

The next bottleneck in AI products is not intelligence.

It is permission.

On July 7, Google expanded Managed Agents in the Gemini API with background execution, remote MCP connections, custom functions, and credential refresh. The release lets an agent keep working across longer tasks, connect to external systems, and continue inside the same environment after an access token changes.

That sounds like infrastructure. For a founder, it is a product warning.

The moment your agent can read a customer database, update a project board, send a message, or change a record, you are no longer designing only a workflow. You are designing who can do what, with which data, under whose authority, and with what evidence afterward.

A strong prompt cannot answer those questions for you.

Every useful tool creates a trust decision

A demo agent can work from a sample file. A real product needs access to the systems where the work already happens.

That may include:

  • customer records;
  • email and calendars;
  • shared drives;
  • billing or inventory systems;
  • internal knowledge bases;
  • industry-specific databases;
  • tools that can publish, send, delete, or approve.

Each connection creates two separate capabilities: reading information and changing something.

Founders often bundle them together. They should not.

Imagine you know commercial construction. You build an agent that reviews daily site reports, detects schedule risks, and prepares follow-up tasks. Reading a report is low consequence. Drafting a task is reversible. Assigning that task to a subcontractor changes someone’s work. Sending a delay notice could create a contractual issue.

The model may use the same reasoning across all four steps. The permission policy should treat them differently.

Your domain experience tells you where observation ends and consequence begins. That line is part of your product design.

Start with the smallest useful permission set

The Model Context Protocol, or MCP, is becoming a common way for AI applications to connect with tools and data. Its authorization guidance follows the principle of least privilege: request the scopes required for the resource, rather than asking for broad access by default.

You do not need to become an OAuth expert to use that principle.

For your first version, create a simple permission map with four columns:

  1. Resource: What system or data does the agent need?
  2. Action: Does it need to read, create, edit, send, or delete?
  3. Boundary: Which account, folder, project, customer, or record is in scope?
  4. Approval: Can the action run automatically, or must a person confirm it?

Then remove anything the first customer outcome does not require.

If the agent summarizes support tickets, do not give it permission to close tickets. If it prepares a renewal brief, do not give it access to every customer folder. If it drafts outreach, do not let it send until the workflow has earned trust.

Broad access makes a prototype feel powerful. Narrow access makes a product easier to trust, test, and sell.

Approval should depend on the action

OpenAI’s current guidance for connectors and remote MCP servers defaults to requesting approval before data is shared with an external tool. Developers can restrict which tools are available and decide which calls still require approval.

That is a useful product pattern: approve the consequential action, not every small step.

If the user must approve every search, lookup, and calculation, the agent becomes tedious. If the agent can take every action without review, one wrong assumption can become a real operational mistake.

A better policy might look like this:

  • Automatic: search approved sources, classify documents, calculate routine fields, prepare drafts;
  • Review when uncertain: flag missing information, conflicting evidence, or an exception outside known rules;
  • Always approve: send messages, publish content, change a system of record, delete data, commit money, or create an external obligation.

The exact boundary changes by industry. A marketing founder and a healthcare founder should not use the same approval policy.

This is where a domain expert has an advantage. You already know which “small” action can create a large downstream problem.

Credentials expire, people leave, and access changes

Google’s new managed-agent capability includes network credential refresh because access tokens and short-lived API keys expire. Its implementation can replace network rules while preserving the agent’s environment, files, and installed packages.

The practical lesson is bigger than token rotation.

Access is temporary.

A customer disconnects an integration. An employee changes roles. A project ends. A vendor key is rotated. A user revokes consent. Your agent must stop using the old authority without losing the work it already completed.

Design for these moments before launch:

  • What happens when a credential expires halfway through a job?
  • Can the user reconnect without restarting the entire workflow?
  • Does revoked access stop future tool calls immediately?
  • Can an administrator see which integrations are active?
  • Can the customer remove one connection without deleting the account?
  • Does the audit trail show which user authorized the action?

The forthcoming July 28 MCP specification is hardening authorization around real OAuth and OpenID Connect deployments, including issuer validation, credential binding, scope handling, and refresh-token guidance. That direction is a signal: agent access is becoming a first-class production concern, not a detail to hide behind the prompt.

Build the permission prototype before the autonomous agent

Before you add another tool, create one page that explains the agent’s authority in plain language.

Show the customer:

  • what the agent can access;
  • what it can only read;
  • what it can change;
  • which actions require approval;
  • how to disconnect a system;
  • where completed actions are recorded.

Then test that page with someone who actually does the job.

Ask one question: Would you let this run on a real account?

If the answer is no, a better model will not fix the product. You need a narrower scope, a clearer approval point, or stronger visibility into what the agent is doing.

The opportunity for domain-expert founders is not to build the most autonomous agent. It is to build the most useful agent a customer can confidently authorize.

That requires technical controls. But it begins with process knowledge: knowing which information matters, which actions are reversible, which exceptions require judgment, and where a human must remain accountable.

If you want help turning the workflow you know into a focused AI product with clear trust boundaries, book a strategy call. That is what we build inside the AI Product Accelerator.

Sources: Google, “Expanding Managed Agents in Gemini API” (July 7, 2026); Model Context Protocol, “The 2026-07-28 MCP Specification Release Candidate”; OpenAI Developers, “MCP and Connectors”.