Governing Shadow AI: 5 Takeaways from Our Webinar with Atlassian

“Honestly, we don’t know.”

This was the leading response when attendees at our Governing Shadow AI webinar were asked where their organization’s biggest Shadow AI exposure was.

The response captures one of the biggest challenges with Shadow AI.

An organization may have an AI policy, approved tools, and security controls in place and still lack visibility into which AI tools employees are actually using, what data is being shared with them, and what AI agents can access or do.

The visibility gap becomes more important as AI moves beyond chatbots. AI agents can read data, trigger workflows, connect systems, and take actions. Governance therefore has to go beyond deciding which tools are allowed. Organizations also need to understand what AI can access, what it can do, and whether those actions can be traced.

On September 9, BuzzClan’s Abhi Garg sat down with Gary Pentecost of Atlassian to discuss how Shadow AI is changing enterprise risk and what organizations can do to bring AI use under greater visibility and control.

From why blocking AI is not enough to what happens when an auditor asks for evidence, the conversation focused on the practical questions organizations are facing as AI adoption expands.

Here are five key takeaways from the discussion.

Takeaway 1: Shadow AI Is Not Just Shadow IT with a New Name

The behavior behind Shadow AI is familiar. Someone finds a tool that helps them work faster and starts using it before IT has formally approved it.

The risk, however, has changed.

As Gary explained during the webinar, Shadow IT was largely concerned with where organizational data was sitting. Shadow AI introduces another question: Where is the data going, and what happens once it gets there?

Consider an employee who pastes a case file, student record, source code, or other sensitive information into a public AI tool. The concern is no longer limited to an unauthorized application. Organizational data has entered an AI system that IT may have limited visibility into or control over.

AI agents add another layer. They can read data, trigger workflows, connect to other systems, and take actions. Organizations therefore need visibility not only into which AI tools are being used, but also into what those tools can access and what they are allowed to do.

The security foundation remains familiar: discover sensitive data, classify it, and control how it moves. Shadow AI expands the scope of where those controls need to apply.

Takeaway 2: Blocking AI at the Firewall Isn’t Enough

Blocking access to a known AI service can reduce one source of exposure, but it does not provide control over the broader ways AI enters and operates within an organization.

AI can be accessed through browsers, APIs, personal devices, mobile networks, and features added to applications the organization has already approved. Restricting one public chatbot does not necessarily tell IT where else AI is being used or what organizational data is reaching it.

There is also a practical problem with relying on bans: the need that drove people to AI in the first place does not disappear.

During the webinar, Gary used education as an example. If employees are using AI to draft emails or lesson plans because it saves time, removing the tool without providing a practical alternative can push the same activity outside IT’s visibility.

A stronger approach is to provide a sanctioned path employees can realistically use while establishing boundaries around the data and actions available to AI.

The governance questions then become:

• What data can AI access?
• What actions can it take?
• Who is allowed to use it?
• Can the organization trace what happened?

A firewall can be part of the control strategy. It cannot provide the visibility, access controls, and auditability required to govern AI on its own.

Takeaway 3: Shadow AI Risk Goes Beyond Business Users

Shadow AI is easy to associate with employees using public chatbots for emails, research, or other routine tasks. But some of the more consequential exposure can happen much deeper inside the technology environment.

Developers routinely work with source code, credentials, infrastructure configurations, production logs, and other sensitive technical data. Using an unapproved AI tool to debug a stack trace or review private code can expose information with implications far beyond an individual productivity task.

Developers can also create AI systems, not just use them. They may connect agents to applications, pipelines, APIs, and live data, giving AI the ability to interact directly with enterprise systems.

The stakes become even higher in regulated environments. The webinar discussed organizations operating under requirements such as FedRAMP, CJIS, and FERPA, where AI interactions involving criminal justice information, student records, or other protected data can create serious compliance and audit concerns.

The answer is not to keep developers away from AI. Gary emphasized providing approved AI tools, defining what agents can access and do, and maintaining records of their activity.

Abhi shared an example from a tier-one banking engagement where AI-assisted QA and testing reduced the testing cycle from 12 team days to one. The example reinforces an important point: stronger governance does not have to come at the expense of AI-driven productivity.

Takeaway 4: If You Can’t Prove It, You Haven’t Governed It

Knowing that employees use AI is not enough. Organizations need to be able to understand what happened when an AI interaction becomes an incident, compliance concern, or audit question.

As Abhi put it during the webinar, “Visibility has to come before enforcement because you cannot govern what you cannot see.”

In practice, visibility needs to connect with controls. Organizations need to know which AI tools and agents are being used, who has access to them, what data they can reach, and what actions they are allowed to take. Risk-based policies can then determine which tools are approved, restricted to controlled environments, or prohibited.

But governance also needs to leave evidence behind.

An organization should be able to trace which AI actions ran, who initiated them, what data was involved, and what controls were applied.

The webinar illustrated this with an engineer debugging a production issue using a log containing citizen data. In the governed scenario, sensitive content had already been classified, an unauthorized export could be blocked, sensitive fields could be redacted when using the sanctioned assistant, and those actions could be recorded in an audit log.

The important difference is not only whether the control worked. The organization can demonstrate that it worked.

Traceability cannot be reconstructed after an incident. The records, controls, and visibility needed to answer an auditor’s questions have to exist before something goes wrong.

Takeaway 5: AI Governance Does Not Have to Start Big

AI governance can sound like a major transformation initiative, but organizations do not need to solve every governance challenge before they can make meaningful progress.

During the webinar, Abhi recommended starting with an AI audit to understand how AI is already being used across the organization. From there, teams can identify which tools should be approved, create controlled environments where employees can experiment safely, and provide clear guidance on responsible use.

Gary brought the data side into the discussion. Before organizations can decide what AI should be allowed to access, they need visibility into where sensitive information already exists and how it is classified and protected.

Together, these ideas point to a practical starting point: understand how AI is already being used and where sensitive data may be exposed. Organizations can then introduce approved tools and controlled environments for experimentation, adding stronger controls as AI use expands.

The level of governance should also reflect what AI is being asked to do. Using AI to help draft or summarize content creates a different risk profile from deploying an agent that can access enterprise systems, move information, or trigger workflows.

Organizations do not need to build the entire governance model on day one. They need enough visibility and control to support the AI use they have today, with a clear way to strengthen those controls as AI takes on greater access and responsibility.

Conclusion: Shadow AI Governance Starts with Visibility

Shadow AI becomes difficult to govern when organizations cannot see where AI is being used, what information it can access, or what actions it can take.

As AI moves beyond individual productivity tools and becomes connected to enterprise data, systems, and workflows, governance has to evolve with it. Organizations need visibility into AI activity, clear boundaries around data and access, and records that show what happened when AI takes an action.

The webinar also reinforced an important point about accountability. Organizations remain responsible for how their data is accessed, protected, and used. Technology platforms and implementation partners can provide the controls and evidence needed to manage that responsibility, but accountability ultimately remains with the organization.

The goal is not to keep AI outside the organization. It is to make AI visible, controlled, and accountable enough to use with confidence.

Frequently Asked Questions