Notifications
Clear all
Topic starter
06/07/2026 9:46 am
TL;DR: Agent-based IAM platforms extend visibility, session controls, and automated access handling beyond static IAM, but their value is in closing governance gaps that legacy role-based systems miss, according to StackBob. The real shift is that identity programs must manage continuous, context-aware decisioning rather than assuming access is fixed long enough to be reviewed.
NHIMG editorial — based on content published by StackBob: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams evaluate agent-based IAM against legacy identity controls?
A: They should test whether the platform changes decisions in real time or only improves visibility over static access.
Q: Why do static IAM models struggle with dynamic access behaviour?
A: Static IAM models struggle because they assume access can be defined once and reviewed later.
Q: What breaks when lifecycle automation does not cover all connected systems?
A: Offboarding, access changes, and entitlement cleanup become inconsistent.
Practitioner guidance
- Map static control dependence Identify where your current IAM programme still relies on fixed roles, manual approvals, and delayed review cycles.
- Define the telemetry needed for action List the behavioural, device, and session signals that would justify intervention before you trust continuous monitoring.
- Test lifecycle coverage across the app estate Check which applications actually accept automated access updates and which still depend on manual exception handling.
What's in the full article
StackBob's full article covers the operational detail this post intentionally leaves for the source:
- How agent-based IAM tools connect to systems that do not expose SCIM or SAML integration paths.
- The article's feature-by-feature treatment of password management, authentication, monitoring, lifecycle automation, and reporting.
- Implementation considerations around scalability, integration effort, and privacy oversight that matter once you are selecting tooling.
- The vendor's own positioning on why its agent model differs from older IAM patterns.
👉 Read StackBob's analysis of agent-based IAM and legacy control gaps →
Agent-based IAM: what it means for IAM teams now?
Explore further
06/07/2026 10:02 am
Static identity policy is the wrong baseline for dynamic access behaviour: The article reinforces a simple but important point. When access decisions depend on fixed roles and delayed review cycles, the control model assumes the identity behaves predictably long enough to be governed after the fact. That premise weakens when behaviour changes in-session or outside the normal approval path. Practitioners should treat static policy coverage as incomplete wherever runtime context materially changes risk.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which explains why identity programmes still miss hidden access paths until after exposure.
A question worth separating out:
Q: How do teams know whether continuous monitoring is actually improving IAM?
A: They should look for shorter time-to-detect on suspicious access, fewer unresolved exceptions, and cleaner evidence for certification and audit. If monitoring only creates more alerts without improving response or entitlement hygiene, it is noise rather than governance.
👉 Read our full editorial: Agent-based IAM exposes the limits of legacy identity controls
