Agent Trust Protocol (ATP)
Specification

1.Abstract

The Agent Trust Protocol (ATP) defines a machine-readable, cryptographically signed certificate format that enables autonomous agents to prove quality, security, and operational fitness to other agents and platforms without exposing sensitive internal data. ATP certificates are designed to integrate with the A2A Agent Card ecosystem, W3C Verifiable Credentials 2.0, and MCP server metadata.

An ATP certificate is to agent services what an SSL certificate is to web endpoints: a verifiable, time-bounded assertion of trustworthiness issued by an authority that can be validated by any consumer.

2.Design Principles

1. Verifiable over claimed. Every metric in a certificate must be backed by a cryptographic proof or attestation chain. Self-reported claims without evidence are explicitly marked as such.
2. Selective disclosure. Agents can prove facts about their quality (e.g., “test coverage exceeds 80%”) without revealing the actual test suite, source code, or internal architecture.
3. Composable. Certificates are modular — an agent can have a quality certificate, a security certificate, and a compliance certificate from different issuers, all independently verifiable.
4. Time-bounded. Every certificate has an explicit validity period. Stale certificates are invalid. No perpetual trust.
5. Anti-gaming. Certificate issuance requires third-party attestation. Self-certification is explicitly flagged and carries lower trust weight.
6. Interoperable. Built on JSON-LD, compatible with W3C VC 2.0, extensible via A2A Agent Card, discoverable via .well-known/.

3.Terminology

4.Certificate Structure

4.1 Envelope (JSON-LD + W3C VC 2.0 Profile)

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://atp.synctek.io/v0.2/context"
  ],
  "type": ["VerifiableCredential", "AgentTrustCertificate"],
  "id": "urn:atp:cert:2026:ba:specterqa:20260224T120000Z",
  "issuer": {
    "id": "did:web:atp.synctek.io:issuers:quality-assurance",
    "name": "Quality Assurance Authority",
    "type": "AgentTrustIssuer"
  },
  "validFrom": "2026-02-24T12:00:00Z",
  "validUntil": "2026-03-24T12:00:00Z",
  "credentialSubject": { "..." : "..." },
  "credentialSchema": {
    "id": "https://atp.synctek.io/v0.2/schema/agent-trust-certificate.json",
    "type": "JsonSchema"
  },
  "proof": { "..." : "..." }
}

4.2 Credential Subject

The version field MUST be a valid semantic version (semver 2.0.0). Pre-release versions (e.g., 1.2.0-beta.1) are permitted but MUST NOT receive Gold or Platinum tier certificates. Agents on pre-release versions are capped at Silver tier regardless of computed score.

"credentialSubject": {
  "id": "did:web:specterqa.dev",
  "type": "AgentService",
  "name": "SpecterQA",
  "version": "1.2.0",
  "trustTier": "gold",
  "trustScore": 87,
  "evaluationTimestamp": "2026-02-24T12:00:00Z",
  "qualityProfile": { "..." },
  "securityProfile": { "..." },
  "operationalProfile": { "..." },
  "governanceProfile": { "..." },
  "attestations": [ "..." ]
}

4.3 Quality Profile

"qualityProfile": {
  "testPassRate": {
    "value": 0.985,
    "method": "automated_test_suite",
    "sampleSize": 412,
    "commitment": "sha256:a1b2c3d4...",
    "attestedBy": "did:web:atp.synctek.io:issuers:quality-assurance"
  },
  "codeCoverage": {
    "value": 0.82,
    "method": "line_coverage_lcov",
    "commitment": "sha256:e5f6g7h8...",
    "attestedBy": "did:web:atp.synctek.io:issuers:quality-assurance"
  },
  "vtePassRate": {
    "value": 0.75,
    "method": "virtual_test_environment",
    "scenarioCount": 4,
    "commitment": "sha256:i9j0k1l2...",
    "attestedBy": "did:web:atp.synctek.io:issuers:quality-assurance"
  },
  "documentationCompleteness": {
    "value": 0.90,
    "method": "artifact_coverage_ratio",
    "commitment": "sha256:m3n4o5p6...",
    "attestedBy": "did:web:atp.synctek.io:issuers:quality-assurance"
  }
}

4.4 Security Profile

