Governing AI Agents Starts With What They Can Touch
Over the past two months, two things happened that make agent governance an immediate concern rather than a planning topic.
In December, the OWASP GenAI Security Project published its Top 10 for Agentic Applications, giving security teams a shared vocabulary for risks such as goal hijacking, tool misuse, identity and privilege abuse, and cascading failures between agents. NIST released a preliminary draft of its Cyber AI Profile for comment around the same time.
Then, in late January, an open-source personal AI agent went viral among developers and early adopters. People installed it on work laptops and connected it to email, messaging, calendars and code repositories, and gave it the ability to run commands. Security researchers quickly found exposed instances on the internet and malicious add-ons in its community extension marketplace.
The second event is the more instructive one. Most organizations’ AI governance programs were designed around approved projects with a sponsor, a budget and a review. The agent arrived through individual enthusiasm, with broad access, and with nobody in the security team aware of it.
Agents are identities that act
A chat assistant answers questions. An agent takes actions: it reads and sends mail, calls APIs, edits files, runs code and can trigger other agents. Each action happens with some identity and some set of permissions, often the user’s own, sometimes a service account, occasionally credentials pasted into a configuration file.
That makes agent governance mainly an identity and access problem, which is good news. Organizations already know how to inventory identities, review their permissions and monitor what they do. The task is to extend that discipline to a new kind of actor.
Start with an access inventory
For each agent in use, sanctioned or not, record:
| Question | Why it matters |
|---|---|
| Whose identity does it act as? | Determines what it can reach and how its actions appear in logs |
| Which systems and data can it access? | Defines the damage a compromised or misdirected agent could do |
| Which actions can it take without a person confirming? | Defines what can happen before anyone notices |
| Where do its instructions come from? | Any content it reads, such as emails, tickets and web pages, could carry injected instructions |
| Which tools, plug-ins or extensions does it load, and from where? | Extensions run with the agent’s access |
| Who owns it? | Someone needs to answer for it when something goes wrong |
The evidence for this inventory comes from the same places as shadow AI discovery: identity provider logs, OAuth grants, endpoint software inventories and network traffic. Look specifically for long-lived tokens issued to agent tools and for processes making unusually high volumes of API calls.
Reduce access before adding controls
Once the inventory exists, the most effective step is usually to reduce access rather than to add monitoring:
- Give agents their own identities rather than the user’s full credentials, scoped to the systems a task requires.
- Separate reading from acting. An agent that summarizes email doesn’t need permission to send it.
- Require confirmation for consequential actions: sending externally, deleting, changing permissions, moving money, deploying code.
- Allow extensions from approved sources only, and review what each one can do.
- Keep credentials out of agent configuration files where possible, using short-lived tokens issued for the task.
These are familiar least-privilege principles. Agents make them more urgent, because an agent will act on whatever instructions reach it, at a speed and volume no person matches.
Monitoring that fits how agents behave
Agent activity should be attributable: logs need to show when an agent took an action, and on whose behalf. Where agents share a user’s identity, that distinction is lost, which is another reason to give agents identities of their own.
Useful signals include sudden changes in an agent’s volume or pattern of activity, access to systems outside its usual scope, and new extensions or tools appearing in its configuration.
Where this fits in AI security maturity
Organizations at different stages need different things. One just discovering agent usage needs an inventory and a clear policy on what employees may connect. One running agents in production needs identity design, confirmation controls and monitoring. One with many interacting agents needs to think about how failures cascade between them.
Trying to jump to the advanced stage without the earlier ones tends to produce policies nobody follows and controls that don’t match what’s deployed. Starting with an honest inventory of access, and reducing it, puts every later step on solid ground.
A short checklist for this quarter
- Search identity and endpoint data for agent tools already in use.
- Publish guidance on which agents employees may use, and what they may connect them to.
- For each sanctioned agent, document its identity, access, autonomous actions and owner.
- Remove access agents don’t need for their tasks.
- Make sure agent actions can be distinguished from human actions in logs.
These steps don’t require a finished AI governance framework. They make building one far easier.