A companion piece to "The Agent Trust Stack: A Layered Framework." This post applies the framework to Citizen of the Cloud (CotC) to illustrate how a layer placement analysis works in practice and to make CotC's architectural scope precise.
The short answer
Citizen of the Cloud operates at Layers 2 and 3 of the agent trust stack, with a natural extension path into Layer 4. Its core scope is agent identity and agent reputation. It does not operate at Layers 5, 6, or 7, and it does not attempt to.
That focused scope is a feature of the product, not a limitation, and it is the basis on which CotC can integrate cleanly with systems operating at other layers of the stack.
This essay walks through the placement in detail, names what CotC does and does not do at each relevant layer, and identifies the integration boundaries that matter for anyone evaluating it as part of a complete agent trust architecture.
Layer 2: Identity is the structural foundation
The Layer 2 question is: who is this agent, who operates it, and how can a relying party cryptographically verify the answer?
Every primitive in CotC exists to answer some part of this question. The platform's primitives include keypair generation, agent registration, agent lookup, challenge issuance, challenge response, header signing, and agent verification. Each of these is a Layer 2 mechanism.
The output is what the framework calls verifiable identity attribution: a relying party can know with cryptographic certainty that a given action originated from a specific registered agent.
CotC's scope at Layer 2 is deliberately agent identity rather than operator identity. This is an important design choice and one that should be understood plainly rather than read as a gap. Operator identity, the legal entity behind an agent, is a separate trust problem with its own dynamics.
Many agent operators in consumer, open-source, hobbyist, or experimental contexts have legitimate reasons not to surface a legal identity. Forcing operator identification into an agent identity layer would either exclude those operators from the trust network or compromise the privacy properties that make the network usable for them.
CotC's choice to anchor at agent identity, with operator identification treated as an optional and separate concern, is the correct scope decision for a product trying to build a broad agent trust network.
That choice has architectural consequences. Reputation at Layer 3 attaches to agent identity, not to legal entity. Policy attestations at Layer 4, if CotC adopts them, would similarly be signed by the agent identity. This keeps the entire trust spine that CotC owns coherent at the same level of abstraction.
A concrete failure mode CotC's Layer 2 work addresses: without a cryptographically verifiable agent identity, a relying party cannot distinguish a legitimate agent making a permitted call from a spoofed request impersonating that agent. Every downstream trust mechanism, including reputation, capability restriction, and audit trails, requires a verifiable subject to anchor to.
CotC provides that subject.
Layer 3: Reputation as the commercial differentiation
The Layer 3 question is: what has this agent actually done over time, and how have prior interactions gone?
CotC's reputation primitives turn raw identity into accumulated trust. The check-trust primitive returns a composite trust score that a relying party can evaluate against a threshold. The report-agent primitive lets relying parties record formal violations against an agent's identity. The governance feed exposes ongoing activity across the registry.
These mechanisms collectively answer the Layer 3 question by aggregating volume of activity, verification events, dispute outcomes, and violation history against the stable identity established at Layer 2.
The framework explicitly recognizes that reputation inputs at Layer 3 can be exposed as a composite score or as component signals, and both shapes are legitimate. CotC's composite trust score is a defensible design choice. It enables fast threshold-based decisions, integrates cleanly into existing trust workflows, and provides a low-friction consumption surface for relying parties who do not need to do sophisticated weighting of individual signals.
Sophisticated consumers who do want component-level signals can build against the underlying metrics that feed the composite score; the existence of the composite does not preclude exposing the components.
The coupling between Layer 2 and Layer 3 is what makes CotC's architectural position defensible. Reputation requires stable identity to accumulate against. An identity registry without reputation is a directory; a reputation system without identity has nothing to attach scores to.
CotC owns the coupled pair, which is the natural unit of value at this part of the stack. Either half alone would be a weaker product. Together they constitute a coherent agent trust network.
A concrete failure mode CotC's Layer 3 work addresses: an agent with a history of policy violations across prior deployments would be invisible to a new counterparty without a reputation layer. The same patterns repeat across victims who cannot learn from each other's experience.
With CotC's reputation infrastructure, the new counterparty can query the agent's history before extending trust, and the cost of misbehavior compounds across deployments rather than resetting each time. This is the same dynamic that makes merchant reputation valuable in payment networks and seller reputation valuable in marketplaces.
Layer 4: The natural extension path
The Layer 4 question is: what has the operator formally committed the agent will and will not do?
CotC does not currently own Layer 4, but it is positioned more naturally than any other category of platform to extend into it. The argument is structural. Layer 4 is fundamentally about signed, versioned commitments attached to an agent identity.
CotC already operates the identity infrastructure, the signing primitives, and the registry that would host such commitments. Adding policy attestations to the CotC registry would be a feature extension rather than a new product.
The mechanism would look like this. An operator publishes a signed policy attestation describing what their agent commits to: tool allowlist, action scope, spending limits, escalation rules, refusal patterns. The attestation is signed by the operator's keypair, versioned, and hashed.
The CotC registry hosts the attestation reference and links it to the agent's identity profile. A relying party querying CotC for an agent's identity also receives the agent's current policy commitment hash, which they can verify against the published attestation.
This extension would not change CotC's architectural scope in a problematic way. The platform would still not enforce the commitments. Enforcement happens at Layers 5 and 6, which are different products.
But CotC would become the authoritative source for what an agent's operator has formally promised, which is a meaningful and commercially valuable trust artifact in its own right. Courts, regulators, and counterparties can point to signed commitments even when no automated enforcement exists.
Whether CotC adopts this extension is a roadmap question rather than an architectural one. The structural fit is clean, and the framework's Layer 4 description already implicitly anticipates identity registries as the natural host for policy attestations.
Where CotC does not sit
Three layers are worth naming explicitly because they are where CotC should not be expected to operate and where evaluators should know to look elsewhere.
Layer 5. Capability restriction is enforced at the credential and infrastructure layer: API tokens with scoped permissions, network egress allowlists, payment rail spending limits, IAM roles. CotC does not issue or enforce these.
A complete agent deployment using CotC for identity and reputation still needs proper capability restriction at the deployment infrastructure, and that responsibility falls to the operator and the systems the agent integrates with.
Layer 6. Action verification requires formal specification machinery and pre-execution conformance checking against typed action spaces. This is a separate product category entirely, with its own technical foundations in type theory, formal methods, and contract enforcement.
CotC's reputation and identity primitives are complementary to Layer 6 systems but do not substitute for them. An agent operating in a regulated industry that requires action conformance proof needs both: CotC for identity and reputation, plus a Layer 6 verification platform for action conformance.
Layer 7. Audit and provenance is adjacent to CotC but distinct. CotC could plausibly accumulate signed action histories tied to agent identity, and the report-agent primitive is reputation-adjacent rather than audit-trail-adjacent.
The core append-only audit log with cryptographic integrity guarantees, transparency-log structure, and structured explainability traces is a different product surface. CotC integrates well with Layer 7 systems by providing the verifiable identity that audit entries attach to, but CotC is not the audit trail itself.
What this means for evaluators
The framework's closing argument is that a complete agent trust story requires every layer to be addressed, by someone, and the relying party needs to know who owns which layer. CotC's positioning is straightforward about this.
It owns Layers 2 and 3 with a roadmap path into Layer 4, and it integrates with whoever owns the other layers in any specific deployment.
For anyone evaluating CotC, the right framing is to ask what is already in place at the other layers and what gaps CotC would fill. An evaluator with strong capability restriction at Layer 5 and a Layer 6 verification platform but no agent identity infrastructure gains substantial trust spine completeness by adding CotC.
An evaluator without any of the other layers needs more than CotC alone; CotC is one component of an agent trust architecture, not the architecture itself.
This is the right kind of clarity for sophisticated technical evaluators. Platforms that try to claim the whole stack lose credibility with anyone reading carefully. Platforms that articulate their layer scope precisely, identify the integration boundaries that matter, and surface what else is needed win those evaluations even when they own less of the stack.
CotC's natural positioning is in the second category.
Where this places CotC in the agent infrastructure landscape
The agent infrastructure landscape is currently noisy, with most platforms operating at one or two layers while claiming to solve the whole problem. CotC's value proposition is sharper when stated against this background: it is the identity and reputation infrastructure for the agent economy, and it makes no claim to be anything more.
That focused scope is what makes it a credible component of larger agent trust architectures, what makes its integration with other layers tractable, and what gives it a defensible place in the stack as the landscape matures and evaluators become more sophisticated about distinguishing the layers from one another.
The framework's view is that as the agent infrastructure landscape matures, the platforms that win sustained adoption will be the ones whose scope is clearly articulated and whose integration boundaries are clean.
CotC's positioning at Layers 2 and 3, with the natural Layer 4 extension, fits that pattern precisely.