Portal Access Offboarding

The defect

Agencies, law firms, accountants and property managers all build the same portal, and access is a link — a signed URL, a magic link, an invite token. That link is a bearer credential: whoever holds it is the client.

Then the engagement ends. The client is offboarded in the CRM, removed from the project, marked inactive. The link keeps working, because it was never connected to the relationship. No error, no alert, and no screen anywhere listing "people who can still see your files". The usual way this is discovered is a forwarded email, months later.

  auditGrants(grants, { now, relationships: { c1: "ended" } });
  // [{ severity: "critical", problems: ["outlived_relationship"],
  //    detail: "the client relationship is ended, but this grant still opens …" }]

Revoke the set, not the link

A three-year engagement leaves a trail: the original invite, a re-send after someone lost it, one issued to the client's accountant, one pasted into a Slack channel. Revoking the link revokes one of them.

  grantsToRevoke(grants, "c1", now);  // every live grant for that client

An unknown client is treated as ENDED

The relationship map comes from your CRM. The realistic reason a client is missing from it is that the record was deleted or the export missed it — **exactly the cases where access should have been cut.** Defaulting unknown to "active" would make the audit quietest on the records that fell out of the system, which is where the risk actually is.

Where the token sits

| placement | verdict | |---|---| | query (?token=…) | flagged | | fragment, header, cookie | fine |

A token in the query string leaks in ways nobody intends: the Referer header sends the full URL to every third-party asset on the page, and it lands in server access logs, analytics, browser history, and whatever the client pastes into an email. The fragment is never transmitted to the server at all.

Also flagged: grants with no expiry, links needing no sign-in (forwarding the link forwards the access), and long-dormant grants — where revoking costs nobody anything.

What it does not do

| not included | why | |---|---| | Issuing, storing or revoking grants | it reads your grant records and tells you which to kill | | Authentication | see route-guard-flash for the client-side half | | Field-level redaction inside the portal | public-disclosure-projection |

issuable() checks a grant before you mint it, which is the cheaper place to fix all of this.