Your company may already have AI agents IT doesn't know about
Clutch's June 2025 survey of 254 US full-time employees found that nearly three in four use AI at work. PwC's May 2025 survey of 308 senior US executives found that 79% say AI agents are already being adopted in their companies. LangChain's 2026 survey of over 1,300 professionals found that 57.3% of teams had AI agents in production, with another 30.4% actively developing them.
Those numbers measure different things at different stages of deployment, but the direction they point is consistent: organizations are accumulating AI agents faster than most governance programs are designed to handle. Deloitte's 2026 survey of 3,235 leaders found that only 21% of surveyed organizations have mature agentic AI governance in place, meaning roughly four in five are scaling agent autonomy without the controls to contain it.
The issue is not that employees building agents is inherently problematic. It often produces real business value: workflow automation, research, data processing, communication assistance. The issue is that when an agent can access company data, connect to business systems, or take actions on a user's behalf, it has become something different from an AI chatbot. It has become software with permissions, behavior, and operational consequences, and most companies are not tracking it with the same rigor they apply to other software with those properties.
The governance gap this creates is predictable: nobody knows which agents exist, what they can access, what they are allowed to do, or who is responsible when one of them does something wrong.
AI agents are different from ordinary AI tools
The distinction matters because it determines the governance model. A tool that answers questions does not change state in your business systems. An agent that can read, write, send, modify, and trigger downstream workflows does. That difference carries real operational and security implications.
| Capability | Example | Governance need | Why it changes |
|---|---|---|---|
| Answer | Summarize a support ticket | Low | No state change, no access required beyond the document |
| Draft | Prepare an email response | Low to moderate | Human sends or discards; agent cannot act without explicit approval |
| Recommend | Suggest a customer action from CRM data | Moderate | Reads sensitive business data; recommendations may influence decisions |
| Execute with approval | Create a support ticket after human confirms | Moderate to high | Writes to business systems; human approval loop is the primary control |
| Execute automatically | Send messages, update CRM records | High | Takes action without per-instance human approval; errors propagate immediately |
| Autonomous/consequential | Change configurations, approve transactions, modify production records | Very high | Consequential, potentially irreversible actions at system level; full identity and access controls required |
This is a practical governance model, not a formal industry standard. Its purpose is to help IT and security teams allocate review effort proportionately: low-autonomy tools warrant lightweight oversight; high-autonomy agents warrant the same controls applied to any other software with write access to production systems.
The four questions IT needs to answer about every agent
These four questions form the foundation of any AI agent inventory. They don't require specialized tooling to answer first. They require an honest assessment of what agents are running and what permissions they were given when they were built.
Build an agent inventory before you try to control everything
Visibility is the prerequisite to governance. Before a company can apply controls, it needs to know what it is controlling. The priority is not discovering every employee experiment immediately. It is identifying agents that are connected to production systems, handle sensitive information, or communicate externally, because those carry the greatest operational and security risk.
| Inventory field | What to record and why |
|---|---|
| Agent name / identifier | Unique name so the agent can be referenced in logs, access systems, and incident response |
| Owner (person and team) | Accountable individual and escalation path; critical when that person changes roles or leaves |
| Purpose | The workflow or task it performs; helps identify when an agent is operating outside its intended scope |
| Data it can access | Every data source, system, and API it connects to; the starting point for access-control decisions |
| Permissions (read/write/delete/external) | What it can do in each connected system; the basis for least-privilege review |
| Environment | Prototype / test / production; changes the urgency of governance controls significantly |
| Human approval required? | Whether consequential actions require a human in the loop before execution |
| External communication? | Whether it can send emails, API calls, or messages outside the company; a significant risk multiplier |
| Monitoring / logging | Whether activity is logged and who reviews it; the only way to detect anomalous behavior after the fact |
| Risk classification | Low / Medium / High based on data access, permission scope, and autonomy level |
| Shutdown method | How credentials can be revoked and the agent disabled quickly; must exist before production deployment |
Treat AI agents like software identities, not user shortcuts
One of the most common governance mistakes is giving an AI agent the same permissions as the employee who built it. The reasoning feels intuitive: the employee has access to those systems anyway, so the agent they built can have access too. But this conflates two different security objects with very different behaviors.
A human identity is subject to attention, judgment, and fatigue. A human making an error notices something is wrong and stops. An agent with elevated permissions and autonomous execution capability can apply an error at machine speed across every record it can reach before anyone detects the problem.
The NIST NCCoE's February 2026 concept paper on software and AI agent identity and authorization, and the Cloud Security Alliance's Agentic Trust Framework published the same month, both make this direction explicit: agents should have their own distinct identity, scoped to the minimum permissions required for their specific workflow, with authentication and authorization enforced at the tool level rather than inherited from a user account.
The practical implications for an IT team managing employee-built agents:
Unique identity per agent. Each agent should authenticate with its own credentials or identity, not the employee's personal account. This makes activity attributable to the agent specifically and allows revocation of the agent's access without affecting the employee.
Least-privilege permissions. The agent should have the minimum access required to perform its defined workflow. An agent that summarizes support tickets does not need write access to the CRM. An agent that updates order records does not need access to HR data.
Scoped tool permissions. Where agents connect to external systems through APIs or integration platforms, those integrations should grant the minimum scope the workflow requires, not full API access because full access was simpler to configure.
Credential lifecycle management. Agent credentials should expire, be rotatable, and be revocable independently of the employee's own account. When the employee who built the agent leaves, their departure should not automatically grant the agent continued access with no owner to review it.
Logging and auditability. Agent activity should be logged at a level that supports incident investigation. The OWASP Non-Human Identities Top 10 (2025) identified 24 million leaked non-human identity credentials on GitHub in 2025, of which 70% from 2022 remained valid, illustrating how poorly managed non-human identities create long-lived, unreviewed attack surfaces.
Give agents levels of autonomy matched to controls
Not every agent needs the same governance model. The appropriate controls depend on what the agent can do and how independently it operates. The following autonomy levels are a practical business governance model, not an official framework, but they can help organizations allocate review effort and set baseline requirements proportionately.
Levels 1 and 2 can generally proceed with lightweight oversight. Level 3 and above should have IT awareness. Levels 4 and above require distinct identities, scoped permissions, logging, and defined shutdown procedures before production deployment. Level 6 should not go into production without formal security review, tested incident response, and explicit executive sign-off on the risk profile.
The prototype-to-production transition is where governance changes most
The practical answer to "Can employees build their own agents?" is not a simple yes or no. It depends on what the agent does and where it operates.
Employees can generally experiment with agents that: summarize or research using data they already have access to; draft content that humans review before sending; perform internal productivity tasks in sandboxed environments; process data that is not sensitive or regulated; and perform reversible tasks in test environments.
IT and security review should be engaged before an agent moves into regular use when it: accesses customer data, employee records, or financial information; connects to production business systems; can send communications externally; can write, modify, or delete records; operates without per-action human approval; handles regulated workflows; or uses credentials that aren't the employee's personal account.
The transition from "an employee experiment that uses the same permissions as the employee's laptop" to "a system that automates actions in production" is where the governance model needs to change. That transition is often invisible when governance is not actively watching for it.
What happens when an agent gets something wrong
Operational resilience for AI agents is an underappreciated part of the governance conversation. Most discussions focus on preventing harm. Equally important is the ability to detect, contain, and recover from an agent failure.
For effective response, the organization needs to be able to:
Without these capabilities, the company can stop the agent but cannot easily determine what it damaged, how badly, or over what period. AI governance that focuses only on access control without addressing detection, response, and recovery is incomplete.
An AI agent governance checklist you can use now
This checklist is a starting point for internal review, not a compliance standard. Use it to identify where current practice may have gaps before a production agent surfaces the problem for you.
- Do we have a record of which employee-built agents currently exist or are in active use?
- Does every agent connected to a production system have a named owner?
- Do we know what data each agent can access, and is that scope documented?
- Are agent permissions limited to what the workflow actually requires?
- Does each production agent have its own identity distinct from the employee who built it?
- Can we see a log of what each agent has done and when?
- Are consequential actions (write, delete, external communication) subject to human approval or strong guardrails?
- Can we revoke an agent's credentials quickly without affecting the employee's own account?
- Do we have a defined process for disabling an agent that is misbehaving?
- If the employee who built an agent leaves the company tomorrow, does the agent automatically lose access?
- Has any production agent been tested against realistic failure scenarios?
- Is there a defined process for deciding when an employee experiment requires IT or security review?
- Do agents that interact with regulated data or workflows have appropriate compliance review?
When to bring in external IT, security, or AI expertise
Organizations managing a handful of low-autonomy agents with clear ownership and limited access can often handle governance with internal resources and policy. The triggers below indicate when external expertise in IT, cybersecurity, or AI engineering is worth engaging.
Multiple agents are appearing across departments without centralized visibility. When the inventory itself becomes difficult to maintain internally, the governance infrastructure needs to scale.
Agents are accessing sensitive data or connecting to production systems. Security review of access controls and identity architecture is warranted before, not after, production deployment of high-autonomy agents.
The organization cannot quickly revoke or disable an agent's access. This is a foundational capability gap. Until it is addressed, any agent failure has an extended blast radius.
Monitoring is weak or nonexistent. If the company cannot tell what its agents are doing in the logs, it cannot detect or investigate failures. Building logging and alerting infrastructure for agent activity may require specialist support.
Regulated workflows are involved. Healthcare, financial services, and other regulated environments may need governance frameworks that align with specific compliance requirements. The EU AI Act's Article 14 human-oversight requirements, for instance, apply to autonomous agents deployed in high-risk domains.
Agents are moving from experiments into broad production use. The inflection point between individual productivity tools and operational infrastructure is where governance requirements typically jump, and where organizations often lack the internal experience to design the right controls at the right scale.
AI agent governance is becoming part of normal IT governance. It is not a separate theoretical AI problem. It is the same set of questions IT applies to every other system that has credentials, accesses data, and takes actions in the business.