Passbolt support shows why AI cannot replace product judgement

At a glance

What this is: This is an inside look at Passbolt Support, and its key finding is that AI can assist routine support work but cannot replace contextual judgement in troubleshooting and recovery.

Why it matters: It matters to IAM and security teams because support workflows often touch credentials, recovery paths, and delegated access, where automation without oversight can increase operational and identity risk.

👉 Read PassBolt's support team interview on AI, recovery, and troubleshooting

Context

AI-assisted support changes the shape of operational work, but it does not remove the need to understand product behaviour, recovery paths, and infrastructure boundaries. In identity-adjacent workflows, the central governance question is not whether automation can answer common questions, but whether it can reliably distinguish a valid fix from a confidently wrong one.

Passbolt’s support story also points to a broader operational reality for IAM and NHI programmes: tickets often become investigations, recoveries, or access-adjacent interventions. That makes documentation quality, backup validation, and clear escalation paths part of identity resilience, not just support hygiene.

The primary subject here is support operations around a credential management product, which is typical of modern teams that sit at the intersection of user help, recovery, and security escalation. The article is atypical only in how explicitly it connects calm human judgement to reliable identity-adjacent support.

Key questions

Q: How should security teams use AI in application security without weakening human judgment?

A: Security teams should use AI to augment, not replace, experienced AppSec judgment. The best approach is to automate repetitive review, triage, and correlation work, while keeping humans responsible for threat modelling, contextual decisions, and final risk acceptance. AI is most useful when it speeds delivery and reduces noise, but fundamentals such as secure SDLC integration, code scanning, and developer education still determine outcomes.

Q: What breaks when recovery credentials are stored in the system they are meant to repair?

A: Recovery becomes circular. If the platform is unreachable and the credentials or private keys needed to fix it are inside that same environment, teams can lose both the fix and the path to reach it. The right design keeps restore access outside the failure domain.

Q: How do you know a support process is actually working for identity-adjacent issues?

A: It works when tickets are reproducible, escalation is fast, and recovery does not depend on guesswork. A strong process produces enough context up front that support can verify the issue, involve the right team, and restore service without exposing new access risk.

Q: Should organisations prioritise documentation or automation first for support resilience?

A: Prioritise documentation and restore clarity first. Automation helps only when the underlying process is well understood, current, and evidence-driven. If runbooks are outdated or incomplete, AI and workflow automation will simply accelerate the wrong answer.

Technical breakdown

Why AI support answers fail when product context is incomplete

AI support tools work by generating likely answers from patterns in the data they were trained on or retrieved from. That makes them useful for repetitive questions, but fragile when the issue depends on version-specific behaviour, undocumented edge cases, or local infrastructure state. In those cases, the model can produce a plausible answer that is technically wrong. For support teams, the failure mode is not speed, it is false confidence: the response looks authoritative while missing the actual cause.

Practical implication: keep humans in the loop for anything involving recovery, security changes, or unresolved product behaviour.

Support investigations depend on logs, reproduction, and escalation

The article shows a classic support investigation pattern: check whether the issue is known, reproduce it internally, inspect logs, and pull in product or security teams when needed. This is not just customer service, it is operational triage. The quality of the initial report matters because support can only reason from evidence, and the evidence usually lives in version details, environment context, and prior troubleshooting steps. AI can summarise, but it cannot replace that evidence chain.

Practical implication: require structured ticket intake so support can reproduce and classify issues before escalation begins.

Recovery paths are part of identity governance, not just backup management

The support case described in the article highlights a common identity problem: access to fix an infrastructure issue was itself stored inside the affected system. When private keys, recovery material, or passwords are unavailable because the platform is unreachable, the organisation has created a dependency loop. Recovery then depends on a separate trust anchor such as an organisation recovery key, replica access, or offline backup. That is an identity governance problem because the ability to restore access is itself privileged access.

Practical implication: treat recovery materials and backup restore paths as governed identity assets with tested access procedures.

Threat narrative

Attacker objective: The practical objective was to regain operational access to the environment and recover the credentials needed to fix the outage.

1. Entry occurred through an operational failure rather than a malicious intrusion, when a network incident made the Passbolt instance unreachable and blocked normal access to the credentials needed for remediation.
2. Escalation happened because the necessary recovery material, including users' private keys, was trapped in the same broken environment, forcing the team to reconstruct access from a replica and organisation recovery key.
3. Impact was a temporary loss of access to the system that held the credentials needed to repair the system, creating a high-friction recovery loop until the replica was restored and decrypted.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• GitHub Action tj-actions Supply Chain Attack — Compromised tj-actions/changed-files GitHub Action leaks thousands of CI/CD secrets from 23,000 repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI support creates a judgement gap, not just an efficiency gain. The article shows that simple questions can be handled by automation, but the hard cases still depend on code reading, reproduction, and product context. That matters because support work often sits close to credentials, recovery, and exception handling, where a wrong answer is operationally expensive. The practitioner conclusion is that AI should assist triage, not own resolution.

