Identity and access
Keys and service identities
Keys let scripts, AI clients and Git act for an organization with exactly the scopes you choose.
A key is a separate identity that belongs to an organization, not to a person. It has a name, a type and its own scopes.
Types
| Type | Prefix | Accepted by |
|---|---|---|
| MCP client | si_mcp_ | The MCP server, and Git over HTTPS. |
| API | si_api_ | Git over HTTPS. |
| Agent | si_agent_ | The platform API and Git over HTTPS. Platform organization only. |
Git over HTTPS accepts a key of any type that has the git scope it needs. For programmatic access, organizations use the MCP server; the platform API serves the platform's own apps.
Self-hosted agents don't use keys: each device gets its own credential (si_dev_) when it's approved.
Create a key
Owners and admins open https://id.dev.gov.vin, select the organization and open Keys:
- Enter a name and choose the type.
- Optionally set an expiry in days (1–365). Empty or
0means it never expires. - Select the scopes. You can grant only scopes you hold yourself;
:readscopes are preselected. - Select Create key.
The key is shown once. Copy it into your secret store then; it can't be shown again.
Use a key
Send it as a bearer token:
Authorization: Bearer si_mcp_…Git takes it as the password (Repositories).
Revoke a key
Select Revoke next to it. Requests with it fail from then on. The list shows each key's type, number of scopes and when it was last used for MCP.
How keys are stored
Only a SHA-256 hash of each key is stored, so the platform can recognize a key but can't show it again. Creating and revoking keys is recorded in the audit log, and what keys do there is recorded with the key as the actor.