Truston / USB key platform

Trust always on.
Wherever Agents run.

Truston keeps Agent identity, delegated authority, policy checks, and signing keys on a secure USB key. The host receives a signed decision without handling the key material.

Get Started
W3C VC 2.0·IETF OAuth 2.1·FIDO2·CC EAL5+·PQC Ready·ISO/IEC 42001·

The problem

Agent credentials need
a hardware boundary

AI Agents can approve payments, answer customers, deploy code, and query business data. Those actions move between workstations and services while software credentials remain exposed to the host.

A Truston USB key keeps identity, authorization, policy, and signing material attached to hardware instead of the runtime that calls it.

An Agent is an execution principal, separate from the user account that launched it. A shared client credential cannot distinguish a registered Agent instance from an impersonating script or malicious proxy.

TodayWhen runtimes share a software identity, access follows the client instead of the Agent. A test process can present the same credentials as a production Agent.

A request may pass from a user to Agent A, then to Agent B. Each handoff needs to record Authority (who granted it), Intent (the task), and Constraints (its limits). Without those fields, responsibility stops at the first lost link.

TodayAgent-to-Agent calls often forward access without the original grant or its limits. The receiving system sees a valid credential but cannot tell why it was issued.

RBAC and ABAC grant roles or attributes. They do not bind a request to its delegated resource, action, time window, and usage limit. An Agent with read access may attempt a write or continue after authorization expires.

TodayBroad permissions outlive the task that justified them. Reusable tokens turn a narrow approval into standing access.

Incident response needs evidence that can survive outside the system that produced it. An auditor must be able to check the Agent identity, delegation, policy decision, action, and timestamp against a cryptographic signature.

TodayMutable application logs cannot provide that proof. The operator can edit or delete them, and an independent reviewer has no trusted record to verify.

For an Agent-initiated transaction or deployment, the Truston key signs the credential, delegation, policy decision, action, and timestamp. The record can be verified without trusting host logs.

The solution

Truston puts Agent trust
on a USB key

AI Platform LayerLLMs · Agent Frameworks · Orchestration
Truston USB Key PlatformHardware policy check for each action
IDIdentity
AUTHAuthorization
POLICYPolicy
AUDITAudit
SECURE ELEMENTKeys and policy stay on the USB keySIGNED
Enterprise SystemsDatabases · APIs · Cloud · On-Prem
01

Works with your Agent stack

Truston adds a USB hardware boundary between an Agent framework and enterprise systems. The LLM and orchestration layer stay in place.

02

Carries identity and authority

Each key binds the Agent's identity to its delegation, current policy decision, and signed record.

03

Keeps trust always on

The secure element stores private keys and API secrets, evaluates policy, and signs the result. Enforcement remains on the USB key when the host changes.

The trust model

How Truston evaluates
an Agent request

Each request reaches Truston with verifiable claims for the Agent, its delegation, and the requested action. The USB key evaluates those claims against local policy and signs the result.

The trust decision can be checked independently of the host.

Q1

Who is acting?

Verify the Agent instance, the code it runs, and the principal it represents.

ChallengeTruston control
Agent identity is tied to a user accountA DID issued by the Truston secure element binds identity to one hardware instance. The DID cannot be cloned or moved.
A runtime can be replaced or modifiedA SHA-384 signed Agent Manifest checks the version, source, and dependencies at launch.
Agent-to-Agent calls blur identityThe Delegation Graph records each parent-child identity link.
Identity needs rotation and revocationCertificate lifecycle controls cover rolling rotation, expiry, and immediate revocation.
Give every Agent instance its own identity.A user credential identifies the principal. The hardware-bound DID identifies the runtime acting for that principal.
Q2

What may it do?

Check who granted the request, what task they approved, and the limits on that grant.

ChallengeTruston control
OAuth scopes are broader than the taskA Delegation Token limits the resource, action, time window, invocation count, and conditions.
Long-lived authorization outlasts the taskTokens expire automatically, count calls, and support immediate revocation.
A forwarded token loses its historyEvery token records Authority, Intent, and Constraints.
Child Agents can inherit excess accessA child token can only narrow its parent's permissions.
Delegation carries its own context.A scope describes permitted operations. A Truston token also records who approved the task, what they intended, and the boundaries they set.
delegation-token.json
{
  "delegator": "did:truston:user-alice",
  "delegatee": "did:truston:agent-finance-01",
  "authority": "CFO approval via MFA",
  "intent": "read quarterly revenue report",
  "constraints": {
    "resources": ["finance.reports.q2_2026"],
    "actions": ["read"],
    "time_window": "2026-08-10T09:00Z / 2026-08-10T17:00Z",
    "max_invocations": 5,
    "ip_range": "10.0.0.0/8"
  },
  "signature": "ml-dsa-65:..."
}
Q3

Should it act now?

Evaluate the request against the policy in effect at execution time.

ChallengeTruston control
Policy embedded in a prompt is hard to changeDeclarative Policy as Code updates without restarting the Agent.
Static rules miss request contextIntent-Based Authorization checks time, origin, frequency, and data sensitivity.
Policy changes are hard to test before releaseThe simulator tests proposed rules in a sandbox and runs A/B comparisons before deployment.
The host OS can bypass its own policy checkThe Truston key evaluates policy and signs the decision, so the host cannot skip or modify it.
Identity alone does not authorize a request.The decision also uses the declared intent, current context, and active policy.
policy.json
{
  "policy_id": "fin-read-only-business-hours",
  "rules": [
    {
      "effect": "ALLOW",
      "conditions": {
        "action": "read",
        "resource_prefix": "finance.*",
        "time_range": "09:00-17:00 UTC+8",
        "day_of_week": ["Mon", "Tue", "Wed", "Thu", "Fri"],
        "agent_trust_level": ">= verified"
      }
    },
    {
      "effect": "DENY",
      "conditions": { "action": "write", "resource_prefix": "finance.*" },
      "reason": "Write operations require elevated delegation token"
    }
  ]
}
P

Can you prove it?

Produce evidence that an independent verifier can check with the Agent's public key.

ChallengeTruston control
Application logs can be edited or deletedEach step produces a signed, tamper-evident assertion.
Reviewers depend on the log providerPublic-key verification lets them check authenticity directly.
Missing records break the action historyMerkle tree anchoring exposes any gap in the assertion chain.
Evidence falls short of audit requirementsAssertion records are structured for SOC 2, GDPR, MLPS, and forensic review.
signed-assertion.json
{
  "assertion_id": "ast-2026-0810-a1b2c3",
  "agent_did": "did:truston:agent-finance-01",
  "action": "read",
  "resource": "finance.reports.q2_2026",
  "delegation_token_hash": "sha384:...",
  "policy_id": "fin-read-only-business-hours",
  "policy_decision": "ALLOW",
  "policy_hash": "sha384:...",
  "timestamp": "2026-08-10T10:30:00Z",
  "input_hash": "sha256:...",
  "output_hash": "sha256:...",
  "signature": "ml-dsa-65:...",
  "prev_assertion_hash": "sha256:...",
  "merkle_root": "sha256:..."
}
After an incident, the signed assertion identifies the Agent's credential, its delegator, the policy decision, and the action. The signature and Merkle root let an independent reviewer verify the chain.

Start with Truston

Keep trust on when Agents act.

Read the Docs Email Aleron Labs
TRUSTON / PRODUCT FILM
▶
01:30

Product demo

Truston in 90 seconds

This slot is reserved for the product demo. It will show the Truston USB key handling Agent identity, delegated authorization, local policy evaluation, and signed assertions.