Back to Archive

GCP News - 2026-10-27

2026-10-27
最終更新: 2026-10-27 01:30:33 JST

Google Cloud Blog

Scale agents securely with IAM Helper Agent Skills and MCP Tools

詳細を表示

As organizations adopt autonomous agents to build applications, securing identities and access has become more challenging. Developers relying on agents to provision cloud resources, write Terraform, and deploy microservices at machine-speed only find their CI/CD pipelines blocked even faster as security friction scales.  

To help you get ahead of agentic-era Identity and Access Management, today we’re introducing IAM Helper. This suite of intelligent, agent-facing building blocks can automate complex, end-to-end IAM workflows. 

As an agent-native orchestration and interface layer for Google Cloud IAM, it augments Google Cloud’s core IAM engines — including Policy Intelligence and Privileged Access Manager (PAM) — making IAM skills callable directly by autonomous code assistants, deployment pipelines, and custom agents. Using this functionality reduces the administrative overhead of maintaining least-privilege security and agent governance, while maximizing utility, and accelerating deployment.

IAM Helper Agent Skills: Fast, secure deployment with automated governance

Manual troubleshooting of permission blockers creates friction for engineering and administrators, while shortcuts can lead to broad agent over-permissioning that puts least privilege at risk. 

IAM Helper empowers agents to handle access management dynamically. It shifts the burden of policy evaluation away from human administrators and LLMs, offloading complex orchestration directly to the Google Cloud backend, to maximize token efficiency and prevent costly operational bottlenecks.

Rather than operating as isolated utilities, IAM Helper Agent Skills guide agents through the cloud access lifecycle. These end-to-end workflows, helper scripts, and guardrails packaged using the open Agent Skills standard can orchestrate multiple underlying functions and APIs to resolve complex IAM tasks. They work across common agents (Gemini CLI, Gemini Cloud Assist, ADK, Claude Code, and Cursor). 

Built-in guardrails and real-world impact

Every IAM Helper agent skill separates read-only discovery from policy changes: Diagnostics and simulations run automatically, while any change to access policies pauses for human-in-the-loop (HITL) confirmation based on customizable risk tiers. To see the value of IAM Helper in practice, consider how it transforms two everyday scenarios:

  • Scaled user-assisted remediation: Suppose a developer's coding agent hits a 403 error while deploying a new application. Rather than filing a support ticket and idling, the agent uses iam-helper-for-troubleshooting to identify the missing Pub/Sub permission in seconds, then uses iam-helper-for-privileged-access-management to request a one-hour JIT grant, eliminating hours of debugging friction.

  • Autonomous pipeline self-healing: An infrastructure agent encounters a permission block during a routine deployment pipeline. Rather than failing the build, the pipeline uses IAM Helper Agent skills to generate a revised, least-privilege policy, verifies against 90 days of logs via iam-helper-for-policy-simulator that active services won't break, and routes the change to an admin for quick approval.

IAM Helper Agent Skills are designed for maximum token and cost efficiency, allowing agents to execute multi-step administrative operations autonomously.

  1. Authoring compliant, least-privilege policies: As DevOps engineers translate access requirements into JSON, YAML, or Terraform HCL, iam-helper-for-policy-management generates and validates IAM v1 allow bindings and IAM v2 deny rules. It automatically catches and blocks risky configs before they are applied, including public access (allUsers) and broad basic roles (roles/owner, roles/editor).

  2. Unblocking 403 errors in seconds: When an on-call engineer or deployment agent hits a cryptic 403 PERMISSION_DENIED error, iam-helper-for-troubleshooting identifies the exact missing permission or blocking rule in seconds. It adapts to the user’s role: Developers can check if they can unblock themselves locally or generate a structured ticket for their administrator (Requester flow), while security administrators can trace inherited allow and v2 deny rules across organization, folder, and project hierarchies to resolve the issue (Resolver flow).

  3. Simulating blast radius before rolling out changes: Before a platform engineer updates a policy or applies IAM Recommender role reductions, they need confidence that active workloads won't break. iam-helper-for-policy-simulator walks the agent through a structured plan, simulate, analyze, and apply flow, testing proposed changes against 90 days of historical access logs to confirm existing traffic won't be disrupted before any update takes effect.

  4. Elevating access just-in-time instead of granting standing privileges: When responders or maintenance agents need temporary production access, iam-helper-for-privileged-access-management manages the lifecycle of on-demand credentials through Privileged Access Manager (PAM). It supports requester, administrator, and approver workflows so elevated access is audited, time-bound, and automatically revoked once the task is done.