Recovery is an identity control because the restore path becomes a privileged access path. The incident described in the article shows that when private keys and remediation credentials are trapped inside the affected environment, recovery depends on separate trust anchors. That is a lifecycle and governance problem, not just a backup problem. The practitioner conclusion is that restore processes must be treated as governed access paths with explicit ownership and testing.

Documentation quality is now a security control. The support engineer repeatedly points to version details, logs, setup context, and the manual as the difference between a quick resolution and a prolonged ticket. In identity-adjacent operations, incomplete documentation creates ambiguity that AI will happily amplify. The practitioner conclusion is that outdated or vague runbooks increase operational risk even when the underlying product is sound.

Autonomy in support teams should be bounded by verification, not confidence. The article values helping new team members become autonomous, but it also shows that autonomy only works when paired with calm escalation and the ability to spot when something does not add up. That is a useful pattern for identity operations generally: independence is valuable only when the operator can still verify the evidence. The practitioner conclusion is to design for autonomous action inside controlled guardrails.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which shows that confidence and operational discipline are not the same thing.
• That gap matters when support teams depend on clear recovery procedures, so use the NHI Lifecycle Management Guide to tighten provisioning, rotation, and offboarding controls.

What this signals

Support operations are now part of the identity control plane. When help desks, recovery teams, and product support handle credentials, keys, or restore procedures, they are operating inside the same trust surface as IAM and NHI governance. The practical signal for programme owners is that support runbooks must be reviewed with the same discipline as access policies and backup procedures.

With 6 distinct secrets manager instances on average across organisations, per The State of Secrets in AppSec, fragmented operational tooling makes support harder to verify and recovery harder to standardise. The more places credentials can live, the more likely a support team is to confront an inconsistent or undocumented restore path.

Recovery-path governance: restore access, backup validation, and exception handling should be treated as governed identity assets, not ad hoc support tasks. That is where many organisations discover whether their security programme can actually survive an outage.

For practitioners

• Use AI for triage, not final resolution. Let automation summarise common issues and draft responses, but require a human to validate anything involving access recovery, security impact, or version-specific behaviour. This preserves judgement where the cost of a wrong answer is highest.
• Standardise ticket intake before escalation. Require version, setup, logs, and prior troubleshooting steps in every support request so engineers can reproduce the issue instead of guessing. A structured intake reduces back-and-forth and speeds classification.
• Test restore paths under real outage conditions. Validate that backups, replica restores, and recovery keys work when the primary system is unavailable, not just when the environment is healthy. Treat restore access as a live control, not a theoretical one.
• Separate remediation credentials from the failure domain. Keep the credentials needed for infrastructure repair outside the system they are meant to fix, including offline or independently reachable recovery material. That avoids circular dependency when the primary platform is down.

Key takeaways

• AI can accelerate support work, but it does not replace the human judgement needed for recovery, verification, and exception handling.
• Identity-adjacent support becomes fragile when recovery materials sit inside the same system they are meant to repair.
• Documentation, restore testing, and escalation clarity are operational security controls, not just support conveniences.

Key terms

• Recovery Key: A recovery key is a break-glass credential used to regain access when the primary authenticator is unavailable. It should be treated as a highly sensitive access artifact because it can bypass normal login controls, so storage, access, and testing need explicit governance.
• Support Triage: Support triage is the process of classifying, reproducing, and prioritising an incoming issue before assigning deeper investigation. In security-sensitive environments, good triage reduces guesswork, speeds escalation, and limits the chance that a wrong fix creates an access or integrity problem.
• Failure Domain: A failure domain is the set of systems that can fail together because they share an upstream dependency, region, provider, or operational mechanism. In identity programmes, the important question is not only what the service depends on, but how many access paths collapse when one dependency is lost.
• Operational Judgement: Operational judgement is the ability to distinguish a plausible answer from the right answer when the environment is incomplete, unusual, or failing. In support teams, it is what prevents automation from overriding context, evidence, and escalation discipline.

What's in the full article

PassBolt's full article covers the operational detail this post intentionally leaves for the source:

• How the support team reproduces tickets internally before replying to customers
• The mechanics of working through PGP messages, organisation recovery keys, and Docker-based restores
• How support decides when to pull in Product, Engineering, or Security
• What customers can include in a ticket to speed resolution and reduce follow-up

👉 The full PassBolt interview covers the support workflow, the hardest recovery case, and where AI fits into the team’s day-to-day work.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.