Teams should assign ownership, define review cadence, and include machine identities and AI agents in the same certification logic as human access, but with role-appropriate approvers. If a non-human identity can act on sensitive data, it needs a lifecycle owner and a removal path just like any other privileged account.
Why This Matters for Security Teams
Machine identities and AI agents should not be treated as a side category in access reviews. They can authenticate, call tools, move data, and in some cases make downstream decisions without human intervention. That makes them closer to privileged workloads than simple service accounts. Current guidance suggests reviewing them through the same governance lens as human access, but with different evidence, different approvers, and tighter lifecycle control. The risk is not only excess permission, but autonomous behaviour that expands access in ways the original grant never anticipated. The OWASP NHI Top 10 and OWASP Agentic AI Top 10 both reinforce that identity review is really a control over what an agent can reach, not just what it can log into. NHIMG research also shows why this matters now: in the AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope. In practice, many security teams encounter agent overreach only after a workflow has already touched sensitive systems, rather than through intentional certification design.
How It Works in Practice
A workable access review process starts by classifying each non-human identity by function, sensitivity, and autonomy. A build pipeline bot, an RPA script, and a goal-driven AI agent should not be reviewed on the same template unless the template captures their different risk profiles. Security teams should ask three questions for every item: what is the identity, what can it do, and who is accountable if it does it incorrectly? That is where NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework are useful: they push teams to map risk, ownership, and runtime behaviour instead of assuming a static role is enough.
A practical review workflow often includes:
- Inventory all NHIs, agents, service principals, API keys, and tool credentials in one register.
- Assign a business owner and a technical steward for each identity.
- Review entitlements against actual usage, not only the original request.
- Flag any agent with write access, external tool access, or access to secrets for elevated review.
- Require removal paths for dormant or over-scoped identities.
For agentic systems, access review should also test for JIT credentials, ephemeral secrets, workload identity, and intent-based authorization. That means short-lived tokens, runtime policy checks, and cryptographic workload identity such as SPIFFE or OIDC-style proof of identity instead of long-lived static secrets. The design goal is to let an agent receive only the minimum access needed for the current task, then revoke it automatically when the task ends. That approach is consistent with the concerns raised in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the broader threat patterns in the MITRE ATLAS adversarial AI threat matrix. These controls tend to break down when agents are chained across multiple SaaS tools because the approval model loses visibility into each handoff.
Common Variations and Edge Cases
Tighter access review often increases operational overhead, requiring organisations to balance faster automation against stronger governance. That tradeoff becomes sharper when agents are embedded in production workflows, because every review delay can affect delivery or customer service. Best practice is evolving here, and there is no universal standard for whether human approvers, data owners, or system owners should sign off on every agent entitlement. In high-risk environments, a mixed model is common: operational owners approve low-risk access, while security or risk teams approve sensitive scopes, write actions, and any access to credentials or regulated data. The OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both support this principle of risk-based control selection rather than one-size-fits-all certification.
Edge cases matter. An agent that only reads data may still become a problem if it can infer secrets, chain prompts into tools, or pass data into another model. A service account may look harmless until it is reused by multiple agents, which makes attribution and revocation difficult. Human reviewers also tend to over-trust “read-only” labels when the agent can export, summarize, or transform data into a new risk surface. That is why reviews should include tool access, downstream integrations, and secret exposure, not just directory entitlements. The lesson from NHIMG research is clear: the control failure is usually not the login itself, but the invisible path from identity to action. In mixed human and agentic environments, review criteria should be explicit, evidence-based, and short-lived by default, especially when the identity can act on sensitive data through delegated tools.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent autonomy and tool access are central to access review scope. |
| CSA MAESTRO | GOV-1 | MAESTRO emphasizes governance, ownership, and runtime controls for agents. |
| NIST AI RMF | AI RMF GOVERN supports accountability for autonomous identity decisions. |
Use AI RMF governance to document owners, risk decisions, and review cadence for each agent.
