Sweep the estate for risky configuration
Sweeps AWS, Supabase, Fly, Cloudflare and Kubernetes for public buckets, missing alarms, absent backups and single points of failure.
I want to do this: Find the risky configuration: public buckets, missing alarms, single points of failure. ## Setup (skip if Polylane is already set up) Read and follow https://polylane.com/auth.md for non-interactive signup and setup. Start by checking whether I am already signed in; reuse my account and workspace. If the CLI is missing, bootstrap it without starting the interactive wizard: curl -fsSL 'https://polylane.com/setup?ref=prompts' | bash -s -- --install-only Then follow the guide through email verification, workspace selection, source connections, and MCP authentication. Ask me for an email code or OAuth consent only when needed. Verify each step; report pending setup instead of claiming success from installation alone. ## How to work Over MCP: searchTools lists what this workspace exposes, with each tool's schema; call it first. runTool runs one tool, runCode chains several in one call and returns just the answer. search and execute cover the full Polylane REST API: threads, issues, investigations, autofixes, memories. From the terminal: the polylane CLI wraps the same API, with structured output and non-interactive flags everywhere. Reads always work. Write tools appear only if I have opted in, and every write is screened. ## Task: Sweep the estate for risky configuration Steps: 1. Sweep every connected account's advisories: misconfigurations, resilience risks, observability gaps 2. Check the critical tier first: the resources whose failure actually hurts 3. For each finding, pull the configuration evidence behind it 4. Rank by blast radius: what breaks if this specific risk fires 5. Deliver the sweep, worst first, each finding citing its config Ground every claim in data you actually pulled: the query, the log line, the change record. If the data is inconclusive, say so. Ask me before anything that writes.
Every audit finds the same five skeletons.
The public bucket, the database with no failover, the service with no alarm: everyone suspects they're out there, and confirming it means a manual sweep nobody has budgeted for since the last audit.
- Security reviews that happen once a year, drift that happens daily
- The single-AZ database discovered during the outage
- Findings lists with no evidence attached
One prompt, this much work. Every step on your real data.
- 1 Sweep every connected account's advisories: misconfigurations, resilience risks, observability gaps
- 2 Check the critical tier first: the resources whose failure actually hurts
- 3 For each finding, pull the configuration evidence behind it
- 4 Rank by blast radius: what breaks if this specific risk fires
- 5 Deliver the sweep, worst first, each finding citing its config
The skeletons, enumerated and ranked
Every risky config on one list with its evidence and blast radius, refreshed from the live estate instead of last year's audit. Fix the worst one this week.
The quiet failure 
“Find things that look wrong but never alerted: error spikes, dead crons, growing queues.” Know the account 
“Map our AWS account: what's running, what depends on what, and what's critical?” The cron audit “List every scheduled job across our clouds and when each one last succeeded.” Close the gaps 
“Which critical services have no logs or traces? Show the gaps and write the fixes.” Read my dashboards 
“Go through our dashboards and tell me what's drifting from normal this week.” Query to check “Write the query for checkout error rate by region over 24 hours, and save it as a check.” Coverage gaps “Which routes swallow errors or log nothing? Show the gaps and the fixes.” The weekly read 
“Summarise what our telemetry says about last week: regressions, improvements, anything odd.” Watch this deploy “We're deploying checkout-api at 5pm. Watch the metrics after and flag anything that moves.” Onboard me “I'm new here. Walk me through the architecture: the critical path, the data stores, what talks to what.” Instrument the launch “payments-v2 ships next week. What instrumentation should it have before launch? Draft it.”
“Find things that look wrong but never alerted: error spikes, dead crons, growing queues.” Know the account “Map our AWS account: what's running, what depends on what, and what's critical?” The cron audit “List every scheduled job across our clouds and when each one last succeeded.” Close the gaps 
“Which critical services have no logs or traces? Show the gaps and write the fixes.” Read my dashboards “Go through our dashboards and tell me what's drifting from normal this week.” Query to check “Write the query for checkout error rate by region over 24 hours, and save it as a check.” Coverage gaps “Which routes swallow errors or log nothing? Show the gaps and the fixes.” The weekly read “Summarise what our telemetry says about last week: regressions, improvements, anything odd.” Watch this deploy “We're deploying checkout-api at 5pm. Watch the metrics after and flag anything that moves.” Onboard me “I'm new here. Walk me through the architecture: the critical path, the data stores, what talks to what.” Instrument the launch “payments-v2 ships next week. What instrumentation should it have before launch? Draft it.”