While IAM Helper Agent Skills supply the high-level workflow logic, they are all based on a common set of foundational MCP Tools. 

Powered by Google Cloud IAM MCP tools

Google Cloud IAM Helper MCP tools provide the backend connection through atomic, read-only functions exposed via Google-managed MCP servers across core IAM endpoints (Policy Troubleshooter, Policy Analyzer, Policy Simulator, and IAM v1/v2 APIs). 

Rather than requiring teams to write custom API wrappers, MCP tools give agents a standard way to query the cloud backend and get exact answers without parsing verbose policy documents in the prompt, maximizing token efficiency. Agents can dynamically discover and invoke these tools to execute basic operations like checking permissions or listing roles when custom logic is required.

Because operations like hierarchy traversal, group expansion, and policy evaluation happen on dedicated IAM endpoints (spanning IAM v1 allow roles, IAM v2 deny, Policy Troubleshooter, and Policy Analyzer), skills run quickly and accurately with minimal token usage. Teams can also use these atomic MCP tools directly when writing their own custom Agent Skills, making it straightforward to combine Google Cloud's IAM capabilities with internal ticketing systems, custom compliance checks, and existing deployment pipelines.

Getting started

Accelerate your agentic workflows, reduce operational overhead, and bring intelligent, scalable security to your deployment pipelines. Start building with IAM Helper Agent skills today by exploring our Google Cloud Agent Skills Catalog and dive deeper with the official IAM documentation.

Unifying enterprise context and semantics: LookML in Knowledge Catalog is now GA

詳細を表示

As enterprises go from experimental AI agent prototypes to using them in production, data teams are realizing that access to data is not the same as understanding that data. To help bridge that gap, today, we are announcing the general availability (GA) of LookML semantic language indexing in Knowledge Catalog for Looker Core on Google Cloud.

To answer a complex business question accurately, an AI agent needs context — table schemas, data lineage, governance policies, business definitions, etc.. However, context is not a monolith; knowing where data lives is very different from knowing how to calculate metrics with it. In the enterprise, teams often conflate broad organizational context (usually in the form of metadata from structured and unstructured documents) with deterministic business semantics (the exact SQL formulas, join paths, and filtering rules that define metrics like net revenue or churn), assuming that a single data catalog or a business intelligence (BI) tool handling both enterprise-wide asset discovery and precise metric calculation.

In reality, no one tool can carry the entire load for agentic AI, as enterprise agents require both organizational context and deterministic business semantics. In Google Cloud environments, those are provided by Knowledge Catalog and LookML:

  • Broad enterprise context with Knowledge Catalog: Agents need a unified context graph that aggregates metadata across structured tables and unstructured documents. Through Knowledge Catalog, agents discover assets, inspect data quality, trace end-to-end lineage, respect column-level privacy tags, and surface corporate policy documents. The context graph tells an agent what data exists, how it is governed, and how it is connected.
  • Deterministic mathematical semantics with LookML: What a catalog does not author on its own is how the numbers are computed. Describing a table is not the same as defining how tables join or how metrics are calculated. Looker's modeling language, LookML, encodes production-tested semantic logic — multi-grain join protections, conditional filters, and exact KPI formulas — so agents don't guess SQL math at runtime.

With this native integration, the LookML business logic that powers your trusted BI reporting is automatically indexed into Knowledge Catalog — giving Gemini Enterprise and custom AI agents both enterprise-wide discovery and deterministic BI semantics.

Why a context graph needs deterministic semantics

