Notifications
Clear all
Topic starter
04/06/2026 6:43 pm
TL;DR: AI agents are creating a new access layer that reasons, chooses tools, and acts in production, which makes deterministic NHIM controls incomplete for agent governance, according to Oasis Security. The central issue is that intent, tool choice, and execution now happen inside the session, so access review assumptions and static privilege models no longer hold.
NHIMG editorial — based on content published by Oasis Security: What is Agentic Access Management?
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern AI agent access without creating standing privilege?
A: Use session-scoped access, deterministic policy checks, and automatic teardown so the agent never needs a persistent credential to work.
Q: Why do AI agents complicate existing IAM and PAM controls?
A: They complicate those controls because the access request is no longer fully knowable before execution.
Q: What do security teams get wrong about agentic access logging?
A: They often log tool calls without preserving the causal chain that explains why the agent acted.
Practitioner guidance
- Define the agent session as the control boundary Treat each AI agent session as the unit for authorisation, logging, and teardown, rather than relying on a persistent identity record that outlives the task.
- Separate prompt intent from tool permission Review which tasks are authorised because the prompt is allowed and which are authorised because the tool is safe.
- Replace standing agent secrets with ephemeral sessions Use short-lived access with automatic teardown for repeatable agent tasks, especially where the same agent can invoke multiple systems in one workflow.
What's in the full article
Oasis Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The article's three-step access translation model for turning agent intent into IAM controls.
- The vendor's session lifecycle framing for JIT identities, including teardown and audit sequencing.
- The practical discovery, ownership, and posture questions the vendor says teams should answer in a live tenant review.
- How the vendor maps agentic access patterns across Azure AI Foundry, Bedrock, Vertex AI, and SaaS ecosystems.
👉 Read Oasis Security's blog on agentic access management and AI agent identity →
Agentic access management: what it means for IAM teams?
Explore further
04/06/2026 6:53 pm
Agentic access management is an identity problem, not just an AI control problem. The article correctly frames agents as a new access layer because they sit between human intent and machine execution. That means identity governance must follow the session, the prompt, and the delegated action path, not only the underlying workload credential. Practitioners should treat agent governance as an extension of identity security, not an AI-sidecar.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: Who is accountable when an AI agent exceeds its intended scope?
A: Accountability should follow the delegation chain, not stop at the agent label. The human requester, the policy owner, and the team that granted underlying access all matter, because the agent acts within a permission model someone designed. If the chain is unclear, the governance model is already too weak.
👉 Read our full editorial: Agentic access management reframes identity governance for AI agents
