TL;DR: Akeyless summarises Gartner research showing that existing workload identity, agent platforms and secrets tools leave AI agents governed by patchwork controls, while runtime authorization is needed to inspect actions as they happen. The core gap is assumption failure: traditional identity tooling presumes predictable execution, but agents can shift intent mid-session without changing credentials.
At a glance
What this is: Akeyless cites Gartner research arguing that AI agent security cannot stop at identity proofing or credential issuance because agent behaviour must be authorised at runtime.
Why it matters: This matters because IAM, PAM and secrets workflows built for predictable workloads do not reliably constrain autonomous or semi-autonomous agent actions once access is granted.
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.
👉 Read Akeyless's analysis of Gartner's runtime authorization case for AI agents
Context
AI agent security is no longer just a question of who can authenticate. The harder problem is what an agent is allowed to do after it authenticates, especially when the agent can change course based on new information, untrusted content, or shifting instructions.
That creates a governance gap for IAM and secrets teams: identity proofing, credential issuance and vaulting can establish access, but they do not by themselves constrain runtime behaviour. In practice, the control point moves from identity at login to authorization at action time.
Gartner's framing, as cited by Akeyless, is that enterprises need an independent runtime control plane for agents. AI agent authorisation becomes a programme issue rather than a point solution concern when agent platforms, workload IAM and secrets tooling all claim part of the policy surface.
Key questions
Q: What is the difference between secrets management and workload IAM?
A: Secrets management stores and rotates credentials. Workload IAM verifies the identity of the workload at runtime and issues time-scoped access based on policy. The practical difference is that a vault protects a secret after it exists, while workload IAM tries to avoid creating a reusable secret in the first place.
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. Without enforcement at the access layer, policy can describe boundaries that the live agent never has to obey. That is a direct production risk.
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. If any of those answers require manual reconstruction, governance exists on paper but not in operations.
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.
Technical breakdown
Why workload identity is necessary but not sufficient for AI agents
Workload identity establishes that an agent is a recognised actor, but that only answers the authentication question. The harder problem is runtime authority, because an agent can receive valid credentials and still execute an action that was never intended by the human who delegated the task. In agentic systems, the subject of authorisation is not a stable requestor with fixed intent. It is a runtime system whose next action depends on prompts, tool outputs and intermediate reasoning. That is why secrets management and workload IAM alone cannot express the real control boundary. See the Agentic AI Identity Guide.
Practical implication: Practitioners should separate agent identity establishment from action authorisation and treat them as different control layers.
How independent runtime authorisation changes the control model
Runtime authorisation evaluates the requested action at the moment it is about to occur, not when the agent is first enrolled or given a token. That means the control is intent-aware, session-aware and action-specific. In the model described here, the agent never needs to hold a reusable credential. Instead, an approval decision is made on the command that is about to execute, using the prompt, the target, the requested operation and the policy attached to that business context. This shifts the enforcement point from identity infrastructure to action governance.
Practical implication: Practitioners should design policies around actions, parameters and targets, not around static roles alone.
Why agent orchestrators create policy fragmentation
When the orchestrator owns prompt context and tool calling, it is tempting to embed permissions there because it feels close to the developer workflow. The problem is that each platform can then enforce its own policy logic, creating a fragmented control plane across HR, engineering and sales use cases. That fragmentation breaks governance consistency and makes it difficult to prove that the same authority rules apply everywhere. Independence matters because the policy layer must remain separate from whichever agent framework happens to issue the call. See the Agentic AI Security Guide.
Practical implication: Practitioners should avoid letting each agent platform define its own access rules in isolation.
Threat narrative
Attacker objective: The objective is to induce an authorised agent to carry out an unauthorised action while preserving the appearance of legitimate access.
- Entry occurs when an agent authenticates successfully and receives a credential or delegated authority that appears legitimate at issuance time.
- Escalation follows when the agent's reasoning is redirected by untrusted input, but the credential still carries the original scope of access.
- Impact occurs when the agent performs an action that no human intended, because the vault or platform never re-evaluated the request at execution time.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Predictable-interaction assumptions break down the moment an agent can reinterpret its task. Traditional workload identity and secrets management were built for deterministic systems whose access pattern is stable enough to model up front. AI agents invalidate that assumption because the access decision and the action decision are no longer the same event. The implication is that governance must move from static privilege assignment to dynamic action control.
Agent platforms should not be allowed to mark their own homework. When the same platform sees the prompt, chooses the tool and enforces the rule, policy becomes coupled to the orchestration layer. That creates fragmented authority across teams and weakens auditability. Independent runtime control is the cleaner governance boundary because it keeps decision-making separate from execution.
Ephemeral credential trust debt: handing an agent a valid secret creates an enduring trust obligation that the vault cannot repay later. The agent may still be within its original credential scope even after its intent has changed, so the governing failure is not secret exposure alone but the assumption that credential validity implies behavioural legitimacy. Practitioners need to treat this as a broken premise, not a tuning issue.
Workload IAM is the prerequisite layer, not the endpoint. Gartner's cited research is right to pair workload identity with runtime enforcement, because runtime controls cannot compensate for missing actor context. The field should read this as a two-layer model: establish who or what the agent is, then govern what it may do on each action.
From our research library:
- 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.
- Read next: AI Agent Authorisation Guide
What this signals
Runtime authorisation will become the governance seam that matters most for agent deployments. Identity proofing and vaulting still matter, but they no longer define the whole control boundary once an agent can change course during execution. Organisations that keep treating access issuance as the finish line will discover that the real policy question starts after authentication.
The programme implication is that agent governance needs a policy layer that is independent of the orchestration stack and capable of evaluating each action in context. That is where runtime checks, lineage and revocation become operational controls rather than abstract principles.
Access review cadences are too slow for agent behaviour: a credential can be valid, misused and retired before any periodic review sees it. That pushes practitioners toward issuance-time and action-time controls, with audit records designed for attribution instead of after-the-fact reconciliation.
For practitioners
- Separate identity from action governance Map which controls establish agent identity and which controls approve each action. Do not let a single login or token issuance event serve as proof that the downstream behaviour is authorised.
- 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. Treat prompt context as part of the authorisation decision when the agent's intent can change mid-session. See the MCP Security Guide.
- Keep orchestration and policy separate Prevent agent platforms from acting as their own access-control authority. Centralise policy decisions so the same business rule applies across multiple orchestrators and workloads.
- Preserve action lineage for every request Record the raw prompt, the classified intent, the policy verdict, the session and the executed command in a single audit trail that supports attribution and revocation.
Key takeaways
- AI agent security cannot stop at identity establishment because a valid credential does not guarantee that the next action is authorised.
- Gartner's cited survey data shows fragmented management across workload tools, agent platforms and secrets systems, which leaves policy enforcement inconsistent.
- The practical shift is from static credential governance to independent runtime authorization that evaluates each agent action in context.
Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Agentic AI Identity Guide · AI Agent Observability, Audit and Incident Response Guide · MCP Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on agents receiving and misusing authority at runtime. |
| Recommendation — Design controls so every agent action is checked for identity and privilege fit before execution. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The piece argues that authentication alone does not constrain what an agent does after access is granted. |
| Recommendation — Separate authentication from runtime authorisation for agent identities and inspect each action before execution. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core governance issue is whether agent permissions and entitlements are enforced at the point of use. |
| Recommendation — Apply PR.AA-05 to ensure agent entitlements are evaluated dynamically against each requested action. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article repeatedly shows that broad ambient access defeats least-privilege assumptions for agents. |
| Recommendation — Use AC-6 to keep agent permissions task-bounded and deny actions that exceed delegated scope. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The failure mode depends on a valid credential being available to an agent whose intent shifts later. |
| Recommendation — Map agent credential misuse to TA0006 and prioritize controls that stop valid access from becoming misuse. | ||
Key terms
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Task-bounded Access: Task-bounded access is a control pattern where permissions exist only for the duration of a specific job and are removed automatically when the job ends. It is especially relevant for AI agents because autonomous systems can otherwise retain or recreate access long after the original need has passed.
- Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
- Policy Layering: Policy layering is the practice of applying different rules at different decision points, such as application, entitlement, and review. It improves scale and precision when it is deliberate. It becomes risky when layers overlap without a clear authority model or exception path.
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
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 21, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org