Topic starter
11/08/2026 3:13 pm
TL;DR: PlainID argues that agentic workflows expose a governance gap between delegated identity and the tool, API, or dataset an agent touches next, because static access models were built for predictable user-to-application requests. The collapsing assumption is that entitlements and access reviews can govern within-session delegated action, when policy now has to move to the point of execution.
Editorial analysis by NHI Mgmt Group, based on content published by PlainID: “How Microsoft and PlainID Extend Trust Through Agentic Workflows”.
Key questions
Q: How should security teams govern AI agents that choose tools at runtime?
A: Security teams should treat runtime tool choice as a governed access event, not a normal application call.
Q: Why do static IAM models fail in agentic workflows?
A: Static IAM models assume access can be judged at session start and remain valid long enough to govern the whole task.
Q: What are the signs that delegated agent access is drifting beyond user authority?
A: The clearest sign is when an agent can continue across multiple systems with the same access context even as the task changes.
Practitioner guidance
- Map delegated chains to resource-level decisions Identify where human user, agent identity, and downstream resource all influence the same authorisation decision, then require policy at that exact point of access.
- Move enforcement to the point of use Place checks immediately before API calls, tool invocations, data retrieval, and output generation so the decision reflects current context rather than stale session state.
- Treat effective privilege as dynamic Recalculate what the agent may do after each step instead of carrying forward broad delegated access for the entire workflow.
Bottom line: Agentic workflows expose a gap between session start and action-time governance, and static IAM controls do not close it.
What's in the full article
PlainID's full article covers the operational detail this post intentionally leaves for the source:
- How the runtime authorization policy is applied across prompt, retrieval, tool use, and output
- How composite identity binding is used to keep delegated agent access within the user's authority
- How policy continuity is maintained when workflows move beyond the primary ecosystem
- How zero standing privileges are recalculated as the workflow advances
👉 Read PlainID's analysis of runtime authorization for agentic workflows →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
11/08/2026 3:27 pm
Runtime authorization is the missing control plane for delegated agent action: static IAM models answer who started the workflow, but not what the agent may do at each downstream step. That distinction matters because agentic systems can cross tools, APIs, and data stores before any human review occurs. The practitioner conclusion is that authorisation must become action-scoped, not session-scoped.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should teams do when an agent leaves the primary identity ecosystem?
A: Teams should require the same identity and business policy to follow the workflow outside the original platform. When an agent crosses into external tools, APIs, or datasets, the authorisation decision must still reflect task purpose, data sensitivity, and the user’s authority. Without that continuity, governance fragments at the system boundary.
👉 Read our full editorial: Runtime authorization for agentic workflows: what changes for IAM
This post was modified 4 days ago by NHI Mgmt Group