DocsSecurity
Security screen
The console's Security screen: posture checks on your keys and credentials, and the most your gateway keys can spend in the next 24 hours under your limits.
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, under Governance in the console, gathers in one place what INFRO already records about your credentials: which keys are unbounded or open to any network, what the worst day could cost, which signals are open, and every credential that can spend money or change configuration. It is on every plan. It reads only: nothing on it refuses a request or changes a key by itself. Each line links to the screen that fixes it.
It has three tabs: Overview (this page), Signals, Credentials. Tripwire keys are planted from it too.
On the roadmap. The emergency stop, the Rules tab and Incidents are built and not deployed. The emergency stop pauses gateway traffic for the whole organization, one environment, one project, or every key except the ones you name, from this screen and without a deploy. The Rules tab sets policies for new keys and the responses you choose for a signal, and Incidents guides the response to a leak and produces its report. Each part lists its own availability.
Worst day
The most estimated provider cost your organization's gateway keys can produce in the next 24 hours under the limits in force now. It is computed from your configuration, not forecast from your traffic: each key is bounded by the tightest blocking limit that applies to it (its own limit, its project's, or the limit on the member who created it), and the organization's hard cap bounds the total.
- A limit counts what is left in its current window, plus a whole new window when it resets within the 24 hours: a daily limit late in the UTC day admits the rest of today and all of tomorrow. A lifetime limit counts only what is left.
- A project or member limit is shared by every key under it, so it is counted once however many keys it bounds.
- The figure reads Unbounded when a key has no limit at any level and no organization hard cap applies, or when the owner chose to serve unpriced requests past blocking budgets: an unpriced request has no worst case, so nothing bounds it.
- It covers gateway keys only. Playground and Studio use, and anything spent with a provider key directly at the provider, are not in it.
To bound it, set a limit on each key, its project or its creator, or an organization hard cap. See Spend controls and Rate & spend limits.
Posture checks
Each check is one line with a count and a link. Attention asks for a decision; info is a fact that is not wrong by itself; not checked means INFRO cannot answer it with what you have connected, never that the answer is none.
| Check | What it counts | Status when it counts something |
|---|---|---|
| Members without two-factor | Members whose account has no second factor. Info when the organization already requires two-factor. | Attention |
| One owner | The organization has a single owner. | Attention |
| Keys without a ceiling | Usable gateway keys with no blocking limit on the key, its project or its creator. | Attention |
| Keys usable from any network | Usable gateway keys with no allowed networks. | Attention |
| Unrestricted production keys | Production keys that reach every provider and every model, while the organization has no model allowlist. | Attention |
| Keys without an expiry | Usable gateway keys with no expiry date. | Info |
| Keys expiring within 14 days | Keys that stop working within two weeks. | Attention |
| Keys older than 90 days | Keys created more than 90 days ago. | Info |
| Keys unused for 30 days | Keys with no request in 30 days. | Attention |
| Connections without the usage-outside-INFRO check | Connections to a provider whose usage INFRO can read (OpenAI, Anthropic) with no usage credential turned on for it. | Attention |
| Connections without a provider-reported cap | Connections whose provider reported no spending limit on the key. | Attention |
| Provider keys outside INFRO | Keys at your provider that no INFRO connection holds. Not checked without a usage credential. | Attention |
| Management tokens that can write | Management tokens holding a write scope. | Info |
| AI assistant grants | Assistants signed in to the organization through the INFRO MCP server. | Info |
| Models unrestricted | The organization has no model allowlist. | Info |
| Prompt recording on | Prompts and model responses are recorded for this organization. | Info |
The usage credential, and with it the checks that read your provider's own usage, is part of cost reconciliation, on the Business plan. On other plans those two lines read not checked or count the connections without it.
Provider-side caps
On the roadmap. Provider-side cap confirmation is built and not deployed. A spending limit set at your provider on the key you connected is the control that still holds if INFRO itself were breached: a provider key taken from INFRO works directly at the provider, outside every INFRO limit. Where the provider reports a limit on the key, INFRO shows it. Where it does not, an owner, admin or Security member can confirm on the connection that the key has a limit at the provider, from a link to the provider's own limits page. INFRO records who confirmed it and when, and does not check the statement. Saving a newer credential on the connection voids the confirmation, because it was a statement about the old key.
On the roadmap. Provider-side cap confirmation is built and not deployed. Through the console session: GET /console/security/provider-caps lists each connection with status (reported, confirmed or unconfirmed), reported_limit and reported_reset where the provider reports them, confirmed_at, confirmed_by and provider_keys_url. PUT /console/security/connections/{id}/provider-cap with {"confirmed": true} records a confirmation, false withdraws it; each is in the audit log as provider_connection.cap_confirmed or provider_connection.cap_unconfirmed. A member limited to projects is refused.
Who can open it
Owners, admins, developers, analysts and finance members. A member limited to some projects opens Signals and Credentials narrowed to their projects' gateway keys; the Overview is organization-wide and closed to them. Creators cannot open it. See Members.
On the roadmap. The Security role is built and not deployed. Members with the Security role open all of it, and can contain a key from it. See Containing a key and the Security role.
From your own tooling
The console reads GET /console/security/overview with your console session. It returns worst_day (status bounded or unbounded, amount in US dollars or null, unbounded_reasons, the ceiling that bounds each key in by_key), checks (each with id, status, count and the console href that fixes it), the open signals by severity, and the organization's governance facts as the Summary reports them. A member limited to projects is refused with 403 project_restricted.
On the roadmap. Security through the management API and MCP is built and not deployed. With a management token holding security:read, the same answer is GET /manage/v1/security/overview; see Security in the management API.
On the roadmap. The SIEM export is built and not deployed. To send the audit log, security signals and the staff access log to your own logging or SIEM tooling, see SIEM export.