Inside the Gemini factory.

By Abdullah Malik | Published:

Topics: Agentic AI, AI Governance, Tool Execution, Planner/Orchestrator Routing, Scoped Rbac And Least-Privilege Tool Execution Tokens, Deterministic Policy Guardrails And State Checkpoints

The promise of a "unified Gemini experience" where third-party partners and internal skills are wired directly into a single model runtime is an architectural s...

The promise of a "unified Gemini experience" where third-party partners and internal skills are wired directly into a single model runtime is an architectural siren song. Google Cloud’s recent push toward standardized connectors, Model Context Protocol (MCP), and REST-based plugins promises to flatten the distance between a high-level executive query and a back-office execution. For the enterprise leader, this sounds like efficiency. For the Chief Information Security Officer, it sounds like an unmitigated disaster in the making.

We are entering an era where the primary bottleneck is no longer the model’s reasoning capability, but our ability to govern the actions that reasoning triggers. If an agent has the "skill" to update a Salesforce record or trigger a wire transfer, we are no longer just managing a chatbot. We are managing a probabilistic employee with potentially infinite velocity and no inherent sense of corporate policy.

The Fatal Flaw of Integrated Agency

The current industry momentum favors tight integration between the reasoning engine and the execution tool. In my view, this is a fundamental category error. When we allow a foundation model to both plan a sequence of actions and then execute those actions using its own generated logic, we are trusting a probabilistic system to police itself. This violates the first principle of enterprise security: the separation of duties.

The technical mechanism often used here is the ReAct pattern. Research shows that interleaving reasoning traces with external tool actions significantly reduces hallucination and improves task success rates by up to 34% in specific benchmarks (Yao et al., 2023). While this synergy is excellent for "thinking," it creates a massive vulnerability when that same reasoning trace is the only thing authorizing an API call.

The danger lies in "excessive agency," a primary vulnerability where LLMs are granted broad permissions to act on behalf of users without sufficient deterministic checks (OWASP Foundation, 2025). If the model "reasons" that it needs to access a sensitive HR database to answer a payroll query, and it possesses the connector to do so, a simple prompt injection can turn a helpful assistant into an inadvertent internal threat.

Decoupling the Planner from the Policeman

To move from pilot projects to production reality, we must strictly decouple probabilistic planning from deterministic execution. The planner (the LLM), should be responsible for suggesting a path forward. The executor (the enterprise middleware), must be responsible for validating that path against hardcoded, immutable policy.

This architecture requires a "church and state" separation between the orchestrator and the tool runtime. In their research on prompt flow integrity, authors found that LLM agent behavior is determined at runtime by natural language, which necessitates specific controls to prevent privilege escalation (Juhee et al., 2025). We cannot rely on the model to "remember" it shouldn't access a specific table. We must ensure the execution token it holds literally cannot see that table.

This is where the concept of "scoped execution tokens" becomes critical. Instead of giving an agent a broad API key for a system like SAP or Workday, the orchestrator should issue a short-lived, least-privilege token that is restricted to the specific task at hand. This mimics the patterns we see in mobile operating systems. Just as security flaws in Android communication options like broadcast receivers and intents can allow hidden privilege escalation, inter-agent communication (A2A), in an enterprise environment risks similar lateral movement if not strictly governed (El-Zawawy & Hamdy, 2025).

Architecture for the Trustworthy Agent

A robust enterprise agentic architecture requires three distinct layers that never overlap in their responsibilities.

  1. The Probabilistic Planner: Here, the LLM lives. It uses Retrieval-Augmented Generation (RAG), to ground its plans in non-parametric memory, ensuring that its decision-making is based on up-to-date business facts rather than outdated weights (Lewis et al., 2020).
  2. The Deterministic Guardrail: This layer intercepts the plan. It checks the proposed action against a Role-Based Access Control (RBAC), matrix. If the agent suggests "Delete Record," but the user initiating the query only has "Read" permissions, the guardrail kills the execution before it reaches the API.
  3. The Sandboxed Executor: The actual tool execution should occur in a dedicated secure compute environment. This pattern, championed in production-grade multi-agent services, uses managed identity delegation to ensure that every action is tied back to a verifiable human or service principal (Microsoft Corporation, 2024).

Apparently, we spent decades building enterprise firewalls only to consider giving a probabilistic text generator "write" access to the global ledger because it wrote a very convincing five-step plan. This is the architectural absurdity we must solve.

Our Agent Governance Framework: The Autonomy & Enforcement Matrix

Use this matrix to determine the required governance depth for any proposed agentic workflow.

image

Moving Toward Managed Trust

I think the biggest mistake organizations make is treating AI governance as a "checkbox" at the end of the development cycle rather than a core architectural requirement. The National Institute of Standards and Technology (NIST), suggests that organizations must incorporate trustworthiness considerations directly into the design and evaluation of generative AI systems, rather than treating them as an afterthought (National Institute of Standards and Technology, 2024).

To implement this practically, start with these three steps:

1) Implement a Middleware Policy Proxy

Never connect an LLM directly to a production API. Insert a deterministic middleware layer that receives the agent's "request," validates the user's RBAC status, and only then fetches the data or executes the change. This creates an immutable execution audit trail that is independent of the model's own logs.

2) Standardize on Scoped Tool Tokens

Move away from long-lived service accounts. Use OIDC-based identity delegation where the agent receives a token that expires after ten minutes and is restricted to specific endpoints. If the agent is hijacked via prompt injection, the "blast radius" is limited to that narrow scope.

3) Define Human-in-the-Loop State Checkpoints

Identify "irreversible state changes", such as deleting a customer record, changing pricing, or authorizing a payment. These must require a deterministic human escalation trigger. No amount of "interleaved reasoning" (Yao et al., 2023) should ever be a substitute for a human supervisor's digital signature on a high-stakes transaction.

The "unified Gemini experience" is a powerful vision for user productivity. However, in the enterprise, "unified" must not mean "unprotected." By decoupling the plan from the execution, we can enjoy the speed of agentic automation without handing the keys to the kingdom over to a system that doesn't actually understand what a "key" or a "kingdom" is.

References