TL;DR: AI agent sprawl makes static IAM brittle because administrators cannot scale human approval to every call, and Andromeda Security argues that behavioral baselines at the AI Gateway can distinguish routine access from risky deviation. The core issue is that policy assumes stable intent, while agents change context across tools, resources, and time.
At a glance
What this is: This is an analysis of why approval-heavy IAM breaks down for AI agents and why behavior baselines at the gateway become the control point for standing access decisions.
Why it matters: It matters because IAM, IGA, and PAM teams need a way to govern agentic access without turning every request into manual review or silently expanding privilege.
By the numbers:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
- Only 5.7% of organisations have full visibility into their service accounts.
👉 Read Andromeda Security's analysis of approval fatigue and AI agent baselines
Context
AI agent governance is not just about authentication, it is about deciding when access should remain standing and when it should re-enter review. The problem is that traditional IAM assumes stable users, predictable intent, and policies that can be fixed in advance, while agentic systems can span multiple tools, resources, and execution moments in one workflow.
That gap is why behavior baselines have become central to agent identity control. They try to define normal activity by tool, resource, timing, and acting context, which is closer to how real operational risk shows up. For teams building this capability, the Ultimate Guide to NHIs is the clearest baseline reference for lifecycle, visibility, rotation, and Zero Trust patterns.
Key questions
Q: How should security teams govern AI agents without creating approval fatigue?
A: Security teams should govern AI agents with behavioural baselines that learn normal activity and only escalate material deviations. The goal is to avoid reviewing every call while still catching risky changes in resource, timing, or entitlement context. That approach reduces noise, preserves velocity, and keeps human approval focused on exceptions that actually change risk.
Q: Why do AI agents make static IAM policies brittle?
A: AI agents make static IAM brittle because access patterns are no longer stable enough to predict in advance. One user can generate many short-lived agents that span multiple systems and change what they touch from task to task. Policies can define allowed actions, but they cannot reliably infer whether a specific request is ordinary or abnormal.
Q: What breaks when behavioural baselines ignore the resource being accessed?
A: When baselines ignore the resource, they collapse very different risks into the same tool-level signal. A query against public analytics and a query against a finance ledger can look identical if the model only tracks the verb. That makes the baseline blind to the real control boundary and weakens any deviation decision.
Q: Who should approve risky AI agent access decisions in a mature programme?
A: The gateway should auto-handle low-risk deviations and route only high-risk exceptions to human reviewers with enough context to decide quickly. Accountability should stay with the identity and platform teams that define the policy, not with overworked approvers who cannot distinguish a harmless drift from a genuine boundary crossing.
Technical breakdown
Why static IAM policies break for agent sprawl
Static policies work when the caller population is bounded and the intent can be predicted at provisioning time. AI agents change that equation because one human can spawn many agents, each with different task scope, timing, and tool use. A policy can authorize an action class, but it cannot tell whether a specific agent is acting within its ordinary operational shape. That is why pre-approval alone becomes brittle: the control lacks enough context to distinguish safe repetition from dangerous drift.
Practical implication: move from purely static entitlements to controls that can evaluate context at request time.
Why the resource dimension matters more than the tool name
Tool-level visibility is too coarse for meaningful governance. An MCP call such as run_query may look identical whether it reaches public marketing tables or a restricted finance schema, yet the risk is completely different. Behaviour baselines only become honest when they include the underlying resource, not just the verb. That resource context turns a generic action into an auditable identity behaviour pattern, which is what lets the gateway decide whether a call still fits the learned baseline.
Practical implication: classify and monitor agent access at the resource and schema level, not only at the application or tool level.
How deviation scoring turns review into selective intervention
A behavioural baseline is not useful unless deviation means something operational. The model has to score changes by resource sensitivity, action type, entitlement state, and timing. A read against a new table may be low risk if it stays inside the same schema and the human actor is entitled to that data. A write at an unusual hour against a sensitive production system is a different pattern entirely. This is the difference between noisy interruption and targeted control.
Practical implication: tune deviation thresholds so only material behavioural changes trigger human approval.
NHI Mgmt Group analysis
Behavior baselines expose the limit of policy-only governance for AI agents. Classic IAM assumes access can be pre-authorised because the actor's intent is stable enough to predict. That assumption weakens when one person can trigger multiple ephemeral agents across multiple systems in a short task cycle. The implication is that identity governance for agents must be evaluated as runtime behaviour, not only as entitlement state.
Standing access becomes an identity pattern, not a permission class. The article shows that routine access is something a gateway earns by learning the agent's shape across tools, resources, and timing. That is a different governance problem from simply granting a role. The sharper question is whether the organisation can prove what normal looks like before it treats access as safe to leave open.
Resource locality is the named concept that decides whether an agent is truly in bounds. The same tool call can be harmless or dangerous depending on which tables, schemas, or systems it touches. Without resource locality, behavioural baselines flatten risk into activity counts and miss the actual control boundary. Practitioners should treat locality as a first-class governance dimension, not a logging detail.
Approval fatigue is not a UX issue, it is a control failure mode. When every request becomes a manual decision, reviewers stop being a meaningful part of the assurance chain. That is not a personnel problem, it is a design problem in the access model itself. The implication is that governance must reduce human interrupts by design, or it will collapse into rubber-stamp security.
AI gateway mediation is where cross-silo identity governance becomes operational. The article's strongest point is that only a control point with visibility across tools, resources, and acting context can evaluate agentic drift in real time. That aligns with Zero Trust thinking, but it also shows why identity teams need shared enforcement logic across IAM, PAM, and workload controls. Practitioners should align policy, telemetry, and approval handling around one decision layer.
From our research:
- Only 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.
- From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- For a deeper operational lens: Read the Ultimate Guide to NHIs for visibility, rotation, and lifecycle control patterns that underpin stronger baseline governance.
What this signals
Resource locality is becoming the control boundary that separates useful agent automation from blind privilege expansion. As agents move across tools and schemas, teams will need to understand not just what an identity can do, but where that action lands. Without that context, review queues will keep mixing harmless activity with material risk, and the programme will lose credibility.
The practical signal is that access review, privileged access, and runtime policy can no longer sit in separate operational silos. Behaviour-based approval only works when identity telemetry, application context, and entitlements are correlated in one place, otherwise every team will keep making the same decision from a different angle.
With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, behaviour-based control will still fail if the underlying identities are not governed first. The programme signal is clear: runtime control and secret hygiene have to move together.
For practitioners
- Define behavioural baselines per agent and per task class Track the tools used, the resources touched, the timing pattern, and the acting context for each agent before allowing standing access. A baseline that ignores one of those dimensions will misclassify normal behaviour and create either false friction or silent overreach.
- Move governance from tool names to resource locality Map access decisions to the underlying schema, table, tenant, or system boundary, not just to the application verb. This is the only way to distinguish a safe query from the same query aimed at a sensitive data domain.
- Route only material deviations to human review Score deviations by action type, resource sensitivity, entitlement state, and execution timing before escalating. Minor drift should update the baseline and log the event, while high-risk changes should interrupt the call before execution completes.
- Unify IAM, PAM, and gateway telemetry for agent decisions Correlate identity, privilege, and request telemetry so reviewers can see why an agent looks normal in one context and suspicious in another. Without a shared decision layer, the programme will keep duplicating approvals across teams.
Key takeaways
- AI agent governance breaks down when IAM relies on static policy alone, because runtime intent changes faster than pre-authorised access can safely track.
- The real decision boundary is the resource being touched, not the tool name, and that is what makes behavioural baselines useful or blind.
- Enterprises need selective human intervention, not universal review, if they want to preserve both security assurance and agent velocity.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Behavior baselines and runtime approval decisions map to agent misuse and tool governance. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Deviation handling depends on access scope and credential governance for non-human identities. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | The post centers on continuous verification before allowing agent actions through the gateway. |
Apply agentic application controls to constrain tool use, scope drift, and approval handling at runtime.
Key terms
- Behavioural Baseline: A behavioural baseline is the normal pattern of actions an identity is expected to perform, measured across tools, resources, timing, and context. For AI agents, it is the practical boundary that separates routine access from deviations that should re-enter review or trigger escalation.
- Resource Locality: Resource locality is the identity control dimension that records exactly which system, schema, table, tenant, or dataset an action touches. It matters because two identical tool calls can carry very different risk depending on where they land, especially in agentic environments that span multiple applications.
- Approval Fatigue: Approval fatigue is the condition where reviewers are exposed to so many repetitive access decisions that they stop providing meaningful scrutiny. In identity programmes, this usually leads to rubber-stamp approvals, over-permissioning, or delayed workflows that encourage teams to bypass the control entirely.
What's in the full article
Andromeda Security's full post covers the operational detail this post intentionally leaves for the source:
- A walkthrough of how the AI Gateway evaluates behaviour across tools, resources, and timing before making a decision.
- The article's risk-scoring logic for low-risk and high-risk deviations, including how the system separates routine calls from escalation events.
- Examples of how approvals can be auto-cleared, logged, or escalated based on context rather than fixed policy alone.
- The vendor's view of how its gateway fits into agentic security architecture across human and non-human identity.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security 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 governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on 2026-06-12.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org