They should treat it as both, but IAM is the first-order constraint because an agent cannot be safely governed if its privileges are already excessive. Model governance matters, yet the most immediate risk comes from who or what can act, change, and persist in production systems.
Why agentic AI cannot be governed from the model layer alone
The governance mistake is to treat the model as the system and the agent as an incidental wrapper. An agentic system is operationally defined by what it can access, invoke, and persist, so the control plane has to start with authority boundaries. If the agent can reach production data, tools, or write paths too broadly, model governance cannot compensate after the fact.
That is why the first question is not whether the model is acceptable in the abstract, but whether the agent’s permissions are bounded to the task, environment, and duration that the business actually needs. Once autonomy exists, access scope becomes a safety property, not a convenience setting.
The practical implication is that IAM, authorization, and lifecycle controls are the immediate containment layer. Model governance still matters for training, evaluation, transparency, and misuse resistance, but those controls sit above a runtime that must already be constrained. For a useful decomposition of identity, delegation, and retirement issues, see the Agentic AI Identity Guide.
Where model governance ends and access governance begins
Model governance asks whether the system is safe to build, release, and operate as a model-led capability. IAM asks whether an agent is allowed to act, on what resources, through which tools, and under what approval path. Those are different failure modes: a well-governed model can still be dangerous if it is granted standing access, while a tightly scoped agent can sometimes be managed safely even while the underlying model changes.
In practice, the dividing line is who owns the decision at runtime. Model governance usually belongs to AI risk, legal, and platform governance functions. Access governance belongs to the teams that already manage entitlements, privileged access, secrets, and service accounts, because they control blast radius, revocation, and reviewability.
The most useful mental model is that model governance reduces uncertainty, while IAM reduces capability. If you can only improve one first, reduce capability first. The AI Agent Authorisation Guide is useful here because it frames task-scoped and just-in-time access as the deciding control pattern.
What a balanced operating model looks like for agentic AI
A workable operating model treats the model and the agent as separate control domains. The model should be governed for quality, safety, transparency, and testing discipline. The agent should be governed for identity, delegated authority, approval gates, secret handling, tool access, and offboarding. That separation helps prevent a common mistake: assuming that a safer model automatically means a safer autonomous workflow.
At deployment time, teams should be able to answer four questions clearly: what identity the agent uses, what it can do without human approval, what expires automatically, and what evidence shows the permissions are still correct. If those answers are vague, the organisation has not really governed the agent, it has only documented the model.
For a broader control view, the Agentic AI Security Guide helps connect tool use, memory, orchestration, and identity into one threat surface, while the AI Agent Observability, Audit and Incident Response Guide shows why attribution and kill-switch design are part of the operating model, not afterthoughts.
Risk and Threat Considerations
agentic ai creates a compound risk: model weaknesses can produce bad outputs, but overbroad access turns bad outputs into bad actions. The highest-impact failures usually come from excessive privilege, reused credentials, unreviewed delegation, and poor separation between human and agent authority. Those conditions make compromise more valuable to an attacker and make honest mistakes more damaging to the business.
Failure mechanism: The agent is given standing access, long-lived credentials, or broad tool permissions, then a prompt issue, poisoned context, or operator error converts model behaviour into real-world change.
Impact: The result can be unauthorized data exposure, destructive writes, lateral movement, or actions that are hard to attribute and slow to revoke.
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 addresses the attack and risk surface, while NIST AI RMF 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 | Agent authority and privilege are the core issue in this question. |
| ASI02 — Tool Misuse | Runtime tool access determines whether model behaviour becomes harmful action. | |
| ASI10 — Rogue Agents | Unbounded autonomy and persistence can turn an agent into an unmanaged actor. | |
| Recommendation — Enforce least-privilege agent access and require approval for elevated actions. Restrict agent tool access to approved actions and monitor tool invocation. Require registration, ownership, and revocation for every deployed agent. | ||
| NIST AI RMF | Govern | The question is about AI governance decisions and accountable oversight. |
| Recommendation — Establish governance roles, accountability, and documented review for agentic AI. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | First-order control for constraining what the agent can do in production. |
| IA-5 — Authenticator Management | Agent authority depends on secure lifecycle handling of credentials and tokens. | |
| AU-2 — Event Logging | Attribution and reviewability are essential when agents act autonomously. | |
| Recommendation — Apply least privilege to all agent credentials and service access. Rotate, protect, and retire agent authenticators on a defined schedule. Log agent actions, approvals, and privilege changes for later review. | ||
Practitioner Guidance
What to prioritise: Start with the permission boundary, not the model score. If the agent can touch production systems, customer data, or administrative APIs, put entitlement review, expiry, and approval logic ahead of any deeper model tuning.
What to verify: Confirm that each agent has a named owner, a bounded task scope, a revocation path, and evidence of last access review. If the control design cannot produce those four items quickly, the operating model is still immature.
Practitioner takeaway: Treat model governance as necessary but insufficient; the system becomes governable only when the agent’s authority is narrow enough to make mistakes containable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org