DocsSecurity
Credential inventory
Every credential that can spend money or change your INFRO configuration, on one list with owner, last use, last country, scope and ceiling, and a CSV export.
On the roadmap — not available yet. The Security screen is built and in testing, and not deployed: the console does not show it today. This page describes what it will ship with. The controls it links to (turning a key off, limits, allowed networks, rotation) are on the Keys screen today.
Security → Credentials lists every credential that can spend money or change configuration, wherever it is managed. Each row shows who created or holds it, its environment and project, when it was created and last used, the last country it was used from where INFRO records one, its expiry, what it may reach and its spending ceiling in words, and a link to the screen that manages it. No secret is ever shown: a masked ending tells two apart.
What it lists
| Credential | Managed on |
|---|---|
| Gateway keys | Keys |
| Provider connections and their fallback credentials, with the provider's reported cap where it reports one and a link to the provider's key page | Providers |
| Usage credentials (the read access cost reconciliation uses) | Cost reconciliation |
| Provider keys outside INFRO: keys your provider reported usage on in the last 30 days that no INFRO connection holds. They can spend outside every INFRO limit. | Your provider |
| Management API tokens | Management tokens |
| AI assistant grants | AI assistants |
| MCP gateway upstream credentials | MCP gateway |
| The SCIM token | SSO & SCIM |
| Webhook signing secrets | Webhooks |
| Studio share links (listed here, revoked in Studio) | Studio |
Provider keys outside INFRO need a usage credential (OpenAI and Anthropic, on the Business plan) and are listed only when the provider reported usage on them: a key that exists at your provider and was not used in the last 30 days is not listed. Without a usage credential the list says not checked, never none.
What each role sees
A role sees the credentials it can already read on their own screens. Management tokens need the role that manages policies (owner, admin), assistant grants the role that manages members, usage credentials the roles that read billing, and MCP gateway credentials the roles that read the MCP gateway. A section left out is named at the end of the list with the reason. A member limited to some projects sees their projects' gateway keys only.
On the roadmap. The Security role is built and not deployed. A Security member sees gateway keys, provider connections and their fallback credentials, MCP gateway credentials, the SCIM token, webhook secrets and Studio share links; management tokens, assistant grants and usage credentials are named as left out.
CSV export
Export CSV downloads the list as you see it, with these columns: kind, id, name, display, provider, owner, environment, project_id, status, created_at, last_used_at, last_country, expires_at, scope, ceiling. The file holds no secret and no hash. Through the console session: GET /console/security/credentials (JSON, with withheld naming each section left out and why) and GET /console/security/credentials/export (CSV; the X-INFRO-Export-Rows header carries the row count and X-INFRO-Withheld the sections left out).
When a credential may have leaked
- For a gateway key: turn it off from its row, which takes effect on its next request, then rotate it with no overlap once the place it leaked from is fixed. See Authentication.
- For a provider key: replace the credential on the connection, then revoke the old key at your provider from the linked key page. INFRO does not revoke keys at your provider.
- For a provider key outside INFRO: revoke it at your provider, or connect it so INFRO's limits apply to the traffic that goes through INFRO. Traffic sent directly to the provider stays outside them.
- For a management token or an assistant grant: revoke it on its screen.
- Read the audit log and the request log for the window, filtered to the credential.