How should security teams handle authentication when users, digital IDs, and AI agents share the same trust model?

Security teams should separate identity proof, session trust, and action authorisation. Digital IDs may satisfy initial verification, but the application still needs step-up controls and transaction-level review for sensitive actions. When AI agents are involved, delegation must be explicit, revocable, and auditable so the human principal does not become an unmonitored blanket trust anchor.

Why This Matters for Security Teams

When users, digital IDs, and AI agents are treated as if they belong to one trust model, authentication stops being a simple login problem and becomes a delegation problem. A valid identity proof only tells the system who or what was verified at entry; it does not justify every later action, especially when an AI agent can chain tools, move quickly, and act outside human timing. Current guidance from NIST AI Risk Management Framework and OWASP Agentic AI Top 10 both point toward context-aware control, not blanket trust.

NHIMG research shows how quickly exposed credentials are abused in the wild: in the LLMjacking analysis, attackers attempted access to publicly exposed AWS credentials in an average of 17 minutes. That kind of speed matters because shared trust models often leave sessions, API keys, and delegated access far broader than intended. In practice, many security teams encounter abuse only after an agent has already made an irreversible tool call, rather than through intentional delegation design.

How It Works in Practice

The safer pattern is to separate three things: identity proof, session trust, and action authorisation. A digital ID or SSO login can establish a human principal, but sensitive actions should still require step-up verification, transaction-level checks, or policy evaluation at request time. For AI agents, the identity primitive should be workload identity, not a human session copied into automation. That means the agent proves what it is through cryptographic workload identity, then receives only the minimum credentials needed for a single task.

In practice, this is where just-in-time access matters. Short-lived tokens, ephemeral secrets, and explicit delegation boundaries limit what an agent can do if it is compromised or misdirected. Standards and implementation guidance increasingly favor runtime policy checks through policy-as-code, for example with OPA or Cedar, because pre-defined role bundles cannot anticipate every tool chain or goal change. A useful reference point is CSA MAESTRO agentic AI threat modeling framework, which aligns well with runtime control design, and NHIMG’s Ultimate Guide to NHIs, which frames why non-human access should be governed as a distinct security class.

• Use a verified human identity only for the initial approval, not as a perpetual authorisation grant.
• Issue agent-specific, short-lived credentials per task, then revoke them automatically on completion.
• Log every delegated action with the principal, the agent, the context, and the policy decision.
• Apply step-up or re-authentication for high-risk actions such as spending, deletion, export, or privilege changes.

These controls tend to break down when agents are allowed to reuse a user’s long-lived session across multiple tools, because the system loses the ability to distinguish delegation from impersonation.

Common Variations and Edge Cases

Tighter delegation controls often increase operational overhead, requiring organisations to balance user convenience against revocation speed and auditability. There is no universal standard for this yet, so current guidance suggests choosing controls based on the action risk rather than the account type alone. A low-risk read-only assistant can tolerate broader session scope than an agent that can approve payments, delete records, or trigger downstream automation.

One common edge case is shared operational consoles where humans and agents both act inside the same workflow. In those environments, the trust boundary must be explicit: the human may approve the action, but the agent should still operate under its own workload identity and scoped permissions. Another edge case is federated environments with multiple identity providers, where token translation can accidentally widen access if delegation claims are not preserved. NHIMG’s CoPhish OAuth Token Theft via Copilot Studio illustrates how quickly token-based trust can be abused when the chain of authority is unclear, and the OWASP NHI Top 10 reinforces the need for revocation, scoping, and runtime oversight. Where agents can self-replan or call external tools dynamically, static role mappings become too coarse to be reliable.

Related resources from NHI Mgmt Group

• How should security teams manage permissions for AI agents?
• How should security teams govern AI agents that use OAuth access?
• How should security teams limit the risk from AI agents that have access to production systems?
• How should security teams govern AI agents that can access enterprise systems?