DocsSecurity
Security signals
One feed of what may mean a credential is misused: leak signals on gateway keys, provider credential problems, spend anomalies, network refusals, widened access.
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 → Signals lists, newest first, everything INFRO already records that may mean a credential is being misused. Each signal is the evidence it fired on (counts, countries, days, estimated cost) and the next actions that fit it, never a score. No signal refuses a request. A new region or a launch looks like a leak for an hour, so turning a key off, limiting it or narrowing it is your decision, taken from the key itself.
Kinds
| Signal | Fires on | Source and cadence |
|---|---|---|
| Key used from many countries | A gateway key used from six or more countries in one UTC day. Lists the countries seen. | The leak detector, hourly. |
| Key volume jump | A gateway key's day reaching twenty times its median day over the previous seven days, and at least 500 requests. | The leak detector, hourly. |
| Provider credential | A provider reported a connected key revoked, invalid, expired or about to expire. Resolved once you save a newer credential for that connection. | Connection checks. |
| Usage outside INFRO | Your provider's own usage for a key you connected shows 10% or more of its tokens that did not go through INFRO. OpenAI and Anthropic, with a usage credential (on the Business plan). | The provider usage sync, every six hours. |
| Spend anomaly | A gateway key's or a connection's day departing from its usual day. | The spend alerts task, every 15 minutes. |
| Secret in a prompt | The guardrails secret detector matched in a request: a count per key and day, never the text (Business plan, where the detector is on). | Guardrails, per request. |
| Network refusals | Requests a key's allowed networks refused, per key and day. | Per request, counted daily. |
| Access widened | An audit entry that opened access: a key's limit, allowed networks, provider or model list or expiry removed, a key turned on again, a policy loosened, a member made owner or admin, the two-factor requirement turned off, ownership transferred, a management token that can write, an assistant granted, an assistant's refresh token used twice, a SCIM token issued, an SSO provider added. Shows who did it and the IP address the change came from. | The audit log. |
| Retired key presented | Not available yet. A revoked, rotated-out or expired gateway key was presented again: the strongest evidence that a copy of it exists. Counts by country and day. Critical. The request still gets the same 401 as before. | Counted per request; raised by the security checks, every 15 minutes. |
| Turned-off key called | Not available yet. A gateway key you turned off is still being called. Counts by country and day. Warning. | Counted per request; every 15 minutes. |
| Refusal burst | Not available yet. A key's requests refused today by its allowed networks, its spend limit or its model list reached at least 50 and five times its median day over the previous seven days. Critical from 1,000 refusals at fifty times its usual day. The controls held; whoever holds the key is hitting them. | Every 15 minutes. |
| Spend in the last hour | Not available yet. A key's estimated provider cost over the last 60 minutes reached at least $10 and ten times the median of the same 60 minutes one to four weeks earlier. Keys younger than eight days are not scored. Critical from $100 at fifty times. Shown as a volume jump. | Every 15 minutes. |
| New model or provider | Not available yet. A key served a model or reached a provider it had not used in the last 90 days. One signal a key a day, listing them. Info. A key is learned for its first seven days before it can fire. | Every 15 minutes. |
| Key expiring | Not available yet. A key expires within seven days. Warning when it was used in the last seven days (whatever calls it will start getting 401), info otherwise. Not raised for a key replaced by a rotation with an overlap. | Every 15 minutes. |
| New key at your provider | Not available yet. Your provider lists an API key that was not there at the previous read and that no INFRO connection holds: someone created a key in your provider account. The first read only records the list. OpenAI and Anthropic, with a usage credential. | The provider usage sync, every six hours. |
| Tripwire touched | Not available yet. One of your tripwire keys was presented: the place you planted it has leaked. Critical, one signal a tripwire a day, its counts and countries updated as the day goes on. | Per request. |
| Distillation-shaped traffic | Not available yet. A key's last 24 hours took the shape of model distillation: at least 2,000 requests, busy in at least 22 of the 24 hours at a flat rate, and at least 800 output tokens per request on average, when that is not the key's own usual week. A heuristic: a batch job looks the same, so it is a warning and refuses nothing. Read from request metadata only (counts per hour, output tokens, models), never from prompts or responses. | Hourly, in the first quarter of the hour. |
| Sign-in from a new country | Not available yet. A member signed in to the console from a country their account had not signed in from in the last 180 days. Warning, raised in each organization they belong to. See Members' sessions and sign-ins. | At sign-in. |
| Emergency stop | Not available yet. A member pressed or released the emergency stop. Critical, with who did it and the reason; it cannot be muted. | When it is pressed or released. |
Access widened is read from what each audit entry records. Removing a limit is recognised; raising one is not, because the entry does not record the previous value.
INFRO records a country for these counts, never the caller's IP address or user agent. An unknown key belongs to nobody, so a flood of unknown keys is refused per address (429 invalid_api_key_rate_limited) and is not a signal of any organization.
Severity and status
- Critical, warning or info. A revoked, invalid or expired provider credential and a reused refresh token are critical; a credential about to expire is a warning; network refusals are info below 100 requests in a day.
- Open, acknowledged or resolved for signals with a lifecycle: the leak detector's, provider credentials, usage outside INFRO and spend anomalies. You acknowledge a spend anomaly on Alerts as today; the others are read-only on this screen.
- Observed for facts about a window (refusals on a day, a secret seen, an audit entry): nothing to close, never counted as open.
Next actions
A signal on a gateway key offers Turn off, Rotate, Allowed networks, Lower the limit and Open requests (the request log filtered to the key and the window); each opens the key's own control on the Keys screen, under the role it needs today. A signal on a provider credential offers Replace the credential and a link to the provider's own key page, where you revoke it; usage outside INFRO and a new key at your provider offer that link. INFRO does not revoke keys at your provider. An access change offers Review the audit log.
The Keys screen also shows, for each key, the countries it was used from over the last seven days, with request counts and network refusals by country, and the last country it was used from. INFRO records a country per request, never the caller's IP address.
Containing a key
On the roadmap. The Security role is built and not deployed. Contain narrows a gateway key from the Security screen and never widens it, so the people who respond to a signal can act without the rights to create or loosen keys. Owners, admins, Security members and developers may contain; a developer limited to projects only the keys in their projects. It works while the organization is locked for a lapsed plan or held, and takes effect on the key's next request, with no deploy.
| Field | Allowed when it |
|---|---|
disabled: true | Turns the key off. Turning it on again is Release. |
credit_limit {amount, period} | Admits no more in any window than the key's current limit: a longer window with an amount no higher, or a shorter window whose windows inside one current window add up to no more. never adds a lifetime cap beside the window and never replaces it. |
allowed_ips | Lists only networks the key already allows (at least one entry). On a key open to any network, any list. |
allowed_providers | Lists only providers the key may already reach (at least one entry). On a key that reaches every provider, any list. |
model_allowlist | Allows only models the current list allows and keeps every ! block it has (at least one entry). On a key with no model list, any list. |
rate_limit_rpm | Is a lower tier. |
expires_at | Is in the future and earlier than the current expiry; on a key with no expiry, any future time. |
On the roadmap. The Security role is built and not deployed. Through the console session: POST /console/security/keys/{id}/contain with at least one of the fields above and an optional reason (up to 300 characters) returns {id, contained}, the fields applied. A field that would widen the key is refused with 403 permission_denied and code containment_widens, naming the field, and nothing is written. Each containment is in the audit log as api_key.contained, with the fields, their previous values and the reason. POST /console/security/keys/{id}/release turns on again a key that was turned off through Security; a key turned off from the Keys screen needs the Keys screen's rights to turn on, and otherwise gets the same 403 containment_widens. A lowered limit is raised again from Keys, by the roles that may edit keys; the audit entry keeps the old value.
On the roadmap. Security through the management API and MCP is built and not deployed. A management token with security:write, or an assistant through the MCP tool contain_gateway_key, contains a key with POST /manage/v1/security/keys/{id}/contain and the same body, under the same rules, as the person who created the token.
The leak email
When the leak detector raises a signal for a key (six or more countries in a day, or twenty times its usual volume), INFRO emails the organization's billing contact, once while the signal is open. The email names the key and links to it, so you can turn it off, rotate it or limit it. Nothing is blocked. If the traffic is your own deployment, nothing needs doing.
Security email to every member
On the roadmap. Security email to every member is built and not deployed. Each signal the security checks raise is emailed to every member of the organization, whatever their role, creators included, and to the billing contact when no member holds that address: one email when the signal opens, none when it is updated. A member who would get more than five in an hour gets one digest of the rest, at most one an hour. A member limited to projects is emailed about keys anywhere in the organization, because an incident crosses projects; what the console then shows them still follows their role and projects.
On the roadmap. Security email to every member is built and not deployed. Some kinds mean a credential is certainly loose and cannot be muted: usage outside INFRO. Every other kind can be muted by each member for themselves, under Account in the console. Through the console session, GET /console/security/email-preferences lists each kind with mutable and muted, and POST with {"muted": [...]} sets the member's list; a kind that cannot be muted is refused with 400 invalid_request and code security_email_unmutable, and nothing is written. INFRO keeps the record of who was emailed about which signal for 90 days.
On the roadmap. Security email to every member is built and not deployed. Security signals also go to Slack, Microsoft Teams, PagerDuty and signed webhooks on every plan, through a notification rule for a security.* event. See Alerts.
Filters and the API
The console reads GET /console/security/signals. Filters: kind (a comma-separated list of key_countries, key_velocity, provider_credential, usage_outside_infro, spend_anomaly, secret_in_prompt, network_refusals, access_widened), severity, status (open, acknowledged, resolved, observed), subject_type (key, connection, provider, member, organization), key_id, days (1 to 90, default 30) and limit (1 to 500, default 200). An unknown value is refused with 400 invalid_request naming the accepted ones.
Each signal carries id (stable across reads), kind, severity, status, subject (type, id, name, the key's masked form, provider, project), title, evidence, occurred_at, actions and provider_keys_url. The response's open counts the open signals by severity under the same filters. A member limited to projects sees only signals on their projects' gateway keys.
On the roadmap. Security through the management API and MCP is built and not deployed. The same feed, with the same filters, is GET /manage/v1/security/signals for a management token holding security:read, and the MCP tool list_security_signals for an AI assistant. A project-restricted token is refused with 403 project_restricted: an incident crosses projects.