Over the past year, AI agents stopped being something enterprises tested and started being something enterprises depend on. They triage tickets, draft and send communications, query production data, and increasingly, take action inside the systems that run the business — often with far less scrutiny than the human employees they're assisting.
That shift happened faster than most identity and access programs could absorb it. The result is a widening gap between what organizations have deployed and what they can actually see, govern, and explain after the fact. This is our read on where that gap sits today, and the framework we use with clients to close it.
Agents don't fit the identity models we already have
Most enterprise identity infrastructure was built around two categories: people, who authenticate interactively and whose access is reviewed on a cadence, and service accounts, which are provisioned once, granted broad static permissions, and then largely forgotten. AI agents don't cleanly belong to either category. They act continuously like a service account, but they make judgment calls, chain actions together, and operate with a degree of autonomy that looks more like a person's than a script's.
Bolting agents onto the service-account model tends to produce exactly the failure mode you'd expect: broad, standing permissions granted for convenience during a pilot, with no clean way to answer "why does this agent have access to that system" six months later. Bolting them onto the human model isn't much better — MFA prompts and periodic access reviews don't map to a process that might act thousands of times a day.
Why this is now a board-level conversation
What's changed isn't the underlying risk — over-permissioned, unowned identities have always been a problem. What's changed is scale and speed. A misconfigured service account sitting idle is a finding in next quarter's audit. A misconfigured agent with the same permissions can act on them immediately, repeatedly, and across every system it's connected to, long before a human reviewer would ever notice.
Security and technology leaders we talk to are converging on the same three questions, almost word for word:
- Who is acting? Can we distinguish the agent, the system it runs on, and the human or business process it's acting on behalf of?
- What is it allowed to do? Is access scoped to the specific task and context, or is it standing and broad because that was easier to ship?
- Who answers for it? When an agent takes a consequential action, is there a clear, reviewable line back to an accountable owner?
The question is no longer only “what can an AI agent do?” It is also “should it be trusted to do it?”
The framework: Recognized, Authorized, Observable, Accountable
We think trust for autonomous agents has to be designed in from the start, not layered on after deployment. In practice, that comes down to four properties every agent in a production environment should have:
- RecognizedEvery digital worker should be identifiable before it is trusted — with its own identity, not a shared credential borrowed from a human or another service.
- AuthorizedAccess should reflect the purpose, context, and accountable ownership of the task at hand, scoped narrowly rather than granted broadly for convenience.
- ObservableOrganizations need real confidence that an agent's actions stay within expected boundaries — not just a log file no one reads until something goes wrong.
- AccountableImportant decisions should leave a clear, reviewable trail back to a responsible owner, so oversight survives the handoff between people, agents, and systems.
None of these are new ideas in security — they're the same instincts behind least privilege and separation of duties. What's new is applying them to actors that operate at machine speed, initiate their own workflows, and will only become more capable and more embedded over the next few product cycles.
Where this has to be built, not bought
Off-the-shelf identity tooling is starting to catch up, but for most organizations the real work is architectural: deciding how agent identity, scoping, and audit trails fit into systems that were designed before any of this existed. That's deliberately where our own cybersecurity and software engineering teams work together — governance and risk thinking from one side, and the engineering to actually implement scoped, observable, accountable agent access from the other. Neither discipline solves this alone.
What we'd suggest doing this quarter
- Inventory the agents already running in production, even the ones that started as a small pilot — most organizations have more than they think.
- Check what identity each one is actually using today, and whether it's shared, over-permissioned, or genuinely scoped to the task.
- Pick one high-impact agent workflow and rebuild its access model against the four principles above, end to end, as a template for the rest.
- Make sure there's a named, accountable owner for every agent with write access to a production system — not just a team, a person.
We're having early conversations with security leaders, technology executives, and product teams working through exactly this. If your organization is preparing for trusted AI agents at scale, we'd welcome the conversation.
Explore Agent Identity & Trust← Back to Blog