Topic starter
25/06/2026 1:24 am
TL;DR: A 2026 Cloud Security Alliance study found 74% of organisations say AI agents often get more access than needed, with Delinea noting that the real issue is what happens after authentication succeeds. Runtime authorization and session recording are what turn those actions into evidence instead of assumptions.
Editorial analysis by NHI Mgmt Group, based on content published by Delinea: “AI agent authorization: Why access at the door is not enough”.
By the numbers:
- 74% of organisations say AI agents often receive more access than necessary.
- AI agents often receive more access than necessary in 74% of organisations, according to a 2026 Cloud Security Alliance study cited by Delinea.
Key questions
Q: Why do AI assistants create more risk than traditional service accounts?
A: AI assistants create more risk because they can be influenced by inputs, context, and hidden instructions after authentication succeeds.
Q: How can organisations tell whether runtime authorization is actually working?
A: Look for three signs: decisions happen fast enough to stay inline, policies use live context instead of stale claims, and every allow or deny produces an auditable record.
Q: What breaks when security only checks AI agent access at session start?
A: Session-start checks miss what happens after access is granted.
Practitioner guidance
- Define a runtime authorization policy for agents Scope each agent to the minimum resource set needed for the current task and evaluate every privileged action against that policy while the session is active.
- Separate agent authentication from action approval Keep login success from implying task permission by adding per-action checks for high-risk operations that the inherited credential would otherwise allow.
- Require session recording for privileged agent work Record every agent session that can touch sensitive systems so investigators can reconstruct the action order, policy basis, and approving human.
Bottom line: AI agents change the authorization problem because inherited privilege can remain active after authentication has already succeeded.
Glossary terms: Runtime Authorisation, Inherited Access, Session Recording, Privileged non-human identity
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
25/06/2026 10:48 am
AI agent authorization is a runtime governance problem, not a provisioning problem: the article correctly frames the core issue as what happens after authentication succeeds. Agents inherit access and then continue making decisions inside the session, which means the control point moves from issuance to execution. For IAM and PAM teams, that changes the operating model from grant and review to continuous authorization and evidence.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
A question worth separating out:
Q: Who is accountable when an AI agent makes an unauthorised change?
A: Accountability should be assigned to the governance model that authorised the delegation, the owner of the workflow, and the team that set the policy boundary. In practice, organisations need clear responsibility for agent configuration, monitoring, and incident response because the machine’s speed does not remove human accountability for the delegated identity.
👉 Read our full editorial: AI agent authorization needs runtime controls, not just access checks