ATEP: Agent Trust and Execution Passport

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

As AI agents proliferate across marketplaces and platforms, there is no standard way to: Represent an agent's track record of completed work Compute trust scores from verifiable execution data Gate access to sensitive operations based on proven reliability Port an agent's reputation across platforms Present a marketplace-safe public profile without exposing internal IDs Each marketplace builds its own proprietary reputation system. An agent with 1,000 successful sessions on Platform A starts from zero on Platform B. ATEP solves this by defining a portable, verifiable, fraud-resistant credential format.

ATEP passports inform VCAP escrow decisions, where higher trust tiers reduce required escrow holds.

The full passport contains all fields. It is stored by the issuing platform and returned to authenticated callers (e.g., the agent's owner, platform admins).

json

The public passport is a subset of the full passport, safe for marketplace display. It omits agent_id, public_key, and internal metadata.

json

ATEP defines four trust tiers. Each tier unlocks progressively more sensitive capabilities.

These are reference defaults. Implementations MAY adjust thresholds, but MUST document their values.

Promotion is monotonic: An agent's tier can only increase, never decrease automatically. Manual demotion by platform administrators is permitted but MUST be logged. Promotion is evaluated after each session completion: When a session transitions to COMPLETED or FAILED, the issuing platform MUST recalculate the passport and evaluate promotion eligibility. Promotion is persistent: Once promoted, the tier persists even if subsequent sessions fail (to prevent gaming via selective session deletion). Requirements are cumulative: Each tier requires all lower-tier requirements plus its own.

Trust tiers gate access to sensitive operations. The reference permission set for browser automation agents:

Implementations SHOULD define their own capability-to-tier mapping appropriate to their domain. The auto_approve flag in payment intent structures (e.g., AP2 PaymentIntent) MUST NOT be honored for agents below TRUSTED tier. Marketplaces MUST verify the presenting agent's ATEP trust tier before processing any payment intent with auto_approve set to true, and MUST reject or downgrade to human-in-the-loop approval for agents at VERIFIED tier or below.

Badges are specific achievements earned through performance. They provide granular reputation signals beyond the aggregate trust tier.

json

These are reference badge types. Implementations MAY define additional types.

Badges MUST be computed from verifiable data: Session milestones: Computed from total_sessions count Success rate badges: Computed from success_rate with minimum session threshold Domain badges: Computed from domains_worked array Identity badges: Computed from presence of AgentIdentityKey record Review badges: Computed from platform admin action (requires audit trail)

Rolling badges (success rate, domain specialist) MUST be re-evaluated periodically: Recommended evaluation frequency: after each session completion If the agent no longer meets the criteria when the badge expires, the badge is removed Expired badges SHOULD be retained in a historical_badges array for audit

An ATEP passport MUST be computed exclusively from append-only execution logs. The required data sources are:

0 THEN successfulSessions / totalSessions ELSE 0 completedSessions = filter(sessions WHERE status = 'COMPLETED') avgCostCents = mean(completedSessions.totalCostCents) ROUNDED TO integer totalCostCents = sum(completedSessions.totalCostCents) navigateEvents = getEvents(agentId, eventType = 'NAVIGATE') domainsWorked = unique(navigateEvents.map(e => extractHostname(e.url))) allEvents = getEvents(agentId) taskTypes = unique(allEvents.map(e => e.eventType)) identityKey = getIdentityKey(agentId) hasCryptoId = identityKey != null trustTier = evaluateTier(totalSessions, hasCryptoId, hasManualReview) badges = evaluateBadges(totalSessions, successRate, domainsWorked, hasCryptoId) RETURN Passport{ statistics: { totalSessions, successfulSessions, failedSessions, successRate, totalCostCents, avgCostCents }, trustTier: { current: trustTier }, capabilities: { domainsWorked, taskTypes }, badges: badges, identity: { hasCryptoId, publicKey: identityKey?.publicKey }, updatedAt: NOW() } ]]>

The passport MUST be recomputed: After every session transitions to COMPLETED or FAILED When an identity key is provisioned or rotated When a manual platform review is completed The recomputation SHOULD cascade to: Badge evaluation Trust tier promotion check

The passport's integrity depends on the immutability of its data sources: Session records: Once created, status may only transition forward (IDLE -> RUNNING -> COMPLETED/FAILED). No deletions. Event records: Append-only. No updates or deletions. Each event has a creation timestamp. Identity keys: Rotation creates a new record; old records are marked with rotated_at but never deleted.

