The AI agent working for you probably has more access than you do

The AI isn't doing the rep's job. It's a tool the rep uses. But the tool ends up with more reach into the system than the person it's working for. That gap, a human with scoped access using a non-human identity with broader access, is becoming the normal shape of enterprise AI deployment, and almost nobody is reviewing it the way they'd review a person's permissions.

Netwrix's 2026 Data & Identity Security Report, based on a survey of 2,317 security and IT leaders, puts numbers behind that pattern. 72% of organizations say identity-related data exposure risk has increased. 58% say more identities now have enterprise data access than before. 41% are already running agentic AI in production, with those agents acting on behalf of humans against sensitive data. Non-human identities aren't a future problem. They're already the majority stakeholder in a lot of environments.

The part that doesn't show up in an access review

Most identity governance programs were built around a joiner-mover-leaver cadence. Someone starts, their access grows or shifts, and eventually they leave and it gets revoked. Service accounts, API keys, certificates, and automation tokens don't follow that pattern. They get created during a deployment, inherited from whatever template was fastest to stand up, and then left alone because nobody owns the follow-up.

The report backs this up. Only 19% of organizations say they fully govern non-human identities. 76% can't immediately revoke standing access when it's no longer needed. 64% have at least some overprovisioned access to critical data. Put those together and you get a population of credentials that's larger than the human workforce, harder to track, and rarely reviewed.

There's a specific version of this problem worth calling out: certificate-based authentication is becoming the primary trust mechanism for AI agents and automation, but most organizations have little visibility into the certificate infrastructure underneath it. Misconfigured templates, overly permissive enrollment rights, and inherited trust relationships in Active Directory Certificate Services can let an attacker impersonate a privileged identity without ever touching a password.

Why this is a change management problem, not just an identity one

Here's the piece that gets missed. A service account's permissions, a certificate's trust chain, an API key's scope, none of that lives only in an identity platform. It lives in configuration files, registry keys, certificate stores, and scheduled tasks on the actual systems where the account operates. When a regulatory obligation changes, whether that's a new PCI DSS requirement, an updated NIST control, or a NERC CIP revision, the access review and the revocation step are supposed to happen together. In practice, the identity side gets attention and the configuration side drifts quietly in the background.

That drift is exactly where unauthorized change hides. A registry key that grants a service account broader enrollment rights than it needs. A config file that still points to a decommissioned integration. A certificate template edited six months ago that nobody flagged for review. None of these show up in an access certification spreadsheet. They show up when someone looks at what actually changed on the system.

Watching the systems instead of just the roster

This is where file integrity monitoring and security configuration management earn their place in the conversation. Netwrix Change Tracker doesn't manage identities, but it does watch the systems those identities and their credentials live on. It baselines configuration files, registry keys, and system settings, then flags any change that deviates from that baseline in real time. When a Planned Change rule exists, whether it's tied to a patch window or an approved ServiceNow request, matching changes get filtered out automatically. What's left is the unplanned activity: the registry edit nobody approved, the config change with no matching change request, the drift that would otherwise sit unnoticed until an audit or an incident forces someone to go looking.

That closed-loop model, matching observed changes against approved ones through ITSM integrations like ServiceNow, BMC Remedy, and Cherwell, gives security and compliance teams something the access review alone can't: a system-level record of what actually happened, when it happened, and whether it was expected. Combined with 250+ prebuilt compliance reports aligned to frameworks like PCI DSS, NIST, HIPAA, and DISA STIG, that record turns "we think our controls are working" into evidence an auditor can actually check.

The rep still gets the blame

If that Salesforce integration gets compromised, or if the assistant quietly pulls data outside its intended scope, the incident report won't name the AI vendor. It'll name the account that authenticated, and the person whose name is attached to it. Identity governance can set the policy for what that account should be allowed to touch. It can't tell you, on its own, what actually changed on the system last Tuesday. That's a different question, and somebody still has to be watching for the answer.