Trust Model

Anchor Connect trust is explicit and reviewable. The question is simple: did the right component broker the right session for the right user to the right resource under the right policy?

Identity Component identity

Connect components are explicit operational objects, not invisible proxy nodes.

Launch Launch context

Session launch context stays scoped, time-bound, and policy-approved.

Lifecycle Lifecycle

Health, trust, drain, disabled, and credential posture are reviewable.

Evidence Session evidence

Actor, target, broker, status, recording metadata, and audit context stay connected.

Trust Inputs

• Component identity and registration.
• Component trust, health, drain, disabled, and credential state.
• Launch token or session context validity.
• Target resource and account binding.
• Policy decision from the Anchor control plane.
• Session lifecycle status.
• Recording metadata and session termination state.
• Ledger-backed event integrity.

Control Plane Authority

Anchor Connect does not replace Anchor’s policy engine. The control plane remains responsible for authentication, authorization, scope/resource access, effective policy, component eligibility, session metadata, audit history, and Ledger-backed evidence.

The access plane brokers the session. The control plane owns the decision.

Practical Validation

Trust validation answers whether session access is still attached to the intended control model. That matters when teams review component health, target reachability, timeout behavior, termination, launch denial, recording metadata, or session evidence.

Component Component

Connect identity, trust state, lifecycle, and credential posture are visible.

Launch Launch

The control plane issues scoped launch context only after policy allows it.

Session Session

The access plane brokers the session without owning the policy decision.

Evidence Evidence

Recording metadata, lifecycle status, audit, and integrity signals support review.

Session Evidence

A governed session should produce a coherent record:

• Who requested access.
• Which resource and account were involved.
• Which policy allowed, denied, or shaped the workflow.
• Which Connect component brokered the session.
• When the session moved through launch, active, termination, failed, expired, or ended states.
• Whether recording metadata exists and how it maps to the session.
• Which audit and Ledger records support the activity.

Trust Outcome

The trust model gives security teams a direct way to reason about component identity, policy-gated sessions, target resources, and audit evidence without spreading session trust across disconnected tools.