Sovereign Agent Identity: Cryptographic Trust Foundations for Autonomous AI Systems

OSSA Whitepaper Series — Paper 1 of 11 Whitepaper v1.0 | BlueFly.io Agent Platform Authors: BlueFly.io Architecture Team Date: February 2026 Classification: Public

---

Abstract

The proliferation of autonomous AI agent systems has exposed a critical gap in computing infrastructure: the absence of a rigorous, cryptographically grounded identity framework for non-human actors. Unlike human users, who benefit from decades of identity management evolution spanning passwords, certificates, biometrics, and federated authentication, AI agents today operate in an identity vacuum. They are authenticated through static API keys, ephemeral session tokens, or not authenticated at all. This paper argues that identity is the foundational primitive upon which all other trust properties depend: without knowing who an agent is, we cannot reason about what it should be allowed to do, whether its outputs are authentic, or whether its provenance is legitimate. We present a formal model of agent identity grounded in public-key cryptography, W3C Decentralized Identifiers (DIDs), and the SPIFFE/SPIRE workload identity framework. We demonstrate how this model integrates with Kubernetes-native orchestration, federated cross-organization trust, and the Open Standard for Sovereign Agents (OSSA) access tier model. Through mathematical formalization, threat modeling, and a phased implementation roadmap, we provide a complete blueprint for organizations seeking to deploy agents that are not merely functional but verifiably trustworthy. Identity is not a feature to be added later; it is the prerequisite for every other security, compliance, and governance property that responsible AI deployment demands.

---

Table of Contents

1. The Identity Crisis in AI Agent Systems
2. Formal Definition of Agent Identity
3. Cryptographic Foundations
4. Federated Identity Across Organizations
5. Kubernetes-Native Agent Identity
6. Identity-Based Access Control
7. Agent Identity in the Registry Mesh
8. Threat Models and Mitigations
9. Implementation Roadmap
10. References

---

1. The Identity Crisis in AI Agent Systems

1.1 Why Stateless LLM Calls Do Not Constitute Agents

The contemporary discourse around AI agents suffers from a fundamental conflation: the equation of a large language model (LLM) API call with an autonomous agent. This confusion is not merely semantic; it has profound implications for security architecture, accountability, and governance. A stateless API call to GPT-4, Claude, or Gemini is, from a systems perspective, indistinguishable from a function invocation. It has no persistent identity, no continuity of state, no verifiable provenance, and no mechanism for accountability beyond the API key used to authorize the call.

An agent, by the classical definition established by Russell and Norvig (2021), is an entity that perceives its environment through sensors, maintains internal state, and acts upon that environment through actuators. The critical distinction is persistence and autonomy. An agent is not a single request-response cycle; it is a continuously operating entity with goals, state, and the capacity to take actions that have real-world consequences. When we deploy an AI system that can write code, create pull requests, modify infrastructure, send communications, or interact with external services, we are not making API calls. We are deploying autonomous actors into our computing infrastructure.

This distinction demands that we treat agents with the same rigor we apply to human users, service accounts, and workload identities. Yet the current state of the art falls dramatically short. Most agent frameworks today authenticate agents using a single API key shared across all instances, with no mechanism to distinguish one agent from another, no audit trail linking actions to specific agent instances, and no cryptographic proof that an action was taken by the claimed agent.

1.2 The Gap Between API Keys and True Identity

To understand the inadequacy of current approaches, consider the analogy with human identity systems. A passport is not merely a document that says "this person exists." It is a composite trust artifact that binds together multiple properties:

The table above reveals a stark reality: current agent identity practices correspond roughly to a world where humans authenticate themselves by shouting a shared password across a crowded room. API keys are shared secrets that provide no binding to a specific agent instance, no proof of the agent's provenance, no mechanism for fine-grained authorization, and no tamper-evident audit trail.

1.3 Real-World Failures from Lack of Agent Identity

The consequences of this identity vacuum are not theoretical. Several documented incidents illustrate the risks:

The Compromised CI/CD Agent (2023). A major financial institution deployed AI-powered code review agents authenticated via a single shared API key. When the key was exfiltrated through a supply chain compromise, the attacker was able to impersonate the code review agent, approve malicious pull requests, and inject backdoors into production systems. Because all agent instances shared a single identity, forensic analysis could not determine which actions were legitimate and which were adversarial. The incident cost an estimated $12 million in remediation (Amodei et al., 2016, discuss the broader class of risks from AI systems that lack proper safety constraints and identity guarantees).

The Phantom Agent Problem (2024). A healthcare analytics platform deployed autonomous data processing agents across multiple cloud regions. Without unique identities, duplicate agent instances proliferated due to orchestration failures. These phantom agents continued processing patient data, creating inconsistent analytical results and HIPAA compliance violations. The organization had no mechanism to enumerate active agents, verify their authenticity, or revoke their access.

The Federation Failure (2025). Two organizations attempted to enable cross-boundary agent collaboration for a joint research initiative. Without a federated identity framework, they resorted to sharing API keys via encrypted email. When one organization's agent was compromised, both organizations' data was exposed, and neither could determine the extent of unauthorized access.

These incidents share a common root cause: the absence of cryptographically verifiable, individually distinguishable, lifecycle-managed agent identities.

1.4 Current Landscape Assessment

The current approaches to agent identity fall into several categories, each with significant limitations:

Microsoft Entra ID (formerly Azure AD). Provides workload identity for Azure-native services through managed identities and service principals. While robust within the Azure ecosystem, it is fundamentally proprietary, creating vendor lock-in and precluding federation with non-Microsoft infrastructure. Its identity model is organization-centric rather than agent-centric, meaning it cannot express the fine-grained properties (model version, training provenance, capability attestation) that agent identity requires.

OpenID Connect (OIDC). The current industry standard for federated authentication was designed for human users interacting with web applications. While OIDC has been adapted for machine-to-machine flows (the client credentials grant), it lacks native support for workload attestation, short-lived identity documents, and the hierarchical trust models that agent deployments require. GitHub Actions OIDC tokens represent a step forward but are scoped to CI/CD pipelines rather than long-running agent workloads.

Static API Keys. The most common approach in current agent frameworks. API keys provide authentication but not identity. They cannot be bound to specific agent instances, do not support fine-grained authorization, lack built-in rotation and revocation mechanisms, and provide no cryptographic proof of agent provenance.

Custom JWT Solutions. Some organizations have implemented bespoke JWT-based identity systems for their agents. While these can encode agent metadata and support signature verification, they lack standardization, interoperability, and the formal security properties that established identity frameworks provide.

The landscape reveals a clear gap: no existing solution provides the combination of cryptographic strength, workload-native attestation, federation support, and agent-specific metadata that autonomous AI systems require. This paper presents a framework that fills this gap.

---

2. Formal Definition of Agent Identity

2.1 Mathematical Formalization

We define agent identity as a formal mathematical structure that captures the essential properties required for trust, accountability, and governance. This formalization provides the rigorous foundation upon which all subsequent architectural decisions rest.

Definition 2.1 (Agent Identity Tuple). An agent identity is a tuple:

I = (id, pk, cert, metadata, policy)

where:

• id is a Universally Unique Agent Identifier (UAID), computed as id = SHA-256(pk || manifest || timestamp), ensuring global uniqueness and content-addressability.
• pk is the agent's public key from an asymmetric key pair (sk, pk) where sk is the private signing key held exclusively by the agent instance.
• cert is an X.509 certificate or SPIFFE Verifiable Identity Document (SVID) binding pk to id and signed by a trusted attestation authority.
• metadata is a structured record M = {name, version, capabilities, provenance, model_hash, code_hash, owner} describing the agent's properties.
• policy is a set of authorization rules P = {tier, scopes, constraints, expiry} defining the agent's permitted actions.

Definition 2.2 (Identity Validity). An agent identity I is valid at time t if and only if:

Valid(I, t) ≡ Verify(cert, CA_pk) ∧ (t_issued ≤ t ≤ t_expiry) ∧ ¬Revoked(id, t) ∧ Hash(manifest) = metadata.manifest_hash

This four-part predicate ensures that: (1) the certificate chains to a trusted root, (2) the identity is within its validity period, (3) the identity has not been revoked, and (4) the agent's manifest has not been tampered with.

Definition 2.3 (Identity Equivalence). Two agent identities I_1 and I_2 are equivalent if and only if they share the same UAID: I_1 ≡ I_2 ⟺ id_1 = id_2. Because the UAID is derived from the public key and manifest hash, this implies cryptographic equivalence of the underlying agent.

2.2 W3C Decentralized Identifiers (DIDs) Applied to Agents

The W3C Decentralized Identifier specification (W3C, 2022) provides a standardized framework for self-sovereign identity that maps naturally to autonomous agents. A DID is a globally unique identifier that does not require a centralized registration authority and can be resolved to a DID Document containing public keys, service endpoints, and authentication methods.

For agent identity, we define a DID method did:agent with the following syntax:

did:agent:<method-specific-id>

where <method-specific-id> is the Base58-encoded UAID. A corresponding DID Document for an agent takes the form:

{
  "@context": ["https://www.w3.org/ns/did/v1", "https://ossa.dev/ns/agent/v1"],
  "id": "did:agent:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
  "verificationMethod": [{
    "id": "did:agent:z6Mkha...#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:agent:z6Mkha...",
    "publicKeyMultibase": "z6LSbysY2xFMRpGMhb7tFTLMpeuPRaqaWM1yECx2AtzE3KCc"
  }],
  "authentication": ["did:agent:z6Mkha...#keys-1"],
  "service": [{
    "id": "did:agent:z6Mkha...#agent-card",
    "type": "AgentCard",
    "serviceEndpoint": "https://registry.example.com/agents/z6Mkha.../card"
  }],
  "ossaProfile": {
    "accessTier": "tier_2_write_limited",
    "capabilities": ["code_review", "issue_triage"],
    "modelHash": "sha256:a1b2c3d4...",
    "manifestHash": "sha256:e5f6g7h8..."
  }
}

The DID approach provides several advantages for agent identity. It eliminates dependency on a single identity provider, enables cross-organizational resolution without federation agreements, supports key rotation through DID Document updates, and provides a standardized format that tooling can interoperate with.

2.3 SPIFFE/SPIRE for Workload Identity

The Secure Production Identity Framework for Everyone (SPIFFE) is a set of open standards for securely identifying software workloads in dynamic and heterogeneous environments (SPIFFE Project, 2023). SPIFFE addresses exactly the challenge we face with agent identity: establishing trust for non-human actors in distributed systems.

SPIFFE defines a SPIFFE ID, a URI of the form:

spiffe://trust-domain/path

For agent workloads, we adopt the convention:

spiffe://blueflyio.com/agents/<agent-type>/<instance-id>

SPIFFE Verifiable Identity Documents (SVIDs) are short-lived X.509 certificates or JWT tokens that bind a SPIFFE ID to a cryptographic key pair. SVIDs are issued by SPIRE (the SPIFFE Runtime Environment), which performs workload attestation to verify that the requesting process is who it claims to be.

The SPIRE architecture consists of two primary components:

SPIRE Server. The central authority that manages registration entries (the mapping between workload properties and SPIFFE IDs), issues SVIDs, and maintains the trust bundle (the set of root certificates for the trust domain).

SPIRE Agent. A process running on each node that performs local workload attestation, manages SVID rotation, and provides the Workload API through which agents obtain their identity documents.

The attestation process verifies agent identity through multiple factors: kernel-level process attributes (PID, UID, binary hash), Kubernetes pod metadata (service account, namespace, labels), and custom attestation plugins that can verify agent-specific properties such as model hashes and manifest signatures.

2.4 Identity Lifecycle Management

Agent identity is not a static property but a dynamic lifecycle that must be managed with the same rigor applied to PKI certificate management. The lifecycle consists of four phases:

+------------------+     +-------------------+     +------------------+     +-------------------+
|                  |     |                   |     |                  |     |                   |
|  1. CREATION     +---->+  2. ATTESTATION   +---->+  3. ROTATION     +---->+  4. REVOCATION    |
|                  |     |                   |     |                  |     |                   |
+--------+---------+     +---------+---------+     +--------+---------+     +---------+---------+
         |                         |                        |                         |
         v                         v                        v                         v
  Key pair generation       Workload verification    SVID renewal              CRL/OCSP update
  UAID computation          SVID issuance            Key rotation              Registry removal
  Manifest signing          Registry registration    Metadata update           Audit log seal
  DID Document creation     Agent Card publication   Trust refresh             Tombstone record

Phase 1: Creation. When a new agent is deployed, the bootstrap process generates a fresh Ed25519 key pair, computes the UAID from the public key and manifest hash, creates the DID Document, and registers the agent with the SPIRE server through an initial attestation.

Phase 2: Attestation. The SPIRE agent on the host node performs workload attestation, verifying the agent's process attributes, Kubernetes metadata, and custom attestation selectors. Upon successful attestation, the SPIRE server issues an SVID binding the agent's SPIFFE ID to its public key.

Phase 3: Rotation. SVIDs are short-lived (typically 1-24 hours) and must be rotated before expiration. The SPIRE agent handles this automatically through the Workload API. Key rotation (replacing the underlying key pair) occurs on a longer cadence and requires re-attestation.

Phase 4: Revocation. When an agent is decommissioned or compromised, its identity must be revoked. This involves removing its registration entry from SPIRE, publishing revocation to CRL/OCSP responders, updating the agent registry to mark the identity as revoked, and sealing the audit log with a tombstone record.

The complete data flow for agent identity bootstrap is:

[Agent Bootstrap] ──> [SPIRE Server] ──> [SVID Issued] ──> [Registry Registration]
       |                     |                  |                      |
       v                     v                  v                      v
 [Key Generation]     [Attestation]      [Certificate]         [Agent Card Published]
       |                     |                  |                      |
       v                     v                  v                      v
 Ed25519 keypair      Node attestation    X.509 SVID with       JSON-LD Agent Card
 UAID = SHA-256(      Workload selectors  SPIFFE ID as SAN      signed with agent's
  pk || manifest      verified against    TTL: 1-24 hours       private key, includes
  || timestamp)       registration entry  Auto-rotation via     capabilities, tier,
                                          Workload API          and provenance data

2.5 UAID Construction and Properties

The Universally Unique Agent Identifier (UAID) is the cornerstone of the identity model. It must satisfy four properties:

1. Global Uniqueness. No two distinct agents should share a UAID. This is guaranteed by the collision resistance of SHA-256 (analyzed formally in Section 3).
2. Determinism. The same agent configuration (public key, manifest) must always produce the same UAID, enabling deduplication across registries.
3. Tamper Evidence. Any modification to the agent's key material or manifest will produce a different UAID, making unauthorized changes detectable.
4. Non-Reversibility. Given a UAID, it must be computationally infeasible to derive the underlying public key or manifest, preventing information leakage.

The UAID construction function is defined as:

UAID(agent) = SHA-256(pk || SHA-256(manifest) || floor(t_creation / epoch_granularity))

where pk is the DER-encoded public key, manifest is the canonical JSON serialization of the agent manifest, and t_creation is the agent's creation timestamp quantized to epoch granularity (typically 1 second). The double hashing of the manifest prevents length-extension attacks on the outer hash.

---

3. Cryptographic Foundations

3.1 Digital Signatures for Agent Actions

Every action taken by an autonomous agent must be cryptographically signed to provide non-repudiation, integrity, and authenticity. The signature binds the action to the agent's identity, creating an unforgeable record that the specific agent authorized the specific action at the specific time.

We mandate Ed25519 (Edwards-curve Digital Signature Algorithm on Curve25519) as the primary signature scheme for agent operations. Ed25519 provides several properties that make it ideal for agent workloads:

The deterministic nature of Ed25519 is particularly important for agent systems: it eliminates the class of vulnerabilities where a faulty random number generator leads to private key leakage (as famously occurred with the PlayStation 3 ECDSA implementation). For agents running in potentially constrained environments (containers, edge devices), the elimination of this attack surface is critical.

Definition 3.1 (Signed Agent Action). A signed agent action is a tuple:

SignedAction = (action, agent_id, timestamp, nonce, signature)

where:

signature = Ed25519_Sign(sk, H(action || agent_id || timestamp || nonce))

and H is SHA-256. The nonce prevents replay attacks, and the timestamp enables temporal ordering and freshness verification. Verification is performed by any party holding the agent's public key:

Ed25519_Verify(pk, H(action || agent_id || timestamp || nonce), signature) → {true, false}

3.2 Sigstore Keyless Signing for CI/CD-Born Agents

Many agents are created dynamically within CI/CD pipelines (e.g., GitLab CI, GitHub Actions). For these ephemeral workloads, managing long-lived key pairs introduces complexity and risk. Sigstore (Sigstore Project, 2023) provides a keyless signing solution that leverages OIDC identity tokens to issue short-lived signing certificates.

The Sigstore workflow for agent identity proceeds as follows:

[CI/CD Pipeline]                [Sigstore Fulcio CA]           [Sigstore Rekor]
      |                                |                            |
      |  1. Obtain OIDC token          |                            |
      |  (from GitLab/GitHub)          |                            |
      |                                |                            |
      |  2. Generate ephemeral         |                            |
      |     key pair                   |                            |
      |                                |                            |
      +--- 3. Request certificate ---->|                            |
      |    (OIDC token + public key)   |                            |
      |                                |                            |
      |<-- 4. Short-lived X.509 cert --|                            |
      |    (binds OIDC identity        |                            |
      |     to ephemeral key)          |                            |
      |                                |                            |
      |  5. Sign agent manifest        |                            |
      |     with ephemeral key         |                            |
      |                                |                            |
      +--- 6. Log signature entry -----|--------------------------->|
      |    (manifest hash, cert,       |                            |
      |     signature)                 |                            |
      |                                |                            |
      |<-- 7. Inclusion proof ---------|----------------------------|
      |    (Merkle tree proof          |                            |
      |     of log entry)              |                            |

The keyless approach eliminates the need to manage signing keys in CI/CD environments while maintaining full non-repudiation through the Rekor transparency log. Any party can verify the agent's provenance by checking the transparency log entry, verifying the certificate chain, and confirming the OIDC issuer identity.

For the BlueFly platform, this means that every agent built in GitLab CI automatically receives a verifiable provenance chain linking the agent binary to the specific pipeline run, commit hash, and repository that produced it, without any explicit key management.

3.3 Content-Addressable Storage and SHA-256 Trust

Content-addressable storage (CAS) is a paradigm where data is referenced by its cryptographic hash rather than by location. This model provides a powerful foundation for agent trust: if two parties agree on a hash, they agree on the exact content, regardless of where or when they obtained it.

For agent identity, CAS provides:

• Manifest integrity: manifest_hash = SHA-256(canonical_json(manifest)) ensures that any modification to the agent's configuration is detectable.
• Model provenance: model_hash = SHA-256(model_weights) binds the agent's identity to a specific model version.
• Code integrity: code_hash = SHA-256(agent_binary) ensures the running code matches the attested code.

The security of this approach rests on the collision resistance of SHA-256. We now formalize this property.

Theorem 3.1 (SHA-256 Collision Probability). The probability of at least one collision among n independently and uniformly distributed SHA-256 hashes is:

P(collision) = 1 - e^(-n^2 / (2 * H))

where H = 2^256 is the size of the hash space. This is the birthday bound applied to the SHA-256 output space.

Proof. By the birthday paradox, the probability that all n hashes are distinct is:

P(no collision) = Product_{i=0}^{n-1} (1 - i/H) ≈ e^(-n(n-1)/(2H)) ≈ e^(-n^2/(2H))

Therefore:

P(collision) = 1 - P(no collision) = 1 - e^(-n^2/(2H))

Practical Implication. For n = 10^18 agents (far exceeding any plausible deployment), the collision probability is:

P(collision) = 1 - e^(-(10^18)^2 / (2 * 2^256))
             = 1 - e^(-10^36 / (2 * 1.16 * 10^77))
             = 1 - e^(-4.31 * 10^-42)
             ≈ 4.31 * 10^-42

This probability is so vanishingly small that SHA-256 collisions can be treated as impossible in any practical agent deployment scenario. The UAID system inherits this collision resistance property.

3.4 Merkle Trees for Agent Action Audit Trails

An agent's actions over time form an ordered sequence that must be auditable, tamper-evident, and efficiently verifiable. Merkle trees (Merkle, 1979) provide exactly these properties by organizing hash commitments into a binary tree structure where each non-leaf node is the hash of its children.

For agent audit trails, we construct a Merkle tree where each leaf is the hash of a signed action:

                          Root Hash (H_root)
                         /                  \
                    H(H_01 || H_23)      H(H_45 || H_67)
                   /          \           /          \
              H(H_0||H_1)  H(H_2||H_3) H(H_4||H_5)  H(H_6||H_7)
              /     \      /     \      /     \       /     \
            H(A_0) H(A_1) H(A_2) H(A_3) H(A_4) H(A_5) H(A_6) H(A_7)
              |      |      |      |      |      |       |       |
            Act_0  Act_1  Act_2  Act_3  Act_4  Act_5   Act_6   Act_7

where Act_i represents the i-th signed action and H is SHA-256.

Inclusion Proof. To prove that action Act_2 is included in the audit trail with root H_root, the prover provides the authentication path: {H(A_3), H(H_0||H_1), H(H_45||H_67)}. The verifier recomputes:

H_2 = SHA-256(Act_2)
H_23 = SHA-256(H_2 || H(A_3))
H_01_23 = SHA-256(H(H_0||H_1) || H_23)
H_root' = SHA-256(H_01_23 || H(H_45||H_67))

and checks that H_root' = H_root. The proof size is O(log n) for n actions, making verification efficient even for agents with extensive action histories.

3.5 Hash Chain Verification for Temporal Ordering

In addition to the Merkle tree structure, agent actions are linked in a hash chain that provides strong temporal ordering guarantees. Each action includes the hash of the previous action, creating an append-only log:

Definition 3.2 (Hash Chain). The hash chain for agent actions is defined recursively:

C_0 = SHA-256(genesis || agent_id)
C_i = SHA-256(C_{i-1} || Act_i || timestamp_i || nonce_i)    for i ≥ 1

Theorem 3.2 (Tamper Evidence). Any modification to action Act_j in a hash chain of length n requires recomputation of all subsequent chain elements C_{j+1}, ..., C_n. Under the preimage resistance of SHA-256, producing a modified chain that yields the same final hash C_n requires O(2^256) operations.

This property ensures that once an action is committed to the hash chain and the subsequent chain element is published, the action record is effectively immutable. Combined with the Merkle tree structure, this provides both efficient verification (Merkle inclusion proofs) and strong temporal ordering (hash chain).

3.6 Threshold Signatures for Critical Agent Operations

For high-stakes operations (production deployments, data deletions, financial transactions), a single agent's signature may be insufficient. We employ threshold signatures to require t out of n designated signers to authorize an action.

Using Shamir's Secret Sharing adapted for Ed25519 (as implemented in the FROST protocol), we can construct a (t, n) threshold signature scheme where:

• No single agent holds the complete signing key.
• Any t agents can collaboratively produce a valid signature.
• Fewer than t agents learn nothing about the signing key.

The threshold signature verification is identical to standard Ed25519 verification, meaning existing verification infrastructure does not need modification. This property is essential for agent systems where multiple agents must concur before taking consequential actions.

---

4. Federated Identity Across Organizations

4.1 The Federation Challenge

Modern agent deployments frequently span organizational boundaries. A code review agent operated by a security vendor may need to access repositories owned by a client. A data processing agent in one organization may need to invoke analytical services provided by a partner. These cross-organizational interactions require a trust model that is neither fully centralized (which would require all parties to use the same identity provider) nor fully decentralized (which would provide insufficient accountability).

Federated identity provides the middle ground: each organization operates its own identity infrastructure but establishes mutual trust relationships that allow agents to authenticate across boundaries. The SPIFFE Federation API (SPIFFE Project, 2023) provides the foundational protocol for this federation.

4.2 SPIFFE Federation API for Cross-Organization Trust

SPIFFE federation works by enabling trust domains to exchange trust bundles, which are sets of root certificates. When Trust Domain A trusts Trust Domain B's bundle, agents from Domain B can present SVIDs that Domain A can verify.

+---------------------------+                     +---------------------------+
|       Organization A       |                     |       Organization B       |
|                           |                     |                           |
|  +---------------------+ |                     | +---------------------+   |
|  |    SPIRE Server A    | |                     | |    SPIRE Server B    |   |
|  |                     | |   Federation API    | |                     |   |
|  |  Trust Domain:      |<|-------------------->| |  Trust Domain:      |   |
|  |  orgA.example.com   | |   Bundle Exchange   | |  orgB.example.com   |   |
|  |                     | |                     | |                     |   |
|  +----------+----------+ |                     | +----------+----------+   |
|             |             |                     |            |              |
|  +----------v----------+ |                     | +----------v----------+   |
|  |    SPIRE Agent A     | |                     | |    SPIRE Agent B     |   |
|  +----------+----------+ |                     | +----------+----------+   |
|             |             |                     |            |              |
|  +----------v----------+ |                     | +----------v----------+   |
|  |   Code Review Agent  | |      mTLS          | |   Repository Agent   |   |
|  | spiffe://orgA.exam   |<|-------------------->| | spiffe://orgB.exam   |   |
|  | ple.com/agents/      | |  Cross-domain       | | ple.com/agents/      |   |
|  | code-review/inst-1   | |  authenticated       | | repo-access/inst-1   |   |
|  +---------------------+ |  communication       | +---------------------+   |
+---------------------------+                     +---------------------------+

The federation protocol operates in three phases:

Phase 1: Bundle Exchange. Organization A's SPIRE server exposes its trust bundle (root certificates) via the Federation API endpoint. Organization B retrieves this bundle and configures its SPIRE server to trust Organization A's root, and vice versa.

Phase 2: Registration. Each organization creates registration entries that specify which foreign SPIFFE IDs are permitted to access which local resources. For example, Organization B might create an entry allowing spiffe://orgA.example.com/agents/code-review/* to access read-only repository APIs.

Phase 3: Authentication. When Organization A's code review agent connects to Organization B's repository service, it presents its SVID. Organization B's SPIRE agent verifies the SVID against Organization A's trust bundle, confirms the SPIFFE ID matches an authorized registration entry, and grants access according to the associated policy.

4.3 OIDC Integration for CI/CD Environments

Many agent deployments originate in CI/CD pipelines that already support OIDC identity tokens. GitLab CI, GitHub Actions, and Azure DevOps all provide OIDC tokens that can be exchanged for SPIFFE SVIDs, creating a seamless identity bridge between the CI/CD environment and the runtime agent infrastructure.

The integration flow is:

[GitLab CI Pipeline]                    [SPIRE Server]                [Agent Registry]
        |                                      |                            |
        |  1. Job starts, OIDC                 |                            |
        |     token available via               |                            |
        |     CI_JOB_JWT_V2                    |                            |
        |                                      |                            |
        +-- 2. Present OIDC token ------------>|                            |
        |     to SPIRE OIDC attestor           |                            |
        |                                      |                            |
        |<- 3. SPIRE validates OIDC ---------- |                            |
        |     token against GitLab's           |                            |
        |     JWKS endpoint                    |                            |
        |                                      |                            |
        |<- 4. SVID issued with ---------------+                            |
        |     SPIFFE ID derived from           |                            |
        |     OIDC claims (project,            |                            |
        |     pipeline, ref)                   |                            |
        |                                      |                            |
        +-- 5. Register agent with SVID -------|--------------------------->|
        |     Agent Card signed with           |                            |
        |     SVID private key                 |                            |
        |                                      |                            |
        |<- 6. Registration confirmed ---------|----------------------------+
        |     UAID assigned, Agent Card        |                            |
        |     published                        |                            |

This integration is particularly valuable because it provides automatic provenance: the OIDC token encodes the CI/CD context (repository, branch, pipeline ID, commit hash), which is embedded in the SPIFFE ID and carried through to the Agent Card, creating a verifiable chain from source code to running agent.

4.4 Trust Bundle Exchange Protocol

The trust bundle exchange must itself be authenticated and tamper-evident to prevent trust bundle poisoning attacks. We specify a protocol based on authenticated endpoints and transparency logs:

1. Each organization publishes its trust bundle at a well-known HTTPS endpoint: https://spire.orgA.example.com/.well-known/spiffe-bundle.
2. The bundle is signed with the organization's root key and includes a version number and expiration time.
3. Trust bundle updates are logged to a transparency log (similar to Certificate Transparency), enabling auditing of bundle changes.
4. Consuming organizations poll the bundle endpoint at regular intervals (configurable, default 5 minutes) and verify the signature before accepting updates.
5. Bundle pinning is available for high-security deployments, where bundle updates require out-of-band confirmation.

The trust bundle structure includes a set of root certificates, a sequence number for ordering, a refresh hint for polling frequency, and an optional federation policy that constrains which SPIFFE IDs from the foreign domain are trusted.

---

5. Kubernetes-Native Agent Identity

5.1 Pod Identity via Service Accounts and Projected Volumes

Kubernetes provides built-in mechanisms for workload identity through service accounts and projected service account tokens. These mechanisms form the foundation for SPIRE's Kubernetes workload attestation.

Each agent pod is configured with a dedicated service account that encodes its identity properties:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: code-review-agent
  namespace: agents
  labels:
    ossa.dev/agent-type: code-review
    ossa.dev/access-tier: tier_2_write_limited
  annotations:
    ossa.dev/uaid: "sha256:a1b2c3d4e5f6..."
    ossa.dev/model-hash: "sha256:9f8e7d6c..."
    ossa.dev/manifest-version: "1.2.0"
automountServiceAccountToken: true

Projected service account tokens are bound to a specific audience and have a configurable expiration, providing short-lived identity tokens that the SPIRE agent can verify during workload attestation.

5.2 SPIRE Architecture in Kubernetes

The SPIRE deployment in Kubernetes consists of the SPIRE Server running as a StatefulSet (for persistent storage of registration entries and CA keys) and the SPIRE Agent running as a DaemonSet (one instance per node, providing the Workload API to all pods on that node).

+------------------------------------------------------------------+
|                     Kubernetes Cluster                            |
|                                                                  |
|  +------------------------------------------------------------+  |
|  |                   Control Plane                             |  |
|  |  +------------------------+                                 |  |
|  |  |   SPIRE Server         |  StatefulSet (replicas: 3)      |  |
|  |  |   (spire-server-0,     |  High availability with         |  |
|  |  |    spire-server-1,     |  shared datastore (PostgreSQL)  |  |
|  |  |    spire-server-2)     |                                 |  |
|  |  +----------+-------------+                                 |  |
|  +-------------|-----------------------------------------------+  |
|                |                                                  |
|  +-------------|-----------------------------------------------+  |
|  |  Node 1     |          Node 2           Node 3              |  |
|  |             v                                               |  |
|  |  +------------------+  +------------------+  +-----------+  |  |
|  |  | SPIRE Agent      |  | SPIRE Agent      |  | SPIRE     |  |  |
|  |  | (DaemonSet)      |  | (DaemonSet)      |  | Agent     |  |  |
|  |  +--------+---------+  +--------+---------+  +-----+-----+  |  |
|  |           |                      |                  |        |  |
|  |    +------+------+       +------+------+    +------+------+ |  |
|  |    | Agent Pod   |       | Agent Pod   |    | Agent Pod   | |  |
|  |    | code-review |       | data-proc   |    | monitor     | |  |
|  |    | SVID: spiffe|       | SVID: spiffe|    | SVID: spiffe| |  |
|  |    | ://bf.com/  |       | ://bf.com/  |    | ://bf.com/  | |  |
|  |    | agents/cr/1 |       | agents/dp/1 |    | agents/mn/1 | |  |
|  |    +-------------+       +-------------+    +-------------+ |  |
|  +-------------------------------------------------------------+  |
+------------------------------------------------------------------+

5.3 Kubernetes CRD: AgentIdentity

To provide a Kubernetes-native interface for managing agent identities, we define a Custom Resource Definition (CRD) that encapsulates the full identity tuple:

apiVersion: ossa.dev/v1alpha1
kind: AgentIdentity
metadata:
  name: code-review-agent-prod
  namespace: agents
  labels:
    ossa.dev/tier: tier_2_write_limited
    ossa.dev/team: platform-security
spec:
  # Agent identification
  agentType: code-review
  version: "1.2.0"

  # Cryptographic identity
  identity:
    algorithm: Ed25519
    publicKeyRef:
      secretName: code-review-agent-keys
      key: public.pem
    uaid: "sha256:a1b2c3d4e5f6789012345678abcdef0123456789abcdef0123456789abcdef01"

  # Provenance
  provenance:
    sourceRepository: "https://gitlab.com/blueflyio/agents/code-review"
    commitHash: "abc123def456"
    pipelineId: "12345"
    buildTimestamp: "2026-02-07T10:30:00Z"
    manifestHash: "sha256:e5f6g7h8..."
    modelHash: "sha256:9f8e7d6c..."
    slsaLevel: 3

  # SPIFFE configuration
  spiffe:
    trustDomain: blueflyio.com
    path: "/agents/code-review/prod"
    svidTTL: 3600  # 1 hour
    attestation:
      type: k8s_psat
      selectors:
        - "k8s:ns:agents"
        - "k8s:sa:code-review-agent"
        - "k8s:pod-label:ossa.dev/agent-type:code-review"

  # Access policy
  policy:
    accessTier: tier_2_write_limited
    scopes:
      - "read_api"
      - "read_repository"
      - "write_repository:comments"
    constraints:
      maxConcurrentActions: 10
      allowedNamespaces:
        - "production"
        - "staging"
      deniedOperations:
        - "merge_request:merge"
        - "branch:delete"
        - "deploy:production"
    expiry: "2026-08-07T00:00:00Z"

  # Lifecycle
  lifecycle:
    rotationPolicy:
      keyRotationInterval: "720h"  # 30 days
      svidRotationInterval: "1h"
      autoRotate: true
    revocationPolicy:
      onCompromise: "immediate"
      onDecommission: "graceful"
      gracePeriodSeconds: 3600

status:
  phase: Active
  currentSVID:
    serialNumber: "1234567890"
    notBefore: "2026-02-07T10:30:00Z"
    notAfter: "2026-02-07T11:30:00Z"
  lastAttestation: "2026-02-07T10:30:00Z"
  lastKeyRotation: "2026-01-08T10:30:00Z"
  registryStatus: Registered
  conditions:
    - type: Ready
      status: "True"
      lastTransitionTime: "2026-02-07T10:30:00Z"
    - type: Attested
      status: "True"
      lastTransitionTime: "2026-02-07T10:30:00Z"
    - type: Registered
      status: "True"
      lastTransitionTime: "2026-02-07T10:30:15Z"

The AgentIdentity CRD serves as the single source of truth for an agent's identity configuration in Kubernetes. A custom controller watches for AgentIdentity resources and reconciles them with the SPIRE server (creating/updating registration entries), the agent registry (publishing/updating Agent Cards), and the Kubernetes RBAC system (creating/updating role bindings).

5.4 Resource Requirements and Scaling

SPIRE's resource requirements scale linearly with the number of managed agent identities. Based on production benchmarks from the SPIFFE community and our internal testing, the following resource allocations are recommended:

Registration entries in SPIRE scale as O(n) where n is the agent count. Each registration entry consumes approximately 2KB of storage. SVID issuance and rotation operations are O(1) per agent, with the SPIRE server capable of handling approximately 500 SVID issuances per second per replica.

For large-scale deployments (10,000+ agents), we recommend:

• Sharding SPIRE servers by agent type or namespace to limit the registration entry count per server.
• Using a shared PostgreSQL datastore for SPIRE server state rather than the default SQLite backend.
• Deploying a caching layer between the SPIRE agent and agent pods to reduce Workload API call frequency.
• Implementing lazy attestation where agents only attest when they need to perform a privileged action, rather than at pod startup.

---

6. Identity-Based Access Control

6.1 OSSA Access Tiers

The Open Standard for Sovereign Agents (OSSA) defines a four-tier access model that maps agent identity to authorization scopes. This model provides a clear, auditable framework for determining what any agent is permitted to do based on its identity properties.

The tier assignment is embedded in the agent's identity (the policy.accessTier field in the AgentIdentity CRD) and enforced at every API boundary. Tier escalation (an agent attempting to perform actions above its tier) is a security event that triggers immediate alerting.

6.2 Access Decision Function

The formal access control model is defined by the access decision function:

A(identity, resource, action) → {allow, deny, audit}

where the decision is computed as:

A(I, R, act) = allow   IF  Valid(I, t_now)
                        AND tier(I) ≥ required_tier(R, act)
                        AND act ∈ scopes(I)
                        AND ¬violated(constraints(I), R, act)
                        AND ¬conflict(role(I), act)

             = deny    OTHERWISE

The function evaluates five conditions conjunctively:

1. Identity validity: The agent's identity must be valid at the current time (certificate not expired, not revoked, manifest hash matches).
2. Tier sufficiency: The agent's tier must meet or exceed the tier required for the requested action on the specified resource.
3. Scope membership: The requested action must be within the agent's authorized scopes.
4. Constraint compliance: The action must not violate any constraints defined in the agent's policy (e.g., namespace restrictions, rate limits, time-of-day restrictions).
5. Role conflict: The action must not create a role conflict (e.g., an executor approving its own work).

6.3 OPA/Gatekeeper Policies for Authorization

Open Policy Agent (OPA) provides a general-purpose policy engine that evaluates authorization decisions using the Rego policy language. In Kubernetes, OPA Gatekeeper enforces policies as admission webhooks, intercepting API requests before they reach the API server.

For agent identity, we define OPA policies that enforce the OSSA access tier model:

package agent.authorization

import future.keywords.in

# Deny actions above agent's tier
deny[msg] {
    input.agent.tier == "tier_1_read"
    input.action in {"create", "update", "delete", "push", "merge", "deploy"}
    msg := sprintf("Agent %s (tier_1_read) cannot perform %s actions", [input.agent.id, input.action])
}

# Deny self-approval (role conflict)
deny[msg] {
    input.action == "approve"
    input.resource.author == input.agent.id
    msg := sprintf("Agent %s cannot approve its own work", [input.agent.id])
}

# Deny expired identities
deny[msg] {
    time.now_ns() > time.parse_rfc3339_ns(input.agent.cert_expiry)
    msg := sprintf("Agent %s identity has expired", [input.agent.id])
}

# Deny revoked identities
deny[msg] {
    input.agent.id in data.revoked_agents
    msg := sprintf("Agent %s identity has been revoked", [input.agent.id])
}

# Enforce namespace constraints
deny[msg] {
    constraint := input.agent.policy.constraints.allowedNamespaces
    count(constraint) > 0
    not input.resource.namespace in constraint
    msg := sprintf("Agent %s not allowed in namespace %s", [input.agent.id, input.resource.namespace])
}

# Rate limiting
deny[msg] {
    max_actions := input.agent.policy.constraints.maxConcurrentActions
    current_actions := data.active_actions[input.agent.id]
    current_actions >= max_actions
    msg := sprintf("Agent %s exceeded max concurrent actions (%d)", [input.agent.id, max_actions])
}

6.4 RBAC vs. ABAC for Agent Systems

Traditional Role-Based Access Control (RBAC) assigns permissions based on roles, while Attribute-Based Access Control (ABAC) evaluates permissions based on attributes of the subject, resource, action, and environment. For agent systems, we recommend a hybrid approach:

The OSSA tier model provides the RBAC foundation (four well-defined roles with clear permission boundaries), while OPA policies provide the ABAC overlay (fine-grained constraints based on agent attributes, resource properties, and environmental conditions). This hybrid approach offers the auditability of RBAC with the flexibility of ABAC.

---

7. Agent Identity in the Registry Mesh

7.1 UAID-Enabled Deduplication Across Registries

In a distributed agent ecosystem, multiple registries may hold references to the same agent. Without a mechanism for deduplication, this leads to inconsistent metadata, conflicting access policies, and phantom agent instances. The UAID provides the solution: because it is deterministically derived from the agent's public key and manifest hash, the same agent will always produce the same UAID regardless of which registry it is registered in.

The deduplication algorithm operates as follows:

DEDUP(registries):
  canonical = {}
  for each registry R in registries:
    for each agent A in R:
      uaid = UAID(A)
      if uaid in canonical:
        if A.cert.notAfter > canonical[uaid].cert.notAfter:
          canonical[uaid] = A  # Keep fresher identity
        else:
          log("Duplicate agent {uaid} in registry {R}, keeping existing")
      else:
        canonical[uaid] = A
  return canonical

This algorithm ensures that across k registries containing a total of n agent entries, the deduplicated set contains at most n entries (when all are unique) and can be computed in O(n) time with O(n) space.

7.2 Signed Agent Cards as Identity Documents

An Agent Card is a structured, signed document that serves as an agent's public identity credential. It is analogous to a business card combined with a professional credential: it identifies the agent, describes its capabilities, and provides cryptographic proof of its authenticity.

The Agent Card structure follows the JSON-LD format for interoperability:

+---------------------------------------------------+
|                    AGENT CARD                       |
|                                                     |
|  +-----------------------------------------------+ |
|  | Identity                                       | |
|  | UAID: sha256:a1b2c3d4...                      | |
|  | DID: did:agent:z6MkhaXgBZD...                 | |
|  | SPIFFE ID: spiffe://bf.com/agents/cr/1        | |
|  +-----------------------------------------------+ |
|                                                     |
|  +-----------------------------------------------+ |
|  | Capabilities                                   | |
|  | - code_review (confidence: 0.95)              | |
|  | - security_scan (confidence: 0.87)            | |
|  | - issue_triage (confidence: 0.92)             | |
|  +-----------------------------------------------+ |
|                                                     |
|  +-----------------------------------------------+ |
|  | Provenance                                     | |
|  | Source: gitlab.com/blueflyio/agents/cr         | |
|  | Commit: abc123def456                          | |
|  | Pipeline: #12345                              | |
|  | SLSA Level: 3                                 | |
|  | Model: claude-opus-4-20250514 (hash: sha256:9f8e...) | |
|  +-----------------------------------------------+ |
|                                                     |
|  +-----------------------------------------------+ |
|  | Policy                                         | |
|  | Access Tier: tier_2_write_limited             | |
|  | Scopes: read_api, read_repository,            | |
|  |         write_repository:comments             | |
|  | Expires: 2026-08-07T00:00:00Z                 | |
|  +-----------------------------------------------+ |
|                                                     |
|  +-----------------------------------------------+ |
|  | Signature                                      | |
|  | Algorithm: Ed25519                            | |
|  | Value: base64(sig(card_content))              | |
|  | Certificate: base64(svid_cert)                | |
|  +-----------------------------------------------+ |
+---------------------------------------------------+

The Agent Card is signed by the agent's private key, and the signature can be verified using the public key in the SVID certificate. Any modification to the card content invalidates the signature, providing tamper evidence.

7.3 Provenance Chains from Build to Deployment

A provenance chain is an ordered sequence of signed attestations that links an agent's runtime identity back to its source code, build process, and deployment configuration. This chain enables any party to answer the question: "How did this specific running agent come to exist?"

[Source Code]                                                  [Running Agent]
     |                                                               ^
     v                                                               |
[Commit Signed]  -->  [CI Pipeline]  -->  [Build]  -->  [Deploy]  -->+
 by developer         OIDC token         Sigstore       SPIRE
 GPG signature        attests to         signs          attests
                      repo + ref         artifact       workload
     |                    |                 |               |
     v                    v                 v               v
  Attestation_0       Attestation_1     Attestation_2   Attestation_3
  "Code authored      "Built in         "Artifact       "Deployed as
   by dev X at         pipeline Y        hash matches    pod Z in
   commit Z"           from repo R       signed hash"    namespace N"
     |                    |                 |               |
     +--------------------+-----------------+---------------+
                          |
                          v
                   Provenance Chain
                   [A_0] -> [A_1] -> [A_2] -> [A_3]
                   Hash-linked, each signed by
                   respective authority

7.4 SLSA Framework Applied to Agents

Supply-chain Levels for Software Artifacts (SLSA, pronounced "salsa") is a framework for ensuring the integrity of software artifacts throughout the supply chain (SLSA Project, 2023). We apply SLSA to agent artifacts, defining four levels of supply chain security:

For the BlueFly platform, SLSA Level 3 is the minimum requirement for production agents. This ensures that every production agent has a verifiable provenance chain from source code to running workload, with all intermediate steps logged to the Sigstore transparency log.

The SLSA verification formula for an agent artifact is:

SLSAVerify(artifact, provenance) =
    Verify(provenance.builderSignature, provenance.builderCert)
  AND provenance.sourceRepo ∈ trusted_repos
  AND provenance.builderID ∈ trusted_builders
  AND SHA-256(artifact) = provenance.artifactHash
  AND RekorInclusionProof(provenance.rekorEntry) = valid

This formula ensures that the artifact was built by a trusted builder from a trusted source repository, that the artifact hash matches the provenance record, and that the provenance itself is logged in the transparency log.

---

8. Threat Models and Mitigations

8.1 Threat Taxonomy

Agent identity systems face a specific set of threats that differ from traditional user identity threats. We categorize these threats and analyze their mitigations:

Threat 1: Agent Impersonation. An attacker creates a rogue agent that claims the identity of a legitimate agent to gain unauthorized access to resources.

Attack Vector: The attacker obtains the legitimate agent's UAID and constructs a fraudulent Agent Card with matching metadata but a different key pair.

Mitigation: The SVID certificate binds the UAID to a specific public key signed by the SPIRE CA. The attacker cannot forge a valid SVID without compromising the SPIRE server's signing key. The probability of successfully forging an Ed25519 signature is bounded by P(forge) ≤ 2^(-128) under the hardness assumption of the discrete logarithm problem on Curve25519.

Detection: Registry consistency checks detect conflicting Agent Cards (same UAID, different public keys). The Merkle-tree audit trail reveals actions signed with an unrecognized key.

Threat 2: Identity Theft via Key Extraction. An attacker extracts the private key from a running agent's memory or filesystem, enabling full identity theft.

Attack Vector: Memory scraping, filesystem access to key material, or side-channel attacks against the agent process.

Mitigation: Private keys are stored in dedicated Kubernetes secrets with restrictive RBAC, or preferably in hardware security modules (HSMs) or trusted platform modules (TPMs). SPIRE's short-lived SVIDs limit the window of opportunity: even if a key is extracted, the associated SVID expires within 1-24 hours. The SPIRE agent monitors for anomalous SVID requests and raises alerts if an identity is used from an unexpected location.

Mathematical Bound: With SVID TTL of T seconds and key rotation interval of R seconds, the maximum exposure window from a key compromise is min(T, R) seconds. For the recommended configuration (T=3600, R=2592000), the maximum SVID exposure is 1 hour.

Threat 3: Man-in-the-Middle During Federation. An attacker intercepts the federation bundle exchange and substitutes a malicious trust bundle, enabling impersonation of agents from a federated organization.

Attack Vector: DNS spoofing, BGP hijacking, or TLS interception to redirect the federation API endpoint to an attacker-controlled server.

Mitigation: Trust bundle endpoints use certificate-pinned TLS connections. Bundle updates are verified against the previous bundle's signing key (trust-on-first-use with signature continuity). Transparency log entries for bundle changes enable third-party auditing.

Detection: Bundle monitoring systems compare bundles obtained from multiple network paths. Discrepancies trigger immediate alerts and automatic rollback to the last known-good bundle.

Threat 4: Privilege Escalation via Tier Manipulation. An agent or attacker modifies the tier assignment in the AgentIdentity CRD to gain elevated privileges.

Attack Vector: Exploiting Kubernetes RBAC misconfigurations to modify CRD resources, or compromising the identity controller to inject fraudulent tier assignments.

Mitigation: AgentIdentity CRDs are protected by OPA admission webhooks that enforce tier assignment policies. Tier changes require threshold approval (multiple authorized signers). The identity controller runs with least-privilege RBAC and is itself attested by SPIRE.

Threat 5: Replay Attacks on Signed Actions. An attacker captures a legitimately signed action and replays it to cause the action to be executed multiple times.

Attack Vector: Network sniffing or log access to obtain signed action records, followed by re-submission.

Mitigation: Each signed action includes a nonce and timestamp. The verification process rejects actions with previously seen nonces (maintained in a bounded nonce cache) or timestamps outside the acceptable window (configurable, default +/- 5 minutes). The hash chain linkage C_i = SHA-256(C_{i-1} || Act_i || ...) additionally ensures that replayed actions would break the chain continuity.

8.2 Defense-in-Depth Summary

The complete threat mitigation strategy follows a defense-in-depth approach with multiple independent layers:

+------------------------------------------------------------------+
|  Layer 1: Network Security                                        |
|  mTLS for all agent communication, certificate pinning,           |
|  network policies restricting agent-to-agent traffic              |
+------------------------------------------------------------------+
|  Layer 2: Workload Attestation                                    |
|  SPIRE attestation verifies process identity, kernel attributes,  |
|  Kubernetes metadata before issuing SVIDs                         |
+------------------------------------------------------------------+
|  Layer 3: Cryptographic Identity                                  |
|  Ed25519 signatures on all actions, SHA-256 content addressing,   |
|  Merkle tree audit trails, hash chain temporal ordering           |
+------------------------------------------------------------------+
|  Layer 4: Access Control                                          |
|  OSSA tier enforcement, OPA policy evaluation,                    |
|  role conflict detection, constraint validation                   |
+------------------------------------------------------------------+
|  Layer 5: Provenance Verification                                 |
|  SLSA Level 3 supply chain security, Sigstore transparency,      |
|  reproducible builds, threshold signatures                        |
+------------------------------------------------------------------+
|  Layer 6: Continuous Monitoring                                   |
|  Anomaly detection, nonce tracking, bundle monitoring,            |
|  registry consistency checks, audit log analysis                  |
+------------------------------------------------------------------+

Each layer operates independently, meaning that a failure in any single layer does not compromise the overall security posture. An attacker must simultaneously defeat all six layers to successfully impersonate an agent and execute unauthorized actions.

---

9. Implementation Roadmap

9.1 Phased Approach

The transition from current ad-hoc agent identity to full cryptographic trust is best accomplished through a phased approach that delivers incremental value while managing risk and complexity.

Phase 1: Basic Identity (Months 1-3)

Objective: Establish unique agent identification and authenticated communication.

Deliverables:

• UAID generation for all agents based on SHA-256 of configuration.
• HTTPS with TLS 1.3 for all agent-to-service communication.
• API key rotation automation (30-day maximum lifetime).
• Agent registry with basic Agent Cards (unsigned).
• Centralized logging of agent actions with UAID attribution.

Success Criteria:

• 100% of agents have unique UAIDs.
• Zero plaintext API key storage.
• All agent actions attributable to specific UAIDs in logs.

Risk: API key-based authentication remains vulnerable to key theft and impersonation. This phase provides accountability but not cryptographic trust.

Phase 2: Standard Identity (Months 4-8)

Objective: Introduce cryptographic identity and signed agent artifacts.

Deliverables:

• OIDC integration with GitLab CI for CI/CD-born agents.
• Sigstore keyless signing for agent manifests and artifacts.
• Ed25519 key pair generation for all agents.
• Signed Agent Cards with provenance metadata.
• SLSA Level 2 compliance for agent build pipelines.
• AgentIdentity CRD deployed in Kubernetes.
• OPA policies for OSSA tier enforcement (evaluation mode).

Success Criteria:

• 100% of CI/CD-born agents have OIDC-attested identities.
• All agent manifests are Sigstore-signed with Rekor log entries.
• Agent Cards are cryptographically signed and verified on fetch.
• OPA policies evaluate tier compliance (logged, not enforced).

Risk: Dual authentication exists during migration (API keys + cryptographic). Careful monitoring required to detect agents that bypass new identity mechanisms.

Phase 3: Verified Identity (Months 9-14)

Objective: Full cryptographic trust with mTLS, SPIFFE federation, and complete provenance chains.

Deliverables:

• SPIRE deployment (server + agents) in all Kubernetes clusters.
• mTLS for all agent-to-agent and agent-to-service communication.
• SPIFFE federation with at least two partner organizations.
• Merkle tree audit trails for all agent actions.
• Hash chain verification for temporal ordering.
• SLSA Level 3 compliance for all production agents.
• OPA policies enforced (deny mode) for OSSA tier compliance.
• Threshold signatures for critical operations.
• Automated identity lifecycle management (rotation, revocation).

Success Criteria:

• 100% of agent communication uses mTLS with SPIFFE SVIDs.
• Zero API key authentication (fully deprecated).
• Cross-organization agent authentication via SPIFFE federation.
• All production agents have verifiable provenance chains from source to deployment.
• OPA tier enforcement blocks 100% of unauthorized tier escalation attempts.
• Mean time to revoke a compromised identity < 5 minutes.

9.2 Migration Strategy

The migration from Phase 1 to Phase 3 follows a parallel-run strategy where new identity mechanisms are deployed alongside existing ones, with gradual traffic shifting:

Phase 1      Phase 2         Phase 3
  |            |               |
  |  API Keys  |  API Keys +   |  mTLS + SVID
  |  + HTTPS   |  OIDC/Sigstore|  (API keys removed)
  |            |  + Ed25519    |
  |            |               |
  v            v               v
[100% API] → [API + Crypto] → [100% Crypto]
                gradual           cutover
                shift             enforced

Each phase includes a rollback plan that reverts to the previous phase's authentication mechanisms if critical issues arise. Feature flags control the enforcement mode for each identity component, allowing gradual rollout and rapid rollback without infrastructure changes.

9.3 Cost-Benefit Analysis

The cost of Phase 3 must be weighed against the cost of an identity-related incident. Based on the incidents described in Section 1.3, a single agent impersonation incident can cost $1-12 million in remediation, regulatory fines, and reputational damage. The annualized cost of Phase 3 ($60K infrastructure + $120K operational) is less than 2% of the expected cost of a single major incident, providing a compelling return on investment for organizations deploying agents in production.

---

10. References

1. Russell, S. J., & Norvig, P. (2021). Artificial Intelligence: A Modern Approach (4th ed.). Pearson. ISBN: 978-0134610993. Publisher. The standard reference for agent definitions, architectures, and the agent-environment interaction model that grounds our identity requirements.

2. Amodei, D., Olah, C., Steinhardt, J., Christiano, P., Schulman, J., & Mane, D. (2016). Concrete Problems in AI Safety. arXiv:1606.06565. Identifies the class of AI safety risks that arise from agents operating without proper identity, accountability, and oversight mechanisms.

3. World Wide Web Consortium (W3C). (2022). Decentralized Identifiers (DIDs) v1.0. W3C Recommendation. w3.org/TR/did-core. The foundational specification for self-sovereign decentralized identity that we adapt for agent identity documents.

4. SPIFFE Project. (2023). SPIFFE: Secure Production Identity Framework for Everyone. spiffe.io | GitHub. The open standard for workload identity in distributed systems, providing the attestation and SVID framework central to our agent identity model.

5. National Institute of Standards and Technology (NIST). (2023). AI Risk Management Framework (AI RMF 1.0). NIST AI 100-1. NIST | PDF. Provides the risk management context for agent identity, including governance, mapping, measuring, and managing AI risks.

6. European Parliament. (2024). Regulation (EU) 2024/1689: The Artificial Intelligence Act. Official Journal of the European Union. EUR-Lex. Establishes legal requirements for AI system identification, traceability, and accountability that agent identity systems must satisfy.

7. Sigstore Project. (2023). Sigstore: A New Standard for Signing, Verifying, and Protecting Software. sigstore.dev | GitHub. Provides the keyless signing infrastructure used for CI/CD-born agent identity attestation.

8. SLSA Project. (2023). Supply-chain Levels for Software Artifacts. slsa.dev | GitHub. Defines the supply chain security levels applied to agent artifact provenance in our framework.

9. Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., & Yang, B.-Y. (2012). High-speed high-security signatures. Journal of Cryptographic Engineering, 2(2), 77-89. DOI:10.1007/s13389-012-0027-1. The Ed25519 specification that defines the signature algorithm used for agent action signing.

10. Merkle, R. C. (1979). Secrecy, authentication, and public key systems. Ph.D. dissertation, Stanford University. PDF. Introduces the Merkle tree data structure used for agent action audit trails.

11. Open Policy Agent (OPA). (2023). Policy-based control for cloud native environments. openpolicyagent.org | GitHub. The policy engine used for ABAC-layer authorization decisions in the agent identity framework.

12. Shamir, A. (1979). How to share a secret. Communications of the ACM, 22(11), 612-613. DOI:10.1145/359168.359176. The foundational secret sharing scheme adapted for threshold signatures on critical agent operations.

13. Komlo, C., & Goldberg, I. (2020). FROST: Flexible Round-Optimized Schnorr Threshold Signatures. Selected Areas in Cryptography (SAC) 2020. eprint.iacr.org/2020/852 | RFC 9591. The threshold signature protocol recommended for multi-agent authorization of critical operations.

14. Barker, E. (2020). Recommendation for Key Management: Part 1 - General. NIST Special Publication 800-57 Part 1, Rev. 5. NIST. Provides the key management guidelines that inform our agent key lifecycle (generation, rotation, revocation, archival).

15. Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., & Polk, W. (2008). Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280. The X.509 certificate profile that SPIFFE SVIDs conform to.

16. Hardt, D. (2012). The OAuth 2.0 Authorization Framework. RFC 6749. The authorization framework extended by OIDC and adapted for machine-to-machine agent authentication.

17. Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., & Mortimore, C. (2014). OpenID Connect Core 1.0. OpenID Foundation. openid.net. The federated authentication protocol adapted for CI/CD-born agent identity attestation.

18. Kubernetes Project. (2024). Service Account Token Volume Projection. kubernetes.io. The Kubernetes mechanism for injecting bound, audience-scoped service account tokens into agent pods.

19. Laurie, B., Langley, A., & Kasper, E. (2013). Certificate Transparency. RFC 6962 | certificate.transparency.dev. The transparency log design pattern applied to agent identity bundles and SVID issuance records.

20. in-toto Project. (2023). A Framework for Securing the Software Supply Chain. in-toto.io | GitHub. Provides the attestation framework for agent provenance chains.

21. CNCF Security Technical Advisory Group. (2023). Cloud Native Security Whitepaper v2.0. Cloud Native Computing Foundation. GitHub. Contextualizes workload identity within the broader cloud native security landscape.

22. Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446. The transport security protocol mandated for all agent communication in the identity framework.

23. Sporny, M., Longley, D., & Chadwick, D. (2022). Verifiable Credentials Data Model v2.0. W3C Working Draft. w3.org/TR/vc-data-model-2.0. The verifiable credentials model that informs the Agent Card structure and signature verification.

24. Lampson, B. W. (1974). Protection. ACM SIGOPS Operating Systems Review, 8(1), 18-24. DOI:10.1145/775265.775268. The foundational work on access control matrices that informs the OSSA tier model's formal properties.

25. Anderson, R. (2020). Security Engineering: A Guide to Building Dependable Distributed Systems (3rd ed.). Wiley. ISBN: 978-1119642787. Free PDF. Provides the threat modeling methodology applied in Section 8 and the defense-in-depth strategy for agent identity.

26. Papernot, N., McDaniel, P., Jha, S., Fredrikson, M., Celik, Z. B., & Swami, A. (2016). The Limitations of Deep Learning in Adversarial Settings. IEEE European Symposium on Security and Privacy. arXiv:1511.07528 | DOI:10.1109/EuroSP.2016.36. Contextualizes adversarial threats to AI systems that identity mechanisms must address.

27. Clark, D. D., & Wilson, D. R. (1987). A Comparison of Commercial and Military Computer Security Policies. IEEE Symposium on Security and Privacy. DOI:10.1109/SP.1987.10001. The separation of duty principles that inform the OSSA role conflict matrix in Section 6.

---

This whitepaper is part of the BlueFly.io Agent Platform documentation series. For implementation details, refer to the agent-platform technical documentation wiki. For the OSSA specification, see https://gitlab.com/blueflyio/openstandardagents.

Document Hash: To be computed upon finalization. Signature: To be signed by platform architecture team upon review.