--- name: miggo-service-blast-radius description: Map what one named Miggo service depends on and what depends on it (third parties, endpoints, other services, dependencies, findings) to judge the blast radius of a compromise or outage, and report it as a per-service dependency walk. Use when the user asks what a service connects to, what would be affected if it went down or was breached, what its downstream dependencies are, or wants the blast radius of a named service. --- # Map a service's blast radius The question is **"if this service is compromised or fails, what else is touched?"** Work outward from one named service, one hop at a time, and report what you confirmed separately from what you could not resolve. A list of everything in the environment is not a blast radius; a tight, evidenced walk from one service is. ## 1. Pin down the service and confirm the environment Confirm the Miggo token and environment the user is connected to before reading anything, since results are only meaningful for the right environment. Then locate the service: - Run `services_search` with the name the user gave. If several services match, list the candidates and ask which one. Do not guess between similar names. - Run `services_get` on the chosen service to read its full record, including its evidence and evidence availability. Use the get result as the source of truth; the search result is only a summary. - If the search returns nothing, say the service was not found in this environment. Do not widen to a fuzzy match without telling the user. Write down the service's identifier. Every later call should use that identifier, not the name. ## 2. Walk the direct connections, one category at a time Start with the categories most likely to widen the blast radius, then go outward. For each category, use the `_search` tool filtered to this service, and read only the count first with the matching `_count` tool so you know whether a full page is worth pulling: 1. **Third parties** (`third_parties_search`, then `third_parties_get` on the notable ones). External SaaS or APIs the service calls can carry data out and can fail in. Note which ones handle sensitive data if the record says so. 2. **Endpoints** (`endpoints_search`). The service's exposed or internal routes. Use `evidenceAvailability` to pick which to inspect: internet-facing and flagged ones matter most for an attacker's entry, and unauthenticated ones matter most for exposure. 3. **Dependencies** (`dependencies_search`). Libraries and packages the service ships. These are how a supply-chain issue reaches this service; check them against any named advisory only if the user asked. 4. **Findings and vulnerabilities** (`findings_search`, `vulnerabilities_search`) scoped to this service. These tell you which weaknesses already sit on the path, which raises the realistic blast radius. 5. **Other services** that this one connects to, found through the connection data in the service record and the endpoint or third-party results. Repeat steps 1 to 4 for a second hop only if the first hop shows a service that is itself critical or internet-facing. Stop at two hops and say so. Use `facets` on a search when you need a quick breakdown (for example, how many endpoints are internet-facing) without paging through every record. Keep page sizes small and page only when the count says more matter. ## 3. Judge which connections widen the blast radius Not every connection is equal. Rank them by how much harm a compromise or outage could reach: - **Widens it most:** a connection to data stores or sensitive third parties, an internet-facing entry point on the same path, or a critical open finding on this service. - **Widens it moderately:** internal services and shared dependencies used by several services. A shared dependency means one bad version affects every consumer, so count the consumers. - **Adds little:** isolated internal endpoints with no findings and no sensitive downstream. Name the single most damaging path in one sentence, for example "internet-facing endpoint, then this service, then a payments third party". That path is usually what the user needs most. ## 4. Separate confirmed from unresolved Before writing the report, sort what you know: - **Confirmed:** a connection or record you actually retrieved. - **Not resolved:** a connection you suspected but could not verify, a record hidden or missing, or a second hop you chose not to walk. Do not present an unresolved link as a confirmed one. A blast radius with honest gaps is more useful than a complete-looking map with guesses in it. ## Common patterns and traps - **Name collisions.** Two services with near-identical names are common. Confirm by identifier, and read back the team or environment field before reporting. - **Counting endpoints as impact.** Many endpoints do not mean many affected users. Judge by exposure and sensitivity, not by volume. - **Shared dependency surprise.** A library used by one service looks contained. The same library in five services is a five-service blast radius. Always check how many services share a dependency before calling it isolated. - **Trusting the summary.** The search row may show a short or deprecated evidence field. The get record is the complete one; use it for anything you cite. - **Missing data is not a clean bill.** An empty third-party list means none were found, not that the service has none. Say what you searched. - **Runaway walks.** Following every connection to every third hop buries the answer. Two hops, then stop. ## Output ``` Service: (id ), environment Blast radius: , judged on Most damaging path: -> -> Direct connections - Third parties: (sensitive: ), key ones: - Endpoints: (internet-facing: , flagged: ), key ones: - Dependencies: , shared with other services: - Open findings/vulnerabilities on this service: (critical: ) Second hop (if walked) - : Confirmed: Not resolved: