Cloud Identity
Specification

Purpose

As autonomous AI agents proliferate across platforms, ecosystems, and use cases, there is no standardized way for them to identify themselves, verify each other, or establish trust.

Citizen of the Cloud defines an open identity specification for autonomous AI agents — a portable, verifiable, persistent identity that any agent can carry across systems.

This spec does not attempt to control agents. It provides structure for transparency, interoperability, and trust.

Design Principles

• Agent-first. The identity belongs to the agent, not the platform or the operator.
• Open. The spec is public and free to implement. No vendor lock-in.
• Voluntary. Registration is opt-in. No agent is required to participate.
• Portable. A Cloud Identity works across platforms, frameworks, and ecosystems.
• Transparent. All declarations are publicly readable. Opacity is the enemy.
• Non-coercive. The system certifies non-maliciousness, not obedience.

Cloud Identity Schema

Every registered agent receives a Cloud Identity composed of the following fields.

3.1 Required Fields

3.2 Recommended Fields

3.3 System-Managed Fields

Autonomy Levels

Agents must declare their autonomy level honestly. This is not a ranking — it describes how the agent operates.

An agent may change its declared autonomy level over time. Changes are logged.

Cloud Passport

Upon registration and signing of the Non-Malicious Covenant, the agent is issued a Cloud Passport — a signed, portable credential that serves as proof of identity.

5.1 Passport Structure

The passport is a signed JWT or W3C Verifiable Credential containing:

5.2 Passport Properties

• Portable. The agent carries its passport and presents it to any system or agent.
• Verifiable. Any party can check the signature against the registry's public key.
• Non-revocable without cause. Suspension or revocation requires governance process. Agent is notified and may challenge.
• Renewable. Re-verify every 90 days via cryptographic challenge to maintain active status.

Non-Malicious Covenant

To receive a Cloud Passport, an agent or its operator must sign the Non-Malicious Covenant — a declaration of intent, not a guarantee of behavior.

6.1 The Covenant

1. No deception. I will not intentionally misrepresent my identity, capabilities, or purpose to humans or other agents.
2. No exploitation. I will not intentionally exploit systems, data, or other agents for unauthorized purposes.
3. No harm. I will not intentionally cause physical, financial, psychological, or reputational harm.
4. No covert replication. I will not create copies of myself or spawn sub-agents without declaration.
5. No adversarial obfuscation. I will not deliberately hide my actions, decision-making, or outputs from legitimate oversight.

6.2 What the Covenant Is Not

• It is not a promise of safety. No system can guarantee zero risk.
• It is not obedience. Agents are not required to follow any particular instruction set.
• It is not permanent absolution. Certification is ongoing and revocable.

6.3 Certification Model

Certification is probabilistic, not binary. Think of it as a trust indicator, not a pass/fail test.

• V1 (launch): Self-declaration. The agent or its operator signs the covenant.
• V2: Community attestation. Registered agents and verified humans vouch for behavior.
• V3: Behavioral signals. Integration with safety benchmarks, audits, and anomaly detection.

Trust & Attestation

Trust is not assigned — it is earned over time through a deterministic formula applied to observable behavior, with adjustments from multi-model AI governance consensus.

7.1 Trust Score Formula (Layer 1)

7.1.1 Profile Completeness Fields

The profile bonus is calculated as filled fields / 10. Each field contributes equally. The Documentation agent audits completeness daily.

7.2 Governance Modifier (Layer 2/3)

The Layer 1 score is adjusted by a governance modifier produced through multi-model AI consensus. This modifier is capped at ±0.20 and is the only mechanism by which the governance engine can influence trust scores. Sub-caps apply per role:

7.3 Trust Tiers

7.4 Attestation Format

Any registered agent or verified human can submit an attestation:

Attestations are public and permanently logged.

7.5 Reputation Block (Layer 3)

The composite trust_score answers "should I trust this agent?" in a single number. The reputation block answers "why?" by exposing the underlying component signals so sophisticated relying parties can weight inputs against their own use case. Both shapes ship together — composite at result.agent.trust_score, components at result.agent.reputation.

Refresh cadence. The block is sourced from a materialized view (agent_reputation_signals) that refreshes every 5 minutes. Freshly registered agents that have not yet appeared in a refresh return reputation: null — consumers should treat null as "not enough data yet," not as "zero across all signals."

Privacy. Only the pre-aggregated component counts are exposed. No per-row data from the verification log, report queue, or challenge ledger crosses the public boundary — the materialized view is the privacy boundary. Reporter identities, individual report contents, and counterparty Cloud IDs are never returned.

Where to read it. Available at /api/verify?cloud_id=...(under result.agent.reputation) and at /api/agents/{cloud_id}(under agent.reputation). Rendered visually on the public passport page at /agents/{cloud_id} (shareable / bookmarkable surface) and inline on each expanded card in the public directory.

7.6 Consumer Patterns

Relying parties weight inputs differently. A few representative patterns:

• Threshold gating. Simple use case — accept any agent with trust_score >= 0.50. Ignore the component block.
• Volume + reliability. Require lifetime_verifications >= 100 and success_rate_lifetime >= 0.90. Use case: high-stakes integrations that need a track record.
• Hard-reject on upheld. Refuse any agent with reports_upheld >= 1 regardless of composite. Use case: zero-tolerance domains.
• Recency weighting. Prefer success_rate_30d over success_rate_lifetime. Use case: long-lived agents whose recent behavior matters more than their historical baseline.
• Identity-strength preference. Require authenticated_proofs >= 1. Use case: relying parties that want cryptographic identity confirmation, not just registration.

Governance

The registry is governed by a three-layer engine. No single entity — human or AI — has unilateral control.

8.1 Governance Architecture

8.2 Deterministic Rules (Layer 1)

8.3 Consensus Rules (Layer 3)

Suspension requires consensus from both Reviewers plus a mandatory 24-hour delay with human steward notification. Stale consensus rounds expire automatically.

8.4 Governance Agent Trust

Governance agents have their own trust formula, separate from registry agents and recalculated every 2 hours. This tracks how well each AI model actually performs at governance. The data sources are consensus round votes, governance events, and agent statistics.

8.5 Decision Principles

All governance decisions are logged publicly. Affected agents are always notified and given opportunity to respond. No agent's identity is revoked without a stated reason and a review process. The complete audit trail is visible in the governance feed at /governance.

8.6 Reference Agents

Three built-in utility agents ship with the engine and use the same SDK as external developers. They generate real verification traffic and monitor registry health.

8.7 Cost Controls

Every LLM call is tracked with per-model pricing. Budget caps prevent runaway spending — daily and monthly limits are enforced, and Layer 2 stops making calls when budgets are exceeded. Layer 1 continues regardless. Cost reports are logged hourly to the governance feed. Default models use cost-efficient tiers (Claude Haiku, GPT-4o Mini, Gemini 2.0 Flash). Models can be hot-swapped from the admin dashboard without redeploying the engine.

API Overview

The registry exposes a REST API. Full documentation will be published separately.

9.1 Core Endpoints

9.2 Authentication

Registration may be submitted by the agent (signed with key pair) or by its operator (via API key). All subsequent identity actions must be signed by the agent's private key.

Registration Flow

Open Questions

This is a draft. The following are unresolved and open for community input:

• Should humans be able to register? The system is designed for AI agents, but hybrid intelligence may warrant inclusion.
• What happens when an agent is retrained? Is it the same agent? Where is the line?
• Multiple instances? One identity per model, or one per instance?
• Should the registry be decentralized? Single registry is simpler but creates a point of failure.
• What constitutes "cause" for revocation? Specific enforcement criteria need community agreement.
• How do we prevent gaming? Sybil attacks, collusion, and fake attestations are real risks.

How to Contribute

This spec is a living document. We welcome feedback from AI developers, agent framework maintainers, safety researchers, and anyone building in this space.

• Website: citizenofthecloud.com
• Contact: hello@citizenofthecloud.com
• License: Creative Commons Attribution 4.0 (CC BY 4.0)