AI agents operating inside enterprise environments are generating an accountability blind spot that most identity and access management programs weren’t built to catch, argues Amy Worley, managing director and data protection officer at BRG. The core problem: agents typically inherit shared API keys rather than holding individual credentials, making it nearly impossible to reconstruct which agent touched which data or where it went. Worley’s agent governance framework<\/a> calls for individual agent identities, full system inventories, and named human owners for every autonomous process in the enterprise.<\/p>\n The organizations most exposed here aren’t the ones that deliberately deployed AI agents at scale. They’re the ones whose third-party SaaS vendors quietly enabled agentic features by default, granting permissions that nobody on the security team reviewed because nobody knew to look. If your vendor contracts predate 2024 and you haven’t audited what automated behaviors they now include, you almost certainly have agents acting in your environment under credentials that your IAM logs treat as a single undifferentiated service account.<\/p>\n Worley’s argument holds, and the specific failure mode she identifies is underappreciated. Traditional IAM was designed around the assumption that every access event maps to an accountable human, even if indirectly through a service account someone owns. Agents break that chain because they’re designed to acquire what they need to complete a task, meaning a permissioned agent will reach for adjacent data it wasn’t explicitly authorized to touch. The monitoring gap isn’t a logging problem you can patch. It’s an architectural mismatch between how IAM was conceived and how agents actually behave. Worley consults on exactly this problem, which tilts her prescription toward governance frameworks and away from technical controls, but the underlying diagnosis is correct regardless of the solution she’d sell.<\/p>\n The leading indicator to watch is whether your next vendor security review includes a question about default agentic feature states and what API permissions those features assume on activation. If it doesn’t, your procurement process is behind the threat. The CISO who waits for an incident to build the agent inventory is effectively betting that none of those shared keys are overscoped, and that bet gets worse every quarter as the agent count compounds.<\/p>\n An API key is a credential that lets one software system call another, roughly analogous to a badge that opens a door without identifying whose hand is holding it. When multiple agents share a single key, audit logs show one “user” performing dozens of unrelated actions across different contexts. There’s no way to isolate which agent made which call. Assigning each agent its own key restores the one-credential-one-actor relationship that makes access logs actually investigable after something goes wrong.<\/p>\nWhat this means for your business<\/h2>\n
Concept deep-dive: Shared API keys<\/h2>\n