TL;DR: Traditional observability misses AI agents because it tracks uptime and errors, not identity, tool actions, shadow deployments, or credential lifecycle, leaving production activity unaccounted for until audits or incidents surface it, according to Willow. Full visibility depends on identity-aware logging and automatic revocation, not infrastructure monitoring alone.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Willow's blog post: AI agent monitoring requires identity, action-level logging, shadow AI discovery, and credential lifecycle controls rather than standard infrastructure observability.
Why it matters: It matters because agents already have production access, and IAM teams need a governance model that can attribute actions, surface unsanctioned deployments, and revoke access automatically.
Context
AI agent monitoring is a governance problem before it is an observability problem. Standard monitoring was built to track service health, but agents create identity and authorisation questions: who the agent is, what it touched, and whether the action was allowed. Without that shift, production visibility remains incomplete.
The article also points to the gap created by shadow AI, where employees connect agents to systems without approval and those connections never enter normal governance workflows. AI agents vs agentic AI matters here because the visibility model changes as the system moves from simple automation to independently acting software that can affect production tools.
Key questions
Q: What breaks when AI agents are monitored like ordinary automated jobs?
A: What breaks is the assumption that fixed schedules and static logs are enough. Autonomous agents can act continuously, switch context, and combine tools in ways that simple job monitoring will miss. Security teams need observability that links identity, action, decision context, and oversight state in a single reviewable record.
Q: Why do unmanaged AI agents create a larger risk than managed ones?
A: Unmanaged AI agents are harder to audit, revoke, and contain because no one can reliably answer who owns them, what they can reach, or whether they still need access. That makes them more likely to drift, persist after project changes, and become hidden entry points for attackers. Visibility is the first control, because you cannot govern what you cannot see.
Q: What are the signs that AI agent monitoring is incomplete?
A: Common signs include agents visible in tools but not in governance records, access that is attributed only to a shared credential, and logs that show a connection without showing the underlying action. If compliance teams can say that an agent existed but cannot explain what it did, the monitoring model is not sufficient.
Q: Should organisations use one control plane for AI agent identity and logging?
A: Yes, if they want consistent governance. Splitting identity, logging, discovery, and revocation across separate systems creates gaps between policy and enforcement. A single control plane makes it easier to apply one policy layer, keep action records aligned with identity, and revoke access when ownership changes.
Technical breakdown
Why service monitoring misses AI agent behaviour
Traditional observability records uptime, latency, and error rates. Those signals are useful for services, but they do not answer the governance questions agents create in production: which records did it read, what changes did it make, and under whose authority did it act? An AI agent can be healthy from an infrastructure perspective while still taking the wrong action in Jira, GitHub, or Gmail. Identity-aware monitoring closes that gap by attaching each action to a real principal and a specific policy decision. That makes the audit trail usable for incident review and compliance evidence. See the AI Agent Observability, Audit and Incident Response Guide.
Practical implication: Treat agent observability as an identity problem, not a server-health problem.
How action-level logging changes the audit model
Action-level logging captures the actual operation the agent performed inside the tool, not just that it connected successfully. That distinction matters because access-level logs tell you almost nothing about impact. A read-only GitHub session and a main-branch write session are both just connections unless the system records the exact action. For AI agents, the log needs to include tool calls, MCP invocations, and data access events so investigators can reconstruct intent, scope, and blast radius. Without that depth, monitoring cannot support meaningful governance or post-incident analysis.
Practical implication: Log the action, not just the session, so every agent decision is reconstructable.
Why shadow AI needs continuous discovery and offboarding
Shadow AI appears when employees create agent connections outside procurement or security workflows. The problem is not only that the agent exists, but that it may continue operating with valid credentials long after ownership changes or employment ends. That creates a governance blind spot where access survives accountability. Continuous discovery is therefore paired with lifecycle control: find the agent when it appears, assign an owner, and revoke access when that owner leaves or the use case changes. This is the operational difference between a monitored estate and an uncontrolled one. See the Agentic AI Identity Guide.
Practical implication: Discover unsanctioned agents continuously and tie each one to an owner and revocation path.
Threat narrative
Attacker objective: The objective is to operate inside production systems with persistent, unattributed access that avoids detection and audit.
- Entry occurs when employees connect an AI agent or MCP integration to production systems without approval, creating an unmanaged access path.
- Credential exposure follows when the agent runs under shared, hardcoded, or orphaned credentials that are not tied to a governed identity lifecycle.
- Escalation happens when the agent can take actions beyond its intended scope because the monitoring stack only sees the connection, not the action.
- Impact appears when compliance reviews, incident response, or offboarding discover that the agent has been operating for months with no reliable audit trail.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI agent monitoring is really identity governance with a telemetry layer attached. The article is right to reject service-style observability as the primary model, because an agent’s risk is defined by who it is, what it can do, and whether that action is attributable. When monitoring is detached from identity, organisations can see system activity but cannot prove authorization. The practical conclusion is that visibility must begin with identity binding, not dashboards.
Shadow AI creates governance debt the moment it is allowed to persist unowned. The article’s strongest point is that unsanctioned agents do not merely expand the tool estate, they expand the ungoverned identity estate. That changes the problem from detection to lifecycle control, because access that nobody owns will not be revoked on time. Readers should treat unmanaged agent sprawl as a lifecycle failure, not just an inventory issue.
Access review processes assume the thing being reviewed still exists in a stable form. That assumption fails when an agent can appear, act, and be retired through automation faster than a human reviewer can certify it. The implication is not simply more review cadence, but a rethink of where governance evidence is generated. For AI agents, the evidence has to be created at issuance and at action time, not later in a quarterly review.
One control plane is the right governance shape for AI agents. Separating identity, logging, discovery, and revocation across different tools creates policy drift and blind spots between systems. The article describes the operational problem accurately: if policy lives in one place and enforcement in another, the organisation will always be behind the agent. Practitioners should want a single policy layer where identity, permissioning, audit, and revocation stay aligned.
From our research library:
- 7% of security leaders admit they do not know how often their AI systems are making autonomous changes to infrastructure, according to the 2026 Infrastructure Identity Survey.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
AI agent governance is moving from static access control to event-level accountability. Organisations that still treat agents like ordinary applications will keep missing the decision point where access becomes action. That shift means the useful control is no longer just whether the agent was provisioned, but whether every action can be attributed, reviewed, and revoked in context.
Shadow AI turns identity sprawl into an operational blind spot. When agents are created outside IT approval, the issue is not merely discovery. It is that access can exist without an owner, which breaks offboarding, review, and incident reconstruction. The 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey, which shows how quickly governance can outrun intent.
Runtime guardrails will become the differentiator between visible and governable agents. The next maturity step is not more logging volume, but better control at the moment of action. Teams that can tie identity, policy, and revocation together will be able to manage AI agents as governed identities rather than as opaque automation.
For practitioners
- Define a real identity for every agent Bind each AI agent to a unique directory-backed identity so actions are attributable to one owner and one policy context.
- Log every tool action, not just the connection Capture each MCP call, API invocation, and data access event so investigators can reconstruct what the agent actually did.
- Surface shadow AI at the network or identity layer Use passive discovery to detect unsanctioned agents as soon as they connect, rather than waiting for periodic scans or audits.
- Tie revocation to employee offboarding Automatically revoke every agent credential linked to a departing owner so orphaned access does not survive the lifecycle event.
- Apply least privilege at the action level Grant specific actions in specific tools, such as read-only access to pull requests instead of merge permission, to reduce blast radius.
Key takeaways
- AI agent monitoring fails when teams rely on infrastructure telemetry instead of identity-aware action records.
- Shadow AI is the hardest visibility problem because unsanctioned agents can operate for months outside normal governance workflows.
- The control model that matters is a single policy layer for identity, permissions, logging, and revocation.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Observability, Audit and Incident Response Guide · AI Agent Authorisation Guide · Zero Trust for AI Agents
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on making sure each agent authenticates as a real, attributable identity. |
| NHI-05 — Overprivileged NHI | The post warns against broad tool access and emphasizes action-scoped permissions for agents. | |
| NHI-01 — Improper Offboarding | Automatic revocation on employee departure is a central control in the article. | |
| Recommendation — Bind each agent to a unique identity and remove shared credentials from production access paths. Limit each agent to the smallest action set needed for its task and review excess privilege regularly. Revoke agent credentials automatically when ownership changes or an employee leaves. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing agent permissions and ensuring actions are authorised. |
| DE.CM-01 — Networks and network services are monitored to find anomalies | Continuous discovery of shadow AI requires monitoring for new agent connections and anomalies. | |
| Recommendation — Enforce least-privilege entitlements for agents and verify access at the action level. Monitor for new agent and MCP connections so unsanctioned activity is detected as it appears. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article emphasises credential lifecycle, revocation, and non-shared authentication for agents. |
| Recommendation — Manage agent authenticators centrally and revoke them when the owning user or workload changes. | ||
Key terms
- Runtime Agent Monitoring: Runtime agent monitoring is the continuous observation of an AI agent’s requests, tool calls, and interactions while it is operating. It helps security teams detect when the agent is drifting beyond intended scope, triggering a policy breach, or exhibiting behaviours that require containment or shutdown.
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
- Action-Level Log: A record of what an agent did, not just what it produced. For governance purposes it should capture the action, the human authority behind it, the target system and the outcome, so auditors can reconstruct the decision path and prove accountability across overlapping regimes.
- Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org