Notifications
Clear all
Topic starter
14/07/2026 4:20 pm
TL;DR: AI agent deployments should each have a distinct directory identity, named owner, narrow purpose, and short-lived credentials, according to Identra.ai, with controls such as allowlists, egress policy, sandboxing, approval gates, and behavioural baselining used to constrain and detect misuse. The central assumption is that agents cannot be governed safely through borrowed accounts or broad, static privilege.
NHIMG editorial — based on content published by Identra.ai: Securing AI Agent Identities: A Practical Guide
Questions worth separating out
Q: How should security teams govern AI coding tools that create non-human identities?
A: Teams should treat every AI coding tool that can authenticate or call systems as a non-human identity with an owner, a scope, and a lifecycle.
Q: Why do shared service accounts create risk for AI agents?
A: Shared service accounts hide which agent made a request, so they collapse accountability and make incident response slower.
Q: What breaks when AI tools are exposed through loosely governed MCP servers?
A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight.
Practitioner guidance
- Assign every agent deployment a distinct directory identity Record one named human owner, one narrow purpose statement, and one retirement path for each deployed agent.
- Downscope authority at each delegation hop Require one audience per token, enforce RFC 8693-style token exchange profiles, and block token passthrough at MCP servers so downstream tools never inherit unrelated privilege.
- Separate environments by identity, not by policy alone Give development and production different agent identities, keep dev agents on synthetic or masked data, and treat any cross-environment grant as a finding until it is explicitly approved.
What's in the full article
Identra.ai's full guide covers the operational detail this post intentionally leaves for the source:
- A step-by-step identity pattern for deployment-level agents, including owner fields, purpose scoping, and retirement handling.
- Practical guidance on token exchange, audience restriction, and MCP authorization boundaries for delegated execution.
- A rollout model for inventorying agents, setting review cadence, and managing shadow-agent discovery across the fleet.
- Control examples for approval gates, sandboxing, egress restrictions, and behavioural baselines in live agent environments.
👉 Read Identra.ai's guide to securing AI agent identities →
AI agent identities: are your controls keeping up at runtime?
Explore further
14/07/2026 4:28 pm
Borrowed identity is the original design failure in AI agent governance. The guide is right to treat shared human accounts and generic service accounts as anti-patterns, because both erase the boundary between operator and executor. That boundary is the basis for attribution, selective revocation, and purpose-bound access in IAM and NHI programmes. Practitioners should stop asking whether an agent can be made convenient to deploy and start asking whether it can be named, owned, and retired without collateral damage.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which is why orphaned machine access persists long after ownership changes.
A question worth separating out:
Q: How do organizations prove AI agent controls are actually working?
A: Organizations prove control effectiveness by showing which agents accessed which data, what actions they executed, and whether those actions stayed within approved task boundaries. Useful evidence includes logs, policy decisions, anomaly alerts, and review records. Without that chain, governance is mostly declarative.
👉 Read our full editorial: Securing AI agent identities requires narrow delegation and runtime control
