Trust Levels

Overview

IDProva implements a progressive trust model. Agents are not trusted by default — they earn trust through verifiable mechanisms, from simple self-declaration to continuous monitoring with automated demotion.

L0 (Unverified) → L1 (Domain) → L2 (Org) → L3 (Attested) → L4 (Monitored)

Trust Level Definitions

L0 — Self-Declared (Unverified)

The agent has created a DID Document but has not undergone any external verification.

• Verification: None — the agent’s claims are self-asserted
• Use case: Development, testing, local agents
• Risk: Identity claims are unverified; impersonation is trivial

L1 — Domain-Verified

The agent’s controller has proven ownership of the domain in the DID’s authority component via DNS TXT records.

• Verification: DNS TXT record at _idprova.{domain} containing the controller’s DID
• Use case: Production agents where domain ownership provides baseline trust
• DNS record format:

  _idprova.example.com TXT "did=did:idprova:example.com:controller"

L2 — Organisation-Verified

The agent’s controlling organisation has been verified by a registry operator through out-of-band checks.

• Verification: Registry operator confirms organisation identity (ABN check, domain whois, manual review)
• Use case: Enterprise agents interacting across organisational boundaries
• Trust signal: A trusted third party has confirmed the organisation exists and controls the domain

L3 — Third-Party Attested

The agent has been assessed and attested by an independent third party (auditor, certification body, IRAP assessor).

• Verification: Signed attestation from an accredited assessor
• Use case: Government systems, regulated industries, high-value transactions
• Trust signal: Professional assessment of the agent’s security controls and compliance posture

L4 — Continuously Monitored

The agent is under active, continuous monitoring by an authorised monitoring service. Behaviour anomalies trigger automated trust demotion.

• Verification: Active monitoring service with real-time receipt analysis
• Use case: Highest-security environments, agents handling sensitive data
• Trust signal: Ongoing behavioural validation, not just point-in-time assessment
• Special property: L4 agents can be automatically demoted to a lower level if monitoring detects policy violations

Trust Properties

Directional

Trust is not symmetric. Agent A may trust Agent B at L2 while Agent B trusts Agent A at only L1. Each party independently evaluates the other.

Contextual

An agent’s trust level may vary by scope. An agent may be L3 for mcp:tool:filesystem:read but L1 for mcp:tool:filesystem:write. High-trust operations may require higher trust levels.

Temporal

Trust levels can change:

• Elevation: Agent undergoes additional verification, trust level increases
• Demotion: Attestation expires, monitoring detects violations, trust level decreases
• Revocation: Agent is deactivated, trust drops to zero

Trust in Practice

Policy Decisions

Verifiers use trust levels to make policy decisions:

if agent.trustLevel >= L2:
    allow mcp:tool:database:write
elif agent.trustLevel >= L1:
    allow mcp:tool:database:read
else:
    reject  # L0 agents not permitted for database operations

Cross-Organisation Interactions

When agents from different organisations interact:

1. Both agents resolve each other’s DID Documents
2. Both check the other’s trust level
3. Each applies its own trust policy
4. The interaction proceeds at the lower of the two trust levels

Trust Elevation Path

A typical agent’s trust journey:

1. Created → L0 (self-declared)
2. Domain DNS TXT added → L1 (domain-verified)
3. Registry operator verifies org → L2 (org-verified)
4. IRAP assessment completed → L3 (third-party attested)
5. Monitoring service activated → L4 (continuously monitored)

Next Steps

• Identity (AIDs) — Agent Identity Documents
• Delegation (DATs) — Scoped delegation tokens
• Audit (Receipts) — Tamper-evident action records