Notifications
Clear all
Topic starter
25/06/2026 1:28 am
TL;DR: Production AI agents break inherited service-account assumptions because their tool use, credentials, and attribution are all runtime-dependent, making JIT access and zero-standing privileges central to control, according to Riptides. The underlying issue is that access review models assume stable identities and reviewable artefacts, while agentic execution can change within a single session.
NHIMG editorial — what this means for AI and NHI governance
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams govern AI agents that act on behalf of users?
A: Treat the agent as a distinct runtime identity and preserve the user context it borrows for the session.
Q: Why do AI agents create more attribution risk than normal workloads?
A: Agents can choose different tool paths, request different credentials, and trigger actions that span multiple systems in one session.
Q: When does JIT access reduce risk for AI agents?
A: JIT access helps when the agent needs to reach sensitive systems but does not need persistent standing privilege between actions.
Practitioner guidance
- Define agent identities separately from shared service accounts Assign each production agent a distinct runtime identity and bind it to the workload that actually executes.
- Broker credentials at the call path Issue secrets only for the specific outbound request that needs them, and remove them from user space immediately after use.
- Preserve session context in every agent action record Record the agent, the initiating user, the tool path, and the policy decision together so investigations do not depend on cross-correlating multiple logs later.
What's in the full announcement
Riptides' full post covers the operational detail this post intentionally leaves for the source:
- Kernel-path attestation and how the runtime binds identity to the executing process
- The exact flow for composite identity, including human context binding and policy application
- Step-by-step examples of credential brokering and per-agent access enforcement
- How the same identity model extends to classic workloads and developer workstations
👉 Read Riptides' analysis of runtime machine IAM for AI agents →
AI agent attribution and access control: what changes for IAM teams?
Explore further
25/06/2026 10:53 am
AI agent identity is forcing IAM to confront runtime behaviour, not just entitlement design. Existing IAM programmes were built for identities that behave predictably between reviews. That assumption weakens when agents can choose different tools, request different credentials, and alter execution paths inside the same session. The implication is that identity governance for agents has to be judged on what it can prove at runtime, not on what it assigned at onboarding.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage.
A question worth separating out:
Q: What should IAM teams review first when agents start touching production systems?
A: Start with the identities the agents inherit, the credentials they can retain, and the systems they can call without approval. Those three areas reveal whether the environment is still running on service-account assumptions. If the answers are vague, policy enforcement and attribution will both fail under pressure.
👉 Read our full editorial: Runtime machine IAM for AI agents closes the attribution gap
