A critical service alert fired. What changed, what is affected, and what can be safely remediated?
Pull recent changes, service health, logs, ownership, related findings, and runtime facts into one case before deciding who acts and what is safe.
Capability
Investigate
Turn an operational question or configuration intent into a target-bound case with API operation discovery, bounded evidence, repository context, a current summary, and a guarded next action.
Case workspace
Targeted source selection
Evidence timeline
Hypotheses and narrated method
Operational need
Infrastructure and security teams need one place to understand what changed, what is affected, what is still uncertain, and what can safely happen next.
Operators spend less time rebuilding context and more time reaching a defensible conclusion, handing off safer action, and retaining the investigation record.
Operating signals
- The same issue sends operators across monitoring, logs, identity, notes, repositories, and asset records before they can trust a conclusion.
- Advanced configuration requires discovering the real operation and schema surface across several connected systems, not guessing from one vendor tool.
- Investigation tools should stay read-only; mutation requires a separate evidence-backed proposal and explicit approval path.
- Useful findings should become retained case history instead of disappearing into chat, shells, or tickets.
What you get
Where it starts
Common starting points.
These examples enter the product surface that owns their state. They do not all become a case, ticket, owner, or shared evidence record automatically.
Why is this host or service failing?
Build a read-only current picture from monitoring, service status, logs, recent work, documentation, and operator notes before anyone changes the system.
Which systems are affected by this vulnerability, and what remediation is safe?
Use scanner findings, affected assets, exposure, ownership, and execution readiness to separate immediate risk from safe follow-up.
Can this service, host, or appliance be decommissioned or cleaned up?
Check lifecycle state, monitoring history, dependencies, ownership, usage, vulnerabilities, and open work before cleanup creates a second problem.
Is this user activity suspicious or explained by a known change?
Review sign-ins, related alerts, surrounding changes, and environment context before escalating normal activity into incident work.
Can the infrastructure definition be updated as part of the fix?
Inspect existing code and live configuration, retrieve the supported operation schemas, then propose complete IaC files so the fix can be maintained instead of patched by hand.
Can we design a new Entra ID, Azure, or Intune configuration without piecing together every API by hand?
Search the configured tenant’s available API specifications and current-state reads, model the cross-service prerequisites, and retain the resulting design as code while identifying unsupported or portal-only steps.
How it works
How work moves.
The product path below names its inputs, decisions, controls, and output without implying the same lifecycle applies to every capability.
- 01
Open the case
Start with a direct operational question and resolve the service, host, user, vulnerability, repository, environment, or appliance in scope.
- 02
Discover the available surface
Identify the target, search relevant API operations, retrieve exact schemas, and pull likely sources first while keeping operator override when more context is needed.
- 03
Build current truth
Use available typed, read-only tools to gather bounded live evidence, test hypotheses, and explain what is happening now.
- 04
Review the next step
Keep the current summary, uncertainty, notes, and proposed action visible in the case so approval is based on evidence, not memory.
- 05
Hand off and retain
Retain findings, summaries, diagrams, runner output, and any approved action without losing the investigation trail.
Product model
Investigation model.
The diagrams show how a resolved target becomes bounded evidence, how hypotheses and narrated steps remain reviewable, how mutation stays behind a guarded proposal, and how outputs remain case-scoped.
Source targeting
Resolved target to evidence-backed conclusion.
A direct question becomes a case with an explicit target. Typed read-only capabilities return bounded live observations that support hypotheses, findings, and the current operator summary.
Read-only RCA
Bounded facts without changing systems.
Investigation tools are typed and read-only. Their outputs are bounded and redacted, and external mutation is rejected from the evidence-gathering lane.
Controlled remediation
Real changes use a guarded proposal path.
A proposal requires same-case live evidence, declared risk, preconditions, stop conditions, rollback, scope containment, approval, and policy-required step-up before execution.
Retained context
The case record keeps value after closure.
Evidence, hypotheses, narrated steps, findings, summaries, diagrams, runner transcripts, notes, and action state stay attached to the case.
What it includes
What the record shows.
These parts participate in the workflow. The record shows what was used and why it mattered.
Case intake
Operator questions, suspicious changes, cleanup checks, and vulnerability follow-up use the same durable investigation workflow.
Investigate case workspace
Target and source selection
A target catalog resolves and materializes the target so tool calls remain bound to the intended operational object.
Target catalogue and source routing
Operational evidence
Available capabilities expose monitoring, logs, identity, cloud, workload, findings, documentation, repositories, runtime, security, and platform facts without granting a general mutation path.
MCP capability catalog, operation search, schema lookup, and bounded tool results
Repository and IaC path
Configured repositories expose bounded file, code-search, and history reads; a complete set of generated changes can become a durable pull-request proposal.
Repository inspection, desired-state files, action proposal, approval, and pull request
Method and case chronology
Hypotheses, investigation steps, findings, conclusions, follow-up turns, evidence, and the current operator summary remain separate but connected case records.
Case timeline, evidence ledger, hypotheses, summary, and runner transcript
Approved next action
When live evidence supports a change, the proposal records risk, scope, safeguards, and rollback before approval, optional step-up, and controlled execution.
Action proposal, approval policy, step-up, execution, and reset surfaces
Control model
Controls stay specific to the workflow.
Integrations, AI assistance, routines, and agents use different permissions and records. The controls below describe this capability rather than a universal approval model.
Target resolution and typed capability discovery happen before broad evidence collection, keeping the investigation bound to an explicit case target.
Operation search and schema retrieval can cover broad upstream specifications, but invocation remains limited by the configured connection, tenant permission, target scope, and integration policy.
Read-only analysis and mutation proposals are separate paths; external mutation is rejected from the investigation tool lane.
A Git proposal never opens a pull request immediately; the configured repository must allow PRs and an operator must approve the durable proposal before execution.
Tool output is bounded and redacted, while evidence, hypotheses, narrated steps, findings, conclusions, summaries, diagrams, and runner events remain case-scoped.
An action proposal requires same-case live evidence plus risk, preconditions, stop conditions, rollback plan, and scope-containment checks.
Approval, required step-up, execution state, and reset remain explicit stages instead of being collapsed into an AI recommendation.
Value over time
Product path for Investigate.
Scope
Resolve a target and question
The case determines which configured typed capabilities are available.Read
Retain bounded evidence
Evidence, hypotheses, narrated steps, findings, notes, and summaries remain in the case.Decide
Close or propose action
External mutation uses a separate evidence-backed proposal and control path.Next step
Want to see investigate on your stack?
Book a walkthrough and I will map this workflow to the integrations and controls you already use.