Topic starter
14/05/2026 6:12 pm
TL;DR: AI agents shift the security problem from model accuracy to access scope, because they act inside enterprise systems with real permissions, according to Saviynt. Task-scoped, time-bound identity controls now matter more than output quality when the system can retrieve data, write code, and trigger workflows.
Editorial analysis by NHI Mgmt Group, based on content published by Saviynt: “AI Agents Aren’t Trustworthy (But We’re Deploying Them Anyway)”.
Key questions
Q: What breaks when AI agents have broader access than their tasks require?
A: Over-privileged agents break segregation of duties, weaken auditability, and expand blast radius across transactions, data lookups, and workflow triggers.
Q: Why do AI agents create access risk even when the model is accurate most of the time?
A: Because the risk is not only incorrect reasoning, it is incorrect action.
Q: What are the signs that runtime access control for AI agents is failing?
A: The most common sign is policy that looks complete on paper but does not stop chained tool calls, cross-system reach or sensitive actions in the live session.
Practitioner guidance
- Constrain agent permissions to task scope Define the minimum resources, actions, and data an AI agent needs for one workflow and deny all unrelated access by default.
- Enforce runtime authorisation checks Evaluate access at execution time using the current request, task context, and user intent instead of relying only on provisioning-time roles.
- Remove access when the task completes Revoke temporary permissions immediately after the step that needed them finishes so the agent cannot keep acting with stale scope.
Bottom line: AI agents change the security boundary because they can act, not just recommend, and that makes access scope the primary control problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/05/2026 6:13 pm
AI agent identity is now a governance boundary, not an implementation detail. Once a system can act across applications, retrieve data, and trigger workflows, the security question becomes who or what it is allowed to act as. The old separation between model output and enterprise action no longer holds, so identity governance has to extend into the execution layer. Practitioners should treat the agent as an identity subject with scope, duration, and accountability, not as a chat interface with tools.
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.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Should organisations treat AI agents at checkout as a separate identity pattern?
A: Yes. AI agents can place transactions at a speed and sequence that look unlike normal human checkout, which means legacy fraud controls may misclassify them. Teams should explicitly model authorised agents, capture session and permission context, and decide in advance how those patterns will be scored.
👉 Read our full editorial: AI agent access control is the new NHI security boundary