Circle of Trust adds identity context, not authentication, to trust decisions

At a glance

What this is: Circle of Trust is a trust-graph service that returns context labels for people, brands, and channels so products can surface trust cues at the moment of interaction.

Why it matters: It matters because IAM and security teams often mix trust, identity proof, and access control, and this model shows why those layers must stay separate across human, NHI, and future agent workflows.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Scramble ID's Circle of Trust design details for trust cues and proof

Context

Circle of Trust is best understood as a trust context layer, not an authentication layer. It answers whether a person, channel, or entity is recognized in a curated trust graph, which is exactly the kind of decision many security teams already make informally but cannot enforce consistently across products.

That distinction matters for identity governance because trust cues are often treated as proof at the point of interaction. In practice, teams need separate controls for identity proofing, authorization, and display-time trust indicators, otherwise the UI becomes a source of false confidence rather than decision support.

The source article is explicit that CoT is still in development, so architects should treat it as a design direction rather than an operational control today. The underlying problem it addresses is typical: organisations have trust lists, but they are scattered, non-auditable, and unavailable when a real decision has to be made.

Key questions

Q: How should security teams use trust signals without turning them into proof?

A: Use trust signals only as context for routing, warnings, or step-up decisions, and keep authentication and authorization separate. A trusted label should never complete access on its own. The clean model is trust for expectation, proof for session establishment, and policy for the final decision.

Q: Why do trust lists fail in live identity workflows?

A: Trust lists fail because they are often fragmented, not normalized across channels, and unavailable at the moment of decision. A directory entry or phone list may tell you who is known, but it does not tell you whether the current interaction is legitimate. Live workflows need auditable, policyable trust context.

Q: What should teams do when a trust cue is only a near match?

A: Treat near matches as unverified and, at most, surface them as a warning. If the system cannot establish an exact match after normalization, it should return unknown rather than guess. That rule prevents false confidence and keeps the trust layer from becoming a spoofing oracle.

Q: Who is accountable when trust context is used inappropriately?

A: Accountability sits with the team that allowed a contextual label to be treated as proof. Governance should define where trust cues may appear, who can configure them, and which actions still require session-bound verification. If that boundary is unclear, the control will be misused.

Technical breakdown

Trust context versus authentication

Circle of Trust is a trust-graph service that returns labels such as verified brand, trusted person, or possible spoof based on curated inputs and exact-match rules. That is materially different from authentication, which proves a subject’s right to a session or action. CoT sits upstream of proof, feeding policy and user-interface cues without ever claiming to establish identity by itself. Its value depends on strict semantics: unknown remains unknown, and near matches never become verified. That is the right design boundary for any system that wants to reduce ambiguity without conflating context with assurance.

Practical implication: keep trust cues separate from proof and authorization logic in your identity architecture.

Exact match rules and spoof resistance

The design only allows a verified label when the subject matches exactly after normalization, such as E.164 for phone numbers or a lowercased registrable domain for web origins. That matters because fuzzy matching creates an enumeration oracle and turns a trust service into a guess engine. The optional possible spoof label is useful only when it remains a warning, not an approval path. In other words, CoT is a controlled classifier with conservative output, not a discovery tool that should expose every near hit or inferred relationship.

Practical implication: audit any trust-lookup workflow for leakage, especially where lookalike domains or numbers might be probed repeatedly.

How trust context fits zero trust and caller authentication

CoT aligns with Zero Trust Architecture because it acts as a context signal at the policy decision point, not as a standing entitlement. It also complements STIR/SHAKEN by answering a different question: the telecom layer can attest to the number, while CoT can indicate whether the identity behind that number is recognized in the relying organisation’s trust graph. Those are distinct controls and should remain distinct in design, telemetry, and UI language. If products collapse them into one green indicator, the operator loses the ability to tell recognition from proof.

Practical implication: wire trust context into policy as an input signal, but never let it override session-bound proof or step-up checks.

Threat narrative

Attacker objective: The attacker wants the target to accept a malicious request as legitimate by exploiting trust cues that were never meant to serve as proof.

