Should teams use one access review process for humans, service accounts, and Bedrock agents?

Yes, but with actor-specific evidence. Humans are reviewed on authentication and role membership, while Bedrock agents must be reviewed on their assumed roles, connected data sources, guardrails, and invocation rights, because those are the controls that define their actual reach.

Why a single review process works, but the evidence must change by actor

A single access review programme can cover humans, service accounts, and Bedrock agents if the review model is actor-aware. The mistake is treating every principal as if role membership alone explains its reach. For non-human access, the meaningful question is not who clicked approve, but what the actor can assume, invoke, or reach at runtime.

That is why access certification works best when it is designed around the control surface for each actor type. Human reviews usually centre on identity proof, role membership, and separation of duties. Service account reviews usually centre on credential scope, ownership, rotation, and privilege. Agent reviews must go further, because the agent’s actual reach often depends on roles, tools, data sources, guardrails, and invocation paths.

Teams that already manage mixed populations can use one process framework, but they should not force one evidence set across all three populations. A review that cannot distinguish assigned access from effective reach will miss the risks that matter most in automation-heavy environments. NHIMG’s IAM and IGA Basics is a useful parent concept for this model because it frames authentication, authorization, entitlements, and access review as separate but connected decisions.

What to review for humans, service accounts, and Bedrock agents

For humans, the review should confirm whether the person still needs the role, whether the role remains properly scoped, and whether any privileged membership has outlived the job function. For service accounts, the review should confirm ownership, where the account is used, whether the credential is still live, and whether the account is overprivileged for the systems it touches. NHIMG’s Service Account Security Guide is directly relevant here because service-account review depends on lifecycle, least privilege, and governance, not just on login presence.

For Bedrock agents, the review has to include the assumed role or execution identity, the connected data sources, the guardrails that constrain behavior, and the invocation rights that allow the agent to act. That is because the agent’s practical reach may be broader than its nominal role if it can call tools, read sensitive sources, or chain actions across systems. NHIMG’s Human vs Non-Human Identity helps explain why non-human access needs a different evidence set even when the approval workflow looks similar.

For teams with AWS Bedrock deployments, the review should also check whether an agent’s access model is tied to short-lived, tightly scoped permissions or to standing access that quietly expands over time. NHIMG’s Cloud Workload Identity Guide is a good adjacent reference because it shows how workload identities depend on temporary credentials, trust policies, and keyless design choices.

Where one process breaks down in practice

The failure mode is usually not the review cadence, but the review criteria. If a team asks the same checkbox questions for all actors, it can end up recertifying a service account or agent because “the owner approved it” while missing the fact that the actor has retained access to production data, cross-environment systems, or sensitive toolchains. For agents, the bigger issue is that the access path can be indirect: the model may not hold the data itself, but the tools and roles it can invoke still define the blast radius.

There is also a lifecycle problem. Human access changes with hiring, transfers, and departures. Service accounts and Bedrock agents change with system design, integrations, prompts, policies, and upstream data connections. If reviews do not track those dependencies, the organisation can keep approving access that no longer matches the current architecture. NHIMG’s NHI Lifecycle Management Guide is useful because it treats access review as part of ongoing lifecycle governance, not a one-time attestation exercise.

Where agentic access is involved, the control question becomes whether the review can prove what the agent is actually allowed to do, not just what it was originally configured to do. That distinction matters when guardrails, prompts, data sources, or assumed roles change faster than the review cycle. If those changes are not captured, the review becomes documentary rather than operational.

Practitioner Guidance

What to verify: Use one review workflow, but require different evidence by actor class. Humans should be reviewed on role membership and current business need; service accounts on owner, credential status, and privilege; Bedrock agents on assumed role, connected data sources, guardrails, and invocation rights.

Decision rule: If an actor can reach production data or execute actions indirectly through another system, review the effective reach, not just the named permission set. If you cannot describe that reach in one sentence, the review is too shallow to trust.

What good looks like: A reviewer can tell, from the evidence pack alone, why the actor still exists, what it can access, who owns it, and which control would need to change if that access were no longer justified.

Practitioner takeaway: One process is fine, but one evidence model is not. The more autonomous or indirect the access path, the more the review must focus on runtime reach rather than static approval history.

Related resources from NHI Mgmt Group

• How should security teams govern Active Directory service accounts?
• Should organisations use JIT access for service accounts and AI agents?
• How should security teams govern AI agents that use service accounts and MCP tools?
• Should healthcare teams use the same zero trust model for AI agents and service accounts?