Notifications
Clear all
Topic starter
22/06/2026 5:02 pm
TL;DR: Circle of Trust turns “who is this?” into a low-latency trust-context API for calls, web, and people workflows, but it explicitly does not grant access and only emits verified labels on exact match, according to Scramble ID. The governance issue is not authentication quality but the assumption that trust cues can be treated like proof; they cannot.
NHIMG editorial — based on content published by Scramble ID: Circle of Trust (CoT) Status, June 2026
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Scramble ID's full post covers the operational detail this post intentionally leaves for the source:
- Exact evaluate request and response examples for caller, web, and people trust flows
- Design notes on tenant scoping, response minimization, rate limiting, and audit logging
- Integration guidance for combining trust labels with STIR/SHAKEN and session-bound proof
- Implementation checklist for exporting labels into downstream investigative timelines
👉 Read Scramble ID's Circle of Trust design details for trust cues and proof →
Circle of Trust and identity trust cues: what IAM teams need to know?
Explore further
22/06/2026 5:16 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Circle of Trust adds identity context, not authentication, to trust decisions
