Connecting a platform to Threat Unknown creates a credential inside your account. You should not have to take our word for what it can reach. Every one of them is visible on a screen you already own, and every one of them can be removed by you, without asking us.
You create the service account and the identity pool inside your own Google project, and you add one domain-wide delegation entry for it. We never hold a key. Find the entry in the Admin console under Security, Access and data control, API controls, Domain-wide delegation: it is the row carrying that account's numeric client ID. Deleting the row ends our access.
A CloudFormation template you run creates a role called ThreatUnknownAudit in your own account. Its trust policy names exactly one principal on our side, requires an external ID, and caps a session at one hour. Find it under IAM, Roles, ThreatUnknownAudit, where you can read the trust relationship and every permission attached to it. Deleting the stack removes the role.
A GitHub App installed on your organization, not an engineer added to your repositories. Find it in your organization settings under GitHub Apps, where the Configure screen lists every permission it was granted and every repository it can see. Uninstalling it there ends our access.
Either an API token you create and paste, or an OAuth grant. We recommend the token, because you choose what it carries: the four edit permissions in our setup guide are optional, and skipping them leaves us able to report but not to change anything. Find it under My Profile, API Tokens, where you can roll it or delete it.
A team token you create and paste. Vercel does not offer a read-only token, so it carries your own permissions. That is a Vercel constraint rather than a choice of ours, and it is the reason the next section matters. Find it under Settings, Tokens, and delete it there to end our access.
No cloud platform we support offers a credential that can read everything a security assessment needs and change nothing. Vercel has no read-only token at all. So the honest claim is not that we cannot change your environment. It is that the scanning code does not, and that this is checked rather than promised: a test walks everything the scan imports, on every platform, and fails the build if it reaches any call that is not on a list of reads. It is an allow list rather than a block list, because the block list we tried first missed six ways of writing.
Any tool that changes something has to present a single-use approval token, and the token is checked against a hash of the exact arguments, your organization and the session it belongs to. The dispatcher refuses the call if the token is missing, already spent, bound to different arguments, or if the service that verifies it cannot be reached. It fails closed, not open. A change tool that skips the gate is not something an engineer here can write by accident either: the registry rejects it at startup.
Disconnecting a platform deletes our stored copy of your credential. It does not reach into your account and revoke the underlying access, and we would rather say so than let you assume otherwise. The screens listed above are yours. You can revoke there first, without telling us, and the disconnect will still clean up our side afterwards.
You should not have to trust a security vendor. You should be able to check one.