Trust score.
A continuous, behavioral, per-action score for every principal, computed live from identity, authority, policy, and runtime signals. Not static allow/deny.
What it is
A trust score is a live, numeric assessment of how safe it is to let a given principal, an AI agent, a service account, a drone, or any other autonomous actor, take a specific action right now. The score is not attached to the principal in the abstract. It is attached to the pair (principal, action-in-context), and it is recomputed on every request.
Traditional identity and access management answers a binary question: does this identity have this permission, yes or no. A trust score answers a richer one: given everything we know about this principal, this scope, this policy, and this behavior in the last hour, how confident are we in permitting this action, and if less than fully, what is the safe response short of a hard block.
Why continuous, not static
Static allow/deny is what happens when a system assumes principals are stable. Humans mostly are. Agents are not.
An LLM-based agent's behavior can shift the moment a new prompt lands in its context. A principal that was trustworthy an hour ago can be prompt-injected into exfiltrating data now. A service account that ran clean for months can be compromised in a single credential leak. Static IAM catches none of these situations, because none of them change the identity or the assigned permission. They change the behavior, and only a behavioral signal will surface them.
A continuous trust score is the signal. It moves as the principal moves. It falls when behavior deviates from norm. It recovers when the deviation resolves. Enforcement follows the score, not a permission table set six months ago.
What feeds the score
Four families of signal, combined on every request.
Identity signals
Is the caller's signed identity valid, unrevoked, and issued to a known principal. Has the identity been rotated recently. Is the issuer trusted for this class of principal.
Authority signals
Does the caller hold a valid delegation from a human principal for this scope. Was the chain composed under only-tighten. Is the requested action inside the granted scope, and if so, by how much margin.
Policy compliance
What is the principal's recent history against the applicable policy set. Repeated near-misses drag the score down; a clean history holds it up.
Behavioral signals
Rate of requests over the last window. Blast radius of the requested action, how much can this write touch. Fit against known attack chains, does this sequence look like a step in a familiar exfiltration or privilege-escalation pattern. Peer comparison, how far from the median behavior of comparable principals in the same role.
The signals are combined into a single per-action number. The exact combination is a policy decision and can be tuned per tenant.
How the score maps to verdicts
Runtime governance turns the score into one of five verdicts. The thresholds are directional, not published constants, and they are set per policy pack.
- Allow. The score is high enough that the action runs as requested.
- Redact. The score is high enough for the action, but the response should have sensitive fields removed on the way back.
- Throttle. The score is borderline; the action runs but at a reduced rate or with tightened concurrency.
- Escalate. The score is low enough that a human should confirm before the action commits.
- Block. The score is low enough, or the action risky enough, that the request is refused.
The gradient is the point. A static allow/deny system has to pick one of two answers and live with the consequences of the wrong pick. A continuous score gives runtime governance five ways to keep an action safe without either paralyzing the agent or letting an incident through.
How Veldt implements it
Trust scoring is a core capability of the Runtime Governance pillar. The runtime scores every request in under 50 milliseconds, writes the score and the verdict into the tamper-evident audit trail, and signs both to the principal that produced the action.
The score is not a black box. Every score comes with the signals that produced it, so a reviewer or auditor can walk backward from a verdict to the reason. That property is what makes the score defensible to a regulator, and useful to an incident responder.