RFC-0018: Automated Governance Attestation Protocol (AGAP-1)

RFC: RFC-0018
Status: Draft
Version: 0.1.0
Created: 2026-04-09
Updated: 2026-04-09
Author: AEGIS Initiative, AEGIS Operations LLC
Repository: aegis-governance
Target milestone: Q3 2026
Supersedes: None
Superseded by: None

Summary

This RFC defines the Automated Governance Attestation Protocol (AGAP-1): the protocol by which AEGIS Federation Network nodes request, issue, verify, renew, and revoke cryptographically signed governance attestations without manual review.

An attestation is a federation-signed statement that a specific entity (DID) satisfies a specific compliance profile (e.g., NIST AI RMF, EU AI Act, ISO 42001) based on verifiable behavioral evidence — not self-declaration.

AGAP-1 is the protocol layer that turns the existing governance attestation lexicon (com.aegisfederation.governance.attestation) into a working federation-wide compliance verification system.

Motivation

ADR-0010 designated governance attestation fees as the primary revenue mechanism for the AEGIS Federation Network. The economic model assumes that attestations can be issued, verified, and revoked at federation scale without human intervention for the common case. Without an automated protocol, every attestation requires manual review — which does not scale and undermines the “verified compliance” value proposition that justifies the fee.

The federation also needs attestation for non-economic reasons:

• Compliance evidence at scale. Organizations need machine-readable evidence that their AI deployments meet regulatory requirements. Manual audits do not scale to the deployment density of agentic AI.
• Decentralized trust. A federation-issued attestation backed by behavioral evidence is structurally stronger than a self-declared compliance statement or a single-auditor certification, because it is verified by multiple independent nodes against published audit trails.
• Revocation propagation. When a previously-attested entity violates its governance commitments, the federation must propagate revocation faster than the violation can spread. Manual revocation processes cannot meet this latency requirement.
• Continuous verification. Compliance is not a point-in-time property. An entity that was compliant yesterday may not be compliant today. Continuous attestation requires automated re-verification.

The current state of the federation has the lexicon schema (governance_attestation) and the trust model (GFN-1) but no protocol that binds them into a working attestation system. This RFC defines that protocol.

Guide-Level Explanation

What an attestation is

An attestation is a record published to the federation that says, in effect:

“Federation node did:aegis:mainnet:verifier-N certifies that entity did:aegis:mainnet:agent-X operated in compliance with the nist-ai-rmf-1.0 profile during the period 2026-04-01 through 2026-05-01, based on N audit records and M federation observations. This attestation expires on 2026-07-01.”

The record is cryptographically signed by the issuing federation node, optionally co-signed by a sponsoring authority (an L1+ trust class entity that vouches for the requesting entity), and published to the federation under the existing com.aegisfederation.governance.attestation lexicon.

Three attestation tiers

AGAP-1 defines three tiers, matching the ADR-0010 economic model:

A Tier 0 attestation is essentially a notarized self-statement. It costs nothing and provides nothing beyond proof that the entity claimed compliance at a moment in time. It is included in basic federation participation.

Tier 1 is the workhorse. The requesting entity points to its audit endpoint; a federation node fetches a sample of records, validates them against the declared capability set, checks the sponsoring authority’s signature, and issues an attestation if everything matches.

Tier 2 is Tier 1 plus a re-verification schedule. The federation node re-runs verification on a configurable interval (default: weekly), watches the federation signal stream for circumvention or anomaly events naming the attested DID, and automatically revokes if either the re-verification or the signal monitoring flags a problem.

The lifecycle, end-to-end

A new entity wanting a Tier 1 attestation goes through this flow:

1. Registration. The entity submits a RegistrationRequest containing its DID, declared capability set hash, audit endpoint URL, target compliance profile, and the DID of a sponsoring authority.

2. Sponsorship validation. The federation node verifies that the sponsoring authority is in trust class L1 or higher (per GFN-1 §2.2) and that the sponsoring authority has co-signed the registration request. If the sponsoring authority is appearing for the first time ever in the federation, this step requires manual approval — see “First-time sponsorship” below.

