A trust score is only useful if the people looking at it understand exactly what it's measuring and, just as importantly, what it isn't. TELEON's trust scoring is designed to reflect how a given agent's or activity's recent behavior compares to its own established pattern over time, and a trust report is the summarized, reviewable form of that signal, organized so a team can look across agents or across a time period and see where activity has deviated from what's normal for that specific agent. It's a genuinely useful prioritization tool. It is not a compliance certificate, a security guarantee, or proof that an agent is or isn't behaving correctly, and treating it as any of those will lead to disappointment the first time a low score turns out to reflect something entirely benign, or a high score turns out to have missed something real.
What the underlying score is actually built from
Trust scoring draws on the activity TELEON observes at the tool-call and model-call boundary: which tools got called, how often, in what sequence, and how that compares to the specific agent's own historical pattern rather than a generic baseline shared across every agent. A report built on this scoring reflects deviation from established norms, not an absolute judgment of good or bad behavior, since what's normal for one agent's task can look completely different from what's normal for another's.
Reports work best as a prioritization tool across many agents
For an organization running several agents, a trust report's real value is helping decide where to look first. An agent whose score has shifted meaningfully deserves review sooner than one behaving exactly as expected, simply because there's more reason to think something's changed. Used this way, a trust report turns a review process that would otherwise require checking every agent equally into one that's weighted toward where attention is actually more likely to be needed.
A score reflects deviation, and deviation isn't automatically a problem
It's worth repeating because it's the single most common way trust reports get misused: a deviation from an established pattern can reflect a genuine problem, a manipulation attempt, a bug, or it can reflect a legitimate change, a new feature, a one-off edge case, a shifting business need. The report surfaces the deviation. Determining which of those explanations actually applies takes investigation and business context that the score itself doesn't carry.
Reports need a time window that matches how the review will actually be used
A trust report summarizing a full quarter tells a very different story than one summarizing the last 24 hours, and picking the wrong window for a given review purpose produces a report that answers a question nobody was actually asking. A short window suits an active investigation into a specific recent incident; a longer window suits a periodic governance review looking for slower drift. Matching the window to the actual review purpose is a judgment call that belongs with whoever's requesting the report.
It's worth generating reports at more than one window routinely rather than picking a single default and sticking with it. A short-window report can miss a slow, gradual drift that only becomes obvious over a longer period, while a long-window report can dilute a sharp, recent deviation into an average that looks unremarkable.
What a trust report cannot substitute for
A trust report is not a substitute for reviewing the audit trail directly when something specific needs investigating, and it's not a substitute for a security assessment of the agent's design or the tools it can access. It's a summarized signal built on observed behavior; it has no visibility into whether an agent's underlying model, prompts, or tool schemas are sound, since that's outside what activity monitoring can observe in the first place.
Treating a consistently high trust score as proof an agent's design is fundamentally sound is a similar mistake in the other direction. An agent can behave entirely consistently with its own established pattern while that pattern itself reflects a poorly scoped or overly permissive design nobody has reassessed in a while. Consistency and soundness are different properties, and a report speaks only to the first one.
Where TELEON fits
TELEON's trust scoring, produced through activity observed at the gateway or supported middleware, reflects how an agent's behavior compares to its own established pattern over a chosen time window, and a trust report summarizes that signal for review. It is not a compliance certification, a guarantee of correct behavior, or a substitute for direct audit trail investigation or a security assessment of the agent's underlying design.
A short checklist
- Choose a report time window that matches the actual review purpose, short or long.
- Use trust reports to prioritize review across many agents, not as a final judgment on any one.
- Investigate the audit trail directly whenever a report flags a meaningful deviation.
- Distinguish a legitimate behavior change from an actual security problem before acting.
- Don't treat a trust report as compliance evidence or a security certification.
- Refresh baselines periodically so reports reflect an agent's current, legitimate normal pattern.
- Pair trust reports with periodic security assessment of agent design, not as a replacement for it.
- Share reports with whoever actually has context to interpret a deviation meaningfully.
Trust scoring earns its usefulness by directing attention efficiently, not by rendering a verdict on its own. A trust report built from it tells a team where recent activity looks different from what's normal, which is valuable exactly because it narrows down where a limited amount of review time should go. What that deviation actually means, and what should be done about it, still depends entirely on someone who understands the agent's business context looking closely at what's behind the number.