Skip to main content

Traces & risk

Splyntra's data model has one central object — the agent run — and two views over it: a performance trace and a security risk score. They share the same spans, so you can always move between "what happened" and "was it safe."

Runs, traces, and spans​

Every time your agent executes, Splyntra records a run, backed by an OpenTelemetry trace. A trace is a tree of spans, where each span is one unit of work:

  • Agent / graph node — a step in the agent's control flow.
  • Model call — an LLM invocation, with model name, prompt, completion, token counts, and latency.
  • Tool call — a function/tool invocation with its arguments and result.
  • Retrieval — a vector or document lookup.
  • Handoff — control passing to a sub-agent.

Spans nest to mirror the agent's actual execution, so a re-planning loop or a sub-agent's work appears as a subtree. Splyntra follows the OpenTelemetry GenAI semantic conventions, so if you emit standard gen_ai.* attributes they populate the UI automatically.

run_5f3a  (support-agent)               4.21s   $0.0132   risk 12
├─ plan                                  0.34s
├─ retrieve: policy_docs                 0.08s
├─ llm: gpt-4o  (1,204 → 88 tokens)      1.90s   $0.0121
└─ tool: send_email                      0.21s            ← finding: PII (email)

The risk score​

Each run gets a risk score from 0 to 100, where higher means more risk. It is a composite of the individual findings detected across the run's spans:

  • Secret detection — API keys, tokens, private keys, and credentials appearing in prompts, tool arguments, or outputs.
  • PII detection — emails, phone numbers, national IDs, payment data, and similar.
  • Prompt-injection detection (beta) — attempts to override the agent's instructions via retrieved content or tool output.
  • Policy violations — breaches of governance policies (Enterprise/Cloud). See Governance.

The score weights findings by severity and confidence, so a high-confidence leaked secret moves the needle far more than a low-confidence PII match. A run with no findings scores near zero.

How detection maps onto spans​

Detection runs per span, so findings are anchored to the exact span where the risky text appeared — a leaked key on a tool call, injected instructions on a retrieval. When you open a run's risk view, each finding links to its span and highlights the offending field.

{
  "span_id": "span_9c2…",
  "kind": "tool_call",
  "name": "send_email",
  "finding": {
    "type": "pii",
    "subtype": "email_address",
    "severity": "medium",
    "confidence": 0.94,
    "field": "arguments.to",
    "redacted": true
  }
}
note

Detected secrets and PII are redacted before storage by default, so the raw values are not persisted. Only the finding metadata (type, location, severity) is kept. See Security for redaction configuration.

Why unify them​

Keeping traces and risk on the same spans means a security signal is never divorced from its context. You can:

  • Filter runs by risk score and jump straight to the offending span.
  • See the latency and cost of the exact call that leaked data.
  • Alert on runs that cross a risk threshold, with the full trace attached.

Next steps​