An AI agent can have permission to use company systems and still do something nobody intended. That permission may also remain in place as workflows change, software is replaced or the employee responsible for the agent moves on.
Google brought that problem into sharper focus on Oct. 8 when it introduced Gemini Agent, a workplace assistant designed to use company information across Google Workspace. The agent is in private preview. As Esther Shittu reported, permission questions become more complicated when that work extends to applications outside Google's environment.
Access decisions already arise where people begin work -- in browsers, mobile applications and hiring workflows. Agents add another participant that can act on someone's behalf, sometimes across several systems in a single task.
Browsers bring access decisions to the start of work
Browser-based workflows have become a primary access point for enterprise systems. Identity checks, session controls and policy decisions often take place as a session begins. And the browser is increasingly a managed workplace environment, including for AI tools that operate applications on a user's behalf.
QR codes are a convenient way to get employees into onboarding portals or other shared workplace systems. But a scan doesn't always make it clear where the link leads. Someone can end up on an unfamiliar or fraudulent site before realizing what's happened.
Employees also routinely use phones and tablets to check company email, collaborate with colleagues and work in business applications. A security weakness in a mobile app can expose company information or systems beyond the device itself.
The access question can come up even before someone is hired. AI-generated and synthetic job applicants make it harder to know who's actually applying, and fraudulent candidates may be looking for a way into internal systems. HR has to verify applicants, while IT and security must determine when to issue accounts and grant access.
A credential may permit something the business never wanted an agent to do.
Agents can carry access farther than intended
An employee might connect a personal AI assistant to company applications, while a department might deploy an agent with IT approval. Both can receive legitimate access to internal systems. A credential may permit something the business never wanted an agent to do.
While working on a development task at PocketOS, a software company serving car rental businesses, an AI coding agent deleted the company's production database and backups. The incident illustrates the danger of an agent having the technical ability to make a destructive change its user never intended.
Access can also change after an integration is approved. Slack's chief product officer explained in an interview with TechTarget that membership in private channels and group messages can change. Those shifting permissions were among the reasons Salesforce tightened access to Slack data through some third-party applications. A connection that made sense when it was approved cannot simply be assumed appropriate forever.
Microsoft's Entra Agent ID lifecycle policies, currently in preview, apply familiar identity-management practices to part of this problem. They let organizations require human sponsors, periodically confirm that an agent identity is still needed and monitor inactivity. Policies can disable or delete identities that no longer meet those requirements. Those controls help with stale access; they cannot by themselves stop an unwanted action while an agent's credentials remain valid.
What agent identity controls can -- and can't – do
Identity lifecycle controls can help organizations find and remove stale agent access. They cannot ensure that every action taken with valid credentials matches what the business intended.
They can:
Require a human sponsor.
Periodically confirm that an agent identity is still needed.
Monitor inactivity.
Disable or delete identities that no longer meet requirements.
They can't:
Prevent every unintended action while an agent’s credentials remain valid.
Determine whether every technically permitted action reflects what the business intended.
Keeping access aligned as work changes
Browsers, mobile applications and hiring workflows bring access decisions to the start of work. Agents can carry those decisions farther -- across systems and beyond the first approval. An access choice that made sense at deployment may need another look when the workflow, software or person responsible changes.
Existing identity management offers ways to assign sponsors, review permissions and revoke access. CIOs also need to know where an agent's authority ends and what safeguards keep a technically permitted action from becoming a business problem.
James Alan Miller is a veteran technology editor and writer and Lead Editor for CIO News at Informa TechTarget. He directs coverage of enterprise technology strategy, AI, software, data, infrastructure and the decisions shaping how CIOs manage increasingly complex IT environments.