When an LLM agent connects directly to raw database tables — even when armed with basic table descriptions or a business glossary — it still has to infer mathematical relationships on the fly. Without explicit semantic rules, agents routinely fall into two traps:

  1. Metric definition drift: Standard text-to-SQL agents can invent conflicting formulas for foundational KPIs like net revenue or customer acquisition cost, failing to apply domain-specific accounting rules (such as recognizing revenue only when order_status = 'Complete' or prorating annual contracts across active service days).
  2. Naive join fan-outs: Complex schemas often contain one-to-many (1:N) and zero-to-many (0:N) relationships across invoices, line items, and refunds. Without pre-modeled join relationships and symmetric aggregation rules, agent-generated SQL can multiply rows and inflate financial totals.

Knowledge Catalog and Looker solve this together, enabling you to model once in LookML and access those semantics everywhere across Google Cloud's AI ecosystem. Knowledge Catalog enforces semantic math when that logic is defined in a semantic modeling tool; LookML provides a mature, production-proven language for defining those exact mathematical relationships.

What's new: LookML in Knowledge Catalog

Previously, catalog integrations only captured shallow, file-level pointers and basic dashboard inventories. With this release, LookML's deterministic semantics become a first-class layer in the Knowledge Catalog context graph. An agent that finds a metric in the graph now also finds its exact definition, its join path, and its lineage back to source tables — in the same place, under the same governance. Synchronization is always on by default with no action required from end users, and with live sync, any update pushed to production LookML is reflected in Knowledge Catalog in near-real-time so agents operate on the freshest business logic.

Because this metadata is indexed directly into Knowledge Catalog by default, it is immediately available to Gemini Enterprise, without custom agent code or separate catalog data stores. When connected to Knowledge Catalog, Gemini Enterprise uses built-in read-only skills and hybrid search to look up technical schemas, business glossaries, and indexed LookML logic in a single step, passing that rich context directly to your federated BigQuery connector to generate accurate SQL. (For developers building custom agents, the same context bundles are also accessible via the LookupContext API.)

Knowledge Catalog now captures and links the following entity levels across Looker Core on Google Cloud:

  • LookML models (looker-model): Captures descriptive metadata, database connection routing, include hierarchies, data validation tests (assert), and parent-child EntryLinks mapping models to their associated Explores, Views, and LookML dashboards.
  • LookML Explores (looker-explore): Indexes full relational join logic (type, sql_on, relationship cardinality such as many_to_one fan-out protection, foreign_key, required_joins, and sql_where) as Schema-Join relationships. It also captures mandatory filter guardrails (always_filter, access_filter), inherited dimensions and measures, and predefined starter queries that help agents and analysts overcome the cold-start problem.
  • LookML Views and fields (looker-view): Extracts column-level compiled LookML SQL expressions (for example, ${total_revenue} / NULLIF(${count}, 0)), primary keys, dimension group timeframes, field synonyms, and derived table transformation logic (including SQL and native derived tables, partition keys, and cluster keys).
  • Dashboards, Looks, and tiles (looker-dashboard, looker-dashboard-element, looker-look): Catalogs both UI-created and LookML-defined dashboards and visualization tiles, complete with dashboard filters, chart types, ownership, and usage statistics. Users in Knowledge Catalog are able to see table- and column-level lineage from underlying BigQuery tables all the way to individual dashboard tiles, allowing data engineers to evaluate schema changes proactively, before disruptions occur.
<div class="article-module h-c-page">
  <div class="h-c-grid">


<figure class="article-image--large
  
  
    h-c-grid__col
    h-c-grid__col--6 h-c-grid__col--offset-3
    
    
  ">

  
  
    
    <img alt="1 - LookML Indexing in Knowledge Catalog" src="https://storage.googleapis.com/gweb-cloudblog-publish/original_images/1_-_LookML_Indexing_in_Knowledge_Catalog.gif" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>Looker Core on Google Cloud automatically indexes resolved LookML models, Explores, Views, lineage, and dashboards directly into Knowledge Catalog.</p></figcaption>
  
</figure>


  </div>
</div>

Three patterns for data agents

Bringing LookML into Knowledge Catalog gives Gemini Enterprise (and your broader agent ecosystem) a single place to retrieve both broad organizational context and governance from Knowledge Catalog and explicit mathematical relationships and SQL definitions authored in LookML.

To see the impact of combining these two layers in Gemini Enterprise, compare how three architectures handle a complex cross-domain prompt: "What was our total revenue last fiscal quarter by product category, and which regional promotional policy limits apply?"

