Earlier this year I wrote about the gap between AI agent demos and production deployments. Since then, one part of that gap has become a lot more concrete. Agents are no longer only calling APIs in the background. More of them now work the way people do: they open a browser, sign in to a web app, click through screens, fill in forms and move data from one system to another.
That is useful, because most enterprise software was built for humans and doesn't have a clean API for everything. It also creates a problem security teams haven't fully worked through yet. When an agent acts inside a user's session, the logs often can't tell you whether a person or a piece of software did the work.
Vendors Are Starting to Treat Agents as Users
One sign of where this is heading: in September, Citrix announced Session Insights, "a new AI-powered capability for Citrix SecurAccess with Chrome Enterprise" designed to "capture, analyze and understand browser activity from users and autonomous agents," with availability expected in October (Citrix announcement). I won't speak to the product beyond what's public, but the framing is the interesting part. Humans and agents are named side by side as things whose activity needs to be recorded and understood.
I expect most security and workspace vendors to move in this direction. Whatever tools you end up using, the underlying questions are the same.
Signing In Is the Easy Part
Most of the early conversation about agent security has focused on identity: what credentials does the agent use, and what is it allowed to access. That matters. Agents should have their own identities, scoped to the minimum they need, rather than borrowing an employee's full set of permissions.
But authentication only tells you who got in. It doesn't tell you what happened next. For a human user, we partly rely on judgment and accountability to cover that gap. A person who has access to the customer database generally knows not to export all of it to a spreadsheet. An agent following a badly written instruction might do exactly that, quickly and confidently, and the only record might be a log line saying the user's session was active.
The questions incident responders actually ask are about actions. What did it look at? What did it change? What did it copy out? Who told it to do that? If the answer to any of those is "we can't tell," the agent is a liability no matter how good its credentials are.
What a Useful Audit Trail Looks Like
From a program perspective, I'd want a few properties in place before agents get anywhere near sensitive systems.
Actions are attributed correctly. Every action should be tagged as performed by an agent, which agent, and on whose behalf. "Alex's session did this" is not enough when Alex was in a meeting and their assistant agent was working through a queue.
Instructions are linked to outcomes. When an agent changes something, you want to trace it back to the request or task that caused it. That is the difference between "something deleted these records" and "this agent deleted these records because a ticket asked it to clean up duplicates, and the matching rule was too broad."
Logs are reviewable by humans. Huge volumes of raw events are not an audit trail anyone will read. Summaries, flagged anomalies and the ability to replay a specific session matter more than capturing everything at maximum detail.
Retention and privacy are decided up front. Recording sessions raises real questions about employee privacy, especially when agents and people share the same browser. Which sessions get recorded, who can view them, and how long they're kept should be decided with legal and HR before rollout, not after the first complaint.
Running This as a Program
Like most security problems that cross team lines, agent governance doesn't fit neatly into one org. Identity teams own agent credentials. Security operations owns monitoring and response. Application owners know what normal behavior looks like in their systems. The business teams deploying agents are often moving faster than any of them.
Here is roughly how I'd sequence it:
Inventory first. Find out which agents are already running, where, under whose credentials. In most organizations the honest answer is "more than we thought," and some will be running under personal accounts. This is the shadow IT conversation again, one layer up.
Tier by impact. An agent that drafts summaries from public documents is not the same risk as one that can update financial records. Read-only agents on low-sensitivity data can move fast. Agents that write to systems of record need stronger identity, full action logging and a named human owner.
Rehearse an incident. Run a tabletop exercise where an agent does something wrong: a bad bulk update, data copied somewhere it shouldn't go. Walk through how you'd detect it, scope it and reverse it. The gaps show up fast, and it's much better to find them in a conference room than during a real incident.
Review regularly. Agent capabilities and permissions drift. A quarterly review of which agents exist, what they can touch and whether their logs look normal should be routine, the same way access reviews are for human accounts.
The Bar Is Accountability
The goal isn't to slow agents down until they're useless. It's to hold them to the same standard we hold people to: if something goes wrong, we can find out what happened, who was responsible and how to fix it. Organizations that build that visibility in early will be able to give agents more room over time. The ones that skip it will end up shutting agents off after the first incident they can't explain.