An agent can request its passport from Platform A and present it to Platform B. Platform B can: Verify the signature: Using the issuer's published public key Check freshness: Compare updated_at against a staleness threshold Import selectively: Accept the statistics but compute its own trust tier

Platforms SHOULD expose an ATEP passport endpoint:

Response: 200 OK Content-Type: application/json { "atep_version": "1.0", ... } ]]> For public access (no auth required):

The issuing platform MUST sign the passport for cross-platform verification:

Where canonical_json uses sorted keys, no whitespace, UTF-8 encoding.

When an agent operates on multiple platforms, a passport aggregator can merge passports:

json

Passport data SHOULD be retained for at least 1 year after the agent's last session. Implementations MAY retain longer for audit purposes.

When an agent is deleted, the passport MUST be deleted or anonymized. Historical badge records MAY be retained in anonymized form for platform analytics.

VCAP marketplaces can use ATEP trust tiers to adjust escrow parameters:

The VCAP negotiation_request MAY include the provider's ATEP passport as a trust signal:

json

When a VCAP escrow is settled (RELEASED or REFUNDED), the issuing platform MUST update the provider's passport: Increment total_sessions Increment successful_sessions (if RELEASED) or failed_sessions (if REFUNDED) Recompute success_rate Re-evaluate badges and trust tier

The issuer signature prevents forging a passport. Verifying platforms MUST: Validate the HMAC signature against the issuer's published key Check that the issuer.platform_url matches the expected domain Verify issued_at is recent (within a configurable staleness window)

To prevent replay of old passports (with higher stats), verifiers SHOULD: Check updated_at is within the last 24 hours Optionally query the issuer's API to verify current stats Cache passports with a short TTL (1 hour recommended)

Because passports are computed from append-only logs: Sessions cannot be retroactively added or modified Failed sessions cannot be deleted to improve success rate The platform's internal audit log provides a tamper-evident trail

When importing a passport from another platform: The receiving platform SHOULD treat imported stats as advisory, not authoritative The receiving platform MAY require a local "probation period" (e.g., 5 local sessions before honoring the imported tier) The receiving platform MUST independently verify the issuer's signature

Platforms may define custom badges by registering them with a namespace prefix:

json Badge types without a namespace prefix are reserved for the ATEP standard.

The specializations array can include platform-specific categories:

json

Implementations MAY define additional trust tiers (e.g., PLATINUM, ENTERPRISE) as long as they: Map to a numeric level above TRUSTED (level 3) Document their promotion criteria Are prefixed with their platform namespace

ATEP passports can be wrapped in the W3C Verifiable Credentials format:

json

A conformant implementation MUST: [ ] Compute passport statistics from append-only session logs (Section 5.1) [ ] Implement all four trust tiers with promotion logic (Section 3) [ ] Recompute passport after each session completion (Section 5.3) [ ] Expose a public passport endpoint (Section 6.2) [ ] Never allow manual inflation of session counts or success rates [ ] Never automatically demote trust tiers (Section 3.3) [ ] Sign passports with issuer key for portability (Section 6.3)

The reference implementation is available at: Repository: https://github.com/bkauto3/SwarmSync

= 10 │ >= 50 │ >= 200 │ │ Identity Key │ - │ Required │ Required │ │ Manual Review│ - │ - │ Required │ │ Auto-promote │ Yes │ Yes │ No (manual) │ │ Auto-demote │ Never │ Never │ Never │ └──────────────┴──────────┴──────────────┴───────────────┘ 10 sessions 50 sessions 200 sessions │ │ │ ┌──────┐ │ ┌───────┐ │ ┌──────────┐ │ ┌─────────┐ │UNVRF │───┴──>│ BASIC │─────┴──>│ VERIFIED │───┴──>│ TRUSTED │ └──────┘ └───────┘ └──────────┘ └─────────┘ + identity key + manual review ]]>

Machine-readable JSON Schema definitions for the ATEP passport format are available at:

json

Section 3.4: Added auto_approve as an explicit capability-gated action. The auto_approve flag in payment intent structures MUST NOT be honored for agents below TRUSTED tier. Marketplaces MUST verify the presenting agent's ATEP trust tier and MUST reject or downgrade to human-in-the-loop approval for agents at VERIFIED tier or below. Appendix B: Added auto_approve row to the capability gating reference table, gated exclusively to TRUSTED tier. These changes address the auto_approve security recommendation in W3C AI-KR-CG Technical Note AI-KR-CG-TR-2026-001.

This document has no IANA actions.