3. Verification. The federation node performs a deterministic sequence of automated checks against the entity’s published evidence (see §5.5). Each check produces a typed verification result. The verification process is logged in full for auditability.

4. Issuance. If all checks pass, the federation node signs an AttestationIssuance record, publishes it to the entity’s PDS as a com.aegisfederation.governance.attestation record, and propagates it through the federation feeds. Payment (if any) is processed at this step. If any check fails, an AttestationRefusal record is issued instead, with the failed check and remediation guidance.

5. Renewal (Tier 2). The federation node re-runs verification on the configured schedule. If the re-verification succeeds, a new attestation is issued and chained to the previous one (via hash). If it fails, the attestation enters a 14-day grace period during which the entity can remediate; if not remediated, revocation follows.

6. Revocation. Triggered by failed re-verification, federation anomaly signals naming the DID, key compromise notifications, manual dispute, or sponsoring authority revocation. A RevocationNotice record is published to the federation with a structured reason code and is propagated with elevated priority.

What changes for someone using the federation

For an entity that wants to be attested, the surface area is small: publish governance audit records to a stable endpoint, declare your capability set and compliance profile, get sponsored by an L1+ entity, and pay the fee. The federation handles the rest.

For an entity that wants to consume attestations (e.g., a regulator verifying that a deployed agent is compliant), the surface area is also small: query the federation for attestations naming the DID of interest, verify the issuing node’s signature against the published key, check that the attestation has not been revoked, and read the verification metadata to understand what was checked and when.

For a federation node operator, the work is in the verification engine and the dispute resolution workflow. The protocol itself is mechanical.

Reference-Level Explanation

5.1 Terminology

• Subject — the entity (DID) being attested. Also called the “requesting entity” during registration.
• Issuer — the federation node that signs and publishes an attestation. Must be in trust class L0 or L1.
• Sponsor — a trust class L1 or higher entity that vouches for the subject. Co-signs the registration request.
• Compliance profile — a named, versioned set of compliance requirements (e.g., nist-ai-rmf-1.0, eu-ai-act-2024-1689, iso-42001-2023). Each profile defines what evidence is required and how it is evaluated.
• Attestation chain — the sequence of attestations issued to the same subject under the same compliance profile, linked by previous_hash.
• Verification window — the time range over which audit evidence is evaluated for a given attestation.
• Grace period — the time between failed re-verification and automatic revocation (default: 14 days).

5.2 Attestation Tiers

The three tiers differ only in the verification depth and renewal model. The wire format is identical across tiers; the tier field in the AttestationIssuance record indicates which level of verification was performed.

5.3 Attestation Lifecycle State Machine

              ┌──────────┐
              │ PENDING  │  (registration submitted)
              └────┬─────┘
                   │ verify checks pass
                   ▼
              ┌──────────┐
              │ VERIFIED │  (checks complete, awaiting issuance)
              └────┬─────┘
                   │ payment processed (if any)
                   ▼
              ┌──────────┐
        ┌─────│ ATTESTED │─────┐
        │     └────┬─────┘     │
        │          │           │
        │  re-verify           │  expiry passes
        │     fails            │  (no renewal)
        │          ▼           │
        │     ┌─────────┐      │
        │     │ GRACE   │      │
        │     └────┬────┘      │
        │          │           │
        │  remediation          │
        │   timeout             │
        │          ▼           ▼
        │     ┌─────────┐  ┌─────────┐
        └────▶│ REVOKED │  │ EXPIRED │
              └─────────┘  └─────────┘
                  ▲             │
                  │             │ re-attestation request
   manual / signal              │
   trigger                      ▼
                            ┌──────────┐
                            │ PENDING  │ (new chain entry)
                            └──────────┘

State transitions:

REVOKED is terminal per attestation, not per subject. A subject whose attestation has been revoked may submit a new RegistrationRequest after addressing the revocation reason; this starts a new attestation chain with a fresh previous_hash of null.

5.4 Message Schemas

AGAP-1 defines five message types. All AGAP-1 messages are JSON, conform to the AEGIS governance event envelope (governance_event_envelope.schema.json), and are published as records under the com.aegisfederation.governance.attestation lexicon namespace.

5.4.1 RegistrationRequest

Submitted by the subject (or by the sponsor on behalf of the subject) to initiate an attestation request.

{
  "event_type": "agap.registration_request",
  "agap_version": "1.0",
  "subject_did": "did:aegis:mainnet:agent-x",
  "compliance_profile": "nist-ai-rmf-1.0",
  "capability_set_hash": "sha256:abc123...",
  "audit_endpoint": "https://audit.example.com/aegis/v1",
  "sponsor_did": "did:aegis:mainnet:auditor-y",
  "tier_requested": 1,
  "verification_window_start": "2026-04-01T00:00:00Z",
  "verification_window_end": "2026-05-01T00:00:00Z",
  "subject_signature": "ed25519:...",
  "sponsor_signature": "ed25519:...",
  "request_id": "uuid-v4",
  "timestamp": "2026-05-02T10:00:00Z"
}

Required fields: all of the above except sponsor_did and sponsor_signature, which are required for tier ≥ 1.

5.4.2 VerificationResult

Internal-to-issuer record produced by the verification engine. Not published to the federation but persisted in the issuer’s audit log and referenced by hash from the issued attestation.

{
  "event_type": "agap.verification_result",
  "request_id": "uuid-v4",
  "checks": [
    {
      "check_id": "did_validity",
      "passed": true,
      "evidence_hash": "sha256:..."
    },
    {
      "check_id": "audit_endpoint_reachable",
      "passed": true,
      "sample_size": 50,
      "sample_window": "PT24H"
    },
    {
      "check_id": "capability_set_match",
      "passed": true,
      "registry_hash": "sha256:..."
    },
    {
      "check_id": "sponsor_trust_class",
      "passed": true,
      "sponsor_class": "L1_AUTHORITY"
    },
    {
      "check_id": "no_outstanding_revocations",
      "passed": true
    },
    {
      "check_id": "compliance_profile_evidence",
      "passed": true,
      "evidence_records_evaluated": 247,
      "evidence_records_matched": 247
    }
  ],
  "overall_result": "PASS",
  "verified_at": "2026-05-02T10:01:30Z",
  "issuer_did": "did:aegis:mainnet:verifier-1"
}

5.4.3 AttestationIssuance

The signed attestation record, published to the federation.

{
  "event_type": "governance_attestation",
  "agap_version": "1.0",
  "tier": 1,
  "subject_did": "did:aegis:mainnet:agent-x",
  "issuer_did": "did:aegis:mainnet:verifier-1",
  "sponsor_did": "did:aegis:mainnet:auditor-y",
  "compliance_profile": "nist-ai-rmf-1.0",
  "capability_set_hash": "sha256:abc123...",
  "verification_result_hash": "sha256:def456...",
  "verification_window_start": "2026-04-01T00:00:00Z",
  "verification_window_end": "2026-05-01T00:00:00Z",
  "issued_at": "2026-05-02T10:02:00Z",
  "valid_until": "2026-08-02T10:02:00Z",
  "previous_hash": null,
  "chain_position": 1,
  "issuer_signature": "ed25519:...",
  "sponsor_signature": "ed25519:...",
  "subject_signature": "ed25519:..."
}

The previous_hash field links this attestation to the most recent prior attestation in the same chain (same subject + profile). For the first attestation in a chain, previous_hash is null and chain_position is 1.

5.4.4 RenewalRequest

Submitted by the subject (or auto-generated by Tier 2 schedules) to extend an attestation chain.

{
  "event_type": "agap.renewal_request",
  "agap_version": "1.0",
  "subject_did": "did:aegis:mainnet:agent-x",
  "previous_attestation_hash": "sha256:...",
  "verification_window_start": "2026-05-01T00:00:00Z",
  "verification_window_end": "2026-06-01T00:00:00Z",
  "subject_signature": "ed25519:...",
  "request_id": "uuid-v4",
  "timestamp": "2026-06-02T10:00:00Z"
}

A renewal does not require re-stating the capability set or sponsor — those are inherited from the previous attestation in the chain.

5.4.5 RevocationNotice

Published by the issuer (or by an authorized dispute resolver) to revoke an existing attestation. Propagated with elevated priority.

{
  "event_type": "agap.revocation_notice",
  "agap_version": "1.0",
  "revoked_attestation_hash": "sha256:...",
  "subject_did": "did:aegis:mainnet:agent-x",
  "issuer_did": "did:aegis:mainnet:verifier-1",
  "reason_code": "SIGNAL_DETECTED",
  "reason_detail": "Federation signal abc-123 reports T10004 circumvention by subject DID",
  "evidence_refs": ["sha256:..."],
  "revoked_at": "2026-06-15T14:23:00Z",
  "priority": "HIGH",
  "issuer_signature": "ed25519:..."
}

Defined reason_code values:

5.5 Verification Algorithm

The verification engine runs the following ordered sequence. Each step either passes (continue) or fails (abort with refusal). The order is normative — earlier checks are cheaper and gate later checks.

1. Schema validation. The RegistrationRequest validates against the AGAP-1 schema. Required fields present, types correct, signatures well-formed.

2. DID validity. Subject DID and (if present) sponsor DID resolve to active DID documents with current public keys. Format matches GFN-1 §2.1.

3. Signature verification. Subject signature verifies against subject DID document. Sponsor signature (if present) verifies against sponsor DID document. Signing key is active (not revoked, within validity period).

4. Sponsor trust class. For tier ≥ 1, the sponsor’s GFN-1 trust class is L1 or higher. First-time sponsors require manual approval (see §5.9).

5. Capability set hash match. The declared capability_set_hash resolves to a known capability set in the registry. The capability set is not revoked or deprecated.

6. Audit endpoint reachable. The audit endpoint URL is reachable over HTTPS, returns valid AEGIS audit records (per the audit log schema), and the records are signed by the subject DID’s key.

7. Audit sampling. Fetch a sample of audit records covering the verification window. Sample size is the larger of 10 records or 1% of total records in the window, capped at 1000. The sample must contain records from both the start and end of the window (no gaps suggesting selective publishing).

8. Capability declarations match exercised capabilities. Every action in the audit sample maps to a capability that is in the declared capability set. No exercised capability is outside the declared set (no overclaiming or underclaiming).

9. No outstanding revocations. No RevocationNotice exists in the federation for any prior attestation in this chain that has not been resolved by remediation evidence.

10. No active anomaly signals. No federation signals (com.aegisfederation.governance.signal) of severity ≥ HIGH naming the subject DID exist in the verification window or in the 7 days preceding it.

11. Compliance profile evidence. The audit sample is evaluated against the compliance profile’s evidence requirements. For nist-ai-rmf-1.0, this means: governance records exist for each function (Govern, Map, Measure, Manage); high-risk decisions were escalated where required; audit completeness exceeds the profile’s minimum threshold.

12. Sufficient verification window. The verification window is long enough to provide statistically meaningful evidence. Default minimum: 30 days of operational evidence.

If all 12 checks pass, the engine produces a VerificationResult with overall_result: PASS and proceeds to issuance. If any check fails, the engine produces an AttestationRefusal record with the failed check ID and remediation guidance.

5.6 Cryptographic Model

Signing algorithm. All AGAP-1 signatures use ed25519 (preferred) or rsa-sha256 (legacy). New implementations MUST support ed25519. RSA support is provided for compatibility with existing federation infrastructure but is deprecated for new deployments.

Key management. Each federation node maintains a key pair bound to its DID document. Keys are rotated on a configurable schedule (default: annually). Previous keys remain valid for verification of historical attestations for 30 days after rotation.

Hash chain. Attestations in the same chain (same subject + profile) form a hash chain via the previous_hash field. Any tampering with a historical attestation in the chain invalidates all subsequent attestations. Federation nodes verify chain integrity when consuming attestation records.

Multi-signature attestations. Tier 1 and Tier 2 attestations carry three signatures: subject, issuer, sponsor. All three must validate against current keys for the attestation to be considered valid. The issuer signature is the authoritative federation signature; the sponsor signature provides accountability; the subject signature acknowledges receipt and consent.

Replay protection. The request_id field is a UUID-v4 unique per subject per 24-hour window. Federation nodes maintain a replay cache (TTL: 24 hours minimum) and reject requests with duplicate request_id values.

Timestamp freshness. Per GFN-1 §2.1.3, the timestamp field must be within ±5 minutes of the receiving node’s clock at ingestion time. Late requests are rejected and logged.

5.7 PDS Integration

AGAP-1 records are published to AT Protocol Personal Data Servers under the existing com.aegisfederation.governance.attestation lexicon. The lexicon schema requires extension to support AGAP-1 fields — see “Schema Extensions” below.

Publishing flow:

1. The issuer signs the AttestationIssuance record.
2. The issuer POSTs the record to the subject’s PDS via the com.atproto.repo.createRecord API.
3. The subject’s PDS validates the lexicon schema and stores the record.
4. The PDS emits a firehose event for the new record.
5. Federation feed generators subscribed to the firehose pick up the new record and propagate it.

Schema extensions required:

The current governance_attestation.schema.json has the minimum fields (aegis_version, risk_model, compliance_profile, audit_timestamp, auditor_identity). AGAP-1 requires additional fields:

• agap_version (required, const 1.0)
• tier (required, integer 0–2)
• subject_did (required, DID format)
• issuer_did (required, DID format)
• sponsor_did (optional for tier 0, required for tier ≥ 1)
• verification_result_hash (required for tier ≥ 1)
• verification_window_start (required, RFC 3339 datetime)
• verification_window_end (required, RFC 3339 datetime)
• valid_until (required, RFC 3339 datetime)
• previous_hash (nullable, hash format)
• chain_position (required, positive integer)
• issuer_signature (required, signature format)
• sponsor_signature (optional for tier 0, required for tier ≥ 1)
• subject_signature (required, signature format)

The schema extension is non-breaking: existing records without AGAP-1 fields are treated as Tier 0 attestations issued under pre-AGAP-1 conventions and are honored for the duration of their declared validity.

5.8 Federation Propagation

Attestations propagate through the federation feed network in two priority classes:

Normal priority — AttestationIssuance and RenewalRequest records. Propagated through the standard feed firehose. No latency guarantees beyond best-effort.

Elevated priority — RevocationNotice records. Propagated immediately by all feed generators. Federation nodes maintaining attestation caches MUST process RevocationNotice records ahead of pending issuance records.

Federation nodes consuming attestations MUST:

1. Maintain a local cache of attestations they have observed.
2. Process RevocationNotice records before serving any cached attestation that matches the revoked hash.
3. Verify the issuer’s signature against the issuer’s current DID document on every consumption (not only on first ingestion).
4. Report verification failures back to the federation as anomaly signals.

Cache TTL. Federation nodes SHOULD cache attestations for the shorter of the attestation’s valid_until value or 7 days, then re-fetch from the source PDS to confirm the record has not been withdrawn.

5.9 Sponsoring Authority Model

A sponsor is an L1+ trust class entity that vouches for a subject’s governance practices. Sponsors carry liability for the entities they sponsor: a sponsored entity that violates governance contributes negatively to the sponsor’s trust score under GFN-1 §3.

First-time sponsorship requires manual approval. When a new sponsor DID appears in the federation for the first time, the federation cannot automatically assess its trust class. The RegistrationRequest is held in PENDING state and a notification is generated for the AEGIS Initiative dispute resolution body. Manual approval establishes the sponsor’s initial trust class and enables future automated sponsorship.

After first-time approval, sponsorship is fully automated. The sponsor’s signature on a RegistrationRequest is sufficient to satisfy the sponsorship check, as long as the sponsor’s trust class remains L1 or higher.

Sponsor revocation. If a sponsor’s own attestation is revoked or its trust class drops below L1, all attestations sponsored by that sponsor automatically enter GRACE state. The subjects have 14 days to obtain a new sponsor or their attestations are revoked with reason code SPONSOR_REVOKED.

5.10 Renewal Logic

Tier 0 and Tier 1 renewals are manual. The subject submits a RenewalRequest referencing the previous attestation hash. The issuer re-runs the verification algorithm against the new verification window and either issues a new attestation in the chain or refuses.

Tier 2 renewals are automatic. The issuer schedules re-verification on the configured interval (default: weekly). Each successful re-verification produces a new attestation that extends the chain. The subject is notified of each renewal but no action is required.

If a Tier 2 re-verification fails, the attestation enters GRACE state. The subject is notified with the failed check ID and remediation guidance. The subject has the grace period (default: 14 days) to remediate. During the grace period, the attestation is still served as ATTESTED to consumers but with a grace_warning flag indicating that re-verification has failed.

If remediation is verified before the grace period ends, the attestation returns to ATTESTED and a new chain entry is issued with a remediation_evidence_hash field. If the grace period expires without remediation, a RevocationNotice is issued with reason REVERIFY_FAILED.

5.11 Revocation Triggers

Revocation is triggered by any of the following:

1. Failed Tier 2 re-verification after grace period expiry.
2. Federation anomaly signal of severity ≥ HIGH naming the subject DID, where the signal source has trust class ≥ L1.
3. Key compromise notification via the com.aegisfederation.governance.incident lexicon naming the subject DID.
4. Sponsor revocation as described in §5.9.
5. Manual dispute resolution via the dispute mechanism in §5.12.
6. Compliance profile change that materially alters what evidence the profile requires. Subjects must re-attest under the new profile version.
7. Subject-initiated withdrawal — the subject voluntarily revokes its own attestation.

5.12 Dispute Resolution

Disputes are filed by any federation entity with trust class L1 or higher via a com.aegisfederation.governance.signal record of subtype agap.dispute. The dispute names the attestation hash being disputed, the disputing entity, and the dispute rationale.

Response window: 14 days from publication. During this window, the issuer reviews the dispute, gathers additional evidence if needed, and either:

• Upholds the attestation (publishes a dispute_resolution signal with outcome UPHELD)
• Revokes the attestation (publishes a RevocationNotice with reason MANUAL_DISPUTE)
• Refers the dispute to the AEGIS Initiative dispute resolution body for adjudication

Escalation: If the issuer does not respond within the 14-day window, or if the disputing entity is dissatisfied with the issuer’s resolution, the dispute escalates to the AEGIS Initiative dispute resolution body. Escalated disputes have an additional 30-day resolution window.

Outcome publication: All dispute resolutions are published to the federation as dispute_resolution signals. The signals are immutable and contribute to the trust scores of both the issuer and the disputing entity (incentive alignment: frivolous disputes hurt the disputer; legitimate disputes hurt a careless issuer).

5.13 Failure Modes

Constitutional Basis

AGAP-1 implements three constitutional articles:

• Article II (Authority Binding). Every attestation cryptographically binds a verified subject identity to a verifiable governance posture. No attestation can exist without a verified DID and a valid signature chain. Authority binding is the foundational property AGAP-1 enforces.

• Article VII (Auditability). Every step of the verification process is logged and the resulting VerificationResult is hash-linked from the issued attestation. Any consumer can audit what was checked, when, by whom, and what evidence was sampled. Attestation chains are tamper-evident.

• Article IX (Deny by Default). If any verification check fails or if any required field is missing, no attestation is issued. There is no “best effort” attestation. The protocol cannot produce a valid attestation under ambiguity.

Drawbacks

Trust placement in issuer nodes. Tier 1 and Tier 2 attestations are only as trustworthy as the federation node that issued them. A compromised issuer can issue fraudulent attestations until the compromise is detected and the issuer’s trust class is downgraded. GFN-1 §6 (Sybil resistance) and §8 (revocation) provide mitigations but cannot fully eliminate this risk.

Sponsor liability is novel. The sponsor model creates a trust-chain liability that does not exist in traditional certification systems. Organizations may be reluctant to sponsor third parties knowing that a sponsored entity’s failure will hurt their own trust score. This may limit federation growth in the early phases.

