Notifications
Clear all
Topic starter
19/08/2026 3:53 pm
TL;DR: AI agents can request and use access in ways that exceed their original provisioning, and Fiddler’s article argues that existing permission models, bearer tokens, and static grants are not designed for that behaviour. The core issue is assumption collapse: access review and fixed-scoping models presume stable permissions, while agents can seek new access mid-task and expose secrets through context.
NHIMG editorial — based on content published by Fiddler: AI Agents Have an Identity Complex
By the numbers:
- 90 to 95 percent of permissions granted today are over-privileged.
Questions worth separating out
Q: How should security teams manage permissions for AI agents?
A: Security teams should regularly assess and update the permissions granted to AI agents to ensure they align with their intended scope.
Q: Why do autonomous AI systems create more identity risk than normal automation?
A: Normal automation follows a fixed path, but autonomous systems can interpret goals, choose actions, and continue without waiting for a person.
Q: What do organisations get wrong about securing AI agents with secrets?
A: They often treat shared secrets and fixed tokens as acceptable trust mechanisms for agents that behave dynamically.
Practitioner guidance
- Define runtime access request boundaries Map every point where an agent can request new access during a task and require policy approval before the request can proceed.
- Keep credentials out of model context Deliver secrets through a proxy or gateway so tokens never enter the LLM context window.
- Separate local agent execution from secret-bearing file paths Restrict what the process can read on developer laptops, especially downloads folders, dot files, and recovery-code locations.
What's in the full article
Fiddler's full blog covers the operational detail this post intentionally leaves for the source:
- The identity-attestation approach for local agent processes, including kernel audits and code-signing trust chains.
- The proxy and hints pattern for keeping secrets out of LLM context while still allowing task completion.
- The runtime authorization sequence that separates policy decision from enforcement for agent requests.
- The discussion with 1Password's Jeff Malnick and the Agent Auth Protocol reference points.
👉 Read Fiddler's analysis of AI agent identity and permission risk →
AI agent identity: are your permission models keeping up?
Explore further
19/08/2026 4:30 pm
AI agents are not just another NHI class, because their reasoning changes the access model itself. The identity question is no longer only whether a workload has a secret, but whether it can decide that new access is required during task execution. That shifts the security problem from static provisioning to runtime governance. The implication is that agent identity must be treated as a behavioural control surface, not a one-time entitlement record.
A few things that frame the scale:
- 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, according to AI Agents: The New Attack Surface report.
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
A question worth separating out:
Q: What is the difference between human access review and AI agent access review?
A: Human access review focuses on stable job roles and periodic entitlement checks. AI agent access review must also account for runtime behaviour, changing integrations, token lifetimes, and delegated actions across SaaS systems. Agents can change what they touch faster than a standard access review cycle expects.
👉 Read our full editorial: AI agent identity exposes the gaps in existing permission models
