Your organization reviewed an application six months ago. Security assessed it, procurement approved it, the appropriate business owners signed off. The application was added to the enterprise technology environment and became another trusted part of everyday operations. Then the vendor releases an update, the application can now determine information, interact with additional systems, make decisions and execute actions on behalf of employees. Nothing new was purchased, nobody installed an unauthorized tool, and the application is still on the approved software list. But is it still the same risk?
That question is becoming increasingly important as agentic capabilities appear inside established enterprise platforms. A recent Forbes article, “Agentic AI Governance: When Approved Software Turns Agentic”, highlighted precisely this problem: sanctioned software can gain materially different capabilities after its original security risk review. The deeper governance problem is bigger than agentic AI itself.
For decades, enterprise technology governance has operated around an implicit assumption: once software has been reviewed and approved, its fundamental security characteristics will remain reasonably consistent until the next significant review, but agentic software weakens that assumption. For IT and security leaders, “approved” can no longer be treated as a permanent state.
The important distinction doesn’t lie between AI and non-AI software; it’s between the capabilities an organization evaluated and the capabilities an application has today. Traditional enterprise applications already change frequently. Vendors introduce features, integrations, and new workflows through cloud updates. Agentic functionality can make some of those changes more consequential because software may prove beyond presenting information or waiting for explicit user commands. Depending on its design and permissions, an agent may be able to access data, invoke tools, interact with other applications, and perform actions.
An application that could read information yesterday might be able to act on that information tomorrow. An assistant that previously generated recommendations might gain the ability to execute them. A tool operating within one data environment might gain connectors to several more. Autonomy doesn’t automatically make the software unsafe, but the conditions under which the software was originally approved may no longer describe how it operates. This creates an expiration problem for enterprise approval.
Most enterprises have mechanisms for managing technology risk: procurement controls, security assessments, architecture reviews, vendor questionnaires, data protection reviews, and periodic assessments. These remain important but so does the point in time when software capabilities change between those formal reviews. Material changes such as additional autonomy, permissions, data access, and integrations should become triggers for reassessment rather than relying exclusively on scheduled vendor reviews. Don’t worry, that doesn’t mean restarting an entire security assessment for every product enhancement.
We believe enterprises should take that idea further and begin moving toward continuous trust validation.
Instead of asking only:
Was this application approved?
IT and security teams should ask:
Does this application still operate within the conditions under which we approved it?
But certain events should trigger targeted reassessment, including:
- introduction of AI or autonomous agent functionality
- expanded authorization scopes
- additional integrations
- access to new categories of enterprise data
- autonomous decision making or execution
- material changes to authentication or identity
- new data retention or processing behavior
- the ability to initiate consequential actions without direct human execution
The depth of reassessment should depend on change. A new summarization function doesn’t warrant the same scrutiny as an agent being granted write access to a financial system. The goal is proportional governance, not more bureaucracy. This risk based approach is consistent with the broader direction of NIST’s AI Risk Management Framework. NIST describes the AI RMF as a voluntary framework designed to help organizations incorporate trustworthiness considerations into the design, development, use, and evaluation of AI systems. NIST’s framework also supports current and target profiles so organizations can identify and prioritize risk management gaps.
Agentic functionality should be considered through the same fundamentals enterprises already use to secure users, applications and workloads. Identity. Authorization. Least privilege. Monitoring. Data protection. Segmentation. Accountability.
Consider an employee who asks an enterprise agent to perform a task. The employee may initiate the request, but the agent may determine which systems to access and which actions to perform. If the resulting audit trail records only the employee’s credential, investigators could have difficulty determining what actually happened.
Was the action directly performed by the user? Was it executed by an agent at the user’s request? Which agent? What authorization did it possess?
This distinction is becoming important enough that identity platforms are beginning to address agents explicitly. Microsoft, for example, documents AI agent identities as distinct identities that can receive their own access rights and governance. Its security guidance recommends explicitly identifying and authorizing users, agents, workloads, plugins, and tools rather than allowing them to inherit implicit trust. The architectural principle matters beyond any specific platform.
Enterprise identity strategies increasingly need to distinguish human authority from machine execution.
An agent should not automatically inherit every permission available to the employee on whose behalf it operates. Doing so could turn an ordinary authorization decision into a much broader delegation of authority. Microsoft’s current AI security guidance recommends giving agents and tools explicit identities and authorization, with minimum necessary rights and stronger controls around consequential actions.
The principle also aligns naturally with Zero Trust. CISA describes Zero Trust in terms of accurate, least privilege, per request access decisions and granular controls between users, systems, data and assets that change over time. Applied to agentic environments, that suggests a simple rule:
Trust the authorization required for the task, not the fact that the software itself has previously been trusted.
Most discussions of shadow AI focus on employees adopting unauthorized AI services. That no longer encapsulates the whole of the problem. AI can also arrive through software the enterprise intentionally purchased.
No employee has circumvented procurement. No new SaaS subscription necessarily appears. No unauthorized application needs to be downloaded. Instead, a sanctioned vendor introduces AI functionality into a product already present in the environment. The Forbes article specifically identifies this possibility, describing how approved software can become a source of shadow AI when vendors add agentic capabilities after initial approval. For security leaders, this means AI discovery cannot focus solely on finding unauthorized applications. They also need visibility into new capabilities appearing inside authorized applications. That makes vendor management, software inventories, identity telemetry, and security monitoring part of the AI governance architecture.
The question becomes less about discovering which products contain AI and more about understanding where AI has meaningful authority within the enterprise.
IT teams are already familiar with configuration drift. A server, cloud resource, or security control begins in an approved configuration but gradually moves away from its intended state.
Island Networks proposes a related way to think about agentic software: capability drift. Capability drift is not presented here as an established industry standard. It is a useful enterprise governance framing for what happens when the functional authority of software materially changes after its original approval.
- more integrations
- broader permissions
- additional data sources
- autonomous workflows
- decision making authority
- tools capable of acting on external systems
Individually, each change may appear manageable. Collectively, they may result in software that bears little resemblance to the risk profile originally assessed. That suggests a useful governance principle: Risk reviews should follow material capability changes, not simply the software purchasing calendar.
Enterprises already monitor configuration drift because technical state changes over time. They should begin thinking about how to detect capability drift for the same reason.
Enterprises do not need to rebuild their entire governance model around agentic AI. Much of the foundation already exists.
An inventory labeled “AI tools” will miss an important part of the environment. Track where material AI functionality exists within broader enterprise applications, particularly where it can access enterprise data, invoke tools or perform actions. The unit of governance should increasingly become the capability, not merely the product.
Establish which product changes require targeted reassessment. Expanded permissions, new integrations, autonomous execution, access to sensitive data, and material identity changes are reasonable examples. The purpose is not to review every release note. It’s to identify changes that alter the application’s security assumptions.
Understand not only which applications users can access, but what agents and automated workflows can access once acting on their behalf. Look for unnecessary standing permissions and authorization scopes that have expanded beyond the intended task.
Agentic workflows should receive only the access necessary for their intended functions. Where architecture permits, separate the agent’s authorization from the user’s broader privileges. This follows established Zero Trust thinking around granular, least privilege access. [cisa.gov], [learn.microsoft.com]
If an agent can perform materially consequential actions, organizations should evaluate whether it requires a distinct, governable identity. That separation can improve access governance and make actions easier to attribute. Current Microsoft identity architecture, for example, supports dedicated agent identities with distinct access rights and lifecycle governance.
Logging needs to answer more than which account authenticated. For consequential workflows, security teams should seek enough telemetry to determine the initiating user or process, the agent or workload involved, the resources accessed, and the resulting action. Without adequate attribution, incident response becomes significantly harder once humans and software can both initiate business actions.
Vendor risk programs should account for meaningful changes to deployed products rather than relying entirely on the initial questionnaire and periodic reassessment. AI governance therefore becomes part of ongoing third-party technology governance, not a separate exercise.
Security, IT, procurement, risk teams, and business owners all have legitimate responsibilities here. The practical challenge is defining who detects a capability change, who determines whether reassessment is necessary, and who owns the resulting risk decision. Without that clarity, material changes can fall between existing organizational processes.
Policies matter, but policy alone cannot determine what an agent accessed yesterday or stop an automated workflow from receiving excessive permissions tomorrow. Governance ultimately becomes real through technology controls.
Identity and access management determines what human and machine identities can access. Security monitoring and SIEM capabilities help teams understand activity across the environment. Data protection controls influence what information applications can reach. Continuous compliance and governance processes help identify when conditions move outside approved parameters. Infrastructure and operational visibility provide the telemetry necessary to compare intended behavior with real behavior. That makes agentic AI governance an infrastructure and cybersecurity problem as much as it is a policy problem.
The enterprise may have an excellent AI policy, but if teams cannot identify agent activity, understand permissions, inspect relevant logs or determine where sensitive data can flow, enforcing that policy becomes difficult. This is also why existing security disciplines should not be discarded in favor of an entirely separate “AI security” stack. Many of the core principles remain familiar.
Zero Trust. Least privilege. Strong identity. Visibility. Monitoring. Data governance. Risk based controls. The challenge is applying these disciplines to a technology environment in which software itself may increasingly participate in decisions and actions.
For the cybersecurity specialists at Island Networks, preparing for agentic AI is not about treating AI governance as an isolated technology project. The more useful starting point is examining the environment holistically. Where does identity live? How is access controlled? What security telemetry exists? Where are the visibility gaps? How are vendor risks reviewed? Which systems contain sensitive data? How are changes monitored? And how does the infrastructure supporting AI connect with the organization’s broader cybersecurity architecture? These questions connect directly to areas Island Networks already addresses across cybersecurity, Governance, Risk & Compliance, Identity & Access Management, security monitoring and visibility, continuous compliance, and enterprise infrastructure.
As organizations integrate generative and agentic technologies into existing environments, those disciplines become increasingly interconnected. Rather than simply adding another isolated AI security product, enterprises should evaluate whether the underlying technology environment provides the identity, visibility, access controls, monitoring, and governance necessary to support AI securely. The objective is not to create friction around every new capability. We want to make sure that when capabilities change, the organization can see the change, understand the resulting exposure and respond proportionately.
Agentic AI exposes a weakness in an assumption that has existed far beyond AI: software approval can behave like a permanent designation even though the technology itself continues to change. That assumption is becoming harder to sustain. The important question is no longer simply:
Is this application approved?
Organizations increasingly need to ask:
Is what this application can do today still within the risk boundaries we originally approved?
Answering that question does not require slowing AI adoption. It requires a stronger operating model around it: clearer identity, least privilege, security visibility, meaningful telemetry, risk based reassessment, and governance processes capable of responding when technology materially changes. That is how enterprises can move from point in time approval toward continuous trust validation. Ultimately, that is what confident AI adoption should look like: not assuming trusted technology will remain unchanged, but building an environment capable of recognizing when trust needs to be validated again.