Treat it as an extension of identity governance, but with runtime enforcement added. IAM still matters for authentication, attribution, and lifecycle control, yet MCP workflows require inline policy, action-level scoping, and auditability that conventional identity reviews do not provide on their own.
Why Insurers Should Not Collapse AI Agent Governance Into IAM Alone
For insurers, the core issue is not whether AI agents have identities. It is that they act with delegated authority, can change behaviour at runtime, and may chain tools in ways a static identity review cannot fully predict. IAM remains necessary for onboarding, offboarding, authentication, and attribution, but it does not on its own govern what an agent can do once it is live. That is why insurers should treat agent governance as an extension of identity governance, not a synonym for it.
This matters because insurance teams often inherit controls built for humans or fixed service accounts: role assignment, periodic access review, and credential lifecycle management. Those controls help establish ownership and accountability, yet they do not answer the more difficult questions of whether an agent may invoke a claims system, move customer data into a prompt context, or trigger an underwriting workflow under changing conditions. The practical gap is between having a named principal and constraining the actual action.
Current guidance from OWASP Top 10 for Agentic Applications 2026 reflects that split by focusing on agent-specific abuse paths such as tool misuse, prompt injection, and unsafe action execution. In practice, many insurers discover that the first meaningful failure is not a missing identity record, but an over-broad agent action path that was never separately governed.
How It Works in Practice for Underwriting, Claims, and Broker Automation
The workable model is layered. IAM should answer who or what the agent is, how it is authenticated, and what persistent privileges it is allowed to hold. A separate agent-control layer should answer what the agent may do right now, under what conditions, and with what approval or constraint. That second layer is where runtime policy, action scoping, transaction context, and audit-grade event capture become essential.
In insurer environments, that usually means four operational decisions:
- Use identity governance to bind each agent to an owner, purpose, and lifecycle state.
- Use short-lived credentials or token-bound access where the agent must call external systems.
- Apply inline policy for actions that can move money, change policy state, or expose regulated data.
- Log both the decision and the triggering context so a reviewer can reconstruct why the action was allowed.
This is where conventional access reviews stop being enough. A quarterly review can tell you that an agent is authorised to access a claims API. It cannot tell you whether that same agent should be blocked when it receives untrusted content, attempts an unusual sequence of tool calls, or crosses a policy boundary after context drift. For that reason, many programmes now separate entitlement review from runtime authorisation, even when they keep both under one governance umbrella. CSA MAESTRO agentic AI threat modelling framework is useful here because it frames the control problem around agent behaviour and trust boundaries rather than around identity records alone. NHIMG’s guidance on agentic applications also emphasises that agent risks are often action-path risks, not simply access-path risks.
For insurers, the practical test is whether a control can stop or contain a harmful action before it affects policy data, customer records, reserving logic, or payment workflows. If the answer depends entirely on post-hoc review, the control is incomplete. These controls tend to break down when agents can call multiple systems, retain context across sessions, or inherit broad back-end permissions that were never designed for dynamic decision-making.
Where the Boundary Gets Fuzzy: Shared Governance, Different Enforcement
Tighter control over AI agents often increases operational overhead, requiring insurers to balance speed of automation against the need for real-time constraint. The boundary is fuzzy because some controls still belong in IAM and some clearly do not. Lifecycle, ownership, authentication, and role assignment belong with identity governance; task-level approvals, context checks, and action blocking belong with runtime enforcement.
That distinction becomes more important in edge cases. A read-only knowledge assistant may fit comfortably inside existing IAM with limited augmentation. A claims triage agent that can retrieve documents, draft decisions, and trigger downstream work is different because its risk is not just access to a system, but the effect of a sequence of actions. Best practice is evolving, but there is no universal standard for this yet, so insurers should avoid pretending that a broad identity review is sufficient for all agent classes.
For governance teams, the useful question is not “IAM or separate domain?” but “Which risks are controlled by identity state, and which require runtime policy?” If a failure would be caught only after the agent has already executed a harmful workflow, that is a signal the control domain is too shallow. NIST AI Risk Management Framework is helpful for the broader governance lens, while OWASP NHI Top 10 is useful when the insurer needs a more identity-centred view of delegated machine access. In practice, the separation becomes non-negotiable when an agent can act across systems that were never designed to trust each other by default.
Risk and Threat Considerations
The material risk is over-reliance on static identity governance for a control problem that is partly behavioural. If insurers treat AI agents like ordinary users or service accounts, they can end up with legitimate identities that still execute unsafe, excessive, or contextually inappropriate actions.
Failure mechanism: The weakness appears when broad entitlements, long-lived credentials, and weak runtime checks combine with agent autonomy. Attackers and abusers do not need to defeat IAM entirely; they may only need to induce the agent into making an authorised but harmful call sequence, or exploit a trust boundary that was never separately constrained.
Impact: The result can be unauthorised policy changes, exposure of regulated customer data, fraudulent workflow execution, or operational loss of control over automated decisions. In insurer settings, the harm is often not one broken login, but a chain of valid actions that should never have been allowed in that combination.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 — Agent Identity and Access | AI agents need scoped identity plus action governance, not IAM alone. |
| Recommendation — Constrain agent actions with explicit policy, not identity membership alone. | ||
| CSA MAESTRO | GOV — Governance | Insurance must govern agent behavior, ownership, and accountability. |
| Recommendation — Assign clear ownership and governance for each agent before deployment. | ||
| NIST AI RMF | GOVERN — Govern, Map, Measure, and Manage | This is an AI risk governance question about accountability and controls. |
| Recommendation — Map agent risks, measure control gaps, and manage them under a formal AI governance process. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | IAM still matters for agent authentication, attribution, and entitlement control. |
| Recommendation — Bind each agent to a managed identity and enforce least-privilege access. | ||
| CIS Controls v8 | 5 — Account Management | Agent accounts need lifecycle control, ownership, and timely revocation. |
| Recommendation — Inventory agent accounts and revoke unused or over-privileged access promptly. | ||
Practitioner Guidance
What to prioritise: Separate identity ownership from action authorisation in your operating model. Identity teams should own lifecycle, attribution, and entitlements; platform or AI governance teams should own the runtime policy that constrains agent actions.
Decision rule: If an agent can cause financial, legal, or customer-impacting change, do not treat IAM review as the final control. Require an additional enforcement point that can evaluate the live request context before the action executes.
What to verify: Confirm that every privileged agent has a named business owner, a defined purpose, short-lived or tightly scoped access, and an auditable path for each high-impact action. If any of those elements is missing, the governance model is incomplete.
Practitioner takeaway: Insurers should treat AI agent governance as identity-governed but runtime-enforced; the control failure to avoid is assuming that a valid principal is automatically a safe actor.
