When a contractor leaves, the organization needs to remove their access without taking the production application they maintained offline. Gateman keeps those actions separate: an account owner can disable the contractor's console membership, while the application continues authenticating to Gateman with its own runtime identity.
The next authenticated console request from the former team member is denied, even if their browser session has not expired. The application's authorized runtime requests are unaffected by that membership change. That lets the owner handle the Gateman access change directly, then review credentials according to what the contractor actually possessed.
Disable the person, keep the application running
Suppose an external developer maintained a live application for the organization. When the engagement ends, an account owner opens Team, chooses Disable for that member, and confirms. Gateman marks that account membership disabled. On the person's next authenticated console request, Gateman checks the current membership and denies access to that account—even through a session that was already open.
The change applies to the person's membership in this Gateman account. It does not delete their Gateman user account or modify their membership in a different account. The current Team interface does not offer a re-enable control; a returning contractor must accept a new invitation.
The application has a different identity. It authenticates to Gateman using its own application ID and signing configuration, and its enabled capabilities remain attached to the application. Disabling the contractor's membership does not disable that application, revoke its signing credential, or change its provider configuration. If the application and its other dependencies remain valid, its authorized production requests continue without a redeploy just to remove the contractor's console access.
That separation prevents a routine personnel change from automatically becoming an application outage. It does not replace the separate decision to rotate an application credential if the contractor had it.
If the contractor had console access only, disabling that membership does not by itself require replacing the application's signing credential. If they also had deployment access or a directly usable provider token, assess those separately.
Review what the contractor could actually use
Offboarding is easier to scope when the organization separates three things: the person's console membership, the application's runtime identity, and credentials the person could use independently.
Console access can change configuration
Members assigned to an application can manage its permitted configuration, including adding, replacing, or deleting stored credentials. Existing secret values cannot be retrieved through the console, while ordinary configuration such as sender email addresses and provider settings remains viewable. This lets developers administer an integration without making stored credentials available for copying.
When the membership is disabled, those console actions are denied on the person's next authenticated request. The owner can then decide whether any configuration changes made before departure need review.
Application signing material is a separate access path
Someone who has an application's signing credential can authenticate requests as that application, subject to its configured capabilities. Disabling their human membership does not revoke that material. If the contractor could access application signing material through deployment settings, source control, or another system, assess whether it should be rotated and update the application environment through the normal deployment process.
Runtime credential retrieval has its own authorization
Gateman can perform supported provider operations using configured provider credentials without returning those credentials to the application. Separately, an application may retrieve eligible stored values through authenticated POST /secrets/get when it has secrets:read; provider credentials also require that provider's Allow app retrieval setting. Named database passwords use POST /db/get and db:read instead.
If the contractor had application signing material for an app authorized to retrieve secrets or database passwords, include those values in the exposure review. Also check whether they held independently usable provider tokens or access to provider, cloud, source-control, CI/CD, hosting, or deployment accounts. Gateman does not revoke those external permissions or determine what someone copied outside its console.
This is why disabling console membership should not trigger blanket rotation of every production credential. A contractor who had only console access and no independent application or provider credentials is different from one who could authenticate as the application or use a provider token directly. Rotate or revoke values when the person's actual access warrants it, and update only the consumers that depend on the changed value.
A practical departure sequence
For the departing contractor, the owner can keep the process focused:
- Disable their Gateman membership from Team. Their next authenticated console request to the account is denied.
- Review independent access to application signing material, runtime secret retrieval, provider credentials, and the external systems used for the engagement.
- Rotate or revoke values where warranted, then update the deployments or services that use them.
- Confirm the production application can still perform its authorized operations after any credential changes.
If no independently usable credential needs to change, the membership update alone does not require an application redeploy. If a credential does need rotation, handle that as a separate change and verify the affected operation afterward.
For the exact disable workflow and request-time enforcement, see Teams and access management. Authentication describes the application's runtime identity. The stored-credential guide and database-password guide explain the separately authorized retrieval paths.