How should security teams structure identity security programmes so they can add machine and agent identities without creating procurement bottlenecks?

Why This Matters for Security Teams

Identity programmes break down when every new service account, workload token, or AI agent has to be justified as a separate commercial exception. That creates a procurement gate in front of a security problem, which slows onboarding and encourages teams to work around controls. NHI risk is already material: NHI Mgmt Group’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, while 96% of organisations store secrets outside secrets managers in vulnerable locations.

The operational issue is not just volume. Machine and agent identities behave differently from employees, so a human-centric IAM catalogue does not scale cleanly. Security teams need a programme that separates governance from purchasing, so baseline controls can be applied consistently while commercial terms stay flexible. That means central policy, reusable onboarding patterns, and a model that can absorb new workloads without a fresh vendor review every time. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward context-aware controls, not static entitlement sprawl. In practice, many security teams encounter procurement friction only after developers have already created shadow service accounts and orphaned agent credentials.

How It Works in Practice

A scalable identity security programme starts with a tiered model. The first tier covers low-risk machine identities such as internal service accounts and batch jobs. The second covers secrets-bearing workloads that touch sensitive data or production systems. The third covers autonomous agents that can chain tools, call APIs, and make runtime decisions. This structure lets security define control requirements once, then apply them by risk and behaviour instead of by vendor contract.

At the control level, the programme should combine central governance with operational flexibility. Policies define what is allowed, while onboarding workflows decide how each identity is provisioned. For machine identities, that usually means short-lived credentials, automated rotation, and workload identity rather than shared static secrets. For agents, current best practice is evolving toward intent-based authorisation, where access is evaluated at request time based on task context, data sensitivity, and execution environment. The CSA MAESTRO agentic AI threat modeling framework and NIST guidance both support this shift from pre-approved access lists to runtime policy decisions.

Operationally, teams should standardise three things:

• Identity classes, so procurement can map products to pre-approved control tiers.
• Provisioning patterns, so each class uses the same issuance, rotation, and revocation workflow.
• Evidence requirements, so security can prove who or what accessed which system, when, and under which policy.

This is where NHIMG research is useful. The Ultimate Guide to NHIs highlights that only 20% of organisations have formal offboarding and revocation processes for API keys, which is exactly the kind of gap a phased model should close. These controls tend to break down in heavily decentralised SaaS environments because identity creation happens faster than central policy enforcement.

Common Variations and Edge Cases

Tighter identity control often increases onboarding overhead, requiring organisations to balance speed against assurance. That tradeoff is real, especially when teams support both legacy automation and newer agentic workflows. There is no universal standard for commercial packaging yet, so some organisations use enterprise-wide identity platforms, while others negotiate reusable terms for all machine identities plus separate rider language for autonomous agents.

The main edge case is an environment where agents are allowed to take actions on behalf of users. In those cases, procurement should not be the primary control point. Runtime policy, logging, and revocation matter more than per-product approval because the risk sits in how the agent behaves, not just what it is called. Another common exception is third-party OAuth access. NHI Mgmt Group research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, so commercial flexibility alone is not enough unless visibility and revocation are built into the programme.

Security teams should also avoid forcing long-lived credential models into AI agent use cases. That creates brittle exceptions, especially where tools are chained or environments are ephemeral. The better pattern is to pre-approve controls, not access outcomes: issuance, TTL, monitoring, and revocation standards are fixed, while the exact buyer, product, or workload can change without reopening procurement. For agentic workloads, the OWASP NHI Top 10 and the Ultimate Guide to NHIs both reinforce that governance needs to stay central even when procurement is decentralised.

Related resources from NHI Mgmt Group

• How should security teams use access behavior to improve identity governance without creating unnecessary removals of valid access?
• How should security teams reduce procurement friction when they need identity security controls quickly in cloud environments?
• How should security teams implement device identity certificates in IoT environments without creating onboarding bottlenecks?
• How should security teams add identity verification to signup flows without creating excessive user friction?