1. Entry occurs when an attacker reaches a high-trust interaction surface such as a call, web request, or shared workstation and relies on ambiguity rather than compromise.
2. Escalation occurs when the user interface treats a contextual trust label as if it were evidence of legitimacy, creating a false sense of safety around a request.
3. Impact occurs when that misplaced confidence enables social engineering, misrouting, or unauthorized disclosure before proper proof is completed.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trust context is not proof, and the industry keeps confusing the two. Circle of Trust is useful precisely because it stays in the trust layer and refuses to become an access system. That separation is the right architectural instinct for human IAM, NHI governance, and any future agent-facing trust workflow. The practitioner lesson is to preserve that boundary in policy, UI, and audit trails.

Identity programs need a named trust-context layer, not just a directory and an MFA prompt. Most organisations already maintain curated lists of executives, vendors, and internal contacts, but those lists are rarely normalized, auditable, or available in live channels. A trust-graph service makes that intent operational, which is why this pattern belongs in the broader identity control stack. Practitioners should think in terms of trust signals, proof, and authorization as three separate controls.

Transitive trust is the real governance hazard in cross-tenant or cross-channel models. If one organisation vouches for another without preserving the issuing tier and assurance level, the weaker trust boundary gets inherited by the relying party. That is a familiar failure mode in federation, and it becomes more dangerous when applied to human trust cues. The practitioner conclusion is to retain issuer context on every external trust edge.

Trusted context must be treated as a policy input with a bounded lifetime. A label that is useful at call start may be stale by the time a sensitive action is requested. That makes trust context a time-bound signal, not a durable entitlement, and it belongs in the same governance conversation as session state and revocation. Teams should design for expiry, not permanence.

Identity blast radius is reduced when trust is queryable, but only if responses stay conservative. The value of a trust graph comes from surfacing the minimum reliable cue at the moment of decision, not from maximizing what the system can infer. Conservative semantics, tenant scoping, and auditability are what keep the control defensible. The practitioner conclusion is to optimize for safe ambiguity, not broad visibility.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For lifecycle and offboarding patterns that sit behind these trust-edge decisions, see the Ultimate Guide to NHIs and map external trust cues to revocation discipline.

What this signals

Trust context will become a governance primitive only if teams stop treating it like proof. The practical next step for IAM and security programmes is to document where contextual trust is allowed to influence routing, where it may trigger step-up, and where it is forbidden from changing access decisions. That separation will matter even more as human, NHI, and agent workflows converge in the same interfaces.

Identity programmes should expect more pressure to expose recognition cues at the point of interaction. The moment those cues become visible, they need tenant scoping, logging, and a clear expiry model. Otherwise, the same signal that helps users judge legitimacy can become a probing surface for attackers.

Trust graphs are only as useful as the governance around their edges. If you allow external parties, partner domains, or delegated channels into the model, the assurance level of the issuer must travel with the label. That is the difference between a defensible context service and an inherited weakest-link problem.

For practitioners

• Separate trust cues from authentication decisions Use trust labels only as context in the user interface or policy engine, and require cryptographic proof before any account action, payment, or sensitive workflow can complete.
• Normalize and constrain exact-match inputs Treat phone numbers, domains, and identity handles as normalized subject types, and reject any workflow that promotes near matches into verified status.
• Audit for trust oracle leakage Rate limit lookups, scope results to the tenant, and monitor repeated probing of subjects that could reveal brand or contact relationships.

Key takeaways

• Circle of Trust is a context service, not an authentication control, and that boundary is the point.
• Identity teams need conservative trust semantics because exact match, tenant scoping, and auditability are what keep trust cues safe to use.
• The governance risk is not that trust is visible, but that organisations will mistake recognition for proof and let context overrule verification.

Key terms

• Trust context: Trust context is supplemental identity information used to guide a decision, such as a known contact, a verified brand, or a trusted cohort label. It informs routing, warnings, or step-up, but it does not prove identity or grant access on its own.
• Verified brand: A verified brand is a subject that matches a canonical brand record exactly after normalization, such as a lowercased registrable domain or a phone number in E.164 format. The label indicates recognition within a trust graph, not authentication or authorization.
• Transitive trust: Transitive trust occurs when one party inherits trust from another without preserving the original assurance level or scope. In identity governance, that weakens accountability because the relying organisation may accept a label without knowing how strong, bounded, or revocable the underlying assurance really is.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Scramble ID: Circle of Trust (CoT) Status, June 2026. Read the original.