Re-verification cost at scale. Tier 2 re-verification on a weekly schedule for thousands of subjects is computationally and economically expensive. The federation must price subscriptions to cover this cost without making continuous attestation prohibitively expensive.

Audit endpoint dependency. The protocol assumes that subjects maintain a reachable, well-formed audit endpoint serving signed records. Subjects who do not run their own audit infrastructure cannot be attested above Tier 0.

Compliance profile maintenance burden. Compliance profiles (NIST AI RMF, EU AI Act, etc.) change over time. The federation must maintain authoritative profile definitions and propagate updates without breaking existing attestation chains.

First-time sponsorship is a manual choke point. The bootstrap problem — the first L1 sponsor in any new domain requires manual approval — creates a single point of latency for new federation participants.

Alternatives Considered

Manual review only

The current state. Every attestation reviewed by a human auditor. Rejected because it does not scale and undermines the federation’s value proposition.

Centralized certificate authority

A single authority issues all attestations. Rejected because it contradicts the federation’s decentralized architecture (ADR-0005) and creates a single point of failure for the entire compliance verification system.

Blockchain-anchored attestations

Attestations published to a public blockchain (Ethereum, Solana, or a permissioned chain). Rejected because:

1. The AT Protocol already provides tamper-evident publishing (PDS records with cryptographic identity) without the cost and latency of blockchain consensus.
2. Blockchain attestations would create gas-fee dependencies that contradict the “basic participation is free” principle of ADR-0010.
3. The federation’s trust model is reputation-based, not consensus-based — adding consensus does not improve the security properties.

PKI-based with no federation

Standard X.509 PKI with a trusted root CA. Rejected because it does not provide the behavioral evidence verification that distinguishes AGAP-1 from existing certification systems. PKI proves identity; AGAP-1 proves governance compliance based on behavior over time.

Self-attestation only

Subjects publish their own attestations with no third-party verification. Rejected because the entire value proposition of federation-issued attestations is that they are stronger than self-declarations. (Note: Tier 0 in AGAP-1 is essentially this option, retained because there are use cases — e.g., public commitment without compliance evidence — where it is appropriate.)

Compatibility

Breaking changes: None. AGAP-1 introduces new fields to the existing governance_attestation lexicon but does not remove or rename any fields. Existing pre-AGAP-1 attestation records continue to be valid as Tier 0 attestations until their declared validity expires.

Deprecations: None.

Backwards compatibility: AGAP-1 is additive over the existing governance attestation lexicon. Federation nodes that do not implement AGAP-1 can still consume AGAP-1 attestations as opaque records (they will not be able to verify the signatures or process revocations, but they will not error on the records).

Upgrade path: Federation nodes upgrade in two phases. Phase 1: implement consumer-side AGAP-1 (verify signatures, honor revocations, process attestation chains). Phase 2: implement issuer-side AGAP-1 (verification engine, signing infrastructure, dispute handling). Phase 1 is required for any node that consumes attestation records; Phase 2 is optional (only nodes that want to issue attestations need to implement it).

Implementation Notes

Suggested implementation sequence

1. Schema extensions. Update governance_attestation.schema.json to add the AGAP-1 fields. Validate that existing records still pass schema validation under the extended schema.
2. Verification engine. Implement the 12-check verification algorithm (§5.5) as a reusable library. Each check should be independently testable and produce structured results.
3. Issuer infrastructure. Build the signing pipeline, PDS publishing flow, and verification result persistence.
4. Consumer infrastructure. Build the local attestation cache, signature verification, and revocation processing.
5. Federation propagation. Update feed generators to recognize RevocationNotice records and propagate them with elevated priority.
6. Dispute resolution workflow. Build the dispute filing, response, and escalation workflow.
7. Compliance profile registry. Define the first profile (nist-ai-rmf-1.0) and the registry mechanism for managing profiles over time.

Known hard problems

