Skip to main content
Three catalog agents investigate incidents inside a cloud account: AWS Infrastructure Investigator, Azure Investigator, and Google Cloud Investigator. Each takes an incident description and the questions you want answered, reads that provider’s own evidence, and returns structured findings that cite what they are based on. All three are strictly read-only. None of them has a mutating tool in any deployment mode, so none can stop a resource, change a policy, or roll anything back — turning a finding into an action is Remediation Executor’s job.

​
AWS Infrastructure Investigator

Traces root causes through configuration changes, access-control layers and resource dependencies, citing the CloudTrail event, metric or policy behind each claim. Before you deploy — model access, plus AWS access unless the pod supplies its own identity. The AWS connection offers two authentication modes, and which you see depends on where the agent runs:
The AWS connection is optional because IRSA replaces it. Deployed self-hosted with a ServiceAccount that already carries the role, the agent needs no connection at all.
A connection is validated as configuration, not as working AWS access. A well-formed role ARN with insufficient permissions deploys cleanly and fails on the first run — read that run rather than treating a successful deploy as proof.
Where it stops. It sees only what its credentials reach. An investigation scoped to one account cannot observe a cause living in another, and it reports the gap rather than inferring across it.

​
Azure Investigator

Locates the affected resources, reads their metrics and logs, and correlates what it finds into findings that each carry a portal deeplink — so the evidence can be opened rather than taken on trust. The five capabilities above were measured against a plain Reader role rather than assumed from documentation. Before you deploy — model access, and an Azure connection with read-only access across those five capabilities.
Unlike the Datadog and Grafana investigators, this agent has no MCP Gateway path. Azure publishes no hosted MCP endpoint, so there is no remote server to bind and no group to pick — its Azure tooling runs alongside it, configured from the connection you select.
Where it stops. One subscription’s worth of evidence, bounded by what the connection’s role permits. Where a capability is not granted, it reports the gap instead of inferring around it.

​
Google Cloud Investigator

Narrows the log stream structurally — by resource, log name and severity rather than 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, so a conclusion can be reproduced by running the same query yourself. Before you deploy — model access, a Google Cloud connection with read-only Cloud Logging access for the project the service-account key belongs to, and an integration group, because the agent reaches Cloud Logging through a group-scoped gateway endpoint.
The connection is required rather than optional: the gateway is this agent’s only path. No alternative tooling is bundled alongside it, so without a connection it has no tools at all.
Where it stops. It reads nothing outside Cloud Logging — metrics, traces, resource configuration and billing are all out of reach, and 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 scoped to the single project its service-account key belongs to.

​
Next steps

Agent catalog

Every deployable agent, and what each one is for.

Integrations list

Connecting AWS, Azure and Google Cloud.

Use specialized agents

Deploying a catalog agent and what you can change afterwards.

Remediation Executor

Turning a finding into an action, with approval.