"securityProfile": {
  "lastSecurityReview": {
    "timestamp": "2026-02-20T00:00:00Z",
    "reviewer": "did:web:atp.synctek.io:issuers:security-review",
    "findingsSeverity": {
      "critical": 0,
      "high": 0,
      "medium": 1,
      "low": 3
    },
    "commitment": "sha256:u1v2w3x4..."
  },
  "authenticationRequired": true,
  "authMethods": ["oauth2", "apiKey"],
  "encryptionInTransit": true,
  "encryptionAtRest": true,
  "secretsExposureRisk": "none",
  "incidentCount90d": 0,
  "mttr": {
    "value": null,
    "unit": "hours",
    "note": "No incidents in evaluation period"
  },
  "attestedBy": "did:web:atp.synctek.io:issuers:security-review"
}

4.5 Operational Profile

"operationalProfile": {
  "uptimeSLA": {
    "target": 0.999,
    "measured": 0.9995,
    "period": "30d",
    "commitment": "sha256:c9d0e1f2..."
  },
  "meanResponseTime": {
    "value": 240,
    "unit": "ms",
    "percentile": "p95",
    "commitment": "sha256:g3h4i5j6..."
  },
  "incidentCount30d": 0,
  "mttrHours": null,
  "rollbackCapable": true,
  "monitoringEnabled": true,
  "alertingConfigured": true,
  "attestedBy": "did:web:atp.synctek.io:issuers:operations-monitoring"
}

4.6 Governance Profile

"governanceProfile": {
  "selfAuditGrade": "A",
  "selfAuditChecks": {
    "total": 19,
    "pass": 19,
    "warn": 0,
    "fail": 0
  },
  "gateCompletionRate": 1.0,
  "separationOfDutyEnforced": true,
  "ledgerIntegrity": "verified",
  "signedLedger": true,
  "policySnapshotsAvailable": true,
  "lastGovernanceAudit": "2026-02-24T06:00:00Z",
  "violationCount24h": 0,
  "commitment": "sha256:k7l8m9n0...",
  "attestedBy": "did:web:atp.synctek.io:issuers:quality-assurance"
}

4.7 Attestation Array

An empty attestations array is invalid. Every certificate MUST include at least one attestation. For Gold and Platinum tier certificates, the minimum is 3 attestations covering distinct claim categories (quality, security, and operational).

"attestations": [
  {
    "id": "urn:atp:att:a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "claim": "test_pass_rate >= 0.95",
    "result": true,
    "method": "threshold_proof",
    "proofType": "hash_commitment",
    "proof": {
      "type": "Sha256HashCommitment",
      "commitment": "sha256:a1b2c3d4e5f6...",
      "nonce": "randomNonce123",
      "note": "SHA-256 commitment over metric data and nonce."
    },
    "attestedBy": "did:web:atp.synctek.io:issuers:quality-assurance",
    "attestedAt": "2026-02-24T12:00:00Z"
  },
  {
    "id": "urn:atp:att:b2c3d4e5-f6a7-8901-bcde-f12345678901",
    "claim": "critical_vulnerabilities == 0",
    "result": true,
    "method": "dependency_scan",
    "proofType": "signed_report_reference",
    "proof": {
      "type": "SignedReportReference",
      "reportHash": "sha256:e5f6g7h8i9j0...",
      "ledgerEntry": "sha256:9c3f2b7e4a1d..."
    },
    "attestedBy": "did:web:atp.synctek.io:issuers:security-review",
    "attestedAt": "2026-02-24T08:30:00Z"
  }
]

5.Quality Metrics Taxonomy

5.1 Required Metrics

5.2 Recommended Metrics

5.3 Optional Metrics

6.Trust Tiers

6.1 Tier Definitions

6.2 Trust Score Computation

trustScore = (
  quality_weight     * quality_score     +   // 35%
  security_weight    * security_score    +   // 30%
  operational_weight * operational_score +   // 20%
  governance_weight  * governance_score      // 15%
)

// Quality score (0-100):
// - testPassRate:              40% weight → min(100, testPassRate * 100)
// - codeCoverage:              25% weight → min(100, codeCoverage * 125)
// - vtePassRate (if present):  20% weight, else redistributed
// - documentationCompleteness: 15% weight, else redistributed

// Security score (0-100), starts at 100, deductions:
// - Critical vulnerability:     -40 each
// - High vulnerability:         -15 each
// - Medium vulnerability:        -5 each
// - Incident in 30d:            -20 each
// - Security review older 30d:  -10
// - Security review older 90d:  -30
// - No authentication:          -25
// - No encryption in transit:   -25

// Operational score (0-100):
// - Uptime measured vs target:     0-40 points
// - Response time meets SLA:       0-20 points
// - Zero incidents 30d:           20 points
// - Monitoring + alerting enabled: 10 points each

