Notifications
Clear all
Topic starter
06/07/2026 9:38 am
TL;DR: Agentic AI agents move through training, deployment, retraining, and decommissioning with identities, keys, and permissions that often outlive the workload itself, creating orphaned access and privilege drift, according to Token Security. Access review processes assume access persists long enough to be reviewed; autonomous actors can acquire, mutate, and outlive that window within the same operational lifecycle.
NHIMG editorial — based on content published by Token Security: Agentic AI Lifecycle Management: From Training to Decommissioning Securely
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
Questions worth separating out
Q: How should security teams govern AI agents through their full lifecycle?
A: They should treat each agent as a machine identity with provisioning, operation, retraining, and offboarding controls tied together.
Q: Why do AI agents create more identity risk than traditional automation?
A: AI agents can change behaviour after deployment while keeping the same credentials and policy attachments.
Q: What breaks when AI agent offboarding does not revoke identity access?
A: The organisation is left with ghost identities, valid keys, and service accounts that no longer map to an active workload.
Practitioner guidance
- Link agent lifecycle events to identity lifecycle controls Trigger entitlement review, key rotation, and offboarding workflows when an agent is trained, retrained, redeployed, or decommissioned so the identity state changes with the workload state.
- Replace default-to-admin deployment patterns Assign the narrowest initial RBAC scope the agent needs, then re-certify access when its function changes instead of leaving broad permissions in place for convenience.
- Scan training and operational data for embedded secrets Check datasets, prompts, logs, and code for API keys and passwords before they reach the model, then keep synthetic or redacted data in the training path where possible.
What's in the full article
Token Security's full blog covers the operational detail this post intentionally leaves for the source:
- The staged lifecycle table for data collection, training, deployment, retraining, and decommissioning, including the specific security challenge at each phase.
- The runtime observability workflow for comparing declared permissions with actual agent behaviour and flagging permission gaps.
- The shutdown sequence for revoking sessions, rotating keys, removing IAM groups, and preserving audit logs.
- The article's practical examples of drift, hallucination persistence, and forgotten authorisation risks in deployed agents.
👉 Read Token Security's agentic AI lifecycle management analysis →
Agentic AI lifecycle management: where IAM teams are exposed?
Explore further
06/07/2026 9:53 am
Agentic AI lifecycle governance exposes a broken assumption about identity stability. The article shows that AI agents do not remain behaviourally fixed across their lifecycle, yet many identity programmes still treat access as if it does. That assumption fails when retraining, context shifts, or prompt drift change what the actor does without changing the identity record. The implication is that lifecycle governance for autonomous systems has to be understood as dynamic identity governance, not static provisioning.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should own AI agent identity governance in an enterprise?
A: Ownership should sit across IAM, platform engineering, security architecture, and the teams operating the agents, with clear accountability for lifecycle events. The important point is that no single team can manage agent identity in isolation because provisioning, drift detection, and decommissioning all cut across domains.
👉 Read our full editorial: Agentic AI lifecycle governance is becoming an identity problem
