A single LLM call has one input and one output, but an agent workflow can chain multiple models, tools, and data sources. Each handoff expands the attack surface and creates more chances for unauthorized access, data leakage, or unsafe action. Identity controls must follow the workflow, not just the model endpoint, so access stays limited to the current task.
Why This Matters for Security Teams
Single model calls are easier to contain because the request usually ends where the response ends. Agent workflows are different: they can decide, retry, branch, call tools, fetch secrets, and hand work to other systems. That creates a moving identity problem, not just a model-risk problem. Current guidance from the OWASP Agentic AI Top 10 and NHIMG research on the AI Agents: The New Attack Surface report shows why static permissions are too coarse for autonomous systems.
Identity and access controls need to follow the task, the context, and the runtime state of the agent. If a workflow can search a ticketing system, open a database, and trigger a deployment, then each step must be separately authorized and logged. NIST’s NIST AI Risk Management Framework treats this as a governance and accountability issue as much as a technical one. In practice, many security teams encounter overbroad agent access only after an agent has already read data or taken action it was never intended to reach.
How It Works in Practice
Stronger controls for agent workflows usually start with workload identity, not user-style login sessions. An agent should present cryptographic proof of what it is, and then receive only the minimum access needed for the current action. That is why patterns such as SPIFFE and OIDC-based workload tokens matter: they let systems authenticate the agent instance, then issue short-lived, task-scoped access rather than durable secrets. NHIMG’s OWASP NHI Top 10 and LLMjacking: How Attackers Hijack AI Using Compromised NHIs both reinforce the same point: long-lived credentials are a poor fit for autonomous execution.
In practice, the access pattern should be evaluated at runtime. Policy-as-code tools such as OPA or Cedar can decide whether the agent may read a record, invoke a tool, or pass a result to another service based on the current task, data sensitivity, and environment. A typical control stack looks like this:
- Issue JIT credentials per tool call or per workflow step.
- Limit credentials to a short TTL and revoke them on task completion.
- Separate model access from tool access so model output cannot directly imply privilege.
- Log every handoff, including prompt, tool, and data access decisions.
- Block secret reuse so one successful call cannot expand into lateral movement.
This approach is especially important when agents can chain tools across SaaS, cloud, and internal systems. The CSA MAESTRO agentic AI threat modeling framework aligns with this runtime view of risk. These controls tend to break down when agents operate in legacy environments that cannot issue short-lived tokens or enforce per-request authorization on downstream tools.
Common Variations and Edge Cases
Tighter controls often increase orchestration overhead, so organisations must balance responsiveness against governance friction. That tradeoff is real, especially when an agent needs to complete a multi-step job across systems that were never designed for ephemeral identity. Current guidance suggests that the stricter the agent’s execution authority, the more important real-time policy evaluation becomes.
There is no universal standard for this yet. Some teams can use strong workload identity end to end, while others must rely on proxy layers, brokered secrets, or explicit approval checkpoints for high-risk actions. The right answer depends on whether the agent is reading data, modifying records, triggering production changes, or handing off to another agent. NHIMG’s Ultimate Guide to NHIs is a useful baseline for separating identity, credential, and access-control concerns before extending them into agentic workflows. The Anthropic report on AI-orchestrated cyber espionage also illustrates why autonomous chaining changes the threat model. The hardest edge case is a semi-autonomous agent embedded in a human approval flow, because responsibility is split while the privileges may still accumulate.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Addresses agentic overreach, tool misuse, and runtime authorization gaps. |
| CSA MAESTRO | MT-02 | Covers agent threat modeling and controls for multi-step autonomous workflows. |
| NIST AI RMF | GOVERN | Frames accountability, oversight, and risk management for autonomous AI systems. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Focuses on secret lifecycle and credential sprawl in non-human identities. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero trust supports per-request authorization for dynamic agent actions. |
Bind each agent step to least-privilege policy checks and revoke access after the task ends.
Related resources from NHI Mgmt Group
- Why do AI and agentic workflows increase the need for stronger access controls around APIs and tool servers?
- What is the difference between user identity and agent identity in enterprise AI workflows?
- What is the difference between human identity governance and AI agent governance?
- When does AI agent access create more risk than it reduces?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
