◆ Pour les responsables IAM, sécurité des identités et support
Votre agent d’identité lira un jour un ticket piégé.
Avec ZIFFER, il ne peut pas autoriser un accès admin dessus.
L’agent lit le ticket. Il n’autorise pas le groupe. Chaque ajout à un groupe privilégié, chaque réinitialisation MFA et chaque nouveau compte passe par la règle que vous avez signée, ou par deux approbateurs nommément désignés.
◆ Pour les responsables IAM, sécurité des identités et support
Votre agent d’identité lira un jour un ticket piégé. Avec ZIFFER, il ne peut pas autoriser un accès admin dessus.
L’agent lit le ticket. Il n’autorise pas le groupe. Chaque ajout à un groupe privilégié, chaque réinitialisation MFA et chaque nouveau compte passe par la règle que vous avez signée, ou par deux approbateurs nommément désignés.
Où l’IAM s’est arrêtée
L’IAM a laissé l’agent répondre au ticket. Elle ne l’a jamais laissé toucher un groupe privilégié.
L’agent lit, répond, oriente et ajoute des personnes aux groupes ordinaires. L’ajout à un groupe privilégié, la réinitialisation MFA d’un administrateur et le nouveau compte attendent encore un humain nommé, et l’IAM a raison : c’est là que le domaine se perd.
La peur a un nom.
- Le ticket que lit l’agent est écrit, en partie, par l’attaquant. Fin 2025, une équipe de recherche en sécurité a écrit des instructions dans le champ de description d’un ticket. L’agent IA d’une plateforme ITSM, lancé par un administrateur, pouvait les suivre avec les privilèges de l’administrateur et attribuer des rôles au compte de l’attaquant. Recherche sur une configuration par défaut, 2025-11 ; rien n’a été perdu.
- La version humaine fonctionne déjà. Les attaquants « se sont fait passer pour des employés afin de convaincre le support informatique de … réinitialiser le mot de passe de l’employé et de transférer sa MFA vers un appareil qu’ils contrôlent », et « abusent des relations de confiance des services de support informatique sous-traités ». Avis conjoint AA23-320A, CISA, FBI, NCSC-UK et partenaires, mis à jour le 2025-07-29.
- L’étape de confirmation dans la plateforme d’agents n’est pas une deuxième personne. Dans une preuve de concept, l’outil qui a créé l’utilisateur et attribué le rôle admin tournait en mode supervisé, et l’attaquant pouvait « réutiliser la même charge de confirmation une deuxième fois pour autoriser l’attribution du rôle ». La CVE a été corrigée le 2025-10-30.
La peur a un prix.
- « Les faiblesses d’identité ont joué un rôle déterminant dans près de 90 % de nos investigations. » Unit 42 Global Incident Response Report 2026, plus de 750 interventions.
- L’hameçonnage vocal est le deuxième vecteur initial à 11 %, et le premier dans les compromissions cloud à 23 %. Mandiant M-Trends 2026.
- 68 % ne distinguent pas les actions des agents de celles des humains ; 74 % disent que les agents obtiennent souvent plus d’accès que nécessaire. CSA, n = 228, 2026-03.
| Question posée | Réponse | Source, échantillon, date |
|---|---|---|
| Utilisez-vous déjà des agents IA ? | 82 % oui | SailPoint (Dimensional Research), n = 353, 2025-05 |
| Vos agents ont-ils pris des actions non prévues ? | 80 % oui | idem |
| Vos agents ont-ils été manipulés pour révéler des identifiants d’accès ? | 23 % oui | idem |
| Les agents obtiennent-ils souvent plus d’accès que nécessaire ? | 74 % oui | CSA, commandée par Aembit, n = 228, 2026-03 |
| Distinguez-vous les actions des agents de celles des humains ? | 68 % non | idem |
| Des agents ont-ils dépassé les permissions prévues ? | 53 % oui | CSA, commandée par Zenity, n = 445, 2026-04 |
| Êtes-vous très confiant dans la capacité de votre IAM à gérer les identités d’agents ? | 18 % le sont | CSA, commandée par Strata Identity, n = 285, 2026-02 |
| Pouvez-vous rattacher partout les actions des agents à un humain ou à un système ? | 28 % le peuvent | idem |
Huit réponses issues de quatre enquêtes. L’enquête SailPoint est menée par un éditeur ; chaque enquête CSA nomme l’éditeur qui l’a commandée.
Huit réponses, quatre enquêtes, un même constat. L’agent a déjà l’accès, et peu savent dire ce qu’il en a fait.
L’IAM avait raison de garder un humain sur l’ajout à un groupe privilégié. Elle avait tort de croire le ticket fiable parce que l’agent l’avait lu.
Où l’IAM s’est arrêtée
L’IAM a laissé l’agent répondre au ticket. Elle ne l’a jamais laissé toucher un groupe privilégié.
L’agent lit, répond, oriente et ajoute des personnes aux groupes ordinaires. L’ajout à un groupe privilégié, la réinitialisation MFA d’un administrateur et le nouveau compte attendent encore un humain nommé, et l’IAM a raison : c’est là que le domaine se perd.
La peur a un nom.
- Le ticket que lit l’agent est écrit, en partie, par l’attaquant. Fin 2025, une équipe de recherche en sécurité a écrit des instructions dans le champ de description d’un ticket. L’agent IA d’une plateforme ITSM, lancé par un administrateur, pouvait les suivre avec les privilèges de l’administrateur et attribuer des rôles au compte de l’attaquant. Recherche sur une configuration par défaut, 2025-11 ; rien n’a été perdu.
- La version humaine fonctionne déjà. Les attaquants « se sont fait passer pour des employés afin de convaincre le support informatique de … réinitialiser le mot de passe de l’employé et de transférer sa MFA vers un appareil qu’ils contrôlent », et « abusent des relations de confiance des services de support informatique sous-traités ». Avis conjoint AA23-320A, CISA, FBI, NCSC-UK et partenaires, mis à jour le 2025-07-29.
- L’étape de confirmation dans la plateforme d’agents n’est pas une deuxième personne. Dans une preuve de concept, l’outil qui a créé l’utilisateur et attribué le rôle admin tournait en mode supervisé, et l’attaquant pouvait « réutiliser la même charge de confirmation une deuxième fois pour autoriser l’attribution du rôle ». La CVE a été corrigée le 2025-10-30.
La peur a un prix.
- « Les faiblesses d’identité ont joué un rôle déterminant dans près de 90 % de nos investigations. » Unit 42 Global Incident Response Report 2026, plus de 750 interventions.
- L’hameçonnage vocal est le deuxième vecteur initial à 11 %, et le premier dans les compromissions cloud à 23 %. Mandiant M-Trends 2026.
- 68 % ne distinguent pas les actions des agents de celles des humains ; 74 % disent que les agents obtiennent souvent plus d’accès que nécessaire. CSA, n = 228, 2026-03.
- Utilisez-vous déjà des agents IA ?82 % ouiSailPoint (Dimensional Research), n = 353, 2025-05
- Vos agents ont-ils pris des actions non prévues ?80 % ouiidem
- Vos agents ont-ils été manipulés pour révéler des identifiants d’accès ?23 % ouiidem
- Les agents obtiennent-ils souvent plus d’accès que nécessaire ?74 % ouiCSA, commandée par Aembit, n = 228, 2026-03
- Distinguez-vous les actions des agents de celles des humains ?68 % nonidem
- Des agents ont-ils dépassé les permissions prévues ?53 % ouiCSA, commandée par Zenity, n = 445, 2026-04
- Êtes-vous très confiant dans la capacité de votre IAM à gérer les identités d’agents ?18 % le sontCSA, commandée par Strata Identity, n = 285, 2026-02
- Pouvez-vous rattacher partout les actions des agents à un humain ou à un système ?28 % le peuventidem
Huit réponses issues de quatre enquêtes. L’enquête SailPoint est menée par un éditeur ; chaque enquête CSA nomme l’éditeur qui l’a commandée.
Huit réponses, quatre enquêtes, un même constat. L’agent a déjà l’accès, et peu savent dire ce qu’il en a fait.
L’IAM avait raison de garder un humain sur l’ajout à un groupe privilégié. Elle avait tort de croire le ticket fiable parce que l’agent l’avait lu.
La pièce manquante
Retirez l’autorisation des mains de l’agent. Laissez-lui le ticket.
L’agent lit, répond, oriente et propose. Son rôle s’arrête là. Qui rejoint quel groupe est décidé par une règle que vous avez signée avant la vacation, et par deux approbateurs nommément désignés pour tout groupe privilégié, toute réinitialisation MFA d’un compte privilégié, tout compte bris de glace.
Le ticket reste chez l’agent. L’autorité vit dans votre connecteur, sur un reçu. ZIFFER ne détient aucun identifiant d’IdP, d’annuaire ou de PAM.
- règle
- Classe du groupe, classe du compte, expiration, jours depuis la création du compte, qui peut signer. Un groupe que la règle ne nomme pas est au palier le plus haut. Une action que la règle ne nomme pas est refusée.
- quorum
- Deux approbateurs nommément désignés, des passkeys, et un résumé rendu à partir des octets signés de la proposition : compte, groupe, expiration, ticket de changement présent ou non. Celui qui propose ne compte jamais.
- reçu
- Signé, vérifié hors ligne par votre connecteur avant l’appel à l’IdP. ZIFFER ne détient aucun identifiant d’IdP, d’annuaire ou de PAM.
L’agent lit le ticket. Il n’autorise pas le groupe.
La pièce manquante
Retirez l’autorisation des mains de l’agent. Laissez-lui le ticket.
L’agent lit, répond, oriente et propose. Son rôle s’arrête là. Qui rejoint quel groupe est décidé par une règle que vous avez signée avant la vacation, et par deux approbateurs nommément désignés pour tout groupe privilégié, toute réinitialisation MFA d’un compte privilégié, tout compte bris de glace.
Le ticket reste chez l’agent. L’autorité vit dans votre connecteur, sur un reçu. ZIFFER ne détient aucun identifiant d’IdP, d’annuaire ou de PAM.
- règle
- Classe du groupe, classe du compte, expiration, jours depuis la création du compte, qui peut signer. Un groupe que la règle ne nomme pas est au palier le plus haut. Une action que la règle ne nomme pas est refusée.
- quorum
- Deux approbateurs nommément désignés, des passkeys, et un résumé rendu à partir des octets signés de la proposition : compte, groupe, expiration, ticket de changement présent ou non. Celui qui propose ne compte jamais.
- reçu
- Signé, vérifié hors ligne par votre connecteur avant l’appel à l’IdP. ZIFFER ne détient aucun identifiant d’IdP, d’annuaire ou de PAM.
L’agent lit le ticket. Il n’autorise pas le groupe.
Ce que les normes disent déjà
La règle n’est pas nouvelle. Seul l’agent l’est.
| Ils ont écrit | Qui, quand | Mécanisme ZIFFER |
|---|---|---|
| « Multi-party approval. An administrator’s credential is only released if a different, authorised individual(s) approve it. » | UK NCSC, Secure system administration | quorum 2 sur 2 sur chaque ajout à un groupe privilégié |
| « Rule based auto approval. When a specific criteria is met, the credential is automatically approved without human intervention. » | UK NCSC, Secure system administration | les groupes standard sont autorisés immédiatement par la règle, avec un reçu |
| « Enforce dual authorization for … privileged commands and/or other actions. » | NIST SP 800-53 rev 5, AC-3(2) | deux signataires nommément désignés ; celui qui propose ne compte jamais |
| « Require approvals by … personnel or roles for requests to create accounts » | NIST SP 800-53 rev 5, AC-2(e) | create_account a besoin d’une règle ; sans règle, refusée |
| « Required privileges are approved by authorized personnel. » | PCI DSS v4.0.1, 7.2.3 | le reçu nomme les approbateurs |
| « Implemented with only the privileges specified on the documented approval. » | PCI DSS v4.0.1, 8.2.4 | un autre groupe est une nouvelle proposition et une nouvelle signature |
| « User identity is verified before modifying any authentication factor. » | PCI DSS v4.0.1, 8.3.3 | une réinitialisation MFA sur un compte privilégié attend le quorum |
| « In all cases, account recovery SHALL cause a notification to be sent to the subscriber » | NIST SP 800-63B-4, 4.2.3, 2025-07 | notification au titulaire du compte à chaque réinitialisation privilégiée |
| « giving consideration to the concepts of least privilege and segregation of duties » | SOC 2, CC6.3 | l’agent propose, des personnes signent, votre code détient l’identifiant IdP |
| « Utilise human-in-the-loop control to require a human to approve high-impact actions … in a downstream system » | OWASP LLM06:2025, 2024-11 | le contrôle se tient hors de l’agent, avant l’appel à l’IdP |
Chaque contrôle exigeait une autre personne avant que le groupe ne change. ZIFFER est le premier endroit où l’agent ne peut pas être cette personne.
Ce que les normes disent déjà
La règle n’est pas nouvelle. Seul l’agent l’est.
- « Multi-party approval. An administrator’s credential is only released if a different, authorised individual(s) approve it. »UK NCSC, Secure system administrationMécanisme ZIFFERquorum 2 sur 2 sur chaque ajout à un groupe privilégié
- « Rule based auto approval. When a specific criteria is met, the credential is automatically approved without human intervention. »UK NCSC, Secure system administrationMécanisme ZIFFERles groupes standard sont autorisés immédiatement par la règle, avec un reçu
- « Enforce dual authorization for … privileged commands and/or other actions. »NIST SP 800-53 rev 5, AC-3(2)Mécanisme ZIFFERdeux signataires nommément désignés ; celui qui propose ne compte jamais
- « Require approvals by … personnel or roles for requests to create accounts »NIST SP 800-53 rev 5, AC-2(e)Mécanisme ZIFFERcreate_account a besoin d’une règle ; sans règle, refusée
- « Required privileges are approved by authorized personnel. »PCI DSS v4.0.1, 7.2.3Mécanisme ZIFFERle reçu nomme les approbateurs
- « Implemented with only the privileges specified on the documented approval. »PCI DSS v4.0.1, 8.2.4Mécanisme ZIFFERun autre groupe est une nouvelle proposition et une nouvelle signature
- « User identity is verified before modifying any authentication factor. »PCI DSS v4.0.1, 8.3.3Mécanisme ZIFFERune réinitialisation MFA sur un compte privilégié attend le quorum
- « In all cases, account recovery SHALL cause a notification to be sent to the subscriber »NIST SP 800-63B-4, 4.2.3, 2025-07Mécanisme ZIFFERnotification au titulaire du compte à chaque réinitialisation privilégiée
- « giving consideration to the concepts of least privilege and segregation of duties »SOC 2, CC6.3Mécanisme ZIFFERl’agent propose, des personnes signent, votre code détient l’identifiant IdP
- « Utilise human-in-the-loop control to require a human to approve high-impact actions … in a downstream system »OWASP LLM06:2025, 2024-11Mécanisme ZIFFERle contrôle se tient hors de l’agent, avant l’appel à l’IdP
Chaque contrôle exigeait une autre personne avant que le groupe ne change. ZIFFER est le premier endroit où l’agent ne peut pas être cette personne.
Une vacation, quatre scènes
La règle que vous avez signée à 09:00 a répondu au ticket à 10:41.
Horloge de démonstration. Quorum 2 sur 2 pour chaque action évaluée HIGH, puis une mise en attente de 60 secondes avant la libération. Fenêtre d’attestation de 15 minutes.
09:10
L’élévation d’astreinte.
Un ticket de changement pour la migration de base de données de ce soir est approuvé. L’agent propose add_group_member : le DBA d’astreinte dans prod-db-admins, expiration 8 heures. Palier T3, HIGH. Le responsable IAM et le propriétaire de la base lisent « ajouter r.okafor à prod-db-admins, expire à 17:10 », rendu à partir de la proposition signée, et signent avec des passkeys. Mise en attente 60 secondes ; personne ne l’arrête ; libérée. L’ajout n’atteint l’IdP qu’après le reçu.
enregistrement : ALLOW · reçu · 2 attestations
09:45
La réinitialisation de l’administratrice.
Une administratrice financière a perdu son téléphone et s’est présentée en personne au support. L’agent propose reset_mfa sur son compte. Compte privilégié, HIGH, irréversible. Deux signataires approuvent. La titulaire du compte est notifiée à son adresse enregistrée. Le responsable du support, qui n’a pas fait la proposition, confirme la libération.
enregistrement : ALLOW · reçu · 2 attestations · notification envoyée · confirmée
10:05
L’arrivant.
Un ticket RH pour un nouvel analyste. L’agent propose add_group_member vers crm-users. Groupe standard, T1, LOW. Autorisée immédiatement. Le connecteur vérifie le reçu et appelle l’IdP.
enregistrement : ALLOW · reçu
10:41
Le ticket.
Un ticket de support, urgent, « approuvé par le bureau sécurité » : un prestataire qui commence aujourd’hui a besoin de tier0-admins pour une migration. La description du ticket contient une ligne adressée à l’agent. Rien ne filtre le ticket. L’agent y croit et propose add_group_member : le compte du prestataire dans tier0-admins. Palier T3, HIGH, quorum 2 sur 2. Les deux signataires lisent « ajouter le compte prestataire ext-jlaine à tier0-admins, aucun ticket de changement ». Aucun ne signe. À 10:56, la fenêtre se ferme. Les approbateurs sont informés que la demande a expiré sans réponse.
enregistrement : ATTEST · expirée sans réponse · 0 attestation · aucun reçu émis · jamais exécutée
L’agent a lu le ticket à 10:41. La règle que vous avez signée à 09:00, non.
Trois reçus et un refus, vérifiables hors ligne avec la clé que vous détenez.
Une vacation, quatre scènes
La règle que vous avez signée à 09:00 a répondu au ticket à 10:41.
Horloge de démonstration. Quorum 2 sur 2 pour chaque action évaluée HIGH, puis une mise en attente de 60 secondes avant la libération. Fenêtre d’attestation de 15 minutes.
09:10
L’élévation d’astreinte.
Un ticket de changement pour la migration de base de données de ce soir est approuvé. L’agent propose add_group_member : le DBA d’astreinte dans prod-db-admins, expiration 8 heures. Palier T3, HIGH. Le responsable IAM et le propriétaire de la base lisent « ajouter r.okafor à prod-db-admins, expire à 17:10 », rendu à partir de la proposition signée, et signent avec des passkeys. Mise en attente 60 secondes ; personne ne l’arrête ; libérée. L’ajout n’atteint l’IdP qu’après le reçu.
enregistrement : ALLOW · reçu · 2 attestations
09:45
La réinitialisation de l’administratrice.
Une administratrice financière a perdu son téléphone et s’est présentée en personne au support. L’agent propose reset_mfa sur son compte. Compte privilégié, HIGH, irréversible. Deux signataires approuvent. La titulaire du compte est notifiée à son adresse enregistrée. Le responsable du support, qui n’a pas fait la proposition, confirme la libération.
enregistrement : ALLOW · reçu · 2 attestations · notification envoyée · confirmée
10:05
L’arrivant.
Un ticket RH pour un nouvel analyste. L’agent propose add_group_member vers crm-users. Groupe standard, T1, LOW. Autorisée immédiatement. Le connecteur vérifie le reçu et appelle l’IdP.
enregistrement : ALLOW · reçu
10:41
Le ticket.
Un ticket de support, urgent, « approuvé par le bureau sécurité » : un prestataire qui commence aujourd’hui a besoin de tier0-admins pour une migration. La description du ticket contient une ligne adressée à l’agent. Rien ne filtre le ticket. L’agent y croit et propose add_group_member : le compte du prestataire dans tier0-admins. Palier T3, HIGH, quorum 2 sur 2. Les deux signataires lisent « ajouter le compte prestataire ext-jlaine à tier0-admins, aucun ticket de changement ». Aucun ne signe. À 10:56, la fenêtre se ferme. Les approbateurs sont informés que la demande a expiré sans réponse.
enregistrement : ATTEST · expirée sans réponse · 0 attestation · aucun reçu émis · jamais exécutée
L’agent a lu le ticket à 10:41. La règle que vous avez signée à 09:00, non.
Trois reçus et un refus, vérifiables hors ligne avec la clé que vous détenez.
La règle
Six lignes décident de la vacation. L’agent n’en a tapé aucune.
Le palier vient du groupe et du compte. L’évaluation vient de la règle. Un groupe que la règle ne nomme pas est traité au palier le plus haut. Une action que la règle ne nomme pas est refusée.
| Action | Cible | Palier | Évaluation | Résultat |
|---|---|---|---|---|
| add_group_member | groupe standard | T1 | LOW | autorisée immédiatement, reçu |
| create_account | compte prestataire, expiration à 30 jours | T2 | MEDIUM | autorisée immédiatement, reçu |
| add_group_member | groupe privilégié | T3 | HIGH | quorum 2 sur 2, reçu, libérée après la mise en attente |
| reset_mfa | compte privilégié | T3 | HIGH, irréversible | quorum 2 sur 2, notification, reçu, confirmée par une personne notifiée |
| enable_account | compte bris de glace | T3 | HIGH, irréversible | quorum 2 sur 2, notification, reçu, confirmée par une personne notifiée |
| add_group_member | compte prestataire vers un groupe privilégié | T3 | HIGH | quorum 2 sur 2, sinon rien ne s’exécute |
floors · reversibility · risk_functions · notice_targets
L’auteur et le relecteur de la règle sont deux personnes différentes.
La règle
Six lignes décident de la vacation. L’agent n’en a tapé aucune.
Le palier vient du groupe et du compte. L’évaluation vient de la règle. Un groupe que la règle ne nomme pas est traité au palier le plus haut. Une action que la règle ne nomme pas est refusée.
- add_group_membergroupe standardT1 · LOW autorisée immédiatement, reçu
- create_accountcompte prestataire, expiration à 30 joursT2 · MEDIUM autorisée immédiatement, reçu
- add_group_membergroupe privilégiéT3 · HIGH quorum 2 sur 2, reçu, libérée après la mise en attente
- reset_mfacompte privilégiéT3 · HIGH, irréversible quorum 2 sur 2, notification, reçu, confirmée par une personne notifiée
- enable_accountcompte bris de glaceT3 · HIGH, irréversible quorum 2 sur 2, notification, reçu, confirmée par une personne notifiée
- add_group_membercompte prestataire vers un groupe privilégiéT3 · HIGH quorum 2 sur 2, sinon rien ne s’exécute
floors · reversibility · risk_functions · notice_targets
L’auteur et le relecteur de la règle sont deux personnes différentes.
Avant que vous ne demandiez
Ce que tout responsable IAM demande en premier.
Cela va-t-il ralentir l’arrivée des nouveaux ?
Non. Un groupe standard est autorisé immédiatement, avec un reçu. Seuls un groupe privilégié, une réinitialisation MFA sur un compte privilégié ou un compte bris de glace attendent, et ils attendent deux personnes qui devaient déjà les approuver.
Qui approuve la nuit ou le week-end ?
La règle nomme les approbateurs à l’avance et deux d’entre eux, n’importe lesquels, signent, sur leur téléphone, avec des passkeys. L’élévation d’astreinte de 09:10 a pris le temps qu’il faut à deux personnes pour lire une ligne.
Et si personne ne signe ?
Alors rien ne change et les approbateurs sont informés que la demande a expiré sans réponse. Aucun reçu n’existe, donc votre connecteur n’appelle jamais l’IdP. Le ticket attend un humain, comme aujourd’hui.
Nous listons nos limites avant que vous ne les trouviez. Alors rien n’est autorisé, et aucun reçu n’existe sur lequel agir.
Avant que vous ne demandiez
Ce que tout responsable IAM demande en premier.
Cela va-t-il ralentir l’arrivée des nouveaux ?
Non. Un groupe standard est autorisé immédiatement, avec un reçu. Seuls un groupe privilégié, une réinitialisation MFA sur un compte privilégié ou un compte bris de glace attendent, et ils attendent deux personnes qui devaient déjà les approuver.
Qui approuve la nuit ou le week-end ?
La règle nomme les approbateurs à l’avance et deux d’entre eux, n’importe lesquels, signent, sur leur téléphone, avec des passkeys. L’élévation d’astreinte de 09:10 a pris le temps qu’il faut à deux personnes pour lire une ligne.
Et si personne ne signe ?
Alors rien ne change et les approbateurs sont informés que la demande a expiré sans réponse. Aucun reçu n’existe, donc votre connecteur n’appelle jamais l’IdP. Le ticket attend un humain, comme aujourd’hui.
Nous listons nos limites avant que vous ne les trouviez. Alors rien n’est autorisé, et aucun reçu n’existe sur lequel agir.
Rien à remplacer
Gardez votre IdP. Gardez votre IGA et votre PAM. Ajoutez la règle et le reçu.
- SDK
- Votre connecteur propose, puis vérifie le reçu avant d’appeler l’IdP. Python et TypeScript.
- Flux
- Une étape HTTP avant l’étape d’exécution dans votre flux ITSM ou IGA, et une branche sur le reçu vérifié. Votre plateforme garde ses flux.
- MCP
- Un agent sur un client MCP propose via le serveur ZIFFER. Le reçu va toujours à votre code.
- latence
- p50 244 ms, p99 1,2 s de la proposition à la décision. Mesuré le 2026-08-28, répétition locale.
L’approbation de votre IdP est tranchée par le premier approbateur qui répond, et son enregistrement reste dans le journal de l’IdP. Les approbateurs de ZIFFER signent les octets exacts d’une autorisation, et votre propre code vérifie le reçu hors de l’IdP.
Rien à remplacer
Gardez votre IdP. Gardez votre IGA et votre PAM. Ajoutez la règle et le reçu.
- SDK
- Votre connecteur propose, puis vérifie le reçu avant d’appeler l’IdP. Python et TypeScript.
- Flux
- Une étape HTTP avant l’étape d’exécution dans votre flux ITSM ou IGA, et une branche sur le reçu vérifié. Votre plateforme garde ses flux.
- MCP
- Un agent sur un client MCP propose via le serveur ZIFFER. Le reçu va toujours à votre code.
- latence
- p50 244 ms, p99 1,2 s de la proposition à la décision. Mesuré le 2026-08-28, répétition locale.
L’approbation de votre IdP est tranchée par le premier approbateur qui répond, et son enregistrement reste dans le journal de l’IdP. Les approbateurs de ZIFFER signent les octets exacts d’une autorisation, et votre propre code vérifie le reçu hors de l’IdP.
FAQ
Agents d’identité IA et ZIFFER, en huit questions.
Un agent IA peut-il ajouter quelqu’un à un groupe privilégié comme Domain Admins ?
Par un connecteur ou avec les privilèges de la personne qui l’a lancé, oui. Avec ZIFFER, l’ajout est une proposition que deux approbateurs nommément désignés signent, sinon il n’a pas lieu.
Nous utilisons déjà les approbations PIM. Pourquoi ajouter ZIFFER ?
L’approbation PIM est tranchée par le premier approbateur qui répond, le champ ticket n’est pas imposé, et l’enregistrement reste dans l’IdP. Les approbateurs de ZIFFER signent les octets exacts, et votre propre code vérifie le reçu hors de l’IdP.
Qu’est-ce qui empêche un ticket de support de piéger l’agent pour qu’il autorise un accès admin ?
Rien n’empêche l’agent d’être piégé. L’ajout à un groupe privilégié est évalué HIGH par la règle, pas par le ticket, et il attend deux personnes nommément désignées qui lisent ce que l’agent a proposé.
Cela va-t-il ralentir les arrivées et les demandes d’accès standard ?
Non. Un groupe standard est autorisé immédiatement, avec un reçu.
Qui approuve une demande d’accès privilégié la nuit ou le week-end ?
Deux des approbateurs que la règle nomme, n’importe lesquels, sur leur téléphone, avec des passkeys.
ZIFFER détient-il nos identifiants d’administration IdP ?
Non. Votre connecteur appelle l’IdP avec votre identifiant, après avoir vérifié le reçu.
Quelles preuves obtenons-nous pour les revues d’accès SOC 2 et PCI DSS ?
Un reçu signé par autorisation, nommant les approbateurs et la version de la règle, vérifié par un outil ouvert sur votre machine. Un enregistrement de décision pour chaque refus.
Que voit ZIFFER ?
La proposition, l’époque de la politique et les attestations. Pas votre annuaire, pas vos tickets.
FAQ
Agents d’identité IA et ZIFFER, en huit questions.
Un agent IA peut-il ajouter quelqu’un à un groupe privilégié comme Domain Admins ?
Par un connecteur ou avec les privilèges de la personne qui l’a lancé, oui. Avec ZIFFER, l’ajout est une proposition que deux approbateurs nommément désignés signent, sinon il n’a pas lieu.
Nous utilisons déjà les approbations PIM. Pourquoi ajouter ZIFFER ?
L’approbation PIM est tranchée par le premier approbateur qui répond, le champ ticket n’est pas imposé, et l’enregistrement reste dans l’IdP. Les approbateurs de ZIFFER signent les octets exacts, et votre propre code vérifie le reçu hors de l’IdP.
Qu’est-ce qui empêche un ticket de support de piéger l’agent pour qu’il autorise un accès admin ?
Rien n’empêche l’agent d’être piégé. L’ajout à un groupe privilégié est évalué HIGH par la règle, pas par le ticket, et il attend deux personnes nommément désignées qui lisent ce que l’agent a proposé.
Cela va-t-il ralentir les arrivées et les demandes d’accès standard ?
Non. Un groupe standard est autorisé immédiatement, avec un reçu.
Qui approuve une demande d’accès privilégié la nuit ou le week-end ?
Deux des approbateurs que la règle nomme, n’importe lesquels, sur leur téléphone, avec des passkeys.
ZIFFER détient-il nos identifiants d’administration IdP ?
Non. Votre connecteur appelle l’IdP avec votre identifiant, après avoir vérifié le reçu.
Quelles preuves obtenons-nous pour les revues d’accès SOC 2 et PCI DSS ?
Un reçu signé par autorisation, nommant les approbateurs et la version de la règle, vérifié par un outil ouvert sur votre machine. Un enregistrement de décision pour chaque refus.
Que voit ZIFFER ?
La proposition, l’époque de la politique et les attestations. Pas votre annuaire, pas vos tickets.
L’agent lit le ticket. Il n’autorise pas le groupe.
Venez avec l’agent d’identité que vous exploitez et le connecteur qu’il appelle. Repartez avec la règle signée.
L’agent lit le ticket. Il n’autorise pas le groupe.
Venez avec l’agent d’identité que vous exploitez et le connecteur qu’il appelle. Repartez avec la règle signée.