> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Google Cloud Investigator

> Investigates a Google Cloud project through Cloud Logging — pinning the earliest failing entry and correlating it against the audit log.

Deploy this agent when the evidence for an incident is in Google Cloud Logging and you want it
narrowed structurally rather than by keyword guessing. It is deliberately scoped to one data source,
which makes what it can and cannot answer unusually clear. This page covers that scope, what to
connect first, and where it stops.

## What it does

You give it an incident description and the questions you want answered. It narrows the log stream
structurally — by resource, log name and severity rather than by free-text search — pins the
earliest failing entry, and correlates it against the audit log to find the change that preceded it.

Findings cite the exact filter and time window behind each claim, so a conclusion can be reproduced
by running the same query yourself.

## What it reads

Read-only, and one source.

| Source           | What it uses it for                                              |
| ---------------- | ---------------------------------------------------------------- |
| Cloud Logging    | The failing entries, narrowed by resource, log name and severity |
| Cloud audit logs | The change that preceded the first failure                       |

## Before you deploy

| Requirement             | Detail                                                                            | Where to set it up                                                       |
| ----------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Model access            | The managed model gateway, or your own Claude API key                             | [Credentials & secrets](/manage-your-agents/build/credentials-secrets)   |
| Google Cloud connection | Read-only Cloud Logging access for the project the service-account key belongs to | [Built-in integrations](/manage-your-agents/build/built-in-integrations) |
| MCP group               | The agent reaches Cloud Logging through a group-scoped gateway endpoint           | [Integration groups](/manage-your-agents/build/integration-groups)       |

<Note>
  The connection is required rather than optional, because the gateway is this agent's only path.
  There is no alternative tooling bundled alongside it, so without a connection it has no tools at
  all.
</Note>

## Ask it for

In chat, or as a run's prompt:

```text theme={null}
Something started failing in project acme-prod around 03:40 UTC. Find the earliest
failing log entry, tell me which resource it belongs to, and check the audit log for
what changed just before it. Give me the filters you used.
```

When a workflow drives it instead of a person, it takes the same structured envelope the other
investigators take — `incident_description`, `questions`, `affected_services`,
`investigation_start`, `context` and `budget_seconds`.

## Defaults and limits

|             |                                          |
| ----------- | ---------------------------------------- |
| Catalog ID  | `gcp-investigator`                       |
| Model       | `claude-sonnet-4-6`                      |
| Time budget | 600 seconds, adjustable 120–1800 per run |
| Deployment  | Komodor cloud                            |
| Chat        | Yes                                      |

The time budget degrades rather than fails. At 70% the agent is nudged to converge; at 100% further
tool calls are refused and it reports what it has.

## In a workflow

This is a specialist with a narrow surface, which makes it a good first step rather than a sole one:
it establishes when the failure started and what changed around it, and an orchestrator takes that
timestamp to the specialists that hold the rest of the picture.

See [Orchestration](/manage-your-agents/run/orchestration) for how a step delivers work to it.

## What it will not do

It never writes to Google Cloud, and it reads nothing outside Cloud Logging. Metrics, traces,
resource configuration and billing are all outside its reach — so where a cause lives in one of
those, it establishes the timeline and says plainly that the rest is not something it can see.

It is also scoped to the single project its service-account key belongs to.

## Next steps

<CardGroup cols={2}>
  <Card title="Integration groups" href="/manage-your-agents/build/integration-groups">
    Scope the gateway tools this agent is given.
  </Card>

  <Card title="AWS Infrastructure Investigator" href="/manage-your-agents/build/catalog/aws-investigator">
    A broader cloud investigation, over AWS.
  </Card>

  <Card title="Runs & evidence" href="/manage-your-agents/run/runs-evidence">
    Read the queries behind a finding.
  </Card>

  <Card title="Agent catalog" href="/manage-your-agents/build/catalog/overview">
    Every catalog agent, side by side.
  </Card>
</CardGroup>


## Related topics

- [Agent catalog](/manage-your-agents/build/catalog/overview.md)
- [Use specialized agents](/manage-your-agents/build/use-specialized-agents.md)
- [Built-in integrations](/manage-your-agents/build/built-in-integrations.md)
- [Grafana Investigator](/manage-your-agents/build/catalog/grafana-investigator.md)
- [AWS Infrastructure Investigator](/manage-your-agents/build/catalog/aws-investigator.md)