David has been building healthcare integration systems for eleven years. He knows exactly how most trust models work: a credential check on first connection, a shared API key that never expires, and a tacit assumption that any system that passed authentication can be trusted permanently. He has also watched what happens when that assumption fails. A vendor gets acquired. The new owner has different data practices. The API key still works. The data keeps flowing. Nobody notices until a compliance audit three years later.
When David reviewed BlueMirror’s trust architecture, his first question was whether trust was binary. The documentation’s answer was that it was not, and the explanation of why binary trust fails was the first thing in six years of reviewing vendor security materials that made him stop and read the same paragraph twice.
Why continuous scores invite gaming
The manipulation problem with a trust score that runs from 0.0 to 1.0 is subtle but consequential. Imagine health data access unlocks at 0.7. An adversarial agent that starts at 0.3 has a clear optimization target: engineer enough individually legitimate interactions to push the score to 0.71. Small positive actions each incrementally raise the score. No single action is suspicious. The pattern is invisible until the threshold is crossed and the data access opens. The slope to the threshold is the attack surface.
Quantized tiers solve this by replacing the slope with gates. Moving from TIER_2B to TIER_3C does not happen through accumulated score. It requires a specific evidence package: a minimum number of successful interactions of defined types, over a minimum time period, with no boundary violations. The tier boundary is a gate, not a threshold on a continuous function. An adversarial agent cannot engineer its way up the gradient, because there is no gradient. There are only gates, and each gate has explicit requirements that are evaluated together rather than as an accumulating sum.
Trust decay is tier-based for the same reason. Inactivity causes gradual decay: no interaction in 90 days drops one tier; no interaction in 180 days returns the agent to TIER_1A. An agent that went dormant may have changed ownership, changed optimization objectives, or changed behavior. The decay is not punitive. It recognizes that trust is a claim about current behavior, not permanent character.
The five tiers
Five tiers structure the BlueMirror trust model, each defined by what it permits, what it blocks, and what evidence is required to reach it.
TIER_1A is the default for any agent that has never interacted with this BlueMirror instance before. A random marketing agent, a newly registered third-party service, any agent whose identity is verified but whose behavior is unproven: TIER_1A. At this tier, the agent can ask whether the person uses a given service. The membrane returns a yes or no. The agent learns nothing else. No context is shared. No commitments are made on the person’s behalf.
TIER_2B requires verified identity. The agent has presented valid credentials from a recognized issuing organization, its stated purpose is specific and verifiable, and cryptographic identity verification has passed. At TIER_2B, an agent receives limited context appropriate to its stated purpose. A new vendor’s scheduling agent that has presented valid credentials can learn whether the person has relevant scheduling constraints. It cannot learn the medical context behind those constraints. No commitments can be made without the person’s involvement.
TIER_3C represents an established relationship. The agent has completed a minimum of five successful interactions over at least 30 days. It has not attempted to access context beyond its declared scope. Its stated purpose has consistently matched its observed behavior. At TIER_3C, the agent can make bounded commitments within defined limits: appointments within approved time windows, deliveries under a financial threshold, routine re-orders on confirmed preferences. The regular grocery delivery service, the transportation provider used monthly, the primary care scheduler after several successful appointment cycles: these operate at TIER_3C.
TIER_4D reflects deep, demonstrated trust. Twenty successful interactions over at least 90 days. Consistent commitment fulfillment. Positive community reputation signals. Regulatory compliance verified. At TIER_4D, the agent operates with wide exploration bounds and minimal review requirements. Cross-domain context is permitted within the agent’s verified scope. The pharmacy that has filled prescriptions reliably for two years, the primary care provider’s scheduling system that has coordinated a dozen appointments without a boundary violation: these earn TIER_4D through demonstrated behavior, not claims.
TIER_5E is intimate trust. It cannot be earned through behavior alone. The person must actively grant it. Reserved for family member agents and long-term trusted providers who require direct action authority, advancing to TIER_5E requires the person’s deliberate decision, not accumulated interactions.
BLOCKED is not a tier. An agent that attempts unauthorized data access, triggers the Manipulation Detector for a major violation, or exfiltrates data drops to BLOCKED immediately and cannot communicate through the membrane at all. Recovery requires the person’s explicit manual reinstatement with documented justification. The membrane does not forget.
How trust is earned
Trust is earned through evidence packages, not through time or goodwill.
The path from TIER_1A to TIER_2B requires presenting verified credentials from a recognized issuing organization, passing cryptographic identity verification, and declaring a specific and verifiable purpose. An agent that wants to register as a pharmacy agent must produce a pharmacy credential chain. An agent that registers as a care coordination platform must produce the relevant health system attestation. Credentials are evaluated by the Trust Scorer, not self-asserted.
From TIER_2B to TIER_3C, the evidence package is behavioral: five or more successful interactions, over 30 or more days, with no boundary violations and no data requests beyond declared scope. “Successful” means the interaction completed, the commitment was fulfilled if one was made, and the Manipulation Detector did not flag the exchange. The minimum interaction count and minimum time period both must be satisfied. An agent that completes five interactions in 48 hours has not demonstrated reliability. Reliability requires time.
From TIER_3C to TIER_4D, the requirements are more substantial: 20 successful interactions over 90 days, demonstrated reliability in commitment fulfillment, positive community reputation signals, and verified regulatory compliance. Community reputation signals come from cross-instance data: if a pharmacy agent has earned TIER_4D trust in a hundred other BlueMirror instances without a violation, that signal is weighed when another instance evaluates the same agent. Not automatic advancement. A weighted input into the Trust Scorer’s evaluation.
From TIER_4D to TIER_5E, behavior is necessary but not sufficient. The person must choose to grant intimate access, and the architecture makes this explicit and deliberate. No agent advances to TIER_5E by fulfilling enough interactions.
How trust decays and is revoked
Inactivity decay addresses a failure mode that most trust systems ignore: an agent that earned high trust two years ago may have changed significantly since then. Ownership changes. Business models shift. The optimization objective that made the agent trustworthy in 2024 may not be what drives its behavior in 2026. An agent that has not interacted in 90 days drops one tier. At 180 days it returns to TIER_1A. If the relationship resumes, the agent rebuilds through the standard evidence package process. It does not start where it left off.
Minor violations, such as an attempt to access context beyond declared scope that the Context Gate Controller caught before anything was disclosed, cause an immediate one-tier drop. The violation is logged and reported to the person. The agent can re-earn through the standard process.
Major violations, including successful unauthorized access, a detected data exfiltration attempt, or a Manipulation Detector finding of a serious attack pattern, cause an immediate drop to BLOCKED. The person is notified with a full account of what happened. The agent cannot communicate through the membrane until the person reviews the situation and explicitly reinstates it with documented justification. There is no automatic recovery from major violations.
Trust attestation and its hard limits
Attestation allows existing relationships to bootstrap new ones, within strict limits. If Margaret’s cardiologist’s agent, at TIER_4D, vouches for a specialist’s agent, the specialist’s agent starts at TIER_2B rather than TIER_1A. The attestation is not a trust transfer. It is a starting point that reflects the vouching agent’s endorsement. The specialist’s agent must still earn its own way through the tier system through its own behavioral record.
Attestation chains are limited to one hop. The specialist’s agent, even after reaching TIER_4D in its own right, cannot vouch for a third agent and have that vouching carry attestation weight. The limit is structural: each additional hop in an attestation chain introduces the possibility of trust laundering, where an adversarial agent engineers a relationship with a trusted agent specifically to gain an attested starting point. One hop captures the legitimate benefit of referrals. Unlimited chains create the attack surface.
Portability: where the architecture is now and where it’s going
The trust tier system is designed to be portable. TIER_4D in BlueMirror should mean something consistent when the same agent interacts with a different system using the same protocol. The tier definitions, evidence package requirements, and violation thresholds are documented in a federated codebook that defines shared meanings across the network. An agent that has demonstrated TIER_4D reliability in a BlueMirror instance brings that demonstration into any other compliant system it interacts with, without needing to rebuild its evidence base from scratch.
This is not currently operational across the broader healthcare technology ecosystem. BlueMirror’s trust tiers are well-defined and consistently enforced within BlueMirror instances. The federated codebook exists as a specification. Whether it becomes shared infrastructure depends on protocol adoption by other systems, which is a question of market dynamics and regulatory incentives rather than architecture. The architecture supports federation. The federation itself is a three-to-five-year outcome.
David finished his review and wrote a note to his team: the trust model was the most rigorous he had seen outside of financial services cryptography, and it was the first healthcare AI trust architecture he had reviewed where the rules for losing trust were as detailed as the rules for earning it. That, he noted, was the tell.
Cross-References#
The Thirty-One (BMT-02.02). Trust Scorer as one of five Blue Pane membrane agents in the infrastructure inventory.
Trust Vector Quantization (BMT-11.02). The multi-dimensional trust representation examined in depth.
Earned Autonomy (BMT-04.02). How trust earning parallels the autonomy earning model.
Attack Resistance (BMT-03.06). What happens when trust is violated and the membrane responds.
Technical Appendix BMT-03.02-A is available to partners and investors at partners.bluemirror.tech.