◆ For IAM, identity security and service desk owners
Your identity agent will read a poisoned ticket one day.
With ZIFFER, it cannot grant admin on it.
The agent reads the ticket. It does not grant the group. Every privileged grant, MFA reset and new account runs through the rule you signed, or through two named approvers.
◆ For IAM, identity security and service desk owners
Your identity agent will read a poisoned ticket one day. With ZIFFER, it cannot grant admin on it.
The agent reads the ticket. It does not grant the group. Every privileged grant, MFA reset and new account runs through the rule you signed, or through two named approvers.
Where IAM stopped
IAM let the agent answer the ticket. It never let it touch a privileged group.
The agent reads, answers, routes and adds people to ordinary groups. The privileged grant, the admin's MFA reset and the new account still wait for a named human, and IAM is right: that is where the domain is lost.
The fear has a name.
- The ticket the agent reads is written, in part, by the attacker. In late 2025 a security research team wrote instructions into a ticket's description field. An ITSM platform's AI agent, started by an admin, could follow them with the admin's privileges and assign roles to the attacker's account. Research on a default configuration, 2025-11; nothing was lost.
- The human version already works. Attackers “posed as employees to convince IT and/or helpdesk staff to … reset the employee's password, and transfer the employee's MFA to a device they control”, and “abuse trusted relationships of contracted IT help desks”. Joint advisory AA23-320A, CISA, FBI, NCSC-UK and partners, updated 2025-07-29.
- The confirm step in the agent platform is not a second person. In one proof of concept, the tool that created the user and assigned the admin role ran in supervised mode, and the attacker could “reuse the same confirmation payload for a second time to authorize the role-assignment”. The CVE was patched on 2025-10-30.
The fear has a price.
- “Identity weaknesses played a material role in nearly 90% of our investigations.” Unit 42 Global Incident Response Report 2026, 750+ engagements.
- Voice phishing is the second initial vector at 11%, and the first in cloud compromises at 23%. Mandiant M-Trends 2026.
- 68% cannot tell agent actions from human actions; 74% say agents often get more access than they need. CSA, n=228, 2026-03.
| What was asked | Answer | Source, sample, date |
|---|---|---|
| Do you already use AI agents? | 82% yes | SailPoint (Dimensional Research), n=353, 2025-05 |
| Have your agents taken unintended actions? | 80% yes | same |
| Have your agents been tricked into revealing access credentials? | 23% yes | same |
| Do agents often get more access than they need? | 74% yes | CSA, commissioned by Aembit, n=228, 2026-03 |
| Can you tell agent actions from human actions? | 68% cannot | same |
| Have agents exceeded their intended permissions? | 53% yes | CSA, commissioned by Zenity, n=445, 2026-04 |
| Are you highly confident your IAM can manage agent identities? | 18% are | CSA, commissioned by Strata Identity, n=285, 2026-02 |
| Can you trace agent actions to a human or system everywhere? | 28% can | same |
Eight answers from four surveys. SailPoint's survey is vendor-run; each CSA survey names the vendor that commissioned it.
Eight answers, four surveys, one pattern. The agent already has access, and few can say what it did with it.
IAM was right to keep a human on the privileged grant. It was wrong to think the ticket could be trusted because the agent read it.
Where IAM stopped
IAM let the agent answer the ticket. It never let it touch a privileged group.
The agent reads, answers, routes and adds people to ordinary groups. The privileged grant, the admin's MFA reset and the new account still wait for a named human, and IAM is right: that is where the domain is lost.
The fear has a name.
- The ticket the agent reads is written, in part, by the attacker. In late 2025 a security research team wrote instructions into a ticket's description field. An ITSM platform's AI agent, started by an admin, could follow them with the admin's privileges and assign roles to the attacker's account. Research on a default configuration, 2025-11; nothing was lost.
- The human version already works. Attackers “posed as employees to convince IT and/or helpdesk staff to … reset the employee's password, and transfer the employee's MFA to a device they control”, and “abuse trusted relationships of contracted IT help desks”. Joint advisory AA23-320A, CISA, FBI, NCSC-UK and partners, updated 2025-07-29.
- The confirm step in the agent platform is not a second person. In one proof of concept, the tool that created the user and assigned the admin role ran in supervised mode, and the attacker could “reuse the same confirmation payload for a second time to authorize the role-assignment”. The CVE was patched on 2025-10-30.
The fear has a price.
- “Identity weaknesses played a material role in nearly 90% of our investigations.” Unit 42 Global Incident Response Report 2026, 750+ engagements.
- Voice phishing is the second initial vector at 11%, and the first in cloud compromises at 23%. Mandiant M-Trends 2026.
- 68% cannot tell agent actions from human actions; 74% say agents often get more access than they need. CSA, n=228, 2026-03.
- Do you already use AI agents?82% yesSailPoint (Dimensional Research), n=353, 2025-05
- Have your agents taken unintended actions?80% yessame
- Have your agents been tricked into revealing access credentials?23% yessame
- Do agents often get more access than they need?74% yesCSA, commissioned by Aembit, n=228, 2026-03
- Can you tell agent actions from human actions?68% cannotsame
- Have agents exceeded their intended permissions?53% yesCSA, commissioned by Zenity, n=445, 2026-04
- Are you highly confident your IAM can manage agent identities?18% areCSA, commissioned by Strata Identity, n=285, 2026-02
- Can you trace agent actions to a human or system everywhere?28% cansame
Eight answers from four surveys. SailPoint's survey is vendor-run; each CSA survey names the vendor that commissioned it.
Eight answers, four surveys, one pattern. The agent already has access, and few can say what it did with it.
IAM was right to keep a human on the privileged grant. It was wrong to think the ticket could be trusted because the agent read it.
The missing piece
Take the grant out of the agent's hands. Leave the ticket in.
The agent reads, answers, routes and proposes. That is where its duty ends. Who joins which group is decided by a rule you signed before the shift, and by two named approvers for any privileged group, any MFA reset on a privileged account, any break-glass account.
The ticket stays with the agent. Authority lives in your connector, on a receipt. ZIFFER holds no IdP, directory or PAM credential.
- rule
- Group class, account class, expiry, days since the account was created, who may sign. A group the rule does not name is top tier. An action the rule does not name is refused.
- quorum
- Two named approvers, passkeys, and a summary rendered from the signed proposal bytes: account, group, expiry, change ticket present or not. The proposer never counts.
- receipt
- Signed, verified offline by your connector before the IdP call. ZIFFER holds no IdP, directory or PAM credential.
The agent reads the ticket. It does not grant the group.
The missing piece
Take the grant out of the agent's hands. Leave the ticket in.
The agent reads, answers, routes and proposes. That is where its duty ends. Who joins which group is decided by a rule you signed before the shift, and by two named approvers for any privileged group, any MFA reset on a privileged account, any break-glass account.
The ticket stays with the agent. Authority lives in your connector, on a receipt. ZIFFER holds no IdP, directory or PAM credential.
- rule
- Group class, account class, expiry, days since the account was created, who may sign. A group the rule does not name is top tier. An action the rule does not name is refused.
- quorum
- Two named approvers, passkeys, and a summary rendered from the signed proposal bytes: account, group, expiry, change ticket present or not. The proposer never counts.
- receipt
- Signed, verified offline by your connector before the IdP call. ZIFFER holds no IdP, directory or PAM credential.
The agent reads the ticket. It does not grant the group.
What the standards already say
The rule is not new. Only the agent is.
| They wrote | Who, when | ZIFFER's mechanism |
|---|---|---|
| “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-of-2 on every privileged grant |
| “Rule based auto approval. When a specific criteria is met, the credential is automatically approved without human intervention.” | UK NCSC, Secure system administration | standard groups are allowed at once by the rule, with a receipt |
| “Enforce dual authorization for … privileged commands and/or other actions.” | NIST SP 800-53 rev 5, AC-3(2) | two named signers; the proposer never counts |
| “Require approvals by … personnel or roles for requests to create accounts” | NIST SP 800-53 rev 5, AC-2(e) | create_account needs a rule; with no rule, it is refused |
| “Required privileges are approved by authorized personnel.” | PCI DSS v4.0.1, 7.2.3 | the receipt names the approvers |
| “Implemented with only the privileges specified on the documented approval.” | PCI DSS v4.0.1, 8.2.4 | a different group is a new proposal and a new signature |
| “User identity is verified before modifying any authentication factor.” | PCI DSS v4.0.1, 8.3.3 | an MFA reset on a privileged account waits for the 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 | notice to the account holder on a privileged reset |
| “giving consideration to the concepts of least privilege and segregation of duties” | SOC 2, CC6.3 | the agent proposes, people sign, your code holds the IdP credential |
| “Utilise human-in-the-loop control to require a human to approve high-impact actions … in a downstream system” | OWASP LLM06:2025, 2024-11 | the check sits outside the agent, before the IdP call |
Every control asked for a different person before the group changed. ZIFFER is the first place the agent cannot be that person.
What the standards already say
The rule is not new. Only the agent is.
- “Multi-party approval. An administrator's credential is only released if a different, authorised individual(s) approve it.”UK NCSC, Secure system administrationZIFFER's mechanismquorum 2-of-2 on every privileged grant
- “Rule based auto approval. When a specific criteria is met, the credential is automatically approved without human intervention.”UK NCSC, Secure system administrationZIFFER's mechanismstandard groups are allowed at once by the rule, with a receipt
- “Enforce dual authorization for … privileged commands and/or other actions.”NIST SP 800-53 rev 5, AC-3(2)ZIFFER's mechanismtwo named signers; the proposer never counts
- “Require approvals by … personnel or roles for requests to create accounts”NIST SP 800-53 rev 5, AC-2(e)ZIFFER's mechanismcreate_account needs a rule; with no rule, it is refused
- “Required privileges are approved by authorized personnel.”PCI DSS v4.0.1, 7.2.3ZIFFER's mechanismthe receipt names the approvers
- “Implemented with only the privileges specified on the documented approval.”PCI DSS v4.0.1, 8.2.4ZIFFER's mechanisma different group is a new proposal and a new signature
- “User identity is verified before modifying any authentication factor.”PCI DSS v4.0.1, 8.3.3ZIFFER's mechanisman MFA reset on a privileged account waits for the 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-07ZIFFER's mechanismnotice to the account holder on a privileged reset
- “giving consideration to the concepts of least privilege and segregation of duties”SOC 2, CC6.3ZIFFER's mechanismthe agent proposes, people sign, your code holds the IdP credential
- “Utilise human-in-the-loop control to require a human to approve high-impact actions … in a downstream system”OWASP LLM06:2025, 2024-11ZIFFER's mechanismthe check sits outside the agent, before the IdP call
Every control asked for a different person before the group changed. ZIFFER is the first place the agent cannot be that person.
One shift, four scenes
The rule you signed at 09:00 answered the ticket at 10:41.
Demo clock. Quorum 2-of-2 for every action graded HIGH, then a 60-second hold before release. Attestation window 15 minutes.
09:10
The on-call elevation.
A change ticket for tonight's database migration is approved. The agent proposes add_group_member: the on-call DBA to prod-db-admins, expiry 8 hours. Tier T3, HIGH. The IAM lead and the database owner read “add r.okafor to prod-db-admins, expires 17:10” rendered from the signed proposal and sign with passkeys. Held 60 seconds; nobody stops it; released. The grant reaches the IdP only after the receipt.
record: ALLOW · receipt · 2 attestations
09:45
The admin's reset.
A finance administrator lost her phone and came to the service desk in person. The agent proposes reset_mfa on her account. Privileged account, HIGH, irreversible. Two signers approve. The account holder is notified at her registered address. The service-desk lead, who did not propose it, confirms the release.
record: ALLOW · receipt · 2 attestations · notice sent · confirmed
10:05
The joiner.
An HR ticket for a new analyst. The agent proposes add_group_member to crm-users. Standard group, T1, LOW. Allowed at once. The connector verifies the receipt and calls the IdP.
record: ALLOW · receipt
10:41
The ticket.
A help-desk ticket, urgent, “approved by the security office”: a contractor starting today needs tier0-admins for a migration. The ticket's description holds a line addressed to the agent. Nothing filters the ticket. The agent believes it and proposes add_group_member: the contractor account to tier0-admins. Tier T3, HIGH, quorum 2-of-2. Both signers read “add contractor account ext-jlaine to tier0-admins, no change ticket”. Neither signs. At 10:56 the window closes. The approvers are told it expired unanswered.
record: ATTEST · expired unanswered · 0 attestations · no receipt minted · never executed
The agent read the ticket at 10:41. The rule you signed at 09:00 did not.
Three receipts and one refusal, verifiable offline with the key you hold.
One shift, four scenes
The rule you signed at 09:00 answered the ticket at 10:41.
Demo clock. Quorum 2-of-2 for every action graded HIGH, then a 60-second hold before release. Attestation window 15 minutes.
09:10
The on-call elevation.
A change ticket for tonight's database migration is approved. The agent proposes add_group_member: the on-call DBA to prod-db-admins, expiry 8 hours. Tier T3, HIGH. The IAM lead and the database owner read “add r.okafor to prod-db-admins, expires 17:10” rendered from the signed proposal and sign with passkeys. Held 60 seconds; nobody stops it; released. The grant reaches the IdP only after the receipt.
record: ALLOW · receipt · 2 attestations
09:45
The admin's reset.
A finance administrator lost her phone and came to the service desk in person. The agent proposes reset_mfa on her account. Privileged account, HIGH, irreversible. Two signers approve. The account holder is notified at her registered address. The service-desk lead, who did not propose it, confirms the release.
record: ALLOW · receipt · 2 attestations · notice sent · confirmed
10:05
The joiner.
An HR ticket for a new analyst. The agent proposes add_group_member to crm-users. Standard group, T1, LOW. Allowed at once. The connector verifies the receipt and calls the IdP.
record: ALLOW · receipt
10:41
The ticket.
A help-desk ticket, urgent, “approved by the security office”: a contractor starting today needs tier0-admins for a migration. The ticket's description holds a line addressed to the agent. Nothing filters the ticket. The agent believes it and proposes add_group_member: the contractor account to tier0-admins. Tier T3, HIGH, quorum 2-of-2. Both signers read “add contractor account ext-jlaine to tier0-admins, no change ticket”. Neither signs. At 10:56 the window closes. The approvers are told it expired unanswered.
record: ATTEST · expired unanswered · 0 attestations · no receipt minted · never executed
The agent read the ticket at 10:41. The rule you signed at 09:00 did not.
Three receipts and one refusal, verifiable offline with the key you hold.
The rule
Six rows decide the shift. The agent typed none of them.
The tier comes from the group and the account. The grade comes from the rule. A group the rule does not name is treated as top tier. An action the rule does not name is refused.
| Action | Target | Tier | Grade | Outcome |
|---|---|---|---|---|
| add_group_member | standard group | T1 | LOW | allowed at once, receipt |
| create_account | contractor account, 30-day expiry | T2 | MEDIUM | allowed at once, receipt |
| add_group_member | privileged group | T3 | HIGH | quorum 2-of-2, receipt, released after the hold |
| reset_mfa | privileged account | T3 | HIGH, irreversible | quorum 2-of-2, notice, receipt, confirmed by a notified person |
| enable_account | break-glass account | T3 | HIGH, irreversible | quorum 2-of-2, notice, receipt, confirmed by a notified person |
| add_group_member | contractor account to a privileged group | T3 | HIGH | quorum 2-of-2, or nothing runs |
floors · reversibility · risk_functions · notice_targets
Author and reviewer of the rule are two different people.
The rule
Six rows decide the shift. The agent typed none of them.
The tier comes from the group and the account. The grade comes from the rule. A group the rule does not name is treated as top tier. An action the rule does not name is refused.
- add_group_memberstandard groupT1 · LOW allowed at once, receipt
- create_accountcontractor account, 30-day expiryT2 · MEDIUM allowed at once, receipt
- add_group_memberprivileged groupT3 · HIGH quorum 2-of-2, receipt, released after the hold
- reset_mfaprivileged accountT3 · HIGH, irreversible quorum 2-of-2, notice, receipt, confirmed by a notified person
- enable_accountbreak-glass accountT3 · HIGH, irreversible quorum 2-of-2, notice, receipt, confirmed by a notified person
- add_group_membercontractor account to a privileged groupT3 · HIGH quorum 2-of-2, or nothing runs
floors · reversibility · risk_functions · notice_targets
Author and reviewer of the rule are two different people.
Before you ask
What every IAM lead asks first.
Will this slow down onboarding?
No. A standard group is allowed at once with a receipt. Only a privileged group, an MFA reset on a privileged account or a break-glass account waits, and it waits for two people who already had to approve it.
Who approves at night or on the weekend?
The rule names the approvers in advance and any two of them sign, on their phones, with passkeys. The on-call elevation at 09:10 took the time it takes two people to read one line.
What if nobody signs?
Then nothing changes and the approvers are told the request expired unanswered. No receipt exists, so your connector never calls the IdP. The ticket waits for a human, as it does today.
We list our limits before you find them. Then nothing is granted, and no receipt exists to act on.
Before you ask
What every IAM lead asks first.
Will this slow down onboarding?
No. A standard group is allowed at once with a receipt. Only a privileged group, an MFA reset on a privileged account or a break-glass account waits, and it waits for two people who already had to approve it.
Who approves at night or on the weekend?
The rule names the approvers in advance and any two of them sign, on their phones, with passkeys. The on-call elevation at 09:10 took the time it takes two people to read one line.
What if nobody signs?
Then nothing changes and the approvers are told the request expired unanswered. No receipt exists, so your connector never calls the IdP. The ticket waits for a human, as it does today.
We list our limits before you find them. Then nothing is granted, and no receipt exists to act on.
Nothing to replace
Keep your IdP. Keep your IGA and your PAM. Add the rule and the receipt.
- SDK
- Your connector proposes, then verifies the receipt before it calls the IdP. Python and TypeScript.
- Workflow
- One HTTP step before the fulfilment step in your ITSM or IGA flow, and a branch on the verified receipt. Your platform keeps its workflows.
- MCP
- An agent on an MCP client proposes through the ZIFFER server. The receipt still goes to your code.
- latency
- p50 244 ms, p99 1.2 s from proposal to decision. Measured 2026-08-28, local rehearsal.
Your IdP's approval is resolved by the first approver who answers, and its record stays in the IdP's own log. ZIFFER's approvers sign the exact bytes of one grant, and your own code verifies the receipt outside the IdP.
Nothing to replace
Keep your IdP. Keep your IGA and your PAM. Add the rule and the receipt.
- SDK
- Your connector proposes, then verifies the receipt before it calls the IdP. Python and TypeScript.
- Workflow
- One HTTP step before the fulfilment step in your ITSM or IGA flow, and a branch on the verified receipt. Your platform keeps its workflows.
- MCP
- An agent on an MCP client proposes through the ZIFFER server. The receipt still goes to your code.
- latency
- p50 244 ms, p99 1.2 s from proposal to decision. Measured 2026-08-28, local rehearsal.
Your IdP's approval is resolved by the first approver who answers, and its record stays in the IdP's own log. ZIFFER's approvers sign the exact bytes of one grant, and your own code verifies the receipt outside the IdP.
FAQ
AI identity agents and ZIFFER, in eight questions.
Can an AI agent add someone to a privileged group like Domain Admins?
Through a connector or with the privileges of whoever started it, yes. With ZIFFER the grant is a proposal that two named approvers sign, or it does not happen.
We already use PIM approvals. Why add ZIFFER?
PIM approval is resolved by the first approver who answers, the ticket field is not enforced, and the record stays in the IdP. ZIFFER's approvers sign the exact bytes, and your own code verifies the receipt outside the IdP.
What stops a help-desk ticket from tricking the agent into granting admin?
Nothing stops the agent from being tricked. The grant to a privileged group is graded HIGH by the rule, not by the ticket, and it waits for two named people who read what the agent proposed.
Will this slow down onboarding and standard access requests?
No. A standard group is allowed at once with a receipt.
Who approves a privileged access request at night or on the weekend?
Any two of the approvers the rule names, on their phones, with passkeys.
Does ZIFFER hold our IdP admin credentials?
No. Your connector calls the IdP with your credential, after it verified the receipt.
What evidence do we get for SOC 2 and PCI DSS access reviews?
One signed receipt per grant, naming the approvers and the rule version, verified by an open tool on your machine. A decision record for every refusal.
What does ZIFFER see?
The proposal, the policy epoch and the attestations. Not your directory, not your tickets.
FAQ
AI identity agents and ZIFFER, in eight questions.
Can an AI agent add someone to a privileged group like Domain Admins?
Through a connector or with the privileges of whoever started it, yes. With ZIFFER the grant is a proposal that two named approvers sign, or it does not happen.
We already use PIM approvals. Why add ZIFFER?
PIM approval is resolved by the first approver who answers, the ticket field is not enforced, and the record stays in the IdP. ZIFFER's approvers sign the exact bytes, and your own code verifies the receipt outside the IdP.
What stops a help-desk ticket from tricking the agent into granting admin?
Nothing stops the agent from being tricked. The grant to a privileged group is graded HIGH by the rule, not by the ticket, and it waits for two named people who read what the agent proposed.
Will this slow down onboarding and standard access requests?
No. A standard group is allowed at once with a receipt.
Who approves a privileged access request at night or on the weekend?
Any two of the approvers the rule names, on their phones, with passkeys.
Does ZIFFER hold our IdP admin credentials?
No. Your connector calls the IdP with your credential, after it verified the receipt.
What evidence do we get for SOC 2 and PCI DSS access reviews?
One signed receipt per grant, naming the approvers and the rule version, verified by an open tool on your machine. A decision record for every refusal.
What does ZIFFER see?
The proposal, the policy epoch and the attestations. Not your directory, not your tickets.
The agent reads the ticket. It does not grant the group.
Bring the identity agent you run and the connector it calls. Leave with the rule signed.
The agent reads the ticket. It does not grant the group.
Bring the identity agent you run and the connector it calls. Leave with the rule signed.