1Password and Apono reset access governance for humans, machines, and agents

At a glance

What this is: 1Password’s acquisition of Apono extends identity security into runtime access governance for humans, machines, and AI agents, with just-in-time access, intent-based policy enforcement, and automatic revocation.

Why it matters: It matters because IAM, NHI, and agentic AI programmes are converging on the same control problem: who or what can access which system, under what intent, and for how long.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read 1Password's acquisition analysis for Apono and Unified Access

Context

Access governance is the control layer that decides what an identity can do after authentication, and that layer has become the real pressure point for NHI and AI agent programmes. 1Password’s move is a signal that credential security alone no longer contains the risk when machines and agents can act inside production environments.

The governance gap is not just about securing secrets, but about constraining runtime access by task, intent, and duration. That matters across human, machine, and agent identities because standing privilege creates a larger blast radius than the original credential exposure suggests.

Key questions

Q: How should organisations govern access for AI agents that operate in production systems?

A: Treat agent access as runtime governance, not as a one-time entitlement. Require task intent, scope, duration, and delegated authority to be checked at execution time, then log the resulting actions in a single audit trail. If the agent can change tools or expand scope mid-session, the control must be able to narrow or revoke access immediately.

Q: Why do standing privileges create more risk for NHIs and AI agents than for humans?

A: Standing privileges give non-human identities a larger uninterrupted window to move laterally, access sensitive systems, or reuse credentials after the original task is complete. Unlike human workflows, machine and agent activity can scale quickly and repeat without fatigue, which makes persistent access a structural exposure rather than a convenience.

Q: What breaks when credential security is treated as the same thing as access governance?

A: Teams end up protecting the secret while leaving the action unconstrained. A valid credential can still be used too broadly, for too long, or in the wrong context, so the programme sees the secret as safe while the access path remains overpowered. That gap is where most runtime exposure lives.

Q: Who is accountable when a delegated AI agent accesses the wrong system?

A: Accountability should follow the delegation chain, the policy that authorised the access, and the task context that justified it. If those three are not recorded together, responsibility becomes ambiguous and incident review turns into log archaeology. Governance should make it clear which human sponsor, policy owner, and control point approved the action.

How it works in practice

Just-in-time access changes the permission model, not just the delivery model

Just-in-time access governance grants permissions at the moment of need and removes them when the task ends. Technically, that shifts the control point from static entitlements to runtime policy evaluation, often against cloud IAM, Kubernetes, SaaS, or data platform permissions. The important distinction is that JIT is not only about reducing token lifetime. It also reduces the period during which privilege can be abused, observed, or inherited by downstream sessions. For identity teams, that turns access from a persistent state into an auditable event.

Practical implication: measure whether your highest-risk permissions are still standing by default, because time-bound access is the control that changes exposure.

Intent-based access control adds a second authorisation check for AI agents

Intent-based access control evaluates whether an agent’s actual actions remain aligned with the declared task intent. That is materially different from traditional IAM, which assumes the request itself is the key boundary. For AI agents, the risk is scope drift after access is granted: the agent may chain tools, expand context, or take actions that were never part of the original approval. A runtime comparison between declared intent and observed behaviour gives security teams a way to narrow or revoke access when execution diverges from policy.

Practical implication: define how intent is expressed, logged, and monitored before granting agents access to sensitive production paths.

Credential brokers separate secret custody from system permission

A credential broker protects the secret in one system and releases a verified credential only when a trusted requester needs it. That architecture matters because credential storage and privilege enforcement solve different problems. Storage controls reduce secret exposure, but they do not limit what a valid identity can do once authenticated. Access governance closes that gap by deciding whether the identity should receive access at all, and under what conditions. In practice, the strongest programmes treat secrets, federation, and runtime authorisation as separate but linked layers.

Practical implication: map which controls protect the credential versus which controls constrain the action, then close the gap between the two.

NHI Mgmt Group analysis

Standing access is the quiet liability in modern identity programmes: it assumes permissions can be granted once and safely left in place until review. That assumption was built for slower human-paced administration, not for systems where machines and agents act continuously inside production. The implication is that governance has to shift from static entitlement ownership to runtime control of access duration and context.

Runtime access governance is now the missing middle between secrets management and IAM: credential protection alone does not answer what an identity can do after it authenticates. This acquisition signals that the market is converging on the control plane where permission is evaluated at execution time, not just at login or secret issuance. Practitioners should treat that as a design change, not a product feature.

