How should security teams control AI agents in environments where identities appear and disappear quickly?

Why This Matters for Security Teams

AI agents are not just another workload type. They can appear briefly, inherit permissions from a parent process, chain tool calls, and disappear before an inventory system catches up. That makes identity discovery necessary but insufficient. Security teams need to control the action itself, because the highest-risk event is not that an agent exists, but that it can complete an unapproved database query, cloud change, or shell command.

Current guidance suggests treating these agents as autonomous execution principals, not as stable users. Static IAM and periodic access reviews were built for predictable human patterns, while agentic systems are goal-driven and can vary their path on every run. The practical implication is that policy must move closer to the resource, with runtime checks that evaluate intent, context, and privilege before each action. NHIMG’s research on agentic risk highlights why this matters: the OWASP Agentic Applications Top 10 and the State of Non-Human Identity Security both show how visibility gaps and over-privilege remain common failure points. In practice, many security teams encounter unsafe agent behaviour only after a tool call has already modified data or infrastructure.

How It Works in Practice

The control model should combine workload identity, just-in-time credentialing, and per-request policy evaluation. Instead of issuing long-lived secrets to an agent, issue short-lived credentials bound to a specific task, runtime, or namespace. Workload identity gives cryptographic proof of what the agent is, while policy engines decide what it is allowed to do right now. That distinction matters because an agent can be authorised to exist without being authorised to act broadly.

In practice, teams are moving toward a layered model:

• Use workload identity for the agent runtime, such as SPIFFE-style identities or OIDC-bound tokens.
• Issue ephemeral credentials with tight TTLs and automatic revocation on task completion.
• Enforce policy-as-code at databases, SSH gateways, Kubernetes admission points, cloud control planes, and MCP servers.
• Evaluate request context, including target resource, tool invoked, ticket or workflow state, and whether the action matches the declared task.
• Log every decision so security teams can reconstruct what the agent tried to do, not just what identity it held.

This is consistent with the direction of the OWASP Agentic AI Top 10, the NIST AI Risk Management Framework, and the CSA MAESTRO agentic AI threat modeling framework, all of which emphasize runtime governance over static trust assumptions. NHIMG has also documented how fast-moving AI-enabled access can go wrong in the Moltbook AI agent keys breach, where exposed keys became a high-speed control failure. These controls tend to break down when agents are allowed to spawn child agents with inherited privileges because the approval chain becomes opaque and too fast for manual review.

Common Variations and Edge Cases

Tighter action-level control often increases operational overhead, requiring organisations to balance stronger containment against developer friction and automation latency. That tradeoff is real, especially in environments where agents need many small tool calls to complete a task.

There is no universal standard for this yet, so the right design depends on the environment. In regulated production systems, teams often prefer deny-by-default policies and human approval for high-impact actions. In lower-risk environments, some teams allow broader automation but constrain it with network segmentation, scoped tokens, and mandatory session recording. The important thing is that policy should match the blast radius of the target system, not the convenience of the agent.

Edge cases matter. Multi-agent pipelines may need separate identities for planner, executor, and verifier roles. A code-generation agent may need read access to repositories but no write access to secrets stores. An incident-response agent may need temporary elevation only during an active case. Guidance from MITRE ATLAS adversarial AI threat matrix and NHIMG’s OWASP NHI Top 10 points to the same practical reality: when the agent can change behaviour mid-task, static role assignment alone is not enough. Current guidance suggests treating privilege as disposable, reviewed at runtime, and tightly tied to task context.

Related resources from NHI Mgmt Group

• How should security teams govern machine identity credentials in agentic AI environments?
• 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?