Why do AI agents create trust problems for consumer IAM programmes?

Why This Matters for Security Teams

Consumer IAM programmes are built to answer a human-centric question: who signed in, what did they approve, and did the session look legitimate? AI agents break that model because they can request actions, chain tools, and continue operating after the user has left the session. The result is not just more authentication events, but a shift in trust from login assurance to runtime authorisation, consent scope, and traceability.

This is why current guidance increasingly points to agent-specific governance rather than broader identity hardening alone. The OWASP Agentic AI Top 10 and NIST’s NIST AI Risk Management Framework both reflect the same practical issue: trust must follow the action, not just the identity. NHIMG’s AI Agents: The New Attack Surface report shows why this matters in the real world, with 80% of organisations reporting agents have already acted beyond intended scope.

In practice, many security teams discover the gap only after a consumer-facing agent has already accessed data or performed an irreversible action, rather than through intentional design.

How It Works in Practice

Consumer IAM must evolve from a session-centric model to a task-centric one. Instead of assuming that a user’s authenticated session should inherit broad and persistent authority, security teams should evaluate each agent action at runtime. That means separating human intent from machine execution, then binding the agent to a narrow, auditable purpose. Best practice is still evolving, but current guidance suggests using policy-as-code, consent capture, and short-lived credentials to constrain what an agent can do after it is launched.

Operationally, that often means:

• issuing just-in-time credentials only for a specific task, with short TTLs and automatic revocation
• using workload identity for the agent itself, rather than treating it as an extension of the human user
• evaluating policy in real time, so authorisation depends on context, data sensitivity, and requested action
• logging both the user consent event and the downstream tool calls for auditability

Frameworks such as the CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework both reinforce the need for governance that is continuous, contextual, and observable. NHIMG’s OWASP NHI Top 10 also highlights why static entitlements fail when agents can pivot across tools and data boundaries in ways humans do not predict.

These controls tend to break down when consumer products reuse a single long-lived session or token across multiple autonomous actions, because the system can no longer prove which step was actually authorised.

Common Variations and Edge Cases

Tighter agent controls often increase friction for consumer experiences, requiring organisations to balance user convenience against the need for scoped, revocable authority. That tradeoff is especially sharp when an agent is allowed to act on behalf of a person across multiple apps, because every added approval step can reduce usability while every removed step can weaken trust.

There is no universal standard for this yet. Some environments can tolerate a “recommend only” model, where the agent drafts actions but never executes them. Others need delegated execution for customer support, scheduling, or commerce workflows, but should still enforce per-action consent and clear rollback paths. The hard cases are shared sessions, family accounts, and high-risk consumer domains such as finance or healthcare, where one person’s intent can affect another person’s data or funds.

NHIMG’s The State of Secrets in AppSec is also relevant here because consumer agents frequently expose credentials, tokens, or API keys when trust boundaries are too loose. Where agents may access secrets, current guidance suggests pairing runtime policy with secret minimisation and aggressive rotation, rather than assuming login controls alone are sufficient.

When consumer IAM cannot distinguish recommendation from execution, trust problems surface fastest in delegated workflows, shared accounts, and any environment where the agent can persist beyond the original user intent.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents create more IAM risk than ordinary developer tools?
• Why do AI agents create new risk in non-human identity management?
• Why do AI agents create more risk when they reuse existing credentials?