Service tokens for applications
Pipelines, agents and internal apps get their own named credential instead of borrowing a person's key.
What it is
Administrators issue service tokens to CI pipelines, agents and internal apps, so each integration has its own named credential instead of borrowing a person's key. Service tokens can call models but can't open dashboards or any other part of the application API.
Why you want it
Integrations outlive the people who set them up. A service token keeps working when its creator leaves, appears by name in reports and the request log, and can be given its own grants, quotas and security policy.
One credential per integration, each with its own spend, requests, errors and model list.
Actual Janus interface · Demo identities and synthetic usageHow it works
- Tokens start with janus_svc_, are shown once, and can carry a description and an expiry date. Rename or revoke them at any time.
- They are proxy-only: any call to the application API is refused with policy.service_token_scope.
- Grants, quotas, rate limits and security policy bindings can all target a single service token.
- Service usage counts in organization totals and is kept out of people-oriented reports.
In the product
Screenshot above. Actual Janus interface with demo identities and synthetic usage.
See it on your own network.
The Community edition is free for up to 25 people. The 30-day Business trial unlocks every Business feature.