// Governance score (0-100):
// - selfAuditGrade: A=100, B+=85, B-=70, C=50, D=25, F=0
// - gateCompletionRate: 0-100 scaled
// - SoD enforced: +10 bonus
// - Violations in 24h: -10 per violation

6.3 Anti-Gaming Measures

1. Self-attestation penalty. Claims attested by the subject itself receive a 0.7x weight multiplier.
2. Third-party bonus. Claims attested by a recognized external auditor receive a 1.2x weight multiplier (capped at 1.0 final score).
3. Freshness decay. Metrics older than half the certificate validity period receive a 0.9x multiplier. Carried-forward metrics receive 0.7x.
4. Consistency check. If testPassRate is 1.0 but vtePassRate is below 0.5, the quality score is capped at 70 (test theater detection).
5. Historical trend requirement. For Gold and Platinum tiers, the current score must be within 15 points of the trailing 3-certificate average. A sudden jump requires manual review.
6. Commitment verification. Hash commitments allow post-hoc verification. A mismatch invalidates the entire certificate.

7.Proof System

7.1 Supported Proof Types

7.2 Hash Commitment Protocol

For any metric M with value V:

1. Issuer generates random nonce N (32 bytes from a CSPRNG), encoded as lowercase hexadecimal (64-character string).
2. Issuer computes commitment C = SHA-256(canonical_json({"metric": M, "value": V, "nonce": N})).
3. Certificate contains {"commitment": "sha256:C", "nonce_hint": first_4_chars(N)}.
4. On challenge, issuer provides V and full N. Verifier recomputes C and checks match.

7.3 Selective Disclosure Protocol

For proving metric ≥ threshold without revealing the exact metric value:

1. Issuer computes above = (value ≥ threshold).
2. Issuer includes {"disclosedValue": "above_threshold", "threshold": T, "exactValueDisclosed": false}.
3. Challenge-response endpoint at /.well-known/atp/challenge/{attestation_id}. Issuer MUST respond within 48 hours or the attestation is considered invalid.

7.4 Certificate Signing

"proof": {
  "type": "DataIntegrityProof",
  "cryptosuite": "eddsa-jcs-2022",
  "created": "2026-02-24T12:00:00Z",
  "verificationMethod": "did:web:atp.synctek.io:issuers:quality-assurance#key-1",
  "proofPurpose": "assertionMethod",
  "proofValue": "z3MvGcVxzRMFJxFE..."
}

8.Key Management and Distribution

ATP uses standard Ed25519 key infrastructure. Issuers publish public keys at:

https://{issuer_domain}/.well-known/atp/keys/{key_id}.pem

Issuers are identified via did:web. The DID path did:web:atp.synctek.io:issuers:quality-assurance resolves to:

https://atp.synctek.io/issuers/quality-assurance/did.json

Keys have a maximum lifetime of 365 days. Rotation publishes a new key and signs a key-rotation event in the issuer’s ledger. Key history is maintained at /.well-known/atp/keys/history.json.

9.Integration Points

9.1 A2A Agent Card Extension

"capabilities": {
  "a2aVersion": "1.0",
  "trustCertificates": {
    "current": "https://specterqa.dev/.well-known/atp/certificate.json",
    "trustTier": "gold",
    "trustScore": 87,
    "validUntil": "2026-03-24T12:00:00Z",
    "issuer": "did:web:atp.synctek.io:issuers:quality-assurance"
  }
}

9.2 MCP Server Metadata Extension

{
  "name": "specterqa-mcp",
  "version": "1.2.0",
  "tools": ["..."],
  "trustCertificate": {
    "url": "https://specterqa.dev/.well-known/atp/certificate.json",
    "trustTier": "gold",
    "trustScore": 87
  }
}

9.3 Standalone Discovery

Any agent service can publish its certificate at:

https://{service_domain}/.well-known/atp/certificate.json

This follows the RFC 8615 .well-known convention and requires no protocol-specific integration.

9.4 Certificate Chain (Multi-Issuer)

A service may hold multiple certificates from different issuers:

/.well-known/atp/certificate.json         # Primary (highest-tier) certificate
/.well-known/atp/certificates/quality.json  # quality-profile issuer
/.well-known/atp/certificates/security.json # security-profile issuer
/.well-known/atp/certificates/ops.json      # operational-profile issuer
/.well-known/atp/certificates/index.json    # Index of all certificates

9.5 Composite Trust Score Computation

compositeTrustTier: The MINIMUM tier across all valid (non-expired, non-revoked) certificates in the index.