Zero-standing privilege is becoming a baseline expectation for non-human identities: the combination of AI agents, cloud workloads, and delegated third-party access makes persistent access increasingly hard to justify. The governance model now needs to prove why a privilege should exist at all, rather than explaining after the fact why it was still there. That changes access review from clean-up activity to control failure detection.

Identity governance for AI agents is not just NHI with a new label: autonomous or semi-autonomous execution introduces decision timing, tool chaining, and scope drift that traditional entitlement models were not designed to inspect. When the actor can select actions at runtime, governance must account for behaviour as well as permission. The practitioner conclusion is that agentic access cannot be managed as a simple extension of service account policy.

Task-bound attribution becomes the new accountability floor: the value of unified audit trails is not volume, but the ability to tie a specific action back to a specific task, delegate, and approval context. Without that chain, AI agent governance collapses into after-the-fact log collection. The field needs stronger linkage between intent, access, and execution if it wants to keep autonomous systems governable.

From our research:

• 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Only 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to the same report.
• That confidence gap is why runtime governance now matters as much as credential storage, which is explored further in Ultimate Guide to NHIs: Lifecycle Processes for Managing NHIs.

What this signals

Identity teams should expect access governance to become the primary control plane for AI programmes. As agents, workloads, and delegated identities spread across production systems, the practical question stops being whether a secret is protected and becomes whether access is justified at runtime. Programmes that still separate credential security from authorisation will find the gap widening fastest in cloud and SaaS environments.

Task-bound access will increasingly define what mature NHI governance looks like. The organisations that can express intent, duration, and revocation cleanly will be better placed to manage human, machine, and agent identities together. That is also where audit, compliance, and incident response converge, because the right control is the one that can explain why an action was allowed in the first place.

Standing privilege is becoming the governance debt that identity teams will be asked to pay down. When access is created at request time and torn down afterward, the security model shifts from cleanup to prevention. Teams that want to keep pace should review privileged access design alongside Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.

For practitioners

• Inventory standing privilege across humans, machines, and agents Identify which production permissions remain active by default, then separate persistent access from task-bound access in your access catalogue. Prioritise cloud IAM, Kubernetes, data platforms, and SaaS systems where over-provisioning creates the largest blast radius.
• Define runtime policy for delegated and agentic access Require access decisions to evaluate task intent, target system, and duration at the moment of use. For AI agents, record the declared purpose and compare it with observed actions so you can narrow or revoke access when behaviour drifts.
• Split secret custody from authorisation control Keep credential storage, brokered release, and privilege enforcement as separate controls in your operating model. A protected secret is not the same thing as a justified action, so review where your process still assumes they are equivalent.
• Audit third-party and delegated access offboarding Track when external relationships end, when delegated tasks complete, and when temporary access should be removed. Use the same offboarding discipline for contractors, service accounts, and AI agents that act on behalf of internal users.
• Make audit trails task-specific, not just identity-specific Ensure approvals, grants, revocations, and executed actions land in one trail with enough context to reconstruct why access existed. If the record cannot explain the task, the approver, and the resulting action, it is not sufficient for governance.

Key takeaways

• The core issue is no longer just secret exposure, but uncontrolled runtime access across human, machine, and AI identities.
• The evidence points to a governance gap at the point of action, where access is granted, used, and revoked inside production systems.
• Teams should separate secret custody from authorisation, then move high-risk permissions to task-bound, auditable access.

Key terms

• Just-in-time access: Just-in-time access is a permission model that grants access only when a task needs it and removes it when the task is complete. In identity governance, it reduces standing privilege and shortens the window in which a credential, role, or session can be abused.
• Standing privilege: Standing privilege is access that remains available beyond the immediate need for it. For humans, machines, and AI agents, it creates persistent exposure because the identity can reach sensitive systems without a fresh approval or task-specific justification each time.
• Intent-based access control: Intent-based access control is a runtime authorisation approach that compares what an identity says it will do with what it actually tries to do. It is especially relevant for AI agents because behaviour can drift after access is granted, so policy must follow action, not just request.
• Credential broker: A credential broker is a control layer that releases approved credentials or federated access only to a verified requester at the moment of need. It separates secret custody from direct application access, which helps reduce copied credentials in repositories, apps, and pipelines.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by 1Password: 1Password acquires Apono and extends Unified Access for humans, machines, and AI agents. Read the original.