If an AI agent accesses sensitive data, IT leaders should be able to identify who approved that access and who can revoke it.
1Password surveyed 1,000 full-time US employees, half in IT and security and half in development, at companies with 250 or more employees between May 26 and June 3, 2026, and 71 percent said AI agents have access to customer data, sensitive IP, or HR information at their companies. Only 35 percent said they manage those agents under existing identity and access management processes. The vendor-sponsored survey captures employees’ reports rather than independently verified access controls.
The access figure matters, but it leaves another question unanswered: who approved the agent’s permissions, and who is responsible when its actions cause harm?
The survey’s answer is that no single party dominates. Asked who is held accountable for agent actions in practice, respondents named team or department leadership most often, at 24 percent, with the person using the agent at 19 percent, company leadership at 17 percent, and the security team at 13 percent. Sixty-five percent said a different person should be held accountable than the one who is today.
Different companies can reasonably assign accountability to different functions. The concern is whether responsibilities are clear within each organization. A project sponsor, user, executive, and security team may all influence an agent’s deployment, but their respective authority to approve access, change permissions, and stop operations needs to be documented.
Why the usual answer does not hold
One approach is to give agents service accounts, assign roles, and review permissions periodically. Those controls are useful, but they do not establish whether every action stays within the task a human approved.
Broad permissions can allow an agent to access data beyond its intended scope. Credentials can also remain active after a project ends. Identity and access controls therefore need to connect with application and data-access records so investigators can establish what an agent accessed, which policy permitted it, and who authorized the work.
For HIPAA-covered entities and business associates, these questions also have compliance implications. HIPAA’s Security Rule requires access controls for systems containing electronic protected health information, including access by authorized software programs. It also requires unique user identification and audit controls. Security and legal teams should determine how their implementation identifies agent activity and connects it to authorized access.
The visibility problem makes this worse. Vorlon’s survey of 500 US CISOs, conducted in early 2026, found that 86.8 percent reported limitations in their tools’ visibility into data exchanged between AI tools and SaaS applications. Vorlon sells in this market, so weigh it as you would any vendor research.
Two vendors with products to sell, two different respondent pools, and one shared signal. Security leaders report limited visibility into the data AI tools exchange with SaaS applications, and survey respondents describe scattered ownership of agents. In my view that points to a design flaw in how organizations roll agents out, and no tool purchase fixes a flaw that is organizational.
What to change
Start with decisions. Technology needs clear rules to enforce: who approved what, who may change it, and who answers when it goes wrong. Settle those three points before anyone shops for tooling. The answers guide what every later control must prove.
Assign a named owner to every agent that touches customer, employee, or regulated data. A role is acceptable if a person fills it and a regulator can reach that person. If you cannot name an owner, the agent is not ready for production, and the right response is to pause it, not to leave the question open.
Treat agents as a distinct category of identity governed alongside humans, under one policy and one audit trail. Governance that covers employees but not agents leaves a growing population of data consumers outside the evidence trail, and governance that covers agents but ignores the people who delegated to them breaks the chain of accountability. Both can leave gaps in the audit record.
Then move enforcement to the data, with controls that operate when an agent acts. A per-request policy can evaluate the agent, the data classification, and the context of the request. Logging that decision and its context creates a record of what was allowed and why. Short-lived credentials limit how long a mistake persists. A tamper-evident log helps preserve the integrity of that evidence.
Finally, test the control you hope never to use. Our company’s 2026 Data Security and Compliance Risk: Annual Survey Report collected self-reported responses from 459 professionals in the second quarter of 2026, and only 30 percent said they had an AI kill switch formally deployed. A control nobody has exercised is a hypothesis. In a controlled test, halt one agent, measure how long it takes to revoke its access and reconstruct what it touched, and report the results to your board.
Pick one agent, one week, and one regulator-style question, and produce the record. If that takes weeks, the gap is yours to close before an examiner finds it.
An agent can be given access in a minute, but accountability takes a decision, and the decision belongs to you.
Read more: Examine how AI agents expose gaps in access controls and audit trails to identify what your security team should check beyond authentication.