Topic starter
24/10/2026 8:50 pm
TL;DR: Akeyless's analysis of Gartner research finds AI agent security cannot stop at identity proofing or credential issuance. Practitioners need independent runtime authorization to judge each action in context, because valid credentials do not guarantee the next move is allowed.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “Gartner on AI Agent Security: The Case for Runtime Authorization”.
By the numbers:
- Organizations reported relying on existing workload access management tools (45%), the agent platforms themselves (41%), and secrets management tools (36%) to inventory and manage generative AI identities.
- The 2026 Gartner Surviving the Agentic AI Era Survey was fielded among 251 CISOs and their direct reports.
- Gartner found that 42% of organizations surveyed lack a formal machine IAM strategy.
Key questions
Q: Why do AI agents need separate runtime authentication and authorisation controls?
A: Because agent governance answers who approved the agent and what it should do, while runtime controls decide whether the agent can actually act in a specific system.
Q: How do security teams know if agent governance is actually working?
A: It is working only if the team can answer three questions quickly for any agent: what it can reach, what it did recently, and whether that behaviour matches intent.
Q: What is the difference between secrets management and workload IAM?
A: Secrets management stores and rotates credentials.
Practitioner guidance
- Separate identity from action governance Map which controls establish agent identity and which controls approve each action.
- Block reusable agent credentials Remove direct credential possession from agents where possible and broker execution through short-lived, task-bounded access that is minted only for an approved request.
- Inspect tool parameters at runtime Evaluate the requested command, target and parameters before execution, not after the fact.
Bottom line: AI agent security cannot stop at identity establishment because a valid credential does not guarantee that the next action is authorised.
Glossary terms: Runtime Authorisation, Task-bounded Access, Delegated Authority Model, Policy Layering
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- The Gartner survey breakdown showing how CISOs currently split AI identity management across workload tools, agent platforms and secrets management
- The architecture pattern for independent runtime authorization across MCP, LangChain, CrewAI, AutoGen and other orchestration layers
- The session-level audit model that records prompts, intent classification, policy verdicts and executed commands for later review
- The control flow for dynamic secret minting, brokered sessions and revocation when a task completes or changes scope
👉 Read Akeyless's analysis of Gartner's runtime authorization case for AI agents →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 week ago 2 times by NHI Mgmt Group
25/10/2026 11:13 am
Runtime authorization is the control point, not an optional enhancement. Once an agent can alter its next action at runtime, the security question is no longer whether it authenticated successfully. The question is whether every action is independently checked against task intent, target scope and policy before execution. That makes identity provisioning necessary but insufficient for production governance.
A few things that frame the scale:
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to the 2024 State of Secrets Management Survey.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
A question worth separating out:
Q: Should organisations centralise policy for AI agents across multiple platforms?
A: Yes, because platform-specific policy creates fragmented rules, inconsistent enforcement and weak auditability. A central policy layer lets the same business rule apply across different agent frameworks, which is essential when several teams are deploying agents in parallel.
👉 Read our full editorial: AI agent security needs runtime checks beyond credential trust
This post was modified 1 week ago by NHI Mgmt Group