1Password’s AWS Security Competency raises NHI governance stakes

At a glance

What this is: 1Password’s AWS Security Competency recognition for Infrastructure Protection highlights the growing expectation that identity security must cover human, machine, and AI agent access in cloud environments.

Why it matters: For IAM teams, this is a reminder that AWS programmes now need continuous access governance, secrets control, and audit-ready identity visibility across NHI and emerging agentic workflows.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read 1Password’s AWS Security Competency announcement for identity security context

Context

AWS identity security now has to account for more than human logins. As SaaS, automation, and AI systems take on more operational responsibility, the real issue is whether organisations can govern access continuously across service accounts, credentials, and agent-driven workflows rather than only at sign-in.

That gap matters because cloud programmes often separate identity, access, and workload controls even when the same privileged paths are shared. For teams building on AWS, the question is whether identity governance can keep pace with software that acts on behalf of users, systems, and increasingly AI agents.

The 1Password announcement is best read as a market signal about where identity security expectations are moving. The starting position is typical for modern enterprises, where cloud scale and mixed identity types have outgrown point-in-time access models.

Key questions

Q: How should security teams govern non-human identities in AWS environments?

A: Treat every service account, token, and API key as a governed identity with an owner, purpose, review cycle, and revocation path. In AWS environments, that means connecting discovery to lifecycle control so credentials are not only found but also rotated, audited, and removed when the use case changes. The goal is accountability, not just visibility.

Q: Why do AWS cloud environments increase NHI governance complexity?

A: AWS environments increase governance complexity because access is distributed across applications, pipelines, integrations, and now AI-assisted workflows. Each layer can introduce long-lived credentials or delegated permissions that outlive the original business need. That makes lifecycle ownership and logging essential for proving that access still matches intent.

Q: What breaks when organisations rely on point-in-time access reviews for cloud identities?

A: Point-in-time reviews miss the period between approval and use, which is where many cloud identity risks accumulate. A credential can be valid, over-privileged, or broadly reusable long before the next certification cycle. If the review model cannot see runtime behaviour, it cannot prove that the access is still justified.

Q: Who is accountable when a cloud credential is misused by an AI workflow?

A: Accountability should rest with the identity owner who approved the access, the team operating the workflow, and the governance process that allowed the credential to remain valid. AI does not remove accountability. It makes the ownership chain easier to inspect, which is why logs, approvals, and lifecycle records must align.

Technical breakdown

Continuous access authorisation in AWS environments

Cloud access is no longer a single authentication event. In AWS environments, identity security increasingly depends on continuous authorisation, meaning access must remain valid, monitored, and revocable as workload conditions change. That is especially relevant when the same environment includes humans, service accounts, APIs, and AI-driven workflows. If identity controls only verify entry but do not track ongoing use, the programme loses visibility into when access becomes excessive, stale, or mis-scoped. This is why infrastructure protection is now as much about runtime identity governance as it is about initial trust establishment.

Practical implication: map cloud access controls to continuous verification rather than one-time login checks.

Why NHI credential discovery and auditability matter

Non-human identities expand much faster than human accounts because each application, pipeline, token, or integration can introduce new credentials. Discovery is the first problem, but auditability is the harder one, because teams need to know who or what used a secret, when, and for what purpose. In practice, service accounts and API keys become invisible governance objects when they sit outside review cycles. That makes entitlement hygiene, lifecycle ownership, and logging inseparable. Without those three, cloud security teams cannot prove that access is still justified.

Practical implication: inventory all non-human credentials and tie each one to an owner, purpose, and review path.

AI agent identity on AWS creates shared governance pressure

AI agents change the operating model because they can trigger tool use, data access, and downstream actions inside business workflows. Even when access is preconfigured, the governance burden shifts to proving what the agent can do, when it can do it, and how those actions are captured. That is not just an AI problem. It is an identity problem because the same control stack must now cover humans, machines, and agents in one cloud boundary. Infrastructure protection therefore depends on whether access policies can describe all three without losing precision.

Practical implication: extend AWS identity policy design to include agent actions, not only human and workload access.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud infrastructure protection is now an NHI governance problem, not a perimeter problem. The AWS Security Competency language matters because modern cloud environments are built on credentials, permissions, and workload trust paths rather than static network boundaries. Once access is distributed across human users, machine identities, and AI-assisted workflows, the control question becomes whether identity governance can still explain every privileged action. Practitioners should treat cloud security and NHI governance as one operating discipline.