Agent architecture System mechanics Data logic and governance resolution User experience and token efficiency

Pattern 1: Baseline database agent

Data warehouse only

 Direct LLM writing raw SQL against warehouse tables with no semantic or catalog context.

Ungoverned and non-deterministic

Has no visibility into data quality, PII tags, or corporate documents, and guesses SQL metric logic blindly — assuming a standard January fiscal calendar, summing uncompleted orders, and exposing restricted customer PII.

Fragile and high-risk

Prone to schema hallucinations, fails on questions requiring unstructured policy context, and burns tokens in multi-turn SQL debugging loops.

Pattern 2: Context-grounded agent

Knowledge Catalog without indexed semantics

 Gemini Enterprise or another agent platform uses Knowledge Catalog to look up table descriptions, glossary terms, PII governance aspects, and unstructured policy PDFs, then writes SQL via the warehouse connector.

Context-grounded, but lacks semantic SQL logic 

Enforces Knowledge Catalog governance and retrieves unstructured promotional policy rules, but lacks semantic definitions for SQL metrics and table relationships. This approach can miss conditional accounting rules (like order_status = 'Complete') or cause join fan-outs across multi-grain tables.

Governed discovery, inconsistent math

Solves asset discovery, compliance, and unstructured context, but still suffers from text-to-SQL calculation drift and multi-turn SQL retries.

Pattern 3: Context + semantic-grounded agent

Knowledge Catalog + Looker Core on Google Cloud with indexed LookML

 Gemini Enterprise or another agent platform connects to Knowledge Catalog enriched with indexed LookML metadata, automatically retrieving both broad catalog context and LookML join paths and field formulas to ground its SQL generation.

Governed context plus semantic SQL definitions

Enforces Knowledge Catalog PII aspects, retrieves unstructured policy PDFs, and grounds its SQL in LookML's exact mathematical definitions indexed in Knowledge Catalog, applying status = 'Complete', the May–July fiscal calendar, and predefined join conditions across warehouse tables.

Accurate and token-efficient: 

Pre-mapped LookML join blueprints and compiled SQL expressions replace guessing, prevent join fan-outs, reduce SQL retry loops, and let the agent point users to relevant Looker dashboards and Explores.

When you follow pattern 3 and pair Knowledge Catalog with Looker's semantic layer in an enterprise agent workflow, the agent moves from guessing at raw SQL to a governed, two-stage execution flow:

  1. Context and governance discovery in Knowledge Catalog: Before touching any data, the agent searches Knowledge Catalog, verifies that the thelook_ecommerce LookML model is gold-certified, checks column-level governance tags, and maps the prompt to exact LookML dimensions and measures, converting natural language into structured business intent.
  2. Deterministic semantic execution: Rather than having the LLM invent SQL on the fly, the agent grounds its SQL in LookML's exact mathematical definitions indexed in Knowledge Catalog and returns trusted, repeatable figures.

Alongside the answer, the agent returns an interactive Open in Looker Explore link with the exact measures and filters pre-populated, letting users slice, dice, and inspect row-level line items in a single click.

<div class="article-module h-c-page">
  <div class="h-c-grid">


<figure class="article-image--large
  
  
    h-c-grid__col
    h-c-grid__col--6 h-c-grid__col--offset-3
    
    
  ">

  
  
    
    <img alt="2 - Updated Image with Side By Side" src="https://storage.googleapis.com/gweb-cloudblog-publish/original_images/2_-_Updated_Image_with_Side_By_Side.gif" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>Side-by-side comparison of a baseline agent querying BigQuery directly (left), which guesses at raw SQL and fiscal dates, versus an agent governed by Knowledge Catalog and Looker (right), which applies indexed LookML definitions and returns an interactive "Open in Looker Explore" link.</p></figcaption>
  
</figure>


  </div>
</div>

Scaling agents for BI and the enterprise

A common question from data leaders is: "If we use Looker Conversational Analytics, when do we use an enterprise agent grounded in Knowledge Catalog?"

