Get startedHow LiveProbe works
How LiveProbe works
Understand the control plane, runtime data path, tenancy boundary, and what a probe can and cannot do.
Request path
Human users authenticate to the hosted MCP endpoint with Clerk. The broker resolves their active organization and applies tenant, project, and environment scope. Runtime agents use separately revocable service credentials and poll the broker for probe definitions.
The MCP process never opens a direct connection to an application process. Agents initiate all broker communication over outbound HTTPS, then return sanitized events.
Resource model
| Resource | Meaning | Example |
|---|---|---|
| Organization | Clerk workspace and hard tenant boundary | Astrea Engineering |
| Project | Repository or application identity | acme |
| Environment | Independent deployment scope | production |
| Service | Independently deployed process identity | api |
A service is registered once in a project and can run in multiple environments. Credentials, heartbeats, probes, evidence, source maps, safety state, and audit events are routed by project and environment.
Runtime boundary
LiveProbe is read-only by design. Probe expressions operate on captured values using a broker-compiled bounded AST. Calls, assignment, constructors, imports, reflection, dynamic property expressions, and prototype traversal are rejected.
Node inspector breakpoints and JVM JDI breakpoints may briefly pause an executing thread. Python monitoring callbacks execute inside the target process. Safety budgets bound LiveProbe activity but do not turn it into a no-overhead profiler.
Data lifecycle
- Agents poll probe definitions roughly once per second.
- Captured values are redacted and structurally bounded in-process.
- Counter and metric samples are pre-aggregated before transport.
- Each probe retains up to 500 events; oldest events expire first.
- Probe TTL and hit limits automatically stop instrumentation.
- Removing a probe uninstalls it on the next agent poll.