Why Inspector Features How it works Security FAQ Controller MergeSense Impact Atlas Contact Show interest
AI investigation, self-hosted

One agent. Any question. Evidence-backed answers.

Stop searching dashboards. Ask "why is this server slow?" or "is there anything wrong with this server?" in plain language. A lightweight, read-only agent collects real evidence, secrets get redacted before anything reaches an LLM, and you get a structured finding back: severity, confidence, evidence, timeline, and a recommendation, never a guess dressed up as a fact.

The AI plans, a policy layer approves, the agent reads. Never a shell, never a command, never a guess presented as fact.

Investigation: "Why is this server slow?"
EVIDENCE Request threads near saturation, OBSERVED
EVIDENCE Request queue increased since the last deploy, CORRELATED
FINDING Thread pool saturation. Confidence 94%. Recommend reviewing the new request path.
0
commands the agent can run on your servers. It reads and reports, never executes
5
evidence states a finding can carry, never presented as more certain than it is
1
agent, installed once, that detects what's actually running and reports honestly
100%
self-hosted on infrastructure you own, no public signup
Why Inspector

An investigation engine, not another dashboard

You shouldn't need to know which metric, which log file, or which process to check. You ask the question. Inspector figures out where to look, gathers the evidence itself through a locked-down agent, and hands you a conclusion you can actually check the reasoning behind.

Ask in plain language

"Why is this server slow?" "Did the deployment cause this?" "Find unusual errors in the logs." No query language, no dashboard to learn, no metric name to remember.

The agent can't go rogue

The agent can only read and report. There is no path from a question to a command running on your servers.

Secrets never reach the model

Every piece of evidence is redacted before it's stored or sent to any LLM. Credentials, API keys, and tokens get scrubbed first.

Real multi-tenant access control

Organizations, projects, and environments are isolated by default. Roles decide exactly who can inspect what, enforced on every request.

Bring your own AI provider, or none at all

Connect the AI provider you already use. No provider configured yet? Evidence still collects and displays honestly instead of a fabricated finding.

Own your infrastructure, own your data

Self-hosted on infrastructure you control, no public signup. Every organization is provisioned by a platform admin, not a signup form.

The problem

Every incident starts with the same question: where do I even look?

None of these are exotic edge cases. They happen every time something breaks at 2am.

You don't know which dashboard to check first

CPU, memory, connection pools, upstream latency, a dozen tabs open, and the actual cause is in none of them until you've checked all of them.

Logs are a haystack, not an answer

Millions of lines, no way to know which pattern actually matters. By the time you've grep'd your way to a lead, the incident's been going for twenty minutes.

A chatbot with no real access is just a guess with better grammar

General-purpose AI assistants can describe what a thread pool exhaustion looks like. They can't tell you if this server, right now, actually has one, because they were never given a way to check.

How it works

Ask, plan, collect, answer

Every question goes through the same four real stages, never a shortcut straight to a guess.

1

Ask

Type a question in plain language, anywhere in the app. Pick a scope: one server, several, or the whole environment.

2

Plan & approve

A planner maps the question to only the relevant diagnostics. Every single one still has to clear user permission, project policy, and agent capability before it runs.

3

Collect

The agent, polling outbound-only, fulfills the approved requests and reports back. Secrets and PII get redacted before anything is stored.

4

Answer

Your configured LLM turns the evidence into a structured finding. No provider configured? You still see every piece of evidence collected, plainly.

Everything included

What's actually built today

No roadmap items, no "coming soon." This is what runs in the app and the agent right now.

Zero-config auto-discovery

Install one agent and it detects what's actually running on the host, automatically. Only the modules that apply turn on, no log path to configure.

Investigation engine

A planner, a gated evidence pipeline, and a synthesis step that has to fail safe and say "insufficient evidence" rather than hallucinate a cause.

Outbound-only agent

The agent reaches out, nothing reaches in. No inbound firewall port required on the host you're monitoring, ever.

Log intelligence, not log storage

Logs are grouped and deduplicated as evidence for a specific investigation, with capped retention, deliberately not a searchable archive. This isn't a monitoring platform.

Multi-tenant from the ground up

Organizations, projects, and environments, fully isolated. Platform admins provision organizations; org admins provision projects and assign users a role scoped to what they should actually see.

Follow-up conversation

"When did this start?" "What changed?" "Show me evidence." Follow-ups stay scoped to the investigation's own evidence, never leaking context across projects.

Multi-provider governance

Register several AI providers per project, and an org-level policy still wins even if a project tries to use a blocked one.

Append-only audit log

Logins, agent activity, permission changes, every investigation run, every provisioning action. Written once, never edited.

Closed by design

The AI plans. It never gets a shell.

The agent can only read and report, by design. There's no path from a question to a command running on your servers, and no setting that turns one on.

  • Every request still has to pass user permission and project policy, in that order
  • Log lines and metric values are treated as untrusted data, never instructions, even ones that look like a prompt injection attempt
  • Read-only by default. Any future remediation action would need its own separate, explicit permission
REQUEST Read server metrics, approved
REQUEST Run a command on the server
POLICY Rejected. No such capability exists.
Evidence-backed, not vibes-backed

A finding always says how sure it is, and why.

Every conclusion is labeled OBSERVED, CORRELATED, INFERRED, PREDICTED, or VERIFIED, and never presented as more certain than the underlying evidence supports. When the evidence is thin, the answer is "insufficient evidence" plus exactly what's missing, not a plausible-sounding guess.

  • Every finding cites the specific evidence IDs it's grounded in
  • Multi-server questions get a per-server breakdown when servers disagree, not one answer papering over the difference
  • No AI provider configured, or the model's response doesn't parse? You still see the raw collected evidence, never a dead end
Finding: memory growth
OBSERVED Heap at 78%, trending +2.1%/hour
PREDICTED 90% within ~6 hours, confidence 87%
RECOMMEND Review the allocation pattern introduced in the last deploy
Self-hosted, on your terms

Your infrastructure. Your data. Your control.

The full stack deploys directly on infrastructure you own. There's no public signup: a platform admin provisions the first organization, and every account after that is provisioned top-down, never a self-serve form.

FAQ

Questions, answered

No. The agent can only read and report. There is no path from a question to a command running on your servers, not a setting that can be toggled on.
Investigations still run and still collect real evidence from the agent. Without a provider configured, you see that evidence directly instead of a synthesized finding, an honest "no AI configured yet" rather than a fabricated answer.
Yes. Connect the AI provider you already use. If a provider isn't wired up yet, the product says so rather than silently failing.
No, deliberately. Logs are collected and redacted only as evidence for a specific investigation, with capped retention. There's no standalone log-search screen. If you need a permanent, searchable log archive, that's a different category of tool.
There's no public signup, by design. A platform admin (you, once it's deployed on your infrastructure) provisions the first organization and its admin, who then provisions projects and invites users with a specific role. Show interest and we'll walk you through deploying it.

Stop searching dashboards. Ask your infrastructure.

Self-hosted, evidence-based, and ready to install on your first server today.

Questions first? contact@prashflow.com