The two experiences are designed for complementary jobs across your organization:

  • Looker Conversational Analytics is your dedicated BI assistant: When business users are working inside BI workflows and asking questions scoped to a focused set of curated Looker Explores, Conversational Analytics delivers immediate, self-service data exploration and visualization directly within Looker.
  • Knowledge Catalog + Looker powers your enterprise-wide agents: When users ask questions in Gemini Enterprise across federated Data Cloud sources like BigQuery, they often span structured tables, BI metrics, and unstructured documents. Enabling Knowledge Catalog in Gemini Enterprise gives the assistant built-in skills to dynamically discover relevant semantics across hundreds of LookML models, pass indexed LookML join definitions, metric SQL formulas, and starter queries to the BigQuery connector to prevent join hallucinations, and enforce centralized governance aspects and IAM.

Getting started

Because Looker Core on Google Cloud, Knowledge Catalog, and Gemini Enterprise are natively integrated, you can connect your existing LookML business logic to your enterprise AI assistant in just a few clicks, with no custom agent code required.

To start discovering Looker semantics and grounding your agents:

  1. Confirm first-party metadata indexing is enabled for Looker Core on Google Cloud. This is enabled by default for new instances, with no additional charge for storing Looker technical metadata. Once enabled, metadata synchronization into Knowledge Catalog is always on by default (across both initial indexing and ongoing live updates). Enable the Cloud Dataplex API and Data Lineage API in your project and grant users the required view roles (roles/dataplex.viewer, roles/looker.schemaViewer, and roles/datalineage.viewer) to have your resolved LookML models, Explores, Views, join paths, and dashboards automatically sync into Knowledge Catalog.
  2. Enable Knowledge Catalog in Gemini Enterprise. When you attach a BigQuery (or Spanner, Cloud SQL, or AlloyDB) data store in federated query mode to your Gemini Enterprise app, the Knowledge Catalog integration is enabled automatically. You can also turn it on or off at any time in the Google Cloud console by opening your Gemini Enterprise app, navigating to Configurations > Assistant, toggling on Enable Knowledge Catalog, and clicking Save and publish.
  3. Ask questions. Gemini Enterprise connects to Knowledge Catalog using end-user credentials, meaning users only discover and query data assets they have IAM permission to view (such as roles/bigquery.dataViewer). Behind the scenes, the assistant automatically looks up your indexed LookML definitions, join logic, and starter queries in Knowledge Catalog and passes them to your federated connector to deliver accurate, governed answers.

To dive deeper, read the Manage Looker Core on Google Cloud with Knowledge Catalog documentation and learn how to Connect to Knowledge Catalog in Gemini Enterprise. To build a more customized experience, explore our hands-on ADK agent codelab on GitHub.

Google Cloud Blog (AI & ML)

Scale agents securely with IAM Helper Agent Skills and MCP Tools

詳細を表示

As organizations adopt autonomous agents to build applications, securing identities and access has become more challenging. Developers relying on agents to provision cloud resources, write Terraform, and deploy microservices at machine-speed only find their CI/CD pipelines blocked even faster as security friction scales.  

To help you get ahead of agentic-era Identity and Access Management, today we’re introducing IAM Helper. This suite of intelligent, agent-facing building blocks can automate complex, end-to-end IAM workflows. 

As an agent-native orchestration and interface layer for Google Cloud IAM, it augments Google Cloud’s core IAM engines — including Policy Intelligence and Privileged Access Manager (PAM) — making IAM skills callable directly by autonomous code assistants, deployment pipelines, and custom agents. Using this functionality reduces the administrative overhead of maintaining least-privilege security and agent governance, while maximizing utility, and accelerating deployment.

IAM Helper Agent Skills: Fast, secure deployment with automated governance

Manual troubleshooting of permission blockers creates friction for engineering and administrators, while shortcuts can lead to broad agent over-permissioning that puts least privilege at risk. 

IAM Helper empowers agents to handle access management dynamically. It shifts the burden of policy evaluation away from human administrators and LLMs, offloading complex orchestration directly to the Google Cloud backend, to maximize token efficiency and prevent costly operational bottlenecks.

Rather than operating as isolated utilities, IAM Helper Agent Skills guide agents through the cloud access lifecycle. These end-to-end workflows, helper scripts, and guardrails packaged using the open Agent Skills standard can orchestrate multiple underlying functions and APIs to resolve complex IAM tasks. They work across common agents (Gemini CLI, Gemini Cloud Assist, ADK, Claude Code, and Cursor). 

