TRUSTIVAN support cannot read your organization’s data. Not “does not as a matter of policy” — cannot, because there is no credential that would let them until you grant one, and the grant expires on its own. This page is what that means in practice.

​
What support can always see

Without any grant from you, TRUSTIVAN staff can see your organization’s commercial position and nothing else:
  • its name, slug and creation date
  • its plan, subscription status and renewal date
  • counts: seats, assets, open findings, scans in the last 30 days, failed scans in the last 7 days, API keys
That is what makes it possible to answer “why did my scan quota stop” without asking you to grant anything. It is deliberately a set of numbers. It contains no finding, no image name, no repository, no policy, no credential and no secret.

​
What support can never see

No grant, ever, unlocks any of these:
  • any secret: registry credentials, webhook signing secrets, API keys, TOTP seeds, cloud credentials. These are encrypted or hashed, and there is no read path from the support console to any of them.
  • the ability to write anything inside your organization. A support session runs in a read-only database transaction, so the refusal is PostgreSQL’s, not a check somebody could forget.
  • impersonation. There is no “act as this user” in TRUSTIVAN. If a change has to be made in your organization, you make it.

​
Granting a window

An owner or admin of the organization — a person, signed in, not an API key — turns it on: Settings → Security → TRUSTIVAN support access Choose how long (1 hour, 4 hours, 24 hours, 3 days) and say what it is for. While the window is open, a TRUSTIVAN support engineer can open a read-only session and see:
  • your members: user id, email, role
  • your assets: kind, name, when they were last updated and last scanned
  • your recent scans: status, target and when they ran
Nothing else. Not finding detail, not SBOM contents, not policy definitions. An API key cannot grant this, whatever scopes it holds. Consenting to vendor access is a decision a person makes, so it sits behind a permission that is never granted to a machine.

​
Ending it

Three things end it, and you only have to do the first if you want to:
  1. Revoke now, in the same panel. An open support session stops on its very next request.
  2. The window expires. It ends by itself at the time you chose. There is no state where support keeps access because somebody forgot.
  3. The session times out. Independently of your window, any single support session is capped at 60 minutes.

​
What you can see afterwards

Everything. Settings → Audit log shows every TRUSTIVAN staff action against your organization, recorded as an actor of kind staff, with the person’s address, what they did, and the reason they gave. That includes actions taken without a support window — a plan change, an entitlement override, a suspension. You do not have to ask for this and you do not have to be told: it is in your own audit log, written at the same moment as TRUSTIVAN’s own copy. If the two ever disagreed, yours is the one in your database.

​
Self-hosted deployments

If you run TRUSTIVAN yourself, there are no TRUSTIVAN staff accounts in your deployment at all — the support console has no credential that resolves, so the whole surface is unreachable. Your own operators can create staff accounts (staffctl bootstrap), and everything on this page then describes them, including the consent requirement and both audit trails.