Why do AI agents and other non-human identities complicate trust assumptions in enterprise environments?

AI agents and other non-human identities complicate trust because they act at machine speed, may operate across multiple systems, and can request or perform actions without a human present at every step. That creates new questions around ownership, authorization, lifecycle control, and monitoring. Organisations need to treat agents as governed identities, not just automation, to avoid blind trust and privilege creep.

Why This Matters for Security Teams

AI agents and other non-human identities complicate trust because they collapse the old boundary between software that executes a fixed workflow and software that can decide what to do next. Once an agent can chain tools, request new permissions, or move across systems without a human in the loop, static assumptions about “safe” automation stop holding. That is why current guidance increasingly treats agentic workloads as a separate risk class, as reflected in the OWASP Agentic AI Top 10 and NHI research such as OWASP NHI Top 10.

The practical issue is not just access. It is ownership, scope, revocation, and auditability when the identity is autonomous or semi-autonomous. Organisations often grant an agent broad API access to make it useful, then discover later that the same identity can read more data than intended, trigger destructive actions, or expose secrets. NHIMG’s AI Agents: The New Attack Surface report notes that 80% of organisations report agent actions beyond intended scope, which shows how quickly trust can outrun controls.

In practice, many security teams encounter privilege creep only after an agent has already chained tools or accessed data outside its original mandate, rather than through intentional design.

How It Works in Practice

For autonomous workloads, the identity question shifts from “who signed in?” to “what is this workload allowed to do right now, in this context?” That is why static RBAC alone is usually too coarse. A better pattern is workload identity plus runtime authorisation: issue a cryptographic identity to the agent, bind it to a task, and evaluate permissions at request time based on task, risk, data sensitivity, and environment. Standards and research from NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework both point toward this more contextual model.

In practice, security teams should treat the agent like a workload, not a user. That means:

• Use workload identity such as SPIFFE or OIDC-backed tokens to prove what the agent is.
• Issue just-in-time, short-lived credentials for a specific task, then revoke them automatically.
• Keep secrets ephemeral and narrowly scoped, because long-lived tokens are harder to govern when actions are machine-speed.
• Evaluate policy at runtime with policy-as-code, such as OPA or Cedar, so access reflects current context rather than a stale approval.
• Log tool calls, data access, and downstream actions so the agent’s behaviour can be reconstructed after the fact.

NHIMG incident research also shows why this matters operationally. In cases such as the CoPhish OAuth Token Theft via Copilot Studio analysis and the Gemini AI Breach — Google Calendar Prompt Injection, the problem was not a stolen password in the traditional sense. The problem was an identity that could be induced, redirected, or overextended at runtime.

These controls tend to break down in deeply integrated environments where agents inherit broad service accounts, legacy APIs lack fine-grained policy hooks, or tool chains execute faster than monitoring and revocation can keep up.

Common Variations and Edge Cases

Tighter runtime authorisation often increases operational overhead, requiring organisations to balance agent flexibility against policy complexity and monitoring cost. That tradeoff becomes more visible when agents must complete multi-step tasks across SaaS platforms, internal APIs, and data stores. Current guidance suggests that there is no universal standard for this yet, so security teams should adopt the most conservative pattern that preserves business function rather than assuming one identity model fits every workflow.

One common edge case is the difference between a narrow task agent and a broad orchestrator. A task agent may only need a short-lived token for one API call, while an orchestrator may need delegated authority across multiple systems. Another is human-in-the-loop approval: adding a checkpoint helps, but it does not remove the need for ephemeral credentials or post-action audit. In highly regulated environments, the Ultimate Guide to NHIs — 2025 Outlook and Predictions is useful context for how lifecycle control, secret hygiene, and ownership expectations are converging.

Industry consensus is still forming on whether agents should be managed primarily as identities, applications, or policy-bound workflows. The practical answer is usually all three: an identity for authentication, an application for secure execution, and a workflow for governance. As a result, trust assumptions should be reviewed whenever an agent gains a new tool, new data source, or new ability to act without a person present.

Related resources from NHI Mgmt Group

• Why do AI agents make non-human identity governance harder?
• Why do AI agents create new risk in non-human identity management?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents increase non-human identity risk?