Built-in guardrails and real-world impact

Every IAM Helper agent skill separates read-only discovery from policy changes: Diagnostics and simulations run automatically, while any change to access policies pauses for human-in-the-loop (HITL) confirmation based on customizable risk tiers. To see the value of IAM Helper in practice, consider how it transforms two everyday scenarios:

  • Scaled user-assisted remediation: Suppose a developer's coding agent hits a 403 error while deploying a new application. Rather than filing a support ticket and idling, the agent uses iam-helper-for-troubleshooting to identify the missing Pub/Sub permission in seconds, then uses iam-helper-for-privileged-access-management to request a one-hour JIT grant, eliminating hours of debugging friction.

  • Autonomous pipeline self-healing: An infrastructure agent encounters a permission block during a routine deployment pipeline. Rather than failing the build, the pipeline uses IAM Helper Agent skills to generate a revised, least-privilege policy, verifies against 90 days of logs via iam-helper-for-policy-simulator that active services won't break, and routes the change to an admin for quick approval.

IAM Helper Agent Skills are designed for maximum token and cost efficiency, allowing agents to execute multi-step administrative operations autonomously.

  1. Authoring compliant, least-privilege policies: As DevOps engineers translate access requirements into JSON, YAML, or Terraform HCL, iam-helper-for-policy-management generates and validates IAM v1 allow bindings and IAM v2 deny rules. It automatically catches and blocks risky configs before they are applied, including public access (allUsers) and broad basic roles (roles/owner, roles/editor).

  2. Unblocking 403 errors in seconds: When an on-call engineer or deployment agent hits a cryptic 403 PERMISSION_DENIED error, iam-helper-for-troubleshooting identifies the exact missing permission or blocking rule in seconds. It adapts to the user’s role: Developers can check if they can unblock themselves locally or generate a structured ticket for their administrator (Requester flow), while security administrators can trace inherited allow and v2 deny rules across organization, folder, and project hierarchies to resolve the issue (Resolver flow).

  3. Simulating blast radius before rolling out changes: Before a platform engineer updates a policy or applies IAM Recommender role reductions, they need confidence that active workloads won't break. iam-helper-for-policy-simulator walks the agent through a structured plan, simulate, analyze, and apply flow, testing proposed changes against 90 days of historical access logs to confirm existing traffic won't be disrupted before any update takes effect.

  4. Elevating access just-in-time instead of granting standing privileges: When responders or maintenance agents need temporary production access, iam-helper-for-privileged-access-management manages the lifecycle of on-demand credentials through Privileged Access Manager (PAM). It supports requester, administrator, and approver workflows so elevated access is audited, time-bound, and automatically revoked once the task is done.

While IAM Helper Agent Skills supply the high-level workflow logic, they are all based on a common set of foundational MCP Tools. 

Powered by Google Cloud IAM MCP tools

Google Cloud IAM Helper MCP tools provide the backend connection through atomic, read-only functions exposed via Google-managed MCP servers across core IAM endpoints (Policy Troubleshooter, Policy Analyzer, Policy Simulator, and IAM v1/v2 APIs). 

Rather than requiring teams to write custom API wrappers, MCP tools give agents a standard way to query the cloud backend and get exact answers without parsing verbose policy documents in the prompt, maximizing token efficiency. Agents can dynamically discover and invoke these tools to execute basic operations like checking permissions or listing roles when custom logic is required.

Because operations like hierarchy traversal, group expansion, and policy evaluation happen on dedicated IAM endpoints (spanning IAM v1 allow roles, IAM v2 deny, Policy Troubleshooter, and Policy Analyzer), skills run quickly and accurately with minimal token usage. Teams can also use these atomic MCP tools directly when writing their own custom Agent Skills, making it straightforward to combine Google Cloud's IAM capabilities with internal ticketing systems, custom compliance checks, and existing deployment pipelines.

Getting started

Accelerate your agentic workflows, reduce operational overhead, and bring intelligent, scalable security to your deployment pipelines. Start building with IAM Helper Agent skills today by exploring our Google Cloud Agent Skills Catalog and dive deeper with the official IAM documentation.

前日
Archive