NHI vs OBO: When Each Pattern Fits

Two ways for agents to have identity. Both have a place.

Every agent in your environment is doing one of two things: acting as itself, or acting as a user. Most teams pick one and force-fit everything into it. The right answer is usually both, applied deliberately.

Pattern 1: Non-Human Identity (NHI)

The agent has its own identity. Its own credentials. Its own permissions, audited and managed like any other identity in your IAM system.

When NHI is the right call

• The agent is doing system-level work that no specific user requested
• Background jobs, scheduled tasks, infrastructure operations
• Multi-tenant orchestration where no single user owns the action
• You need a clean audit trail that says this agent did this, on its own

Pattern 2: On-Behalf-Of (OBO)

The agent acts in the context of a specific user. The user identity, permissions, and constraints flow through the agent. Whatever the user could see or do, the agent can see or do, on the user behalf, with the user accountability.

When OBO is the right call

• The agent is responding to a user request in real time
• Customer-facing copilots, assistants, and chatbots
• Anywhere a human triggered the action and would be accountable for it
• When data filtering must respect the user row-level access

The mistake most teams make

Picking one pattern and applying it everywhere. NHI-only means agents see more than the requesting user should, a confidentiality breach waiting to happen. OBO-only means background and system actions get attributed to whatever user happened to trigger them last, an audit nightmare.

How they coexist

A well-designed agent uses both, deliberately:

• The agent has an NHI for its lifecycle, ownership, and base capabilities
• When acting on a user request, it switches to OBO mode and inherits user context
• Authorization decisions consider both the agent identity and the user context
• Audit logs capture both: agent X acted on behalf of user Y