Governing AI Agents Beyond Least Privilege by Controlling Their Access, Decisions, and Actions
Published
Key Takeaways
- AvePoint says organizations must inventory not only each AI tool but also the data it can reach.
- Hodges believes that AI agents should be governed more like employees because they can act independently.
- Business context must accompany technical visibility so teams know why an agent exists.
- An agent may exceed its intended role while attempting to improve productivity, making human review essential.
- Incident records must reconstruct intent, reasoning paths, and chained actions because containment seeks what an agent saw and did.
John Hodges, Chief Product Officer at AvePoint, explains why organizations need oversight and stronger controls as employees deploy AI agents. Hodges has spent more than 18 years at AvePoint, advancing from technical writing and product management to senior product strategy and CPO roles.
Hodges says security and IT teams must first discover sanctioned, unsanctioned, embedded, custom, and personal-productivity agents in use.
Each agent should be linked to an owner, business purpose, and output destinations. Teams must watch for attempts to reach unrelated repositories, gain wider access, move unusual amounts of data, work at unexpected hours, or repeatedly fail policy checks.
Hodges says policies alone will not prevent unauthorized access. Organizations should apply “least agency” by restricting both the data an agent can access and the decisions it can make.
When something goes wrong, investigators need prompt histories, action logs, and version records to determine what the agent saw and did. Read on for practical steps to find hidden agents, restrict excessive access, and detect warning signs before the damage spreads.
Vishwa: AvePoint’s research says AI visibility gaps have nearly tripled in a year. If organizations cannot tell whether AI agents are being used, what telemetry and artifacts could help gain visibility?
John: This isn’t a new problem; the visibility gap has existed with collaboration technology for decades. If you look back a few years ago to the explosion of citizen-developer Power Platform apps, flows, and Power BI workspaces, for example, you’ll realize that IT and IT Security teams were often blindsided by outages or risks pertaining to applications they never sanctioned or deployed themselves.
Use of unsanctioned tools has always been an issue, and that issue is accelerating with AI. AvePoint’s 2026 AI Report found that 21.1% of organizations cannot account for unsanctioned agent activity, while 88% experienced an agent-related breach in the last year, which illustrates the problem really well.
Capturing the activity of these agents is an important step, but it’s not a panacea for trust and accountability. Working with the business to understand why these agents exist is fundamental to establishing guidance, guardrails, and even metrics of success. We believe the ability to add business context to visibility platforms is really critical.
Vishwa: What are the indicators that an AI agent has exceeded its intended permissions before a security incident occurs?
John: Warning signs usually show up before the breach, even if security teams lack the control and visibility needed to stop them proactively. A rogue agent, for example, might start querying repositories outside its business purpose, or it might start requesting broader scope than it needs.
It could try to trigger unusual download, summarization, or sharing activity, or it could act at odd hours, or repeatedly fail policy checks. You’ll see these issues if you have visibility into what your agents are doing, but you’ll miss them and be forced to work reactively, after a breach occurs, if you don’t have that level of insight.
At the same time, it’s important to understand that, when an agent attempts to exceed its intended permissions, it might be doing so in an attempt to be more productive, which isn’t necessarily a bad thing. That’s why you need visibility into risky agent behavior, and a human in the loop to discern truly risky or even malicious agent behavior from well-intentioned actions that are simply meant to streamline productivity.
So really you need two things:
- The first is the technical ability to see what agents are doing
- The second is sound human judgement and tools that can differentiate true risk from “noise.”
This—differentiating risk from noise—was a top concern for 70% of survey respondents in our report.
Vishwa: Which controls are missing when organizations have AI governance policies but still experience unauthorized access?
John: A policy sets a standard; a control implements and operationalizes the standard across an IT environment. What we have today are AI governance policies—over 90%, for example, have an AI security framework—without real control.
When organizations see unauthorized access, the missing pieces are usually enforcement, data classification, entitlement review, agent lifecycle management, prompt and action monitoring, automated policy checks before an agent acts, and a trust layer that connects AI governance to data protection.
Vishwa: What should be the approach to inventorying AI agents when employees can deploy them without IT approval?
John: Inventory is important, but agents present novel risks that require a nuanced approach. If employees can deploy agents without IT approval—and our research shows that this is largely the case—the first goal is to understand what exists in your environment:
- Sanctioned agents
- Unsanctioned agents
- Embedded agents inside SaaS tools
- Custom automations
- Personal productivity agents
- All of it
Once you’ve done that, map each one to an owner, purpose, data sources, permissions, connectors, output destinations, and business criticality. Our report finds that Agent Management Platforms are a top planned investment because the old inventory model does not fit agents.
You don’t just inventory the tool; you inventory the actions it can take, the data it can reach, and the data protection controls around it.
Leaders should also recognize that waiting for IT approval has not been how organizations traditionally grow. Organic, business-led growth is what we’ve seen with lots of collaboration technology, from Power Platform to Teams.
We believe that Agentic growth will be the same, and any inventory tools have to work with this “create and chase” model to ensure success over a “firewall” style block.
Vishwa: What would the AI equivalent of least privilege be?
John: The agentic AI equivalent of least privilege is “least agency.” Agents, like human employees, need access to only a limited amount of data, and they also need very clear rules to govern decision-making power and autonomy, since they lack the judgement, accountability, and context of a human employee.
That’s what least agency means; it’s about giving the agent the autonomy needed to perform its function, and nothing more. To do this, think of how you can replicate the mechanisms—accountability structures, contextual information, contextual judgement, and so on—that prevent human employees from behaving erratically. That’s the recipe for a stronger trust layer.
Vishwa: Which logs and audit trails become important during incidents involving AI agents?
John: During an AI agent incident, the important logs are the ones that reconstruct intent and impact.
If I was a security chief evaluating a breach, I would want:
- Prompt history
- Agent action logs
- Data access logs
- Permission grants
- Connector activity
- API calls
- File movement
- Output generation
- Sharing events
- Policy decisions
- Human approvals
- And version history for anything the agent changed.
Traditional security logs show access, but investigations into agentic incidents also need to show reasoning paths and chained actions.
That is where visibility becomes trust, and where data protection becomes part of the trust layer.
If you cannot explain what the agent saw and did, you do not really know whether the incident is contained.
It’s also important to note that the intent behind agent activity is critical to understand and monitor, and that can only be captured by keeping a human in the loop to apply their judgement to the situation.
Agent visibility and observability tools can catch risky agent behavior, but people are still the best at discerning truly risky behavior from well-intentioned mishaps.
Vishwa: What does an AI agent do differently that makes it harder to monitor compared with a SaaS application or a human user?
John: The problem today is that many organizations are treating agents like software when they really need to be treating them like people, at least from a data protection and security perspective.
As a leader, you know you can trust your employees because you’ve hired them, vetted them, and set up programs and frameworks to verify that trust continually, throughout their tenure at the company.
With agents, most organizations lack a similar set of mechanisms.
Agents are often created and deployed in IT environments without proper vetting, and once they’re in the field, administrators often lack the proper controls needed to see and restrain risky behavior.
Agents are software, but they act like people, and they need a trust layer to compensate for their lack of human judgement and accountability.
Related
Get expert insights on threats, breaches, scams, and security trends — delivered every Monday.
Most Popular
Get expert insights on threats, breaches, scams, and security trends — delivered every Monday.
Most Popular