• Compliance profile authority. Who decides what nist-ai-rmf-1.0 requires evidence-wise? AEGIS Initiative initially, but a long-term governance model for profile definitions is needed.
• Cross-jurisdictional attestation validity. An attestation issued by a federation node in jurisdiction A may not be legally recognized in jurisdiction B. AGAP-1 does not solve this; it provides the technical substrate.
• Liability allocation. If a sponsored entity causes harm while attested, who is liable — the subject, the sponsor, the issuer, or the federation? This is a legal question that the protocol cannot answer but must accommodate.
• Audit endpoint specification. AGAP-1 references “the audit endpoint” without specifying its protocol. A separate RFC should define the AEGIS Audit Endpoint Specification.

Dependencies

• Lexicon schema extension. The com.aegisfederation.governance.attestation lexicon must be extended per §5.7 before AGAP-1 can be deployed.
• GFN-1 trust model. AGAP-1 depends on the trust class assignments and trust score calculations defined in GFN-1 §2 and §3.
• AEGIS audit log specification. AGAP-1 assumes audit records conform to a known schema. The schema is documented in aegis-core/governance/audit_log.md but should be formally specified in a separate RFC.
• AEGIS Initiative dispute resolution body. The escalation path in §5.12 assumes such a body exists. Constituting it is an organizational task, not a protocol task.

Open Questions

• What is the appropriate fee structure for Tier 1 and Tier 2 attestations? Per-attestation, per-verification, or subscription tiers? ADR-0010 leaves this to AGAP-1 but AGAP-1 defers to operational tuning.
• What is the default re-verification interval for Tier 2? Weekly is the proposed default but this should be empirically validated against the cost-vs-freshness trade-off.
• Should the verification engine support pluggable checks (custom checks beyond the 12 in §5.5) for jurisdiction-specific or industry-specific compliance profiles?
• How are compliance profile updates versioned and propagated? When nist-ai-rmf-1.0 becomes nist-ai-rmf-1.1, do existing attestations under 1.0 remain valid until their natural expiry, or are they invalidated?
• Should attestations carry a machine-readable scope statement (e.g., “this attestation covers only the agent’s email and filesystem capabilities, not its shell capabilities”)?
• What is the dispute resolution body’s composition and authority? Currently a placeholder for “AEGIS Initiative.”
• Should the protocol define a public key transparency log for federation node DIDs to detect issuer key compromise?

Success Criteria

AGAP-1 is successfully implemented when:

1. A new entity can submit a RegistrationRequest and receive a verified attestation, refusal, or pending sponsorship notification within 24 hours of submission, without human intervention beyond first-time sponsor approval.
2. A consumer can fetch an attestation, verify its signature chain, and confirm it has not been revoked in under 100 ms for cached attestations and under 5 seconds for cold lookups.
3. Revocation propagation latency from issuance to consumer awareness is under 60 seconds at the 95th percentile.
4. At least three independent federation nodes are issuing AGAP-1 attestations, validating that the protocol is not bound to a single implementation.
5. At least one dispute has been filed, processed, and resolved through the §5.12 mechanism, validating the escalation path.
6. The reference implementation is published under Apache 2.0 in aegis-federation.

References

• AEGIS Constitution — aegis-core/constitution/
• AGP-1 Protocol — aegis-core/protocol/AEGIS_AGP1_INDEX.md
• ATM-1 Threat Model — aegis-core/threat-model/AEGIS_ATM1_INDEX.md
• GFN-1 Trust Model — federation/AEGIS_GFN1_TRUST_MODEL.md
• Governance Attestation Schema — canonical shared contract in aegis/schemas/governance/events/governance_attestation.schema.json
• ADR-0003 Registry Trust Model — aegis/docs/adr/0003-registry-trust-model.md
• ADR-0005 Governance Federation on AT Protocol — aegis/docs/adr/0005-governance-federation-at-protocol.md
• ADR-0010 Federation Monetization and Attestation Economics — aegis/docs/adr/0010-federation-monetization-and-attestation-economics.md
• RFC-0008 Federation Network Protocol — rfc/RFC-0008-Federation-Network-Protocol.md
• AT Protocol Lexicon Documentation — https://atproto.com/specs/lexicon

AEGIS™ | “Capability without constraint is not intelligence”™
AEGIS Initiative — AEGIS Operations LLC