Access for small teams, without shared passwords
If your team runs shared staging, test or small production environments, you have probably shared a root password at some point. WingGate replaces that habit with explicit, auditable, revocable access per member.
The three problems every small team hits
None of these need a big organization to appear — three people and one shared server are enough.
Shared credentials
One root or admin password pasted into a chat. Nobody knows who used it last, and rotating it means telling everyone again.
Hard offboarding
When someone leaves, the honest options are rotating every shared secret or trusting that nothing lingers. Both are bad.
No evidence after incidents
Something broke at 2 a.m. With shared logins there is no reliable way to answer who connected, to what, and what they did.
The authorization model that fixes this
WingGate makes access explicit instead of implied. The chain has three links, each with a clear owner:
-
Organization — your team's boundary
Assets, members and audit history live inside an Organization. Owners invite members; membership never grants access to any asset by itself.
-
Project — a scoped set of assets
A Project groups the assets a granted member may use. Organize by environment or by team; members only see the Projects granted to them.
-
Project access grant — per member, per scope
A grant binds a member to a Project's full data plane. Revoke the grant to take back Web Terminal, SSH, file, and MCP together.
Access methods have fixed permission sets. A grant is all-or-nothing for the Project; finer MCP limits come from Project/asset MCP configuration.
Members never browse the whole fleet. They see exactly the Projects and assets their grants cover, which keeps day-to-day access focused and reduces the blast radius of a compromised account.
What actually happens across a member's lifecycle
The same grant chain answers the three moments that hurt with shared credentials.
Joining
The Owner invites the person into the Organization — they accept from the Invites area of their account — then grants them the Projects their role needs. Their first connection is already attributed to them personally, including MFA enrollment at onboarding.
Changing roles
Moving between teams is a grant change, not a credential rotation: revoke the old Project grant, issue the new one. Existing sessions are re-checked against current authorization.
Leaving
Revoke the member's grants and the next authorization check fails immediately — no shared secret to rotate, no residual access to hunt for. Their historical audit entries remain attributable to them.
Audit and accountability
Every grant decision and every session leaves a record in the Organization's audit view, so accountability does not depend on memory.
- Authentication events, grant changes and session start/end are recorded with the acting identity — who connected is never ambiguous.
- File and MCP operations are covered by the same audit trail, so you can reconstruct what happened during an incident review.
- Revocation takes effect at the next authorization check; an active session can be revoked, which drops its underlying connection.