Notifications
Clear all
Topic starter
22/07/2026 4:36 pm
TL;DR: Privileged access tools fail in practice when they add friction that pushes engineers toward broader, less precise requests, according to Apono. The security issue is not just access brokering but whether the workflow makes least privilege usable under real developer pressure.
NHIMG editorial — based on content published by Apono: Apono vs StrongDM, which privileged access solution delivers better developer experience?
By the numbers:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, so organisations failing to scope AI access properly are 4.5x more likely to experience a security incident.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
Questions worth separating out
Q: How should security teams reduce privilege creep without slowing access requests?
A: Move the decision to request time.
Q: Why do tightly scoped access controls still fail in developer environments?
A: They fail when the request experience is slow, unclear, or disconnected from daily work.
Q: What do teams get wrong about zero standing privilege?
A: They treat it as a feature rather than a maturity shift.
Practitioner guidance
- Measure access friction as a security metric Track request-to-approval time, re-request rates, and the percentage of requests that expand scope after initial submission.
- Map access definitions to real task classes Review whether your permission sets reflect current debugging, incident response, and deployment tasks.
- Move access into the engineer workflow Embed request and approval flows into the tools teams already use, such as CLI, chat, or internal portals, so time-bound access is easier than over-requesting.
What's in the full article
Apono's full article covers the operational detail this post intentionally leaves for the source:
- A side-by-side walkthrough of the access experience differences between Apono and StrongDM in developer workflows.
- Specific workflow examples across Slack, CLI, Backstage, and portal-based request paths for time-bound access.
- The practical implications of runtime provisioning and automatic expiry for teams implementing Zero Standing Privilege.
- The session offer that walks through current-state access design and broad-role persistence in more detail.
👉 Read Apono's comparison of developer experience in privileged access workflows →
Privileged access workflow friction: what it means for least privilege?
Explore further
24/07/2026 4:12 pm
Developer experience is a privileged access control, not a user-experience add-on. When engineers cannot translate intent into the right access scope quickly, they optimise around the system. That is how broad requests become normalised and precision loses to speed. The governance lesson is simple: PAM that is hard to use creates pressure for standing privilege even when policy says otherwise.
A few things that frame the scale:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
- Security leaders also report that 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the same survey.
A question worth separating out:
Q: How do teams know whether privileged access management is actually working?
A: A working privileged access programme produces fewer permanent elevated accounts, clearer ownership, and better monitoring of when high-risk access is used. If administrators still use powerful accounts for routine work, PAM is not constraining the real risk. The test is whether elevated access is rare, justified, and easy to revoke.
👉 Read our full editorial: Developer experience is the hidden control in privileged access
