Cloud/AI Governance/Access Tokens
Access Tokens
The audit of every credential in your fleet: which tokens each MCP server holds, which are active, which have never been used and which were disabled, with the key always masked.
Every request in your fleet carries a Connection Token: it is how Vinkius knows who is asking. Access Tokens is the audit of those identities, server by server. The console states the mission in one line: "Audit every token across your fleet. See which tokens are active, which are stale, and where your security perimeter needs reinforcement."
Access Tokens
Audit every token across your fleet. See which tokens are active, which are stale, and where your security perimeter needs reinforcement.
| Token Name | Hint | Requests | Last Used | Status |
|---|---|---|---|---|
| Production | vk_live_•••••••• | 8,214 | 2m ago | Active |
| Staging | vk_live_•••••••• | 3,102 | 1d ago | Active |
| Token 3 | vk_live_•••••••• | 940 | Never | Disabled |
| Token 4 | vk_live_•••••••• | 152 | Never | Active |
| Token 5 | vk_live_•••••••• | 30 | Never | Active |
The mockup runs on the console's Sample Data. On a paid plan the same screen audits your live tokens, per organization.
The audit at a glance
Four cards open the screen: MCP Servers (how many have active tokens), Total Tokens (across all of them), Total Requests in the period and Avg Latency with a verdict attached: Excellent under 200ms, Moderate under 800ms, Slow after that, on a progress bar you can read from across the room.
One server at a time
The fleet renders as an accordion, one row per MCP server: a letter avatar, the server name, a tokens count chip, its request total, its average latency color coded and a 24 hour latency sparkline. The search box on top filters the fleet as you type, by server or by token name, so "production" or "stripe" lands on the right row instantly.
Click a row and it expands into that server's token table. This is the same flow the console uses for its lazy loading: the token list arrives only when you ask for that server.
Inside a server: the token table
Five columns, each with a job:
- Token Name. The human name you gave the token when it was created (the console's own sample uses Production and Staging first).
- Hint. The credential, masked:
vk_live_••••••••. The audit screen never prints a full key, not even to you. That is the point. - Requests. How much work this exact credential has done in the period.
- Last Used. The honest timestamp: minutes ago for the working tokens, Never for the ones that were provisioned and never called. A Never token is not a placeholder; it is a live key sitting in a drawer, and it is your shortest path to a smaller perimeter.
- Status. Active or Disabled. Disabled stays on the list on purpose: turning a token off is an audit event, not a deletion, so the history remains readable.
Why this screen exists
The tokens are the identities of your fleet. Mission Control's Live Activity attributes every execution to one of them; Agent Activity's Token Distribution shows which client arrived with which one. This screen is the directory that makes both readings possible, and it is where a leak response starts: the link format your AI clients use carries the token in it (https://edge.vinkius.com/vk_YOUR_TOKEN/mcp), so a leaked link is a revoked token away from being harmless. Revoke on the connector's Connection Tokens tab, hand out a fresh key, and the old one stops at the door.
The empty states are the console's own: "No MCP servers with tokens found.", "Try a different search term." and "No tokens found for this server."