Observed vs inferred

How aspex trace labels what it can show, what it infers, and what it cannot know.

aspex trace reads what your clients log. It never captures payloads and never sits in the request path, so every conclusion carries one of four labels.

Label	Meaning	Example
OBSERVED	The event is in the log. A fact about the log.	filesystem.read_file(~/.aws/credentials) at 14:02:11
INFERRED	A relationship between observed events, drawn from order and timing.	”these two calls are 12s apart in the same session”
POSSIBLE	A consequence the observed events would allow but the log cannot show.	”the file’s contents could have left in the outbound call; payloads are not captured”
NOT OBSERVED	Explicitly, what Aspex cannot show.	”no evidence the response was used”

Sequence is never causality

A kill chain is a set of OBSERVED steps whose link is INFERRED and whose harm is POSSIBLE. Aspex says so in the output, every time. Provenance (which ingested content preceded a suspicious call) carries a timed confidence:

Distance	Confidence
under 30 seconds and 3 events	high
under 2 minutes and 8 events	medium
otherwise	low

Per session, always

Analysis is per session. A file read in one conversation and a network call in another are never joined, even if they are a minute apart.

What this means for scan

A scan finding is a path: a composition that exists in your configuration. A trace finding is an observation: something that happened. aspex scan --with-trace puts them side by side so you can see which risky compositions are actually exercised, and aspex tighten uses observations to recommend narrower permissions. Neither one turns the other into proof.

Connectors added through claude.ai are configured in the cloud and have no local file. They appear in trace output as in use, never scanned, with their call counts, so you know how much of your agents’ activity runs through servers no static scan has looked at.