Kill switch et détection d'anomalies
Mettez n'importe quel agent IA en pause instantanément avec le kill switch, et laissez la détection en ligne à règles signaler réveils de dormants, identifiants expirés et pics de volume sans jamais bloquer le trafic légitime.
Un agent IA est un logiciel : il peut être compromis, mal configuré ou simplement oublié. Obexal donne à chaque agent deux filets de sécurité indépendants. Le kill switch met l'agent en pause, instantanément et de façon réversible. La détection d'anomalies en ligne signale les comportements suspects avec des règles déterministes, sans jamais ralentir ni bloquer un jeton légitime.
Ce que fait le kill switch
Le kill switch est le drapeau enabled de la politique de gouvernance de l'agent. Le passer à false neutralise l'agent immédiatement :
- Zéro nouveau jeton, sur tous les grants. Le token endpoint refuse
client_credentials, la délégation Token Exchange, et aussiauthorization_codeetrefresh_tokensi l'agent porte par ailleurs des grants interactifs. Il n'existe aucune porte dérobée. - Les jetons en circulation sont rapportés inactifs. L'introspection (RFC 7662) répond
{"active": false}pour les access tokens comme pour les refresh tokens d'un agent désactivé : les resource servers qui introspectent voient la révocation immédiatement. - Chaque tentative est consignée. Tout usage tenté malgré la désactivation lève une anomalie
killed_usede sévéritédanger.
Le kill switch échoue fermé : si la politique ne peut pas être lue, l'émission est refusée et l'introspection rapporte le jeton inactif, jamais l'inverse.
Un resource server qui ne fait que valider la signature du JWT localement continue d'accepter un access token déjà émis jusqu'à son exp. Plafonnez maxTokenTtlSeconds dans la politique de gouvernance pour borner cette fenêtre.
Une pause, pas une suppression
Désactiver un agent ne change que le drapeau enabled : le plafond de TTL, le plafond de scopes et l'allowlist d'audiences sont préservés, tout comme le client, son secret et ses autorisations utilisateur. La réactivation restaure l'agent exactement tel qu'il était, en un clic dans la console ou un appel d'API. Dans les deux sens, c'est une action sensible : la console exige une vérification MFA fraîche, et chaque bascule est écrite au journal d'audit sous l'action admin.agent.policy_updated.
curl -sS -X PUT https://accounts.obexal.com/v1/admin/agents/$AGENT_ID/policy \
-H "Authorization: Bearer $OBEXAL_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"enabled": false,
"maxTokenTtlSeconds": 300,
"scopeCeiling": ["tickets:read"],
"allowedAudiences": ["https://api.example.eu"]
}'
# 204 No Content : audité sous admin.agent.policy_updatedPUT .../policy remplace la politique entière : renvoyez les plafonds existants avec enabled: false. La console le fait pour vous.
Détection d'anomalies en ligne
La détection est à règles, déterministe, et s'exécute en ligne sur le chemin d'émission des jetons. Elle est strictement non bloquante : l'enregistrement d'une anomalie est en mode best-effort et ne retarde ni ne refuse jamais un jeton légitime. Elle ne s'applique qu'aux agents IA, c'est-à-dire aux clients qui portent le grant client_credentials ou Token Exchange.
Deux règles construisent une baseline comportementale à partir de l'activité horaire de l'agent. Elles sont évaluées quand l'activité de l'agent entre dans une nouvelle heure, sur l'heure qui vient de se terminer.
Les six règles
| Type | Sévérité | Se déclenche quand |
|---|---|---|
dormant_wakeup | info | un agent déjà utilisé, mais inactif depuis plus de 30 jours, émet à nouveau un jeton (une toute première utilisation n'est pas une anomalie) |
expired_agent | warn | une émission est tentée après la date d'expiration de l'agent (la demande est refusée) |
expired_secret | warn | l'agent s'authentifie avec un client_secret expiré (la demande est refusée) |
killed_use | danger | l'agent est utilisé malgré le kill switch (la demande est refusée) |
off_hours | warn | une fois qu'un historique d'activité suffisant existe, l'agent émet dans une heure du jour (UTC) où il n'a jamais été observé |
volume_spike | warn | l'heure qui vient de se terminer présente un pic bien au-dessus de la cadence habituelle de l'agent |
Déduplication et acquittement
Il existe au plus une anomalie ouverte par agent et par type dans l'organisation : les répétitions incrémentent son count et rafraîchissent lastSeen au lieu d'inonder la liste. Les anomalies ouvertes apparaissent aussi en badge sur l'inventaire des agents. L'acquittement ferme l'anomalie et est lui-même audité sous admin.agent.anomaly_acked.
curl -sS https://accounts.obexal.com/v1/admin/agents/anomalies \
-H "Authorization: Bearer $OBEXAL_API_TOKEN"{
"anomalies": [
{
"id": "0d5f0e93-8a43-4a5e-9a3f-2f4f0a7c1d2e",
"clientId": "agent-support-bot",
"agentName": "Support bot",
"kind": "volume_spike",
"severity": "warn",
"detail": {"prevHourCount": 412, "threshold": 96},
"count": 3,
"firstSeen": "2026-07-01T08:00:12Z",
"lastSeen": "2026-07-01T10:00:03Z",
"acknowledged": false
}
]
}curl -sS -X POST https://accounts.obexal.com/v1/admin/agents/anomalies/0d5f0e93-8a43-4a5e-9a3f-2f4f0a7c1d2e/ack \
-H "Authorization: Bearer $OBEXAL_API_TOKEN"
# 204 No ContentAjoutez ?all=true pour inclure les anomalies déjà acquittées dans la liste.
Confinement automatique en cas de dérive extrême
Un pic de volume extrême déclenche le confinement sans attendre un humain. Quand l'heure qui vient de se terminer présente un pic extrême, très au-dessus de sa cadence habituelle, Obexal pose lui-même le kill switch de l'agent, en préservant les autres plafonds, consigne une anomalie auto_contained de sévérité danger et écrit un événement d'audit agent.auto_contained. Un agent déjà désactivé n'est pas touché.
Ce seuil est volontairement placé très au-dessus de l'alerte volume_spike pour limiter les faux positifs. La réactivation est la même opération en un clic qu'après une pause manuelle. Les déploiements auto-hébergés peuvent couper ce comportement avec AGENT_AUTO_CONTAINMENT_ENABLED=false (actif par défaut), voir Configuration.