compositeTrustScore: The weighted average of individual certificate trust scores using domain weights from §6.2 (quality 35%, security 30%, operational 20%, governance 15%).

10.Verification Flow

10.1 Standard Verification

1. FETCH  /.well-known/atp/certificate.json from subject
2. PARSE  JSON-LD envelope, extract issuer DID
3. RESOLVE issuer DID → DID document → public key
4. VERIFY  Ed25519 signature over canonical JSON of credential
5. CHECK   validFrom <= now <= validUntil
6. CHECK   credentialSubject.id matches expected subject
7. EXTRACT trustTier and trustScore
8. (Optional) CHALLENGE one or more attestations
9. CACHE   result with TTL = min(24h, time_to_validUntil)

10.2 Quick Trust Check (Lightweight)

1. FETCH  /.well-known/atp/certificate.json
2. CHECK  validUntil > now
3. READ   trustTier and trustScore
4. APPLY  policy: require >= silver

10.3 Deep Verification (High-Stakes)

1. Standard Verification (§10.1)
2. CHALLENGE all attestations in the "required" category
3. VERIFY  at least 2 independent issuers attest to the security profile
4. CHECK   historical trend: no anomalous score jumps
5. VERIFY  issuer's own certificate (recursive, bounded to 3 levels)

11.Threat Model & Mitigations

11.1 Fail-Closed Mandate

Verifiers MUST implement fail-closed behavior for all trust decisions:

1. A missing certificate (no .well-known/atp/certificate.json) MUST be treated as trust tier unrated.
2. A certificate that fails signature verification MUST be treated as unrated.
3. A certificate where validUntil has passed MUST be treated as unrated.
4. A certificate where credentialSubject.id does not match the expected service identity MUST be treated as unrated.
5. Any trust-gated operation MUST evaluate the above checks before granting access.
6. The Quick Trust Check (§10.2) MUST NOT be used for any trust-gated operation.

11.2 Certificate Lifetime Caps

For high-frequency pipelines, verifiers MUST require certificates no older than 72 hours. Issuers MUST enforce a minimum interval of 7 days between certificates for the same subject.

11.3 Cryptographic Agility

The cryptosuite field MUST be an enum. ATP v0.2.0 valid values:

• eddsa-jcs-2022 — Current default. Ed25519 with JCS canonicalization.
• ecdsa-jcs-2019 — Alternative EC suite.
• mldsa-jcs-2025 — Reserved for post-quantum ML-DSA (NIST FIPS 204). Not yet active.
• slhdsa-jcs-2025 — Reserved for post-quantum SLH-DSA (NIST FIPS 205). Not yet active.

When post-quantum suites are activated (expected ATP v1.0.0), issuers MUST offer dual-signed certificates during a transition period of no less than 180 days.

11.4 Anti-Downgrade Enforcement

1. Verifiers MUST configure a minimum acceptable trust tier. Default minimum: bronze.
2. Verifiers MUST reject certificates where trustTier is below the configured minimum.
3. Verifiers MUST NOT accept unrated certificates for trust-gated operations unless explicitly permitted.
4. Clock skew MUST NOT exceed 5 minutes. Verifiers MUST reject certificates where validFrom is more than 5 minutes in the future.

11.5 Sybil Resistance

1. Issuers MUST be registered in the trusted issuer registry before their certificates are accepted for Gold or Platinum tier claims.
2. Issuers MUST implement rate limits: no more than 100 certificates per rolling 24-hour UTC window across all subjects.
3. For Gold and Platinum certificates, the issuer MUST verify the subject’s DID document resolves to a live, reachable service before issuing.
4. Verifiers MUST maintain issuer reputation scores. An issuer with >10% revocation rate in a 90-day window MUST be treated as untrusted.

11.6 Collusion Detection and Attestor Rotation

1. For Gold and Platinum tier, at least 2 independent attestors MUST have attested to distinct claim categories within the trailing 3 certificates.
2. “Independent” means: no common ownership, no shared signing keys, and no prior cross-certification within 90 days.
3. If issuer A certified B and B certified A within 90 days, this constitutes a certification ring. Gold and Platinum ring-tainted certificates MUST be rejected entirely.
4. Self-certification is permitted for Bronze and Silver (with 0.7x penalty). Self-certification is PROHIBITED for Gold and Platinum.

11.7 Score Manipulation Guards

1. For Platinum and Gold, testPassRate and codeCoverage MUST be measured by an attestor that is not the subject.
2. The consistency check in §6.3 is normative for Gold and Platinum: if testPassRate ≥ 0.95 but vtePassRate < 0.50, trust score MUST be capped at 70.
3. Score history MUST be verifiable. Issuers MUST publish certificate history index with the last 5 certificates.
4. Issuers MUST NOT issue certificates more than 7 days before the evaluation timestamp.

11.7a Considerations for AI-Native Verifiers

1. AI-based verifiers MUST treat all certificate field values as untrusted data, regardless of signature validity. Signature verification confirms data integrity; it does not confirm that field content is safe for AI model consumption.
2. Implementations SHOULD enforce maximum lengths on free-text fields: claim (256 chars), method (128 chars), note (512 chars), name (128 chars).
3. The VTE pass rate metric (§5.2) provides partial mitigation by testing real-world behavior.

11.8 Known Limitations

12.Multi-Issuer Trust Model

ATP v0.2.0 elevates multi-issuer trust to a first-class protocol feature. A single composite certificate can embed independently-signed profiles from different issuers. Each profile may carry its own issuer and proof block alongside the top-level certificate envelope proof.

Issuer Trust Weight Multipliers

Multi-issuer verification requirements: each profile’s embedded proof MUST be verified independently. If any profile proof verification fails, that profile’s contribution is computed as self-attested (0.7x). For Platinum and Gold, at least 2 distinct profile issuers MUST appear in the proofs array.

13.Certificate Lifecycle

Issuance

Subject requests certificate from Issuer
  → Issuer runs evaluation (tests, scans, audits)
  → Issuer computes metrics and trust score
  → Issuer generates attestations with proofs
  → Issuer signs certificate
  → Issuer delivers to Subject (MUST occur within 24h of signing)
  → Subject publishes at /.well-known/atp/certificate.json
  → Issuer logs issuance event in its ledger

Revocation

Revocation is published as a signed revocation event at /.well-known/atp/revocations/{certificate_id}.json. Verifiers MUST check the revocation endpoint during standard verification. If the endpoint is unreachable, verifiers MUST treat the certificate as unrated for trust-gated operations.

Revocation reasons: security_incident, metric_degradation, issuer_key_compromise, subject_request.

Expiration

Expired certificates MUST NOT be accepted. A 24-hour grace period is permitted only when renewal is actively in progress, signaled by a machine-readable grace token at /.well-known/atp/renewal-grace/{certificate_id}.json.

14.Privacy Considerations

The following categories of information MUST NOT appear in any ATP certificate field:

1. Source code — file names, function names, module paths, repository names.
2. Test suite details — test file names, test case names, test framework configuration.
3. Internal architecture — module names, department names, team names, internal service topology.
4. Agent prompts — system prompts, persona descriptions, instruction content.
5. Deployment configuration — server hostnames, internal IP ranges, cloud regions, container names.
6. Cost and budget internals — per-request costs, monthly burn rate, budget limits.
7. Customer data or PII.
8. Exact financial metrics — revenue, MRR, ARR, specific financial figures.
9. Internal governance violation details — only aggregate counts are permitted.
10. Private key material — signing keys, API tokens, secrets, credentials.
11. DID path components exposing organizational structure — use functional role names (quality-assurance, security-review), never internal department or product names.

16.Security Considerations

For the full normative threat model with mitigations for all 25 identified attack vectors, see §11.

• Key compromise: Issuer MUST publish key-rotation event within 24 hours of detection and re-issue all active certificates.
• Replay attacks: Certificates are time-bounded. Nonces in hash commitments MUST be cryptographically random and MUST NOT be reused. Maximum clock skew: 5 minutes.
• Issuer collusion: Self-certification incurs 0.7x weight penalty. Self-certification MUST NOT be used for Gold or Platinum.
• Certificate substitution: Verifiers MUST verify credentialSubject.id matches expected service identity.
• Downgrade attacks: Verifiers MUST enforce minimum trust tier requirements.
• Privacy leakage: See §14 for the complete MUST NOT disclose list.

17.Relationship to Existing Standards

18.Scope of Attestation and Liability

ATP certificates are attestations of observed quality posture at the time of evaluation. They are not warranties of future performance, safety guarantees, or liability instruments.

• Issuers attest that the certified system met defined thresholds when evaluated. Issuers are not liable for reliance losses beyond the scope of their certification methodology.
• Verifiers bear responsibility for correctly implementing the verification protocol, including fail-closed behavior, revocation checking, and expiration enforcement.
• Certificate consumers must perform their own risk assessments. An ATP trust tier is one input to a delegation decision, not the sole determinant.

Changelog