When trust should end

Trust is not forever

Security advice often focuses on adding trust: verify fingerprints, accept invites, confirm identities.

Less often it talks about removing trust when the relationship ends.

That omission matters. A co-founder who leaves the company. A contractor whose engagement finished. A partner you no longer share finances with. Each case needs a way to say: new sensitive handoffs should stop, even if old accepted records remain part of your history.

NT² treats trust as relational and revocable — not as a permanent capability you forgot to clean up.

Block: stop new inbound without rewriting history

Block on a secure contact stops new inbound messages from that vault identity.

It does not erase shares you already Accepted into vault. Those items remain in your structured records because they were decisions you made at the time.

That split is deliberate:

• History — what you chose to keep.
• Future — what you are willing to receive next.

If a former contractor should not send production keys to your vault anymore, block closes the door forward. It does not pretend the past sprint never happened.

Block also hides the contact from the Share recipient picker, so you are less likely to send outbound shares by muscle memory to someone who should no longer receive them.

Remove contact: delete the local trust row

Remove contact deletes the local entry — display name, cached Vault Key DID document, peer connection material for that relationship.

Use it when the relationship is over and you do not expect to reconnect through NT² soon. If you work together again, you will run the invite flow from scratch — which is appropriate after a long gap.

Remove is stronger than block. Block is the everyday "please stop sending" control.

Encrypted links expire by design

Not every trust relationship lives in Contacts.

When you shared an API key to a contractor through an encrypted link with a share passphrase and expiry, the trust model was already one-shot. The link should stop working when the expiry passes.

That is a different off switch — time-bound instead of identity-bound. Read An encrypted link is not an email attachment.

The habit mistake is mixing modes: treating a one-time link like a standing relationship, or keeping a contractor as a verified contact long after the project ended when you only ever needed a weekend deploy key.

When blocking beats silence

Silence is a weak security control. A blocked contact cannot fill your Inbox with new requests you feel guilty ignoring.

If someone rotates out of a team with access to sensitive infrastructure, the healthy move is often:

1. Rotate the secrets they had access to — NT² cannot do that for external systems.
2. Block or remove them as a contact so new vault-to-vault paths close.
3. Prefer encrypted links with short expiry for future short engagements instead of permanent contact rows.

For the habit that created the problem, see You pasted the API key in Slack.

Verified did not mean permanent

Even verified contacts were never "trust everything forever." Inbox still required accept or decline per share. Block and remove exist because verified only meant a proof event happened — not that the relationship cannot end.

Read Verified trust is cryptographic, not a button for how that badge works.

Close the series loop

Trust in NT² stacks in layers:

1. Identity, assets, trust, and sharing — the map.
2. Secure contacts — naming relationships.
3. One-way invite, mutual trust — completing two-way paths.
4. Verified trust — proof, not vibes.
5. Three ways to share — pick the mode that matches the relationship.
6. This post — end trust when the relationship ends.

Browse nt2.me/guides/contacts for contact management, or follow the RSS feed.