Discovery without lifecycle ownership is the real control gap in cloud identity programmes. Organisations can catalogue credentials and still fail to govern them if no one owns rotation, revocation, and review. The deeper issue is not visibility alone but whether every service account, token, and integration has a lifecycle state that can be managed end to end. Practitioners need to close the gap between finding credentials and proving they are still necessary.

Continuous authorisation is the practical line between secure cloud access and stale privilege. In AWS environments, access that is valid at provisioning time can become unsafe once workloads, teams, or agent behaviours change. Static approval models do not capture that drift, especially when software acts faster than human review cycles. Practitioners should re-evaluate whether their current IAM model can detect privilege that remains technically valid but operationally unjustified.

Identity security for AI-enabled cloud work is converging on one control plane. As organisations add AI agents into AWS-based workflows, the same governance layer must describe human intent, machine execution, and agent action scope. That convergence strengthens the case for unified identity security but also exposes how fragmented many programmes still are. Practitioners should expect cloud identity, NHI governance, and agent oversight to be assessed together rather than separately.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, 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.
• That is why the NIST Cybersecurity Framework 2.0 remains relevant for continuous identity governance across cloud and workload access.

What this signals

Continuous cloud identity governance will become the baseline expectation, not a specialist capability. As AWS ecosystems absorb more SaaS, automation, and agent-driven work, teams will be judged on whether they can explain access in motion, not just at rest. The governance gap is no longer isolated to secrets management; it is now embedded in how identity, logging, and policy interact across the cloud stack.

Only 92% of organisations expose NHIs to third parties, raising supply chain concerns, according to Ultimate Guide to NHIs. That level of exposure means cloud programmes should assume delegated access will keep expanding and plan for tighter ownership, review, and removal workflows.

Identity security and cloud platform assurance are converging. The market signal here is that practitioners will increasingly compare identity tooling on whether it can support AWS-scale governance across humans, workloads, and AI agents without fragmenting control. Programmes that keep these domains separate will find audit, remediation, and accountability harder to defend.

For practitioners

• Build a single inventory for cloud and non-human identities Track service accounts, API keys, tokens, certificates, and agent identities in one ownership model so review, rotation, and revocation are not separated across teams.
• Tie every AWS credential to a named lifecycle owner Assign one accountable owner for provisioning, rotation, exception handling, and removal so no credential sits outside an explicit governance path.
• Verify that audit logs capture agent and workload actions Check that access logs show which identity acted, what resource was reached, and whether the action came from a human, workload, or AI agent.
• Review standing access in cloud integrations quarterly Focus on credentials that remain valid after the original use case changes, especially long-lived keys used by pipelines, SaaS connectors, and automation.

Key takeaways

• AWS security competency discussions are increasingly about whether identity governance can span humans, workloads, and AI agents in one cloud model.
• The main control gap is not discovery alone but lifecycle ownership for credentials that outlive their intended use.
• Practitioners should shift from point-in-time access checks to continuous authorisation, logging, and accountable revocation paths.

Key terms

• Non-Human Identity: A non-human identity is any machine or software identity used to authenticate and authorise access, including service accounts, API keys, tokens, certificates, bots, and AI agents. In cloud programmes, these identities often outnumber human users and require lifecycle governance, ownership, and rotation to stay secure.
• Continuous Authorisation: Continuous authorisation is the practice of evaluating access throughout a session or workflow instead of only at sign-in. For cloud and workload identities, it means permissions, context, and runtime behaviour must stay aligned so access can be limited or revoked as soon as the business need changes.
• Lifecycle Ownership: Lifecycle ownership is the assignment of clear accountability for creating, reviewing, rotating, and removing an identity or credential. It matters for service accounts, API keys, and agent credentials because unmanaged identities tend to persist after their original purpose has ended.

Deepen your knowledge

Cloud identity security, NHI lifecycle governance, and continuous authorisation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for AWS environments with mixed human and non-human access, it is worth exploring.

This post draws on content published by 1Password: 1Password becomes AWS Security